Skip to content

Multi-tenancy

The platform is multi-tenant from the ground up. A userId is threaded through every vertical’s repositories, so one API instance safely serves many owners.

How it works

  • Auth issues the identity. better-auth user IDs are mixed-case nanoids ([A-Za-z0-9_-]+) — any userId-touching regex must allow that shape.
  • Jobs stamp userId at creation. Schedule names are namespaced server-side as {userId}.{slug}.
  • The export step threads context.metadata.userId into the destination config — this is the seam that owner-scopes social and blog drafts.
  • Social / blog drafts are created owner-scoped; publishing is worker-owned, atomic-claimed, and idempotent, so two writers never race one target.

What you get for free

Because tenancy lives at the repository + step boundary rather than in each feature, a new vertical that follows the pattern (take userId, scope every query) is automatically multi-tenant. Owner-scoping is one of the cross-cutting concerns the platform handles so you don’t have to.