Hello All,
Right now, I am using a paid tenant. Now, I need to set up all the environments i.e. Prod, Staging and dev under single tenant itself. When I refer to this link, it says that the recommended way is to create a separate tenant for each environment. This link does not satisfy my requirement. In addition to this, I too want that there should be isolation between the environment in terms of DB, Email templates, Hosted page etc. or there should be at least a way by which I can segregate the DB, Email templates and hosted pages too.
@jmangelo, @walsh, @prashantT, @pat.trivedy:- Can you guys please share your feedback and guide me to set up the environment. I need this requirement to be cleared out asap. Thanks in advance. Awaiting a reply.
@ronak.sharma the docs suggest a separate tenant for each env because it is the only way to get true isolation between env. With tenant level separation you can achieve this isolation:
- Dashboard admin access
- Email Templates
- Connections
- Rules
- Hooks
- Tenant Settigns/Flags
- Etc
If you have to use a single tenant you lose most of the isolation above. You can still get some, but tenants are not designed to contain all of your environments. You can of course get some isolation, but many configurations are at the tenant level. Rules, some Connection Types (Google Apps for example), Hooks, tenant settings/flags, and Hosted Pages will be very hard if not impractical to isolate.
Can you explain what the use case is that would prevent you from having tenant level isolation?
@sgmeyer :- Thanks you for the quick response. In order to setup three environments i.e. dev, Staging and Prod, I need to have 3 paid subscriptions since i am using account linking feature which is available in paid subscription only. If everything comes under a single tenant then it would great in terms of manageability without switching to another tenant. On the other hand, may I please know what is the practical use of creating a new custom DB in “Connection” tab? Can we associate that DB with social application? I mean a social application pointing to 2 DB’s.
@ronak.sharma ok I see. The minimum subscription to have dedicated tenants for each env is $167/month of just pay for n subscriptions if that is less than 167/month.
Also can you elaborate more on this?
On the other hand, may I please know what is the practical use of creating a new custom DB in “Connection” tab?
Can we associate that DB with social application?
Do you mean can you account link a custom db identity with a social identity? Yes you can link them, but the user must have logged in once via custom db and social (once each) so they user profile is created in auth0 (I know this is obvious). Once they are both there you can link them via standard account linking.
I mean a social application pointing to 2 DB’s.
Not sure what you mean here can you elaborate?
Ok, back to your env question. Managing multiple environments as a single tenant is partially possible, but it comes with a lot of drawbacks. Keep in mind all rate limits are at the tenant level, so any activity done in a non-prod env impacts the production rate limits. So you can create separate Applications, connections (mostly, but with limitations), APIs… but this is as isolated as you can get. Depending on your subscription you could always use free tenants and forego the account linking in lower envs. If that is a deal breaker you could get the smallest paid subscription for your lower envs. If that is still a deal breaker then you can try to use a single tenant with its current limitations.
@sgmeyer :-
The below is my elaborate idea about the single tenant with multiple environments.
1). We can create environment wise custom DB i.e. one for dev, another for staging and 3rd for prod.
2). Then we can create environment wise applications. This means each application will be pointing to one custom DB and social login i.e. google and facebook.
Now, my question is
1). Since there are multiple DBs then users displayed on Dashboard will be of which DB? I guess all the users across all Dbs will come and they are differentiated by connection specified. Please correct me if I wrong.
In my current paid tenant, I am using rules, email templates, hosted pages and Authorisation Extension. For my application, I can say that rules, hosted page (forget-Password), Authorisation Extension will remain the same as such there are identical across the environments so no isolation is required. But I need segregation within Email Templates so that I can identify environment wise. For my application, email templates have bit variations between the environments. I tried using macros as an alternative to identifying the application who has called it but no success. Can we achieve this? Please share your views on this.
If somehow I am able to segregate the environments for email templates then it will a good alternative for me. Thanks
1). Since there are multiple DBs then users displayed on Dashboard will be of which DB? I guess all the users across all Dbs will come and they are differentiated by connection specified. Please correct me if I wrong.
You are 100% correct. The connections are just ways to validate identities. The users tab are all the user profiles across all of the connections.
I am using rules, email templates, hosted pages and Authorisation Extension. For my application, I can say that rules, hosted page (forget-Password), Authorisation Extension will remain the same as such there are identical across the environments so no isolation is required. But I need segregation within Email Templates so that I can identify environment wise. For my application, email templates have bit variations between the environments. I tried using macros as an alternative to identifying the application who has called it but no success. Can we achieve this? Please share your views on this.
Email templates and rules are things that are shared across tenants. There isn’t a way to isolate these per environment when using a single tenant. Same is true about rate limits. All of your environments will also share the same rate limit bucket for the management API.