Multitenant
Build multitenant applications with three isolation tiers—from cost-effective shared schema to enterprise-grade dedicated databases—each with automatic tenant filtering and PostgreSQL Row-Level Security. Covers RBAC/ABAC patterns, field-level encryption for sensitive data, and critical anti-patterns to avoid cross-tenant data leaks.
Multitenant helps you design and implement multitenant architecture with strict data isolation across shared, dedicated schema, or dedicated database tiers.
AI-generated summary based on this skill's SKILL.md
Install
TheBeardedBearSAS/claude-craft/multitenant · repository language: Shell
git clone https://github.com/TheBeardedBearSAS/claude-craft
cp -r claude-craft/.claude/skills/multitenant ~/.claude/skills/multitenantnpx skillfed install TheBeardedBearSAS/claude-craft/multitenantFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do I isolate customer data safely in a multitenant application?
Multitenant provides three isolation tiers to segregate customer data: shared schema (lowest cost, highest risk), dedicated schema per tenant (moderate isolation), and dedicated database per tenant (strongest isolation). Each tier includes automatic tenant_id filtering in SQL queries and PostgreSQL Row-Level Security to prevent cross-tenant data leaks. Choose your tier based on compliance requirements and cost constraints.
What's the difference between shared schema vs dedicated database tenants?
Multitenant supports three approaches: shared schema stores all tenants in one table with tenant_id filtering; dedicated schema isolates each tenant's tables within one database; dedicated database gives each tenant their own PostgreSQL instance. Shared schema minimizes costs but requires strict filtering discipline. Dedicated databases offer maximum isolation for regulated industries but increase operational overhead.
How does Multitenant prevent cross-tenant data leaks?
Multitenant prevents data leaks through automatic tenant_id filtering on every query, PostgreSQL Row-Level Security policies, and field-level encryption for PII. The framework enforces tenant context propagation across async jobs, middleware, and caching layers (Redis prefixing). Built-in anti-pattern detection catches common mistakes like missing WHERE clauses or unfiltered cache keys.
Can Multitenant implement RBAC and field-level encryption for tenants?
Yes. Multitenant supports both Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) patterns within each tenant's isolation tier. Field-level encryption protects sensitive data like PII at the column level, independent of your chosen isolation strategy. Combine these with Row-Level Security for defense-in-depth security.
How do I migrate tenants between isolation tiers without downtime?
Multitenant supports zero-downtime tier migration: move tenants from shared schema to dedicated schema, or from dedicated schema to dedicated database. The framework handles tenant context propagation during migration, maintains data consistency, and allows gradual rollout by tenant cohort rather than all-at-once cutover.
What multitenant anti-patterns should I avoid?
Multitenant documentation highlights critical anti-patterns: forgetting tenant_id in WHERE clauses, caching without tenant prefixes, not propagating tenant context in async jobs, and mixing isolation tiers without clear governance. These mistakes cause cross-tenant data leaks. Use Multitenant's built-in guards and testing utilities (Pest integration) to catch violations early.
SKILL.md
rendered from the published skill — quoted content, verbatim
Multitenant — Quick Reference
Servir plusieurs clients (tenants) sur la même base de code avec isolation stricte et un coût d'infra contrôlé.
Trois tiers d'isolation
| Tier | Isolation | Coût | Cas d'usage |
|---|---|---|---|
| Tier 1 — Shared schema | colonne tenant_id partout, filtres SQL automatiques |
Faible | Startups, free / petits clients |
| Tier 2 — Dedicated schema | un schéma PostgreSQL par tenant | Moyen | SMB, clients exigeants |
| Tier 3 — Dedicated DB | une base entière par tenant | Élevé | Enterprise, compliance stricte (HDS, FedRAMP) |
Règle de migration : commencer Tier 1, migrer un client en Tier 2/3 quand il représente > 20 % du revenu OU exige un SLA spécifique.
Cinq invariants non-négociables
tenant_idpropagé à chaque requête (AsyncLocalStorage / SecurityContext /
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 2 files
.claude/skills/multitenant/REFERENCE.md
.claude/skills/multitenant/SKILL.md