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.

No, it is more like terminating an EC2 instance. All data is lost.

If you have user data you'd like to retain, please request a database dump before destroying your deployment.

It is an ever changing list, but the easiest way to see it is to go to the FusionAuth pricing calculator and select the region to see what countries are currently supported.

If you would like us to support a country not currently on that list, please contact us with more details.

Peering is not an option at the moment. If you have a use case for this, please file a GitHub issue with more details about how you'd like to see the feature implemented.

Another option is to self host and run FusionAuth within your cloud network infrastructure. If you'd like to do that and still have help from the FusionAuth team, consider a plan with a support contract.

We support deploying to Bahrain. Not sure if you are looking for best latency, but that deployment would be the closest geographically.

FYI a lot more FusionAuth Cloud details are available in the cloud installation guide.

Our billing is hourly, but we bill up-front rather than in arrears.

This means if you sign up we will charge you $75 USD (if you chose the basic hosting).

If you cancel before the end of your billing period, we issue you a refund for the unused amount, pro rated to the hour.

FYI a lot more FusionAuth Cloud details are available in the cloud installation guide.

Yes. FusionAuth Cloud starts with Community Edition as the base version.

You can purchase one of our paid editions for both the self-hosted or FusionAuth Cloud. Once you enter the license id for a paid edition, it activates the premium features in FusionAuth (including Breached Password Detection, LDAP support, Advanced Registration Forms).

If you have the High-Availability plan, we can set up a custom domain name such as you suggest.

The best way to do this is to open a support ticket with the fully qualified domain name (id.example.com, for example). We'll then create the cert on our end in AWS, and then we just have you create two DNS records on your end, which assures AWS the certificate is being created by people with the correct authority.

If you'd rather create the cert, it is possible for us to import your cert, but then you’ll need to be sure that you send us new certificates each time you are issued a new one, so it is more error prone.