Plans and Features

Overview

FusionAuth will always have a powerful, full featured free-to-use Community plan. This is the foundation of FusionAuth and the community surrounding it and as an organization FusionAuth is committed to improving the Community plan, with both features and bug fixes.

However, there are additional tiers of functionality which meet the needs of different types of organizations and offer premium features. For these plans, a license is required.

You can learn more about purchasing FusionAuth plans other than Community on the pricing page. The legal agreement you make when using FusionAuth, with or without a paid plan, is the FusionAuth license. Learn more about the license in the licensing FAQ.

After summarizing the features offered in different FusionAuth plans, this article will explain the differences between hosting FusionAuth yourself, and having it hosted and managed for you in the cloud.

Plans and Features

FusionAuth has different plans which have different features. They are also called editions.

• Community has all features not otherwise labeled in the documentation.
• Licensed Community has all licensed community features.
• Starter has all starter features, but some may have some numeric or usage limits.
• Essentials has all essentials and starter features, but some may have some numeric limits.
• Enterprise has all enterprise, essentials and starter features and no limits.

Please review the features page for much more information on plans and features.

Feature List

Here are the major features available in each licensed plan.

Licensed Community Features

• WebAuthn

Starter Features

• Advanced and Gaming Identity Providers
• Advanced Multi-Factor Authentication
• Application Specific Themes
• Breached Password Detection
• Connectors
• Custom Registration Forms
• Entity Management and Client Credentials Grant
• SAMLv2 IdP Initiated Login
• User Self Service and Account Management

Essentials Features

• Advanced OAuth Scopes
• Lambda HTTP Connect

Enterprise Features

• Application MFA Policies
• SCIM
• Threat Detection
• WebAuthn cross-platform authenticators

Feature Documentation

The FusionAuth documentation calls out features not part of the Community plan so you can make an informed decision about which plan works for you.

If a feature you are using requires a license, you may also encounter an error message in the administrative user interface or in an API message.

Licensed Community Features

Throughout the documentation, you’ll see features available to all licensed plans marked like so:

This feature is available to licensed FusionAuth instances as of version 1.52.0. A free license is available in the Plan tab for any user who registers in the account portal.

In the API documentation, you’ll see licensed features marked like this:

Note: A license is required to utilize this feature

Starter Features

Throughout the documentation, you’ll see starter features marked like so:

This feature is only available in paid plans. Please visit our pricing page to learn more.

In the API documentation, you’ll see starter features marked like this:

Note: A paid plan is required to utilize this feature.

Essentials Features

Throughout the documentation, you’ll see essentials features marked like so:

This feature is only available in an Essentials or Enterprise plan. Please visit our pricing page to learn more.

In the API documentation, you’ll see essentials features marked like this:

Note: An Essentials or Enterprise plan is required to utilize this feature.

Enterprise Features

Throughout the documentation, you’ll see enterprise features marked like so:

This feature is only available in the Enterprise plan. Please visit our pricing page to learn more.

In the API documentation, you’ll see enterprise features marked like this:

Note: An Enterprise plan is required to utilize this feature.

Self-Hosted FusionAuth Versus Cloud-Hosted FusionAuth

Once you have chosen a FusionAuth plan with the features you want, you need to decide where to host your FusionAuth instance. You can host it yourself, either on-premise server or with a cloud service provider like Hetzner or AWS, or you can use FusionAuth Cloud to host your instance. Your decision to self-host or register for FusionAuth Cloud is independent of which plan you choose. There are no differences in plan features between hosts.

Let’s first consider how each hosting type works, and then assess the advantages of each.

How Each Hosting Type Works

For self-hosting, you download the FusionAuth software (as a Docker image, zip file, RPM or DEB—your choice), and run it together with a MySQL or PostgreSQL server. You may also run Elasticsearch, but it’s optional. You have full control over the configuration of FusionAuth but have to manage and maintain all the following considerations:

• Database backups
• Monitoring and error checking
• Networking
• Upgrades to PostgreSQL and FusionAuth
• Server scaling and migration as your users increase
• Load balancing
• Proxy configuration

To learn how to run FusionAuth on your own host, read the guide to using FusionAuth on Docker or one of the other options.

For cloud hosting, you create a FusionAuth Cloud account and choose a plan. You can then start and stop as many instances of FusionAuth (called deployments) as you want through the web interface. You pay for each deployment for as long as it runs but need not worry about any of the considerations of self-hosting.

You can choose what geographic region your deployment runs in, you have API level access to manage your deployment, and you control the upgrade cycle.

To learn how to use cloud hosting in detail, read the FusionAuth Cloud guide. To estimate the fees for the deployments in your account, use the pricing calculator.

Advantages Of Each Hosting Type

Self-hosting gives you complete control over FusionAuth, including the ability to use Kickstart to start an instance with the exact configuration you need, allowing you to specify whether it includes sample applications and users. You can use Kickstart in conjunction with GitHub or continuous deployment services to deploy any number and configuration of FusionAuth instances. You can set up proxies and otherwise limit access to FusionAuth should you need to for compliance or security reasons. You can monitor and instrument FusionAuth using any Java compatible tooling. You can turn off usage data reporting. The FusionAuth database runs on your database. You can make FusionAuth highly available in the same way you would any other web application. With database access, you can run any SQL queries against it to extract data for analytics. Running any queries which modify the database will void your support warranty.

Cloud hosting is more convenient than self-hosting. Starting and stopping a deployment takes only a few clicks, as does upgrading. Deployments scale easily as your number of customers grows, due to the more powerful cloud instances available to handle the greater authentication workload. Backups are automated and available should you need to roll back your database at any time. A team of FusionAuth experts manages the cloud environment and is available if you need support. You can also purchase a 99.99% uptime service level agreement (SLA) to guarantee that your app’s authentication will always be available. FusionAuth is also available in the [cloud marketplaces(/docs/get-started/run-in-the-cloud/marketplaces/), allowing you to use your pre-approved spend to pay for FusionAuth as a single line item.

In exchange for convenience, cloud hosting offers less control than self-hosting.

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 or the admin UI. To install a password hashing plugin, please open a support ticket.
• There is no API to manage FusionAuth Cloud deployments.
• You cannot modify any of the FusionAuth configuration options.
• You cannot self-service downgrade the version of a FusionAuth Cloud deployment. For example, you cannot change the version from 1.35.0 to 1.34.0.
  • If you have a deployment with backups, you can roll back by restoring from backup.
• You cannot run a Kickstart file on a FusionAuth Cloud deployment.
• There is no support for proxy customization to add, for example, tenant routing. To accomplish such goals, add your own proxy layer such as CloudFlare, with FusionAuth Cloud as an origin. Make sure you configure the trusted proxies.
  • You cannot modify X-Forwarded-Port or X-Forwarded-Proto. For example, you can’t proxy a FusionAuth Cloud instance to make it appear as if it was running at http://localhost or another non-TLS endpoint.
• 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 FusionAuth service nodes, follow the instructions in the Deployment IP Addresses section found above. Be aware that even after determining the assigned IP addresses, they are subject to 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 with a 429 status code, you are being rate limited. This isn’t intentional, but an automated part of our infrastructure to ensure FusionAuth Cloud performance and security. Learn more here, including how to avoid rate limiting for certain servers.
• If you want to run Advanced Threat Detection, an Enterprise feature, you’ll need a cloud deployment with sufficient memory. It must be a Large or X-Large.
• With HA and other multi-node deployments, requests are passed through a load balancer. When making requests to node specific metrics endpoints such as /api/status or /api/prometheus/metrics each request may return different results because the response is specific to the service node responding to the request. Using these endpoints to monitor a deployment is not recommended.
  • See this GitHub issue for more.
• You may not modify the Elasticsearch settings or view the Elasticsearch index directly. Among other things, this means that you can’t use some of the troubleshooting steps available to users self-hosting FusionAuth.
• OpenTelemetry data is not available on FusionAuth Cloud deployments.
• There is a limit of 1000 indexed fields. These include user.data, registration.data and standard indexed fields like email.
• In certain cases, only current log files are available for download under System -> Logs . If you need all log files, including those previously rotated, please open a support ticket.

Use Cases For Each Hosting Type

Self-hosting is free (other than any required license, computer and network costs), which is perfect for testing FusionAuth, local development, or any spare resources you already have on an existing server. You can also host FusionAuth anywhere, even on a private network, which may be a requirement for your organization’s data regulations. Self-hosting is a good choice if your team has the knowledge and time to manage FusionAuth.

Cloud hosting is a good choice for businesses that want to spend as little time as possible managing infrastructure or that don’t know enough about FusionAuth and server management to host it themselves.

If neither option offers you an obvious advantage, compare the cost of self-hosting and cloud hosting to decide:

• Self-hosting is a good choice when you have an infrastructure team with spare time to monitor and maintain your own instances.
• Cloud hosting costs money but saves your infrastructure team time.

You should calculate the total cost of cloud hosting your deployments against the cost of having your own team maintaining FusionAuth, and the potential cost of downtime if your local FusionAuth instance were to become misconfigured.