FusionAuth Cloud is an entirely managed FusionAuth instance in the cloud. As the owner of that server, you have complete access to the administrative user interface and can create API keys and manage the instance via client libraries or APIs. But you have no access to the servers or networks where the instance runs.
With FusionAuth Cloud, you create "deployments". A deployment is a FusionAuth instance, a database, a search application, and all the necessary networking configuration to connect your FusionAuth deployment to the internet.
You can create as many deployments as you want and tear them down when you do not need them. You pay only for the time each deployment is running.
Every deployment is separated, both logically and physically, from every other deployment. There is no network path between deployments except over the internet. There is no shared database or other storage infrastructure.
Why Use FusionAuth Cloud
FusionAuth Cloud is a fully managed service which can be used for many use cases. Among them:
Proof of concepts
Testing new versions without affecting prod
High availability production environments
With FusionAuth Cloud, spin up a functioning FusionAuth instance in minutes. This allows you to get to work testing or integrating with FusionAuth, rather than installing or configuring it. FusionAuth Cloud is protected by world class security measures and DDoS protections.
If you want to use FusionAuth and hand all the management burden to the team who built it, FusionAuth Cloud is a good choice.
What Does FusionAuth Cloud Cost
Unlike other installation options, FusionAuth Cloud costs money. You cannot create a FusionAuth Cloud deployment without a credit card or invoicing agreement.
For full pricing information as well as different deployment architectures, visit the pricing page.
You can also find the expected cost without creating an account by using the pricing calculator. You can choose the cloud option, the deployment region, and the number of monthly active users.
How To Use FusionAuth Cloud
There are a few steps to getting access to a deployment. Some occur once, others happen every time a new deployment is created.
Control all aspects of FusionAuth Cloud deployments by logging into the account portal.
Your account portal contains the following tabs:
edition differences here. This is also where you will find your license keys if you are not using the Community edition.- select or modify the account’s FusionAuth edition. More details on the
- configure and manage FusionAuth Cloud deployments.
- add and remove users from the account portal.
- add or update your billing information.
- learn more about support options or open a support ticket.
Adding a user to your company will allow them to manage FusionAuth deployments and take other account portal actions. This action will not provision the user an account on the FusionAuth instance in the deployment.
Setting Up Your Account and Billing
Before you can create a FusionAuth deployment, you register for a free account and provide payment information. Register by going to the account portal.
If you already have an account, you can log in.
If you do not have an account, follow the "Create an account" link. On the registration form, you’ll be prompted for an email, password and other required information.
After you register, you’ll be taken to thetab. When you have no billing information on file, you’ll need to provide that before creating a deployment.
You can navigate away from thetab and explore other areas of the account portal. For example, you can add other users. But before creating a FusionAuth Cloud deployment, provide credit card details.
If you’d prefer to be invoiced rather than provide credit card details, contact us.
If you are paying with a credit card, you will receive a payment receipt to the email address you signed up with. If you need to have the receipt sent to a different email address, please contact us and we’ll change it.
After you have created an account and set up your billing information, create a deployment.
Creating a Deployment
Navigate to thetab. If you have no deployments, you will see a screen like this:
Click the "Launch" button to start your first FusionAuth Cloud deployment.
Provisioning Your Deployment
In order to create the correct FusionAuth instance, you need to specify aspects of the deployment. Pick the tier of this deployment: Basic, Business or High-Availability. Each has different features and data durability guarantees.
Supported regions include:
the Middle East
Within each region, select a geographic area, such as Oregon, USA. Pick the location that meets your legal and compliance needs and is close to your applications.
Next, pick the deployment size. This section includes guidance on how many logins per second can be supported. There are three sizes available:
|Size||Logins/registrations per second|
1 - 10 requests per second
10 - 50 requests per second
50 - 150 requests per second
If you have needs for more requests per second, please see the Custom FusionAuth Cloud Features for more.
You can also specify the FusionAuth version and data compliance attributes of this deployment.
You must provide a unique hostname for the deployment, such as
piedpiper-dev. This hostname will be suffixed with the
fusionauth.io domain name, unless you chose the High-Availability tier. If you need to reuse an existing hostname, open a support ticket.
The screenshots above are for a Basic FusionAuth Cloud deployment. Different deployments will show different options. For example, the Business or High-Availability tiers allow you to choose to replicate your data to another database in FusionAuth Cloud to increase availability.
At the end of the provisioning process, before your credit card is charged, you will be provided an estimate of the monthly cost.
When you have your deployment configured as you would like, click "Launch Deployment". Your credit card will then be charged.
Navigate to thetab to see the new deployment.
The exact duration of the deployment process depends on system load as well as the tier chosen. Expect your deployment to be available in 5 to 30 minutes. When the deployment is ready, the link to your deployment will be live and thetab will look similar to this:
Accessing the FusionAuth UI
Log in to the deployment’s administrative user interface by clicking on the deployment’s URL, such as
At that point the Setup Wizard will begin. You can configure FusionAuth by creating API keys, adding additional users, setting up applications for your users to log in to, or any other task. The interface will be exactly the same as a self hosted FusionAuth instance.
If new to FusionAuth, you might want to work through the 5 minute guide, starting at step 5, and updating the FusionAuth instance URL to point to your deployment.
You’ll also want to update various system or tenant level settings. This includes creating API keys, updating your email host settings and configuring groups and roles.
Many infrastructure or network providers don’t allow any traffic on port 25. This includes FusionAuth Cloud.
We recommend using one of the TLS ports for SMTP, such as 465 or 587. FusionAuth will work with any email provider with an SMTP interface.
Managing Your Deployments
At any time you can log in to the account portal, navigate toand manage your deployments.
To add another deployment, click "Launch deployment". You’ll go through the same provisioning workflow as above, and end up with another FusionAuth Cloud deployment.
You can also upgrade or destroy each deployment. To begin either process, select the menu under "Actions":
Upgrading a Deployment
If your deployment is not running the latest version of FusionAuth, you may upgrade it.
Upgrade management is only available if the deployment is not currently running the latest available FusionAuth version.
There will be downtime of between 5 minutes and 60 minutes. The exact downtime duration depends on the type of deployment, amount of data in your system, and database changes required by the version upgrade. Consult the relevant release notes for functional changes as well.
Due to the downtime, it is recommended that you schedule the upgrade for a low traffic period. Test the upgrade process on development or test servers first.
It is a good idea to run the latest released version of FusionAuth, which has the latest bug fixes, security updates and features. However, you will not be forced to upgrade on a certain schedule.
The upgrading described in this section only updates the version of FusionAuth.
If you are looking to modify other attributes of your deployment, such as the region it is running in, the deployment size, or the service tier, review the Modifying Deployments section.
Perform an upgrade at a time that works for your users, your team and your applications by logging into your account. Record the time you began the upgrade.
Navigate to the Version dropdown.tab. Manage the deployment, then choose the "Upgrade" option. Select the version you are upgrading to from the
Confirm the upgrade:
After confirmation, the deployment will be in an "Upgrading" state until finished. You can monitor the upgrade by viewing the System Status API; when it returns success, the deployment upgrade is complete.tab. If you need to programmatically monitor the upgrade, you can call the
You cannot downgrade a FusionAuth Cloud deployment version.
Upgrades with a High-Availability Plan
Upgrades with this tier have less downtime.
If the release notes indicate a database migration, the upgrade process will result in a few minutes of outage. Otherwise there will be no downtime.
Rolling Back From a Failed Upgrade
If this happens and you identify it within your database backup retention period, open a support ticket. Make sure you provide the time you began the upgrade.
Destroying a Deployment
If you have a FusionAuth deployment and want to delete it, do so by logging into your account.
Before destroying a deployment, ensure you back up your user data and configuration. You can retrieve your configuration using the APIs. See Accessing User Data for more about retrieving user data and passwords.
For Business and High Availability plans, FusionAuth will retain a backup for a maximum of 30 days.
For Basic plans, no backup is available.
Navigate to the Destroy option.tab. Manage the deployment to be destroyed. Choose the
You will be prompted to confirm your decision.
After confirmation, the deployment will transition to the "Destroying" state.
After the deployment is completely removed, it will have a "Destroyed" state on thetab. At this point you will no longer be charged for this deployment.
Migrating a Deployment
You can migrate your user data to a FusionAuth Cloud deployment or from FusionAuth Cloud to a self-hosted FusionAuth instance.
If you are interested in migrating from an auth system other than FusionAuth, you’re looking for our Migration Guide.
Migrating To FusionAuth Cloud
To migrate from a self-hosted instance to FusionAuth Cloud:
You must be running PostgreSQL. If you are running MySQL, please migrate to a PostgreSQL database locally. Here’s a forum post on how to do this. This has been provided by the community and is not supported nor endorsed by FusionAuth.
Export your FusionAuth database to a file. When you run the
pg_dumpcommand, please use the following options:
--compress 9to minimize the file size.
Encrypt the export file with a symmetric solution such as gpg.
Purchase a FusionAuth Cloud deployment that meets your needs. Select the version of FusionAuth that is the same as your local installation. You will be able to upgrade FusionAuth later; see Upgrading a Deployment for more.
Open a support ticket and provide the database export file, the version of PostgreSQL you are running, and the name of the new FusionAuth deployment.
Provide the password for the database export through another channel. You can mention the channel you’d prefer in the support ticket. Slack, email and a separate support ticket are all options.
Within 1-2 business days, we will upload your data to your FusionAuth Cloud deployment.
After your data is uploaded, upgrade your deployment to any subsequent FusionAuth, if desired. See Upgrading a Deployment for more.
Confirmed running Postgres for local instance.
Found FusionAuth version for local instance.
Created a new deployment. Instructions: Creating a Deployment.
Ensured the FusionAuth Cloud deployment and the local instance are running the same version of FusionAuth.
Communicated the version of Postgres used in the export file.
Encrypted the database export.
Provided the decryption password via a separate communication channel.
Migrating Away From FusionAuth Cloud
To migrate from FusionAuth Cloud to a self-hosted instance, please request a database export, as documented in Accessing User Data. After you have the data, install it in a PostgreSQL database and configure your self-hosted instance to point to that database.
Ensure your self-hosted instance uses the same FusionAuth and database versions as those used by your Cloud deployment. You can view your FusionAuth version in the administrative user interface.
To find your deployment’s database version:
If you are running a version of FusionAuth before 1.30.2, open a support ticket.
If running a version >= 1.30.2, navigate toto view the version.
Once you’ve tested your self-hosted installation, destroy your FusionAuth Cloud deployment as outlined here: Destroying a Deployment
Open a support ticket to change any of the following attributes of your deployment:
the region or geographic location
Such changes are typically handled in 1-2 business days.
A common question is: "will I lose any data when migrating between tiers, region, size, or hostname?"
When performing any change which requires modifying cloud infrastructure, the cloud database is backed up, and then reconnected to the new infrastructure.
No data loss should occur and your configuration will be preserved.
If you are on the HA Cloud and want a custom domain name such as
auth.example.com, log into your portal, select the deployment menu (the three … under "Actions") and choose the Custom URL(s) option.
Enter your desired custom URLs, such as
login.piedpiper.com and follow the instructions.
Custom domains are currently only offered for HA Cloud deployments. If you are using Basic or Business Cloud, upgrade for a custom domain name.
Accessing User Data
If you need to export user data from FusionAuth Cloud, whether because you are migrating away from FusionAuth, you are setting up a staging environment locally, or because you need the raw user data for analytics, open a support ticket.
A support request is required because data exports contain sensitive fields, like password hashes. The FusionAuth team will work with you to find a safe data transfer mechanism.
Restoring From Backup
Certain FusionAuth Cloud tiers include regular backups. If you need to restore your user database from a backup, open a support ticket with the details.
You can restore to any point in time in the last three days. In the ticket, provide the date and time and timezone that you’d like to restore your database to.
You can view support options by navigating to thetab:
Support for FusionAuth Cloud is limited in scope. Support can only help with issues related to running your FusionAuth Cloud deployments. Some examples:
"My FusionAuth Cloud instance is down" - supported
"Please restore my FusionAuth Cloud instance from backup" - supported
"I need help integrating FusionAuth into my Express/Rails/Django/Spring/etc application" - not supported
"How do I set up a webhook to sync my user data with an external system?" - not supported
Support from the engineering team for integrating with FusionAuth can be purchased separately.
If you have out of scope questions and have not purchased a support contract, you can find community support in the forums and documentation. Review the technical support page for more detailed technical support guidance.
Custom FusionAuth Cloud Features
If managed FusionAuth hosting does not meet your needs, open a contact us with more details.
We’re happy to discuss custom deployment architectures or configurations. If you need any of these:
Longer retention of database backups.
Static IP addresses capable of being added to a firewall allow/deny list.
Deployments capable of handling more requests per second (custom FusionAuth configurations have handled 2,000 requests per second).
Multi-region deployments for disaster recovery, compliance, or other reasons.
Please contact us to learn more about these options.
SLAs and Availability
We know that availability of your auth system is critical. Below are some of the steps FusionAuth takes to ensure that FusionAuth Cloud systems are available.
For all deployments:
All components are monitored via external software systems as well as internal metrics gathering systems.
The application architecture is not exotic, reducing risk. This is a three tier web application, which is a well understood architecture.
Third party security researchers can submit security issues via a bug bounty program.
The FusionAuth software and infrastructure is pentested on a regular basis.
Major changes, such as FusionAuth upgrades or operating system upgrades, are scripted and the timing of changes is controlled by the customer.
Modifications to the underlying product are tested extensively, including load testing where appropriate.
We have automated rulesets to protect against DDoS.
We use a world class cloud provider’s managed services for system components where appropriate.
Network firewalls are automatically configured on deployment to set up "least privileged" access to each system component.
For high availability deployments:
Each deployment has redundant components. This includes, but is not limited to, the DNS system, load balancer, and the compute nodes running FusionAuth.
Each deployment’s relational database can optionally be set up in a primary/secondary configuration, so if the primary becomes unavailable the secondary will "stand up" and the instance will continue to be available. This is also known as "full database replication" and is a suggested configuration.
Each set of components is run in separate geographic availability zones, separated by many miles. This prevents disasters from affecting both zones.
For high availability deployments with purchased support:
The FusionAuth engineering team will consult on product implementation and can offer "best practices" advice to further ensure system stability.
We size the instance properly for expected traffic, in consultation with the customer.
You can load test FusionAuth to determine if its performance will meet your calculated needs. The FusionAuth team tests the performance of FusionAuth regularly, but every situation is different and running your own load tests on your instance provides useful information.
You may use your own load testing tool. Any tool which can make HTTP requests, such as gatling or jmeter, will work.
There is an open source project which provides some useful scripts for load testing. This is a specialized library and primarily used for internal purposes, so use at your own risk. Scenarios currently supported include:
Registering users for applications
Logging users in using the Login API
A full Authorization Code grant
Performance bottlenecks are typically the database or the CPU nodes, depending on sizing of each of these components and primary functionality tested. For example, both logins and creating users use a lot of CPU due to password hashing. Make sure each of these components are monitored and sized appropriately.
If testing a multi-node system behind a load balancer, ensure that you have disabled sticky sessions, as they are not required for FusionAuth functionality.
Load Testing With FusionAuth Cloud
Load testing is an important part of evaluating FusionAuth. However, it is important to load test in an environment that replicates your expected production environment. This means that if you are planning to use an HA cloud deployment for production, you should load test against that type of environment.
When you are load testing against FusionAuth Cloud instances:
Please open a support ticket to let us know when you are planning to load test. We monitor CPU usage and other metrics and it can be helpful for us to know when you are planning to stress test your instance.
Store configuration as scripts which you can apply to your FusionAuth instance. This allows you to easily stand up and tear down different deployments to see what meets your needs.
If you have an edition with support, please open a support ticket if you’d like additional support or guidance on sizing or testing.
Please don’t use a FusionAuth Cloud Basic deployment to load test. Instances on this tier of FusionAuth Cloud run on a single compute node, so the node is running FusionAuth, Elasticsearch and a PostgreSQL database. The node is therefore 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 planning your production deployment.
Testing on a Business Cloud or High-Availability Cloud plan will provide more useful results. If you cannot achieve your target request per second with a standard setup, you can create a deployment with larger node sizes. You can spin up a deployment, apply your configuration, perform load testing, and tear it down. You’ll only be charged for the time the instance is running.
FusionAuth Cloud has the same limitations as self hosted FusionAuth. Since it is a managed service, there are additional limitations as well:
No access is provided to the server on which your deployment is running. This includes access to the database, Elasticsearch, or ssh. You can access your data via FusionAuth API, administrative console, and by occasionally requesting a database export.
There is no API to manage FusionAuth Cloud deployments.
You cannot change any of the FusionAuth configuration options.
You cannot downgrade the version of a FusionAuth Cloud deployment.
You cannot run a Kickstart file on a FusionAuth Cloud deployment.
There is no support for proxy customization. You can add your own proxy layer, such as CloudFlare, with FusionAuth Cloud as an origin.
Use of port 25 is not allowed. To connect to an SMTP server such as Mailgun or SES, use a different port.
The IP addresses of a FusionAuth Cloud deployment are not fixed. Whenever possible, use the domain name, which is fixed. If you need IP addresses of the deployment nodes for purposes such as a network firewall allow list, please open a support ticket, but be aware that they may change. Please upvote or comment on this open issue about static IP addresses in FusionAuth Cloud.
If you are on FusionAuth Cloud and you find that some requests are failing, it is possible you are being rate limited. This isn’t intentional, but an automated part of our infrastructure to ensure FusionAuth Cloud performance and security. If you are rate limited but need these requests to occur, please open a support ticket with details.
How helpful was this page?