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_-]+) — anyuserId-touching regex must allow that shape. - Jobs stamp
userIdat creation. Schedule names are namespaced server-side as{userId}.{slug}. - The
exportstep threadscontext.metadata.userIdinto 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.