1. Platform
  2. Features
  3. Multi-Tenant Isolation
Feature Multi-Tenant Isolation

Each environment is its own isolated system

Most platforms bolt multi-tenancy onto one shared permission model: every tenant is just rows tagged with a tenant_id. Canopy isolates at the environment level: each environment is its own authorization system, with its own permission catalog, roles, and hierarchy, sharing nothing with the next. Identities stay unified at the account level, so one person is a single identity, granted access independently in each environment.

No shared access model No cross-environment leakage By design, not convention
yourapp · one app, isolated environments NO SHARED STATE
Acme Retail
its own environment
Acme
West
East
store.openinventory.manage
Northwind Health
its own environment
Northwind
Clinic
Hospital
chart.viewrx.approve
Two tenants, two completely different models. Neither can see, or touch, the other.
More than just isolated data

Most platforms isolate users. Canopy isolates systems.

Each environment defines its own permission vocabulary, roles, and hierarchy. Two environments on Canopy can run completely different access models, with no shared authorization config between them.

Most platforms
Isolate users
Shared system
A B A C B A C B
partitioned by tenant_id: one shared model
One permission model. Tenants are rows, separated only by a column.
Canopy
Isolate systems
Acme
Northwind
Cargo
Each environment is a full authorization system: its own vocabulary, roles, and structure.
Stop building tenant logic yourself

Isolation you don't have to engineer

Without proper isolation, permission checks become tenant-aware conditionals, roles leak across customers, and a schema change ripples to everyone.

Without Canopy
  • Tenant-aware conditionals in every permission check
  • Roles and permissions can leak across customers
  • Schema changes ripple to every tenant
With Canopy
  • Every environment is fully contained
  • Access rules stay local to each environment
  • Changes never touch another environment
Complete data isolation

Two boundaries, not one

Identities live at the account level: one person, one identity. Everything that grants access is sealed inside an environment: its own hierarchy, roles, permission catalog, and keys, sharing nothing with the next.

Account: Acme
acme · identity boundary
shared

Identities

One person is a single identity, unified across every environment in the account.

Environment: production
acme · production
isolated

Hierarchy tree

Its own tree shape, never shared or joined across environments.

Roles & permissions

Its own catalog and roles, defined for this environment alone.

API keys & integrations

Keys, OAuth clients, and webhooks scoped to this environment only.

An environment shares nothing with the next: by design, not convention.
Per-tenant configuration

Each environment defines its own everything

No shared assumptions. No global constraints. No two environments need to look alike.

Permission catalog

Its own vocabulary of permission keys.

Roles

Roles that bundle exactly the permissions it needs.

Hierarchy schema

Its own tree shape and depth.

Integrations

Its own API keys and connected systems.

No two environments need to look alike.

Account onboarding

Self-service from day one

New accounts are created through a self-service flow, and each starts with a ready-to-use environment that evolves independently.

1 Create

Self-service signup

A new account spins up with its first environment, isolated and ready instantly.

2 Start flat

Sensible defaults

Each environment begins with the essentials, ready to use.

A root node (flat RBAC)
System roles
Default permission catalog
3 Evolve

Grow into a hierarchy

Add regions, teams, and custom roles to any environment, independently of every other one.

Designed to scale

Add environments without changing your architecture

Each environment grows independently, from flat RBAC to a deep hierarchy.

No shared permission state
No cross-environment joins
No coupling between environments
Acme
Northwind
Cargo
Vertex
Lumen
Orbit
Pylon
+ many
Example

One platform, three very different tenants

A retail chain, a healthcare provider, and a logistics company: each in its own environment, with its own hierarchy, permission model, and roles. All coexisting, completely isolated.

Retail chain
Region → Store → Dept
West Region
Store 12
Store 34
Grocery
Pharmacy
store.openinventory.manageRegional Mgr
Healthcare provider
Facility → Unit → Team
Central Hospital
ICU
Cardiology
Team A
Team B
chart.viewrx.approveAttending
Logistics company
Hub → Route → Driver
Central Hub
Route 1
Route 2
Route 3
Driver
route.assignfleet.manageDispatcher
No conflicts, no overlap: each environment configures access control for its own reality.

Ready to simplify access control?

Create an account and have authentication and hierarchical access control running today.