Better Auth SaaS Template

Better Auth keeps the session table in your database. That avoids a per-seat auth bill and an external user store to synchronize, while allowing direct joins between users and application tables.

The trade-off is that flows handled by a hosted provider become code in your repository. A better auth saas template is most useful when it already implements those flows, because setting up the auth library is only one part of multi-tenant SaaS authentication.

So this page is about the files. Which tables land in your schema, which defaults are already switched on before you notice them, and how much of your codebase ends up knowing the name of your auth provider.

Eleven tables, and where the multi-tenancy hides

The starter adds seven models for the auth engine and four for the application:

Two of them get their own section further down, because Invitation and Admin are both there for reasons that are not obvious. Session.activeOrganizationId deserves attention first because it shapes most tenant-scoped queries in the app.

Which tenant you are currently acting as lives on the session row. Not in a React context, not in a URL segment, not in a header the client sets. Follow one request through and the consequence shows up at the end:

Decisions the starter already made for you

These defaults ship in the config and should be reviewed before launch:

Invitations skip the plugin, on purpose

The organization plugin ships its own invitation table and the starter declares it, then does not use it. Invites run through the app's own OrganizationInvitation model instead, with statuses pending, accepted, revoked, cancelled, and expired, a Resend email that links to /login?invitation_token=..., and a websocket push so an invitee who already has an account sees it without refreshing.

That is a deliberate trade: more code in your repository in exchange for an invitation lifecycle you can modify. For example, a resend rate limit can be added directly to the application flow. The plugin's table stays declared because the schema has to match what the plugin expects, which leaves an unused model in the schema.

Where the engine's vocabulary stops

Better Auth calls the top organization role owner. The application calls it admin. The translation is kept at the identity boundary:

// apps/backend/src/libs/identity/mappers.ts

// Better Auth's organization plugin makes the org creator an "owner". The domain
// contract only models admin/member (parity with the other starters), and an
// owner has the same capabilities as an admin, so collapse it to "admin" right
// here at the engine boundary. Nothing past this file should ever see "owner".
function normalizeRoleSlug(slug: string): string {
  return slug === "owner" ? "admin" : slug;
}

Past that file the code is written against DomainUser and DomainMembership rather than anything a vendor named, and the way to check how far that actually goes is to diff this starter against its WorkOS twin. Of the roughly 217 files in the pack, 136 are byte-identical between the two. What differs is exactly what you would expect to differ: the auth routes, the modules that fetch a user or a membership, the engine config, and the two auth hooks. One version reads a Postgres row and the other calls an API, so those files necessarily differ.

What does survive the swap is the part that is expensive to rewrite. The CASL permission strings like manage:all and read:user, the role presets they map to, the domain types every route signature is written in, and the admin app's screens are the same on both sides. This limits an engine swap mainly to the identity layer rather than the authorization model, though the effort still depends on later customizations.

Grep the pack for better-auth and you get three files: libs/auth/auth.ts where the engine is configured, features/auth/constants/index.ts for the session cookie name, and the test bootstrap. Keeping those references out of route handlers reduces the amount of provider-specific code involved in a future change.

Which engine fits your team

Self-hosted auth is partly a staffing decision. Your team becomes responsible for operating the user store, while a hosted provider takes on more of that work.

The mapper matters because auth is selected before many teams know their eventual compliance and enterprise requirements. This boundary reduces the cost of changing engines later. If SAML becomes a requirement, the expected work is concentrated in the identity layer, but any provider-specific customizations added elsewhere would increase the scope.

Below is the starter running, and what lands in your repository when you install it, so you can run that diff and count the tables yourself rather than taking my word for either.