A Tenant Per User
The installation can create a tenant automatically for each new user signing up under the master tenant.
Where to find it
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
What it produces
Self-service sign-up where every account is its own isolated organisation. That is the right model for a product sold to individuals and small businesses who arrive without a conversation.
When it fits
- A product with a free tier or trial.
- Customers who are individuals or sole traders.
- A sales model with no onboarding conversation.
When it does not
Where customers are organisations with several users. Then the first person to sign up creates a tenant, the second creates another, and you have two organisations that should have been one — which is unpicked by hand, repeatedly.
If your customers are companies, invite users into an existing tenant instead.
It creates tenants indefinitely
Including for people who sign up once and never return, and for anybody testing your sign-up form. Most will be empty forever.
Have a policy: how long an empty, inactive tenant is kept, and what removing one does. Without it the tenant list grows without limit and every operation across tenants gets slower.
Separate database mode changes the arithmetic
Considerably. A tenant per user in separate mode means a database per user, and the operational cost of thousands of databases is not the same as thousands of rows.
If you expect volume sign-up, shared mode is almost certainly the right pairing.
Consider what a new tenant starts with
An empty tenant is a poor first experience. The data-copying setting decides whether a new tenant starts populated from the master, which for a self-service product is often what makes it usable in the first five minutes.
Guard the sign-up
Automatic tenant creation on an open form is an unbounded resource. Rate limiting, e-mail verification and abuse monitoring matter more here than on an ordinary sign-up form.
Worked example
A self-service product creates a tenant per sign-up in shared database mode, populated from the master so a new user sees a working example. Verification is required before the tenant becomes usable, and empty unverified tenants are removed after ninety days.
Recommendations
- Only for individual customers, not for companies.
- Pair with shared database mode.
- Have a policy for empty inactive tenants.
- Rate-limit and verify the sign-up.