Load testing FusionAuth typically involves using a modern tool like k6 to simulate your expected traffic patterns. Here's the general approach:

Use k6 or other HTTP-capable load testing tools: While k6 is a good modern option, FusionAuth can be load tested with any HTTP-capable load testing tool such as Gatling, JMeter, or Locust. FusionAuth also provides an open source load testing repository with pre-built scenarios including creating tenants and applications, registering users, logging users in via the Login API, and full Authorization Code grant flows.

Profile your traffic: Use your load testing tool to determine what your actual traffic patterns will look like, especially accounting for your spiky demand. This helps you understand the load FusionAuth will need to handle. Look beyond just averages—also check the p95 (95th percentile) response time to understand the experience of your slowest users.

Test in a production-like environment: It's critical to load test against an environment that mirrors your expected production setup. If you're using FusionAuth Cloud, the Basic Cloud tier (single node running FusionAuth, Elasticsearch, and PostgreSQL together) is not representative and not recommended for load testing. Instead, use a Business Cloud or High-Availability plan for meaningful load testing. You can spin up an HA instance, run your tests, and tear it down—you'll only be charged for the time it's running.

Notify FusionAuth if testing on Cloud: If you're load testing on FusionAuth Cloud, open a support ticket to let the team know when you plan to stress test, as they monitor CPU and other metrics.

Monitor the right components: Performance bottlenecks are typically the database or CPU nodes. Both logins and user creation are CPU-intensive due to password hashing. If testing a multi-node system behind a load balancer, disable sticky sessions as they are not required for FusionAuth.

IP allowlisting considerations: If you're using FusionAuth Cloud, you may need to consider IP allowlisting depending on your security configuration. FusionAuth Cloud has protections in place to prevent DoS attacks and keep services running smoothly.

The specific approach can vary based on your exact traffic patterns and requirements, but these are the key components most customers use when load testing FusionAuth.

Related Documentation Load Test Documentation - Comprehensive guide on load testing FusionAuth, including tool recommendations and best practices FusionAuth Load Tests GitHub Repository - Open source load testing scripts with pre-built scenarios Handling Spiky Game Traffic: Registration & Autoscaling Best Practices - Specific guidance for handling spiky traffic patterns during high-demand scenarios FusionAuth Cloud High Availability Architecture - Details on HA deployment options for production-like testing FusionAuth Cloud Security - Information about Cloud security protections and rate limiting Troubleshooting Performance - Guide for troubleshooting performance issues Scaling Your Auth - Best Practices for Performance and Security - General guidance on scaling authentication systems

For FusionAuth Cloud (SaaS) instances, database migrations are automatically applied as part of the upgrade process. You do not need to take any action.

The FusionAuth Cloud team handles all required database migrations when upgrading your hosted instance to a new version. This is managed on your behalf as part of the cloud service. When you initiate an upgrade through your FusionAuth Account dashboard, the migrations run automatically during the upgrade process.

For HA Cloud (multi-node) deployments, nodes are upgraded one at a time. When the first upgraded node connects to the database, it locks the database and runs the required migrations while other nodes continue serving traffic, resulting in only seconds of downtime.

For Basic/Business Cloud (single-node) deployments, the entire instance goes offline during the upgrade, with downtime ranging from 5 to 60 minutes depending on the amount of data and schema changes required.

If you are running a self-hosted FusionAuth instance, you would need to follow the upgrade guide and apply any required out-of-band migrations manually (or configure Silent Mode for automatic migrations). However, for cloud-hosted instances, this is handled automatically by FusionAuth.

Note: You cannot downgrade a FusionAuth Cloud deployment version after upgrading, so it's recommended to test upgrades in a non-production environment first if possible.

Related Documentation FusionAuth Cloud - Upgrading a Deployment - Details on the Cloud upgrade process and downtime expectations Upgrade FusionAuth - Upgrade Options - Overview of different upgrade strategies including HA deployments Out-of-Band Database Upgrades - Information on manual migrations for self-hosted instances Silent Mode - Automatic migration handling for self-hosted deployments

Currently, there is no sorting logic implemented for deployments in the FusionAuth Cloud account portal. The order of deployments is not sorted alphabetically or by any other consistent criteria at this time.

This has been noted as a feature request to add sorting capabilities (or the ability to manually sort) deployments in the account portal. This would help prevent accidental selection of the wrong instance when managing multiple FusionAuth Cloud deployments.

In the meantime, extra care should be taken when selecting deployments from the list to ensure you're working with the correct instance. You can use the Rename feature (available in the Action dropdown menu for each deployment) to give your deployments descriptive names that help distinguish between different products or environments.

Related Documentation Managing Your Deployments - Overview of managing FusionAuth Cloud deployments in the account portal The Account Portal - Documentation on accessing and using the account portal FusionAuth Account Portal Reference - Complete reference for the FusionAuth account portal features

FusionAuth Cloud deployments can provide static outbound IP addresses for email delivery and other outbound connections. The availability and process depend on when your deployment was created.

Getting Static IP Addresses

For new FusionAuth Cloud deployments: Static IP addresses are already configured automatically.

For existing deployments: You need to open a support ticket to get static IP addresses assigned.

How to Request Your Deployment's IP Addresses

To retrieve the specific outbound IP addresses for your deployment (e.g., to allowlist them with your SMTP provider):

Open a support ticket Include the name of the deployment for which you need the outbound IP addresses

Once assigned, these IP addresses will remain static and won't change during upgrades, restarts, or normal operations.

Important Notes About the IP Addresses The provided IP addresses are for outbound traffic only (firewalls, allowlists, SPF records, etc.) — they will not respond to HTTP API calls You should add these IPs to your SPF DNS record for your sending domain to prevent password reset and other transactional emails from landing in spam Multiple IP addresses may be provided for high availability Recommended Approach

If you have both production and development environments:

Request and configure the static IPs for your development instance first Test email delivery with the allowlisted IPs Once verified, request and configure the production deployment's static IPs Related Documentation FusionAuth Cloud - Deployment IP Addresses - Official documentation on obtaining IP addresses for your FusionAuth Cloud deployment Configure SMTP - Complete guide to configuring email delivery in FusionAuth SMTP Best Practices - Recommendations for maintaining good sender reputation including SPF records GitHub Issue #1393 - Original feature request for static IP addresses in FusionAuth Cloud

FusionAuth Cloud can add IP addresses to your instance's allow list if they meet the following criteria:

Static: The IP address must be static and not change without notice. Owned by your organization: The IP must be allocated to your company's infrastructure, not shared with other companies or resources (such as through a CDN). Associated with production servers: The IP must be used by production servers, not developer laptops or office networks.

Once you confirm your IP addresses meet these criteria, open a support ticket through your FusionAuth account portal with:

The list of IP addresses to be added Confirmation that each criterion is met The FusionAuth Cloud hostname your application connects to

FusionAuth will then add the addresses to your allow list. Note that if you use shared network infrastructure (like NAT gateways), all traffic from that infrastructure will share the same outbound IP, which is acceptable as long as the criteria above are met.

Important notes:

Allow list changes typically take two to three business days to implement Adding IPs to the allow list helps prevent 429 response codes and CAPTCHA challenges that may occur due to FusionAuth Cloud's rate limiting protections If you no longer need an IP address on the list, you can submit a support ticket to have it removed Related Documentation FusionAuth Cloud CAPTCHA and Rate Limits - Detailed information about IP allow lists and rate limiting FusionAuth Cloud Support - How to access support for your FusionAuth Cloud deployment FusionAuth Cloud Deployment IP Addresses - Information about IP addresses for your FusionAuth Cloud instances

FusionAuth supports customization for some of these scenarios through themes, but not all:

1. Root Path Customization

This is possible. The Index page can be customized through your FusionAuth theme. You can add a redirect (for example, using JavaScript or a meta refresh tag) to send users to your application's login page.

Important: When FusionAuth can't identify the tenant (including when browsing to / without client_id or tenantId parameters), it uses the default tenant. To theme the root page:

Create a copy of the built-in theme — the default theme is immutable because it ships with FusionAuth Edit the index template in your copy to include your redirect (using JavaScript like window.location.href = "https://yourapp.com/login" or HTML meta refresh) Apply this theme to ALL tenants, including the default tenant Test with tenant specified — try the root URL with tenantId or client_id to confirm your edited theme renders

See the Advanced Themes troubleshooting guide for more details on theme issues.

Related: GitHub Issue #378

2. OAuth Error Handling

This is also possible. The OAuth error page can be customized in your theme, so you can implement the same redirect approach for customers who saved stale or broken login links. The OAuth error template is available for customization and you can add JavaScript or meta refresh redirects to handle these scenarios.

Note that OAuth errors can also be returned as redirect parameters to your application's callback URL (depending on the OAuth flow), which allows your application to handle errors directly rather than showing the FusionAuth-hosted error page.

3. 404 Pages for Invalid URLs

This is NOT currently customizable. The 404 page cannot be customized, including on Cloud deployments. Requests to invalid paths (like /whatever) will show the default error page. This is a known limitation tracked in GitHub Issue #404, which requests additional themed error pages (including 404 and 500 pages).

Summary

You can handle root path and OAuth error redirects through theme customization by adding JavaScript redirects to the index and OAuth error templates. However, true 404 pages remain uncustomizable. CloudFront configuration is not exposed to customers on cloud deployments, so there's no workaround at that layer.

Related Documentation Advanced Themes Documentation - Complete guide to customizing FusionAuth themes Theme Templates - Full list of available templates including Index and OAuth error Theme Template Variables - Variables available in each template Index Template Variables - Specific to the root page OAuth Error Template Variables - Specific to OAuth error page OAuth Error API Documentation - How OAuth errors are returned Default Tenant Configuration - Understanding the default tenant

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:

It is static It is owned by your company (not shared infrastructure like a CDN) 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)

At this time, FusionAuth Cloud does not support customizing HTTP security headers on individual tenant deployments. There is an existing GitHub feature request tracking this capability, but it is not currently on the roadmap and no ETA is available for when this might be added.

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.

When submitting a custom password hasher plugin (or any plugin JAR) for installation on FusionAuth Cloud, you should:

Open a support ticket through the account portal as normal (text-only is fine) Reply to the ticket conversation in Slack with the plugin JAR file attached

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.

Installation considerations

When requesting plugin installation, be sure to specify:

Which specific Cloud deployments/tenants need the plugin installed Whether users are actively logging in (there may be 1-2 minutes of downtime during deployment) Your preferred time window for the installation if downtime is a concern Any considerations for dev/test environments if you have ongoing testing

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

For FusionAuth Cloud deployments, you can obtain the outbound IP address list by opening a support ticket in the FusionAuth Account Portal and providing your deployment hostname.

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:

Upgrades Maintenance windows Normal scaling operations

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:

SMTP/email traffic Webhooks HTTP calls from Lambdas Any other outbound connections

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.

Related Documentation Deployment IP Addresses - Official documentation on obtaining IP addresses for FusionAuth Cloud deployments FusionAuth Account Portal - Support - How to access the support portal to request IP addresses FusionAuth Cloud Overview - General information about FusionAuth Cloud deployments

Yes, FusionAuth Cloud uses static outbound IP addresses that you can whitelist in your downstream services. The specific IPs depend on your deployment's region.

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:

New deployments receive static outbound IPs by default. If you have an existing deployment created before static IPs were standard, you may need to request them via support ticket. The provided IP addresses are intended only for allow-listing outbound traffic (such as SMTP services, webhooks, LDAP connectors, etc.). These IPs should not be used to make inbound API calls, as they won't respond to such requests. Static IPs are available for all FusionAuth Cloud deployments, including both standard and High Availability (HA) configurations. Related Documentation FusionAuth Cloud - Deployment IP Addresses - Official documentation on obtaining IP addresses for your deployment FusionAuth Cloud - Support - How to access support and open tickets for IP address requests FusionAuth Cloud Overview - General information about FusionAuth Cloud hosting

No, you cannot configure the same custom domain on two different FusionAuth Cloud deployments at the same time.

The recommended migration sequence is:

Remove the custom domain from the production deployment Configure the custom domain on the dev deployment Configure a CNAME record pointing your custom domain directly to the dev deployment's durable hostname Validate the certificate for the domain on the dev deployment Important Considerations

DNS Propagation Time

DNS changes take time to propagate Expect up to 30 minutes for DNS servers to recognize the changes Propagation may take longer depending on your DNS TTL settings Plan for this downtime window during your migration

Certificate Validation

Certificate validation uses DNS-based methods You must complete the DNS configuration before certificate validation can succeed

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

To resolve this CloudFront conflict, you need to disassociate your custom domain from your CloudFront distribution.

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

Remove the custom domain from your CloudFront distribution — This allows FusionAuth to add the domain to their CloudFront distribution Set up your CloudFront as a proxy — Configure your distribution to proxy requests to FusionAuth's infrastructure

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.

How FusionAuth Custom Domains Work

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:

Custom domain → CNAME → FusionAuth durable URL

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

Related Documentation FusionAuth Cloud Custom Domains - Official guide for setting up custom domains on FusionAuth Cloud Adding a Custom Domain - Step-by-step walkthrough of the custom domain configuration process How to set up a Custom Domain for FusionAuth using AWS CloudFront - Guide for self-hosted FusionAuth installations (note: this is for self-hosted, not FusionAuth Cloud)

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.

Rollback Process for FusionAuth Cloud

For FusionAuth Cloud deployments, the rollback process must be handled by FusionAuth support—it is not something you can perform yourself.

Plan Eligibility and Backup Retention Business and High Availability (HA) Deployments: Upgrade backups are retained and available for 30 days Basic Deployments: Backups are not included, so rollbacks cannot be performed How to Request a Rollback

If you identify an issue after performing the upgrade:

Open a support ticket with FusionAuth The support team will perform the complete database rollback for you Expected Downtime

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

Database size How quickly the operations team can complete the rollback

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

Support During Upgrades

For production upgrades, FusionAuth can provide:

An engineer on standby during your scheduled upgrade window An on-call support number for emergency assistance Pre-Upgrade Best Practices

Before upgrading to 1.69.1:

Review Release Notes for breaking changes, database migrations, and API modifications Choose an Upgrade Strategy: Incremental (version-by-version) for lower risk Direct upgrade for speed (but requires thorough testing) Test in Staging to verify: Authentication flows, webhooks, and APIs function correctly Templates render properly Database migrations complete successfully Coordinate with Support to schedule the upgrade and have assistance available if needed

You’re correct—there is no fixed limit on the number of hosted FusionAuth instances you can have.
However, since your account is on invoiced billing, new hosted deployments cannot be created directly through the Account Portal. That functionality is only available for self-serve billing accounts.

Next Steps

Our Customer Success team will reach out to you via email. They’ll help provision the additional non-production instances and add them to your existing order.

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

Currently your deployments do support custom domains and yes this would be compatible with PKCE. You can have something like auth.mycompany.com provisioned and a user can bookmark this type of URL. In fact, I believe that your company already has a few of these types of URLs configured. So your customers would have to bookmark the full login path (something like http://auth.mycompany.com...authorize?client_id....redirect_uir...response_mode) and then they can login to the OAuth2 page that FusionAuth is hosting for login.

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.

To upgrade the FusionAuth deployment, you just need to visit account.fusionauth.io and go to the Hosting tab. From there, each deployment has a drop down button where you can select Upgrade. From there you can upgrade version by version or leapfrog to the latest version, we always recommend testing out the upgrade on dev before rolling it out to production. For your dev instances, there will be downtime of up to 60 minutes but usually I see it takes 20-30 minutes. For production we do a rolling node upgrade since it's a multi-node instance, therefore it should not have much downtime at all(seconds) as traffic just gets routed to nodes 2 & 3 while node 1 is getting upgraded.

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

Yes—you can safely add a fourth custom URL. The “replace” label appears because the system expects you to submit the entire list of domains each time. To avoid losing any URLs, make sure all four domains—including your existing three—are entered in the form before you submit. Only custom domains omitted from the list will be removed.

More details here:
Updating Custom Domains

Data transfers between FusionAuth deployments aren’t typically included as a standard service, except in cases where a business is scaling up to a larger deployment. However, since this is a new production setup, we can accommodate a one-time migration for you. The process would result in about 10 minutes of downtime.

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.

For Business hosting, FusionAuth creates daily database snapshots around midnight Mountain Time. Three days’ worth of backups are kept. Additionally, a snapshot is taken before any FusionAuth software upgrade and retained for 30 days. Direct database access isn’t available on hosted deployments, so you can’t create traditional database backups yourself. However, most user and configuration data can be retrieved via the FusionAuth API. Some sensitive data, like password hashes or one-time codes (MFA, email verification, magic links), cannot be extracted. Yes — upgrades from Basic to Business or Business to High Availability are possible. A FusionAuth support team member coordinates the process, which typically takes 60–90 minutes and may involve up to 45 minutes of downtime. New deployments use our updated infrastructure, which offers additional features. Downgrading FusionAuth is technically possible but complex and rare. It requires manual intervention by FusionAuth support and can involve significant effort. Downgrades requested within 30 days of an upgrade are simpler and involve less disruption, but the exact downtime is difficult to estimate. Yes — Basic hosting now supports a single custom domain on the new infrastructure. We can help migrate your deployment to the newer model, enabling you to add a custom domain for easier integration. Yes — it’s possible to change your current hosted URL when migrating to the new infrastructure.

More details on hosting plans and capabilities are available here: https://fusionauth.io/docs/get-started/run-in-the-cloud/