Problem statement
We have been testing Auth0 now and are impressed with its ease to integrate with software we are working on. We are however interested in knowing more about the intended design and concept of the tenants feature of your system.
We were under the impression that the tenants were designed to be treated like an environment (dev, stage, prod) as you have the ability to tag tenants as in use for one of them. Is this their intended design or not? Is it wise to put dev, stage and prod applications all on 1 tenant or is that bad for scalability and against your systems design concepts?
The main reason we ask is because you seem to have a subscription that you have to buy per tenant, either I’m mis-understanding your billing model or that seems like it could get costly quick if we were to have tenants per env.
Can you please make a recommendation on the best tenant and application structure for scalability and recommend quote us a price to upgrade our account or tenants if thats the case to allow us to fall in line with your intended design philosophy.
Solution
- “We were under the impression that the tenants were designed to be treated like an environment (dev, stage, prod) as you have the ability to tag tenants as in use for one of them. Is this their intended design or not?”
Yes, the use of different environments is advisable, as this follows the typical pattern of the software development and deployment life-cycle. This is explained further in this document:
- Is it wise to put dev, stage and prod applications all on 1 tenant or is that bad for scalability and against your systems design concepts?
In an ideal scenario, each key stage of your development lifecycle would be assigned its own tenant environment. This is done for several reasons, for example:
a) Software bugs or security issues in early development stages of an application are not likely to impact your applications in Production
b) Production and Dev/Staging tenants have different rate limits assigned to them, as explained here:
You should also be aware of our Entity limit policy, though you are not likely to run into any of these constraints during your early use of Auth0:
- The main reason we ask is because you seem to have a subscription that you have to buy per tenant. Can you please make a recommendation on the best tenant and application structure for scalability?
That is correct, our subscription plans for self-service customers are ‘per tenant’. As noted, for optimum reliability and scalability, it’s best to have separate tenant environments.
If you opt for a single ‘mixed use’ tenant to begin with, tag this as a Production tenant. For example, a tenant used for both development and production should be set to Production. This will ensure that you enjoy the higher rate limits that come with that type of environment.
Note that it is possible to migrate users between tenants (or import from an external database) using our Bulk user import/export tools:
Individual tenant configurations can be backed up (and restored, if necessary) using our Deploy CLI tool:
This can also be used to ‘clone’ tenant configurations, so as to create replica tenants (some additional work will be needed to change the ‘cloned’ configuration).
So if you were to start with a single tenant, it would be possible to expand this into a multi-tenant structure in the future, using the tools mentioned above.
Architectural and implementation choices may also influence your tenant configurations, as explained here:
Finally, if you search our documentation using the phrase ‘best practices’, you will find a wealth of advice on how to get the best out of your investment in Auth0.
With regards to your comment about pricing, it’s best to consult our Pricing page: Pricing - Auth0. This gives you all the information that you need about the different self-service plans that are available.
If you would like to get an idea about the cost of an Enterprise subscription, click on this link to be taken to the sales enquiry page: Contact Us - Auth0