The Helm chart for FusionAuth 1.53.4 has been released and should now be available in the FusionAuth charts repository.

In the meantime, if you need to deploy a specific FusionAuth version before the corresponding Helm chart is released, you can override the image tag in your Helm values file:

image:
  tag: "1.53.4"

This allows you to use the latest Helm chart while specifying the exact FusionAuth Docker image version you need.

Related Documentation

• Deploy with Kubernetes - Helm Chart Configuration - Complete guide on configuring and deploying FusionAuth using Helm charts
• Deploy FusionAuth to the Cluster - Instructions for installing and verifying your Helm deployment
• Kubernetes Overview - Overview of FusionAuth on Kubernetes with architecture diagrams
• Upgrade FusionAuth - General guidance on upgrading FusionAuth installations

When you override the image tag in your values.yaml file, you can verify the correct version is deployed by checking the IMAGES column in your Kubernetes deployment:

kubectl get deployments -o wide

I'm looking to upgrade to FusionAuth 1.53.4 using Helm, but I don't see a corresponding chart version in the FusionAuth charts repository.

Is a Helm chart release for version 1.53.4 expected soon? I'd like to deploy this version today.

I understand I can specify the Docker image version directly in the Helm values, but I typically track helm chart version == image version for FusionAuth deployments.

The rate limiting you're encountering is applied at the WAF (Web Application Firewall) level on FusionAuth Cloud, not from the FusionAuth application itself. These rate limits protect customers and are standard across all FusionAuth Cloud deployments.

Rate Limit Configuration

FusionAuth does not publish rate limits publicly and they are subject to change.

Please open a support ticket to obtain more guidance.

Whitelisting for Performance Testing

Since these are network-level rate limits, they cannot be configured within your deployment. However, IP allow listing is available to bypass rate limiting for performance testing if your IP address meets these requirements:

1. It is static
2. It is owned by your company (not shared infrastructure like a CDN)
3. It is associated with a production server (not a developer's laptop)

If you can provide a static IP address that meets these criteria, you can open a support ticket to get it allow listed. Note that allow list changes typically take two to three business days to implement.

Best Practices for Performance Testing

When planning load or performance tests against FusionAuth Cloud:

• Open a support ticket before testing to notify the FusionAuth team of your planned stress test window
• Don't use Basic cloud deployments for performance testing, as they run on limited infrastructure and results won't be representative. Use a Business or High-Availability plan instead, which you can spin up, test, and tear down as needed
• Implement exponential backoff when you receive a 429 response - this is the recommended approach for handling rate limits gracefully
• Distribute requests over time rather than sending bursts of traffic

Alternative Testing Approaches

If you cannot obtain an allow-listable static IP address (such as for developer machines or CI/CD pipelines), consider:

• Running a self-hosted FusionAuth instance for automated testing, which gives you full control over rate limiting configuration
• Using smaller-scale testing that stays under the rate limits

Related Documentation

• FusionAuth Cloud - CAPTCHA and Rate Limits
• FusionAuth Cloud - Load Testing
• Troubleshooting FusionAuth Cloud API Calls
• User Search API Documentation
• Advanced Threat Detection - Customizable Rate Limiting (for application-level rate limits within FusionAuth)

We are encountering a large number of HTTP 429 (Too Many Requests) errors during performance testing against our FusionAuth Cloud environment.

Error Message:

[FusionAuthCloudRateLimitedException]: Your request has been rate limited. Please reduce the number of requests or wait a period of time before making the next HTTP request.

We have run similar performance tests in the past without encountering this issue. We need to understand:

1. What are the current rate limits configured for FusionAuth Cloud environments?
2. Are these limits applied per API endpoint, tenant, application, IP address, or across the entire environment?
3. Can these rate limits be increased to support our performance testing and expected production traffic volumes?
4. What are the recommended best practices for handling higher request volumes without triggering HTTP 429 errors?

The postMethod variable can be null or missing in certain scenarios (such as when a verification link is clicked multiple times), causing the FreeMarker template to fail.

To fix this, you need to provide a safe fallback for the postMethod variable. Update line 16 in your registration/verify.ftl template from:

[#if verificationId?? && postMethod]

To:

[#if verificationId?? && (postMethod!false)]

The !false syntax provides a default value of false when postMethod is null or missing, preventing the FreeMarker exception.

Steps to apply the fix:

1. Navigate to Customizations → Themes in the FusionAuth admin UI
2. Edit your theme
3. Locate the registration/verify.ftl template
4. Update the conditional check as shown above
5. Save the theme

This pattern can be applied to other templates where variables might be null or missing in certain execution paths.

Why this happens:

According to the FusionAuth documentation, the postMethod variable is not a standard template-specific variable for the /registration/verify template. It is typically available on other verification templates like /email/verify (where it defaults to true). The registration verify template is rendered when a user clicks the URL from the verification email and the verificationId has expired or is invalid. In these scenarios, postMethod may not be set in the template context, which causes the FreeMarker error when attempting to evaluate it as a boolean.

Related Documentation

• Theme Template Variables - Verify Registration - Documents the variables available in the registration verify template
• Theme Template Variables - Email Verification - Shows that postMethod is documented for email verification but not registration verification
• Theme Template Variables - Complete reference for all template variables across different templates

I'm encountering a FreeMarker template error when users click a verification link, specifically on the registration verify page. The error indicates that the postMethod variable is evaluating to null:

FreeMarker template error:
The following has evaluated to null or missing:
==> postMethod  [in template "registration/verify.ftl" at line 16, column 30]

The problematic line in my registration/verify.ftl template is:

[#if verificationId?? && postMethod]

This error seems to occur when the verification link is clicked a second time. The stack trace shows:

freemarker.core.InvalidReferenceException
  at freemarker.core.NonBooleanException.<init>
  at freemarker.core.Expression.modelToBoolean
  at freemarker.core.AndExpression.evalToBoolean
  at freemarker.core.IfBlock.accept

Is there a recommended way to handle this variable safely in the template to prevent this error?

This issue was caused by a bug that existed prior to version 1.68.0. In earlier versions, there was a problem where LDAP connectors scoped to specific domains could incorrectly be called (or not called) for users outside those domains. This could result in the connector appearing to stop functioning entirely after an upgrade.

Solution:

Recreate the LDAP connector configuration. When doing so, verify the Domains field:

• If you need the connector to apply to all users, use a wildcard (*) for the domains.
• If you need domain-specific scoping, explicitly configure the same domains you had previously.

This bug was fixed in FusionAuth 1.68.0. See the release notes for details:

Fixed an issue where Connectors configured for a specific domain in a Tenant could be called for users outside of that domain.

If you encounter this issue after upgrading to 1.68.0 or later and recreating the connector does not resolve it, verify:

1. Debug mode is enabled for both the connector and the reconcile lambda.
2. The LDAP server is reachable from the FusionAuth instance.
3. Event log and system log (fusionauth-app.log) for any connection or authentication errors.

After upgrading FusionAuth to 1.69.2, the LDAP connector and reconcile lambda stopped working entirely. Users cannot authenticate unless they have a local FusionAuth account, and no LDAP-related activity appears in the event log — no reconcile attempts, no communication with the LDAP server.

Debug mode is enabled for both the connector and the lambda, but still no log entries are generated when users attempt to log in. It appears FusionAuth is not honoring or applying the connector configuration at all.

The issue was temporarily resolved by deleting and recreating the LDAP connector, but the root cause was unclear at the time.

The user.login.suspicious webhook event requires the Client Risk Configuration to be enabled at the tenant level. Even though Risk Signals are evaluated by default, the webhook event itself won't fire unless this configuration is explicitly turned on.

To enable it:

1. Navigate to Tenants → Select your tenant → Edit → Security tab
2. Find the Client Risk Configuration section
3. Ensure it's enabled for your tenant

Additionally, verify that the user.login.suspicious event is enabled in the tenant's webhook settings:

1. Go to Tenants → Select your tenant → Edit → Webhooks tab
2. Confirm user.login.suspicious is checked/enabled

Once both are configured, your webhook should start receiving user.login.suspicious events along with details about which Risk Signals triggered the suspicious login determination.

About Risk Signals and Email Volume

If you're seeing a significant increase in suspicious login emails after upgrading to 1.68.0 or later, this is because FusionAuth introduced comprehensive Risk Signals in version 1.68.0. Previously, only Impossible Travel was tracked. Now additional signals are evaluated including:

• Untrusted Device
• Unrecognized Device
• Recent Password Change
• Recent Identity Change
• Dormant Password
• Suspicious Agent

All Risk Signals are enabled by default without any configuration changes.

Managing Email Volume

You can tune which Risk Signals trigger suspicious login alerts:

1. Go to Tenants → Select tenant → Edit → Security tab → Client Risk Configuration
2. Disable specific Risk Signals that are generating too many false positives for your use case

Monitoring Without Sending Emails

You can monitor webhook events while tuning your Risk Signals without sending emails to users:

1. Go to your tenant/application settings → Identities tab
2. Change the Suspicious Login template to "No Template Selected"
3. Monitor your webhook endpoint to see which Risk Signals are triggering
4. Fine-tune your Risk Signal configuration
5. Re-enable the email template once you're satisfied with the detection accuracy

The webhook fires whenever a Risk Signal threshold is met, independent of whether an email template is configured. This allows you to observe and tune the system before alerting end users.

After upgrading FusionAuth, we're seeing suspicious login emails being sent to end users, but we're not receiving user.login.suspicious webhook events in our webhook logs. We've confirmed:

• The webhook has user.login.suspicious set to true in eventsEnabled
• The webhook is scoped to the specific tenant where logins are occurring
• Other webhook events (like user.action, user.password.reset.success, etc.) are working correctly
• Reactor license is activated
• Users are definitely receiving suspicious login emails, confirming the events are being triggered

Our webhook configuration shows:

{
  "eventsEnabled": {
    "user.login.suspicious": true,
    // ... other events
  },
  "tenantIds": ["<your-tenant-id>"],
  "global": false
}

What configuration might we be missing to receive these webhook events?