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

Please open a support ticket to obtain more guidance.

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:

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.

When planning load or performance tests against FusionAuth Cloud:

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

If you are running a self-hosted FusionAuth instance, you can configure these headers using a reverse proxy (nginx, Apache, etc.) in front of FusionAuth. For FusionAuth Cloud customers, this configuration is managed at the infrastructure level and cannot be modified per-tenant.

You may want to subscribe to or comment on the relevant GitHub issue to track progress on this feature request.

The account portal does not accept file attachments during ticket creation, but replying via Slack to an open ticket thread allows you to send files directly to the support team.

Note: Some file-sharing platforms (like Slack) may block .jar files for security reasons. If this happens, you can zip the JAR file first and attach the .zip instead.

When requesting plugin installation, be sure to specify:

The support team will handle uploading and rolling the deployment with the new plugin.

Key facts about FusionAuth Cloud outbound IPs:

Complete list: FusionAuth will provide the complete list of outbound IP addresses for your specific deployment. These are the only addresses your deployment will use. Note that IP addresses are not exposed through the user interface—opening a support ticket is the only way to obtain them.

Static addresses: The outbound IP addresses are static and will not change during:

For new FusionAuth Cloud deployments, static IP addresses are already configured. If the IP addresses ever need to change, FusionAuth will notify you in advance.

All outbound traffic: All outbound traffic from your FusionAuth Cloud deployment originates from the same set of IP addresses, including:

You can safely use these IP addresses to configure firewall rules, SMTP server allowlists, and other security restrictions for services that need to accept connections from your FusionAuth Cloud deployment.

Important: The provided IP addresses should only be used to allow outbound traffic through firewalls and network control layers. Do not use them for HTTP/API calls, as they won't respond to such requests. In addition to IP allowlisting, consider using custom headers, TLS transport, and client certificates to further secure outbound traffic.

These IP addresses are static and will not change under normal circumstances. If FusionAuth ever needs to modify or add to these addresses, customers will receive advance notification.

To obtain the specific outbound IPs for your region, you'll need to open a support ticket through the FusionAuth Account portal with your deployment name and details.

Important Notes:

The recommended migration sequence is:

DNS Propagation Time

Certificate Validation

To minimize downtime, prepare all configurations on the dev deployment beforehand, then execute the domain removal, DNS update, and certificate validation in quick succession.

Since AWS only allows one CloudFront distribution per hostname, and FusionAuth Cloud is implementing CloudFront on their infrastructure, you have two options:

The recommended approach is to remove your custom domain from your CloudFront distribution entirely, as FusionAuth will handle CloudFront configuration as part of their cloud service.

When you configure a custom domain with FusionAuth Cloud, you create a CNAME record pointing from your custom domain to your deployment's durable URL (something like <random-string>.durable.fusionauth.dev). FusionAuth manages the CloudFront distribution and SSL certificates on their infrastructure, so you don't need to maintain your own CloudFront distribution for the custom domain.

The proper DNS setup should be:

This allows FusionAuth to provision and manage the entire CloudFront infrastructure, including SSL certificate validation and renewal, as part of their cloud service.

Note: If you're on a High Availability plan and want to use the Unlimited Custom Domains feature, or if you need assistance with the migration, open a support ticket.

If you identify an issue after performing the upgrade:

The rollback operation typically takes 20 minutes to 2 hours, depending on:

Note that this involves a complete database rollback, so plan for 1-2 hours of downtime.

For production upgrades, FusionAuth can provide:

Before upgrading to 1.69.1:

Next Steps

Once that’s complete, you’ll have access to the new hosted deployments without needing to manage them through the portal yourself.

The real issue that you have here is related to PKCE.

Your app landing page is generating a PKCE challenge and PKCE verifier.

Your integration is then using these values to call the authorize endpoint uniquely each time

If a user bookmarks the values/URLs from step two above, they will have issues logging in (due to a PKCE failure)

All of this is in alignment with the OAuth Specification (the PKCE values should be unique each time that the authorize endpoint is called). The next question then becomes prevention of a user bookmarking the wrong link. To my mind, you could add some information to a customer portal or land page letting the customer know the correct page to bookmark. If the login fails, you may be able to redirect the user to the correct page (your page sees the failure and then determines the login landing page to send the user to) to login as well to recover the customer experience (in the case where the user have bookmarked the wrong link).

The alternative is to not to use PKCE, which introduces security considerations, especially if you are building on mobile.

As far as rollbacks and backups, we keep snapshots of the database for your production deployment since its High Availability. Your dev and staging instances do not have backups since they are Basic Cloud. If you want to enable backups and rollbacks, you would need to move the Dev or Staging instance to the next tier of hosting, Business Cloud. For production, we will take a snapshot of the database every time right before you upgrade. These backups are available for up to 30 days. Then we also have 3 days of general rolling backups for your production that we can rollback to. Rolling back is a manual process from our end so that's something you have to contact us to initiate. Something to keep in mind is that it's a complete database rollback, so any logging or changes made since the snapshot will be lost so there is data loss with these rollbacks.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#upgrading-a-deployment

More details here:
Updating Custom Domains

Make sure you have a master API key on hand, as certain settings—like SMTP configurations—might need to be updated manually after the transfer. Alternatively, you’re welcome to migrate the configuration manually if you prefer.