mcpField
M
multitenant

multitenant

github.com/thebeardedbearsasDevelopment107113 installsUpdated today
Repository

About multitenant

A reference for developers building multitenant applications, with isolation strategies, security invariants, and implementation examples. It covers isolation tiers from shared schemas to dedicated databases, as well as RLS, access control, and migration considerations.

Key features

  1. 01Three tiers of tenant data isolation
  2. 02tenant_id propagation and PostgreSQL RLS
  3. 03Tenant isolation testing requirements
  4. 04Audit trails and field-level encryption
  5. 05RBAC and ABAC selection guidance
  6. 06Laravel and Symfony examples

Use cases

  1. 01Choose an isolation approach for customer segments
  2. 02Prevent accidental cross-tenant data access
  3. 03Plan migration to tenant-specific infrastructure
  4. 04Design access control and sensitive-field protection

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/thebeardedbearsas/claude-craft --skill multitenant

After installing, type/multitenantin Claude Code to confirm it loaded.

Bundled filesREFERENCE.md

Details

From the project README

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

TierIsolationCoûtCas d'usage
Tier 1 — Shared schemacolonne tenant_id partout, filtres SQL automatiquesFaibleStartups, free / petits clients
Tier 2 — Dedicated schemaun schéma PostgreSQL par tenantMoyenSMB, clients exigeants
Tier 3 — Dedicated DBune 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

  1. tenant_id propagé à chaque requête (AsyncLocalStorage / SecurityContext / middleware).
  2. PostgreSQL Row-Level Security (RLS) activé sur TOUTES les tables. Filet de sécurité contre un oubli applicatif.
  3. Tests d'isolation obligatoires. Tenant A ne doit jamais lire/écrire les données de B — y compris via tri, requête nuée, agrégat.
  4. Audit trail isolé par tenant. Pas de log multi-tenant cross-référencé sans permission explicite.
  5. Field-level encryption sur PII / secrets sensibles (Halite PHP, Eloquent Casts, libsodium).

Pattern minimal — Shared schema + RLS

ALTER TABLE invoices ADD COLUMN tenant_id UUID NOT NULL;
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

// Symfony — middleware qui set la variable session pour RLS
$conn->executeStatement(
    'SET LOCAL app.tenant_id = :tid',
    ['tid' => $tenantId]
);

Anti-patterns critiques

  • ❌ Oublier le filtre tenant_id dans une requête raw → fuite cross-tenant.
  • ❌ Cache Redis sans préfixe tenant → données de A retournées à B.
  • ❌ Job worker async qui perd le tenant_id → impossible de retrouver le contexte.
  • ❌ Signed URLs / tokens sans tenant_id dans le payload → utilisable cross-tenant.
  • ❌ Field encryption avec une clé unique partagée → compromission = exposition totale (préférer keys per tenant).

RBAC / ABAC

  • RBAC : rôles globaux (admin, member, viewer) suffisent pour 80 % des cas.
  • ABAC : passer à des policies (Casbin, Cerbos, OPA) quand les règles dépendent d'attributs (région, montant, statut).

Pour aller plus loin

Patterns détaillés par tier, migration tier 1 → tier 2 sans downtime, tests d'isolation (Pest + tenant fixtures), RBAC/ABAC, exemples Laravel + Symfony, checklists par phase : voir @.claude/skills/multitenant/REFERENCE.md.

Comments

Markdown supported