ADR 11: Multi-tenant by default
Every capability serves clients from their own profile or instance.
Status: adopted (2026-07-18), owner-stated direction
Context
Backpack serves many clients from shared infrastructure. Client data, access, and billing must stay separable, the way iese (Chatwoot) separates client inboxes into accounts.
Decision
Everything is multi-tenant, using the strongest isolation the platform natively supports:
- Platform-native tenancy first: iese/Chatwoot accounts per client in one deployment, Postiz workspaces per client, Umami websites per site. One deployment, many tenants.
- Instance-per-client where tenancy is weak: Listmonk is single-tenant by design, so each client gets their own instance (cheap containers via the services registry and the deployment substrate).
- The services registry records which tenant or instance belongs to which client, and the console renders per-client views from it.
- Client offboarding must be clean: export their tenant or hand over their instance, delete our access, done.
Consequences
- Spinning up a client means creating tenants/instances, not sharing ours.
- Tools we build (list-hygiene) run per client with per-client outputs, never mixing lists.
- Cross-client aggregation happens only in the console, reading from tenants, never by pooling client data in one store.