Tenants

A tenant is one instance of LeanSignal. It has its own URL (<short-name>.leansignal.io), its own application backend, and its own telemetry storage. Nothing is shared between tenants.

Everything in a tenant is visible to that tenant’s users

This is the single rule worth internalising: a tenant is a visibility boundary. Every dashboard, alert, and stored metric, log, and trace inside a tenant is visible to every user of that tenant — admins, editors, and viewers alike.

Roles do gate some configuration areas: viewers have no access to Agents, Demands, or notification channels, and only admins reach Settings. But no role narrows the telemetry a user can see. There is no way to scope a user to a subset of the data, or to hide one team’s dashboards from another team’s users. If two groups must not see each other’s telemetry, they need separate tenants.

Split when you need isolation — not by default

A tenant boundary is absolute, which makes it excellent for isolation and inconvenient for everything else. Across two tenants you cannot:

• build a dashboard or alert that spans both,
• query telemetry from one while looking at the other,
• share a demand, dashboard, or alert directly — you export a bundle and import it into the other,
• or share an agent: each tenant needs its own agent and its own agent key.

Quotas are also per tenant — storage, monthly ingestion, users, and agents are counted separately for each (see Limits).

So the guidance is simple: start with one tenant, and add another only when you have a reason to isolate. A second tenant is cheap to create and impossible to merge back.

The two patterns that work

When you do split, one of these two usually fits.

One tenant per team

Each team gets its own instance: its own agents, demands, dashboards, and members. Use it when teams are independent, when they should not see one another’s telemetry, or when you want each team’s usage counted against its own quota.

The cost is that platform-wide views disappear — nobody sees across teams without switching tenants.

One tenant per stage

One tenant per production, integration, and development. Use it when the same team runs several environments and wants noisy pre-production telemetry kept away from the signal that matters.

This is usually the better default of the two, for a reason that has nothing to do with visibility: it keeps production’s demands, alerts, and quota untouched by whatever anyone is trying out in development. You can also rehearse a change in the dev tenant and move it to production as a bundle.

Note

Both patterns compose — a large organisation might run acme-prod, acme-staging, and a separate acme-data-platform for a team with genuinely different needs. Each split should still trace back to a specific reason to isolate.

One account, many tenants

Splitting does not mean separate logins. One account can belong to many tenants with a different role in each, and the tenant app lists them all as Workspaces — a single control-center session serves every tenant you belong to, so switching is a click rather than a sign-in.

Next steps

• Tenants & workspaces — creating a tenant, the short name, and the tenants dashboard.
• Manage users — invitations and membership within a tenant.
• User roles — what admins, editors, and viewers can change.
• Security & data residency — how the isolation is enforced.