So, for the tenant in the dev environment, set tenant.data.assethost to dev.example.com. For the prod environment, set tenant.data.assethost to dev.example.com.

Then, in your theme, you'd have something like this:

The reason to use the tenant object is that it is available on every theme template.

This does mean that your tenant configuration will differ slightly between environments. You can also replicate this field value between tenants if you are using multiple tenants.

But you can set variables in the Helpers template using assign that can be used in other templates. You could use a templating language like jinja to build the Helpers template at build time and then a script to load it during deploy. (Or even sed.)

You can also create different themes (a dev theme, a qa theme) and assign them via scripts to the different environments (unsure if you are using different tenants to represent environments or different FusionAuth instances, but the concept is the same).

Strengths of running in different tenants:

Strengths of running in different instances:

In general, it makes sense to be careful about production environments, as if any configuration changes are made in error, it can impact the customer experience.

It really depends on what works best for you.

The default form fields ship with random ids, as you mention. Some FusionAuth entities that always have the same ids, but if you want to control everything, the easiest way to do so is to create all the entities yourself.

You have two options:

With Kickstart, you can create all the form fields, forms and other entities. You'd hard code the UUIDs for each entity. For example, you could hardcode a form field's UUID like so (an excerpt from a kickstart file):

You would build up forms out of these fields with known ids, then assign forms to the applications/tenants and so on.

If you use Kickstart, the default entities with the random ids will still be added, but can be ignored. Currently you can't run a DELETE operation in Kickstart, but you can either delete the default entities later via an API call. If being able to call a DELETE operation in a Kickstart file is important, please consider filing an issue.

You could do much the same with APIs in python, ruby, java, or any of the other supported languages as well. All entities take an id on creation. With these libraries, you'd also be able to delete the default form and other elements. The benefit of using the API is that you aren't limited by Kickstart, but there's more code to write.

You can also use Kickstart to set up your environment initially and then use the API/client libraries for changes over time.

You could also script all your changes using the API and apply those scripts to different environments. We mostly see folks writing migration scripts that call the APIs. These are very similar to database migration scripts except they make REST calls instead of SQL. The scripts are run during upgrades of their app. (If you are using an app like rails, you could even leverage the existing migration framework and a client library.)

Kickstart works well for dev envts and CI, but doesn't handle changes (it assumes there is no data in fusionauth and won't run if it sees any).

Here's an issue tracking digitalocean database issues--some managed databases don't work right now: https://github.com/FusionAuth/fusionauth-issues/issues/95

The number of open connections should be around 10. I believe that is per fusionauth instance.

What were the specs you were seeing the issues with?

We've seen FusionAuth (the application) run in 64M of RAM. You can specify the maximum amount of memory used in the configuration file or via environment args. More here: https://fusionauth.io/docs/v1/tech/reference/configuration

Note that if you don't need advanced search functionality, you can use the database search engine and avoid running elasticsearch: https://fusionauth.io/docs/v1/tech/tutorials/switch-search-engines talks about how to switch between them. That may eliminate some of the memory pressure if you were running elastic.

Kickstart only works if the other devs' fusionauth instances are going to be starting from scratch.

Otherwise you might want to vote for https://github.com/FusionAuth/fusionauth-issues/issues/560