Hi @gabe1
There’s just one logical instance of the server software (i.e. “Auth0 public cloud”). That’s a big cluster of servers, databases, load balancers and so on, that could be seen as one big service.
It is divided into a few geographical regions: Americas, Europe and Australia. Each gets their own servers, databases.
This Auth0 cloud service is further divided into tenants. One Auth0 customer (e.g. “Acme”) will usually “own” one or more tenants. You would typically set up at least one tenant for production usage and one or more for other environments like QA/dev/test (e.g. “acme”, “acme-dev”, “acme-qa”).
Each tenant contains one or more applications (“clients”) definitions, user databases, rules, user profiles, and so on. There’s no crossover of data between tenants, but that’s a logical divide, as internally some databases could potentially have data from more than one tenant (that’s an implementation detail). But the guarantee is that if you work with the “acme” tenant, you would never see any data from the “contoso” tenant (nor from the “acme-qa” or “acme-dev” tenants, for that matter).
When you create a tenant, you can only choose the region where the tenant ends up. There’s no exposed concept of instances to choose from.
All of the above is for the “public cloud” service. There are other deployment models (see Deploy and Monitor) for cases where a complete isolation is required.