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/

These challenges are expected because of the security protections in place on FusionAuth Cloud deployments. One option is indeed to self-host FusionAuth, which gives you full control over rate limits and CAPTCHA settings.

Alternatively, you could add your IP address to FusionAuth’s allowlist, which can exempt you from certain rate limits and CAPTCHA checks. Details on this approach and the requirements are documented here:
CAPTCHA and Rate Limits - FusionAuth Cloud

Custom domains are available for Basic Cloud deployments. However, this feature relies on a newer backend infrastructure that we’ve recently rolled out. It sounds like your current deployment is on our legacy infrastructure, which does not support custom domains.

We’d be happy to help you migrate your deployment to the new infrastructure so you can enable custom domains. Please note that this migration would involve 30 to 60 minutes of downtime to complete the transition. Let us know if you’d like to proceed!

There are a few approaches and tools you can consider to streamline this migration process:

Database Migration Tools:
Tools like pgloader can help automate the migration of your MySQL database to PostgreSQL. Be aware that direct database migration carries risks. Corrupt or incomplete data may not surface immediately, and issues could arise months later. To mitigate this, test the migration extensively and consider working with third-party experts if needed. API-Driven Migration:
While using API calls for migration can be time-consuming, it ensures the data integrity FusionAuth requires. Automating this process with scripts and batching requests may help speed up the operation. Terraform for Configuration Migration:
Terraform can simplify the configuration migration process by treating your infrastructure as code. This approach allows you to standardize and automate the setup of configurations in your new FusionAuth Cloud environment. It’s especially useful for managing tenants, applications, and other configurations consistently.

Important Note:
If you choose to use a database migration tool, proceed with caution:

Verify the migrated data thoroughly to ensure it matches FusionAuth’s schema and expectations. FusionAuth cannot provide support for issues caused by manual database manipulation or corruption.

Combining API-driven data migration for sensitive information with Terraform for configuration and a reliable database migration tool can significantly reduce the time and effort required for this migration.

There are a few approaches and tools you can consider to streamline this migration process:

Database Migration Tools:
Tools like pgloader can help automate the migration of your MySQL database to PostgreSQL. Be aware that direct database migration carries risks. Corrupt or incomplete data may not surface immediately, and issues could arise months later. To mitigate this, test the migration extensively and consider working with third-party experts if needed. API-Driven Migration:
While using API calls for migration can be time-consuming, it ensures the data integrity FusionAuth requires. Automating this process with scripts and batching requests may help speed up the operation. Terraform for Configuration Migration:
Terraform can simplify the configuration migration process by treating your infrastructure as code. This approach allows you to standardize and automate the setup of configurations in your new FusionAuth Cloud environment. It’s especially useful for managing tenants, applications, and other configurations consistently.

Important Note:
If you choose to use a database migration tool, proceed with caution:

Verify the migrated data thoroughly to ensure it matches FusionAuth’s schema and expectations. FusionAuth cannot provide support for issues caused by manual database manipulation or corruption.

Combining API-driven data migration for sensitive information with Terraform for configuration and a reliable database migration tool can significantly reduce the time and effort required for this migration.

No. Our cloud is a fully managed system, so you shouldn't care about the underlying technology.

It isn't built with Kubernetes so when we launch a deployment in it, it's constructed using a different approach.

If you want to run FusionAuth with kubernetes, that is supported, but you must self-host. More details here: https://fusionauth.io/docs/v1/tech/installation-guide/kubernetes/