How we built multi-tenant isolation in NestJS that even a junior dev can't break

About a year ago, a junior dev on our team wrote a cleanup job that nuked records without a tenant filter. In staging, thankfully — but it wiped out an entire test tenant's data and took half a day to restore. That was the wake-up call.

We run a multi-tenant NestJS + TypeORM SaaS (shared database, shared schema, tenant_id column on everything). The classic approach is "just remember to add WHERE tenant_id = ? everywhere." Which works great right up until it

doesn't.

So we built a three-layer safety net. Sharing it because I haven't seen this exact combo written up anywhere, and it took us a few iterations to get right.

Layer 1: Every entity inherits tenant ownership

typescript
  @Entity()
  export abstract class TenantBaseEntity {
    @Column()
    tenantId: string;
  }

  Dead simple. If an entity doesn't extend this, it doesn't get created. We enforce this in code review — no exceptions.
   It means the column physically exists on every table, which matters for Layer 3.

  Layer 2: Tenant context lives on the request

  @Injectable({ scope: Scope.REQUEST })
  export class TenantService {
    private tenantId: string;

    constructor(@Inject(REQUEST) private request: Request) {
      this.tenantId = this.request.user?.tenantId;
    }

    getTenantId(): string {
      if (!this.tenantId) {
        throw new Error('Tenant context not available — are you in a non-HTTP context?');
      }
      return this.tenantId;
    }
  }

  The key addition we made after getting burned: that guard clause. If something tries to query without a tenant
  context, it throws loudly instead of silently returning unscoped data. Fail closed, not open.

  Layer 3: A custom repository that makes forgetting impossible

  @Injectable()
  export class TenantRepository<T extends TenantBaseEntity> {
    constructor(
      private repo: Repository<T>,
      private tenantService: TenantService,
    ) {}

    async find(options?: FindManyOptions<T>): Promise<T[]> {
      return this.repo.find({
        ...options,
        where: {
          ...options?.where,
          tenantId: this.tenantService.getTenantId(),
        } as any,
      });
    }

    async findOne(options?: FindOneOptions<T>): Promise<T | null> {
      return this.repo.findOne({
        ...options,
        where: {
          ...options?.where,
          tenantId: this.tenantService.getTenantId(),
        } as any,
      });
    }

    // same pattern for save, update, delete...
  }

  Devs inject TenantRepository<Whatever> instead of the raw TypeORM repo. The tenant filter is injected automatically on
   every operation. You can't forget it because you never write it.

  The edge case that bit us: background jobs

  Cron tasks, BullMQ workers — anything outside an HTTP request has no request-scoped context, so TenantService blows
  up. We solved this with an explicit TenantContext wrapper:

  await this.tenantContext.runWithTenant(tenantId, async () => {
    await this.tenantRepository.find();
  });

  Honest tradeoffs

  Not gonna pretend this is perfect:

  - Query performance — composite indexes on every table. Our DBA was not thrilled.
  - Request-scoped injection — NestJS creates new instances per request. At scale, look into AsyncLocalStorage with
  nestjs-cls.
  - Raw queries — if someone writes raw SQL, none of this helps. We lint for query() and createQueryBuilder() in CI.

  Running in production for about a year across ~40 tables. Zero cross-tenant incidents since.

  What's next?

  Genuinely curious — anyone gone the schema-per-tenant route with NestJS? We evaluated it early but connection pool
  management seemed nightmarish at ~200 tenants. Also wondering about Postgres RLS as an alternative.

  ---
  We packaged this pattern (along with auth, Stripe payments, RBAC, admin dashboard, and deployment configs) into a full
   SaaS starter kit:

  - 🔗 https://github.com/sayahweb2-png/saas-starter-lite (MIT licensed)
  - 🔗 https://demo.cloudrix.io
  - 🔗 https://demo.cloudrix.io/blog/nestjs-angular-authentication-jwt-oauth