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/

Elasticsearch access is not available for FusionAuth cloud deployments.

I would recommend running FusionAuth locally, which should display similar results as your cloud deployment for how the user and the entities are mapped.

Our HA cloud offerings, outlined on fusionauth.io/pricing are aimed at the following use cases:

Large production needs Reliability required Higher monthly active users

Development doesn't typically fall into any of these :).

With HA you get an SLA, a custom URL (auth.example.com instead of example.fusionauth.io) and an architecture capable of handling more users.

You might want a custom URL to test your DNS/cookie config. Or you might want to load test (please don't load test with a basic cloud deployment, it won't tell you anything about production performanc).

If you want to derisk this early, in both these cases, we recommend standing up a temporary HA instance, applying your configuration, testing, and then tearing down the HA instance.

Hmmm.

The FusionAuth basic tier is not intended for any type of load testing. So that probably explains poor results.

The reason for this is that the service (with this tier) is running on a single AWS EC2 instance that is running FusionAuth, Elasticsearch and a PostgreSQL database. This means the node is very resource constrained, and attempting to run load tests on this type of system is not recommended. The numbers you get from this type of test will not be valuable to you in context of planning your production deployment.

If you do want to perform load testing, I would recommend you run FusionAuth on-premise using a more realistic production configuration, or upgrade to the High Availability hosting tier. You can spin up an HA instance, perform your load testing, and then tear it down. You'll only be charged for the time the HA instance is up and running.

If you cannot achieve your target request per second with a standard HA setup, you can upgrade from Medium, to Large, or even to X-Large if you need to obtain additional requests per second.

You also may be interested in this load testing guidance: https://fusionauth.io/docs/v1/tech/installation-guide/monitor/#load-testing

And this (dated) forum post: https://fusionauth.io/community/forum/topic/8/what-level-of-performance-can-we-expect-with-using-fusionauth-as-an-idp

@garveymozga33 Thanks for your feedback. The basic cloud plan does not currently include backups and is not intended for production use.

With self-hosted FusionAuth, you are downloading the software, starting up a server (VM in the cloud, in your data center, wherever) and running it yourself. You are responsible for monitoring, backups and everything else to keep your FusionAuth instance available to your customers.

With all the cloud options, we run FusionAuth for you. Each level of cloud has a different set of constraints, as outlined in the pricing links (click on the ? for more details), but in general we take care of operating FusionAuth for you. You still control the upgrade cycle, but much of the other maintenance is handled by us.

Generally speaking, the provisioning depends greatly on the infrastructure being requested as well as the current demands placed on the underlying cloud infrastructure provider.

For smaller deployments, you can expect a 5 to 10 minute timeline. For a setup more aligned with a high-volume system with large CPU and database capacities, you can expect a provisioning time of 20 to 45 minutes.