Better Auth, reviewed: framework-agnostic auth that takes Auth.js seriously

What Better Auth is

Better Auth is an open-source authentication and authorization framework for TypeScript, authored by Bereket Engida and a small contributor base. The project positions itself as “the most comprehensive auth framework for TypeScript,” per the language on its public homepage at better-auth.com, and the framing matters: it is a library you install in your app, not a hosted service you connect to. There is no Better Auth tenant, no per-MAU billing, no vendor account to provision. You bring your own database, your own server, and your own deployment. Better Auth is the code that runs in between.

The library is framework-agnostic by design. It exposes a server-side auth handler that ships with adapters for Next.js, Nuxt, SvelteKit, Remix, Astro, Hono, Express, Elysia, and the standalone Node HTTP server. The client SDK is similarly modular: better-auth/react, better-auth/vue, better-auth/svelte, and better-auth/solid all wrap the same wire protocol. That breadth is the project’s most concrete differentiator from Auth.js, which has historically centered on Next.js with retrofitted support for other runtimes.

The project is licensed MIT. It is free to use, modify, and self-host. There is no “cloud tier” product. If you outgrow what the library does, you fork it or write a plugin — the same path you have with any open-source framework.

What ships out of the box

The Better Auth core, before any plugins are loaded, covers what most production SaaS apps need on day one:

• Email and password with optional verification flows, password reset, and configurable hashing (defaults to scrypt; argon2 and bcrypt are available).
• Social OAuth for Google, GitHub, Apple, Discord, Microsoft, Facebook, X (Twitter), Spotify, GitLab, Twitch, and a generic OIDC provider for anything else. Provider configs are typed objects you drop into the auth handler.
• Magic link sign-in via the magic-link plugin (technically a first-party plugin, but documented alongside the core flows).
• Two-factor authentication — TOTP and backup codes via the twoFactor plugin, with QR code generation built in.
• Session management with cookie-based and JWT-based sessions, configurable expiry, and a session table that lives in your own database.
• Email verification with token issue, expiry, and a hookable email send function (you bring your own provider — Resend, Postmark, AWS SES, etc.).
• Password reset flows with the same hookable email send pattern.
• CSRF protection, rate limiting, and a typed cookie store with sane defaults (SameSite=Lax, Secure, HttpOnly).

The shape of the API is the most important thing to understand. You configure a single auth object on the server with your providers, plugins, and database adapter, then mount the handler at /api/auth/*. Everything else — sign-in, sign-up, sign-out, session, verification, MFA challenge — is a route on that handler. The client calls those routes through a typed SDK. There are no pre-built UI components in the core; you write the form and the SDK handles the wire.

Plugins

The plugin system is where Better Auth makes its biggest pitch. Auth.js (formerly NextAuth) has long been criticized for the long tail of features it does not natively support — organizations, multi-session, RBAC, passkeys — and the painful escape hatches required to add them. Better Auth ships first-party plugins for most of that surface. From the plugins documentation:

• organization plugin — B2B teams, invitations, member roles, and per-organization scoping. Comparable in scope to Clerk’s organizations feature, except free.
• twoFactor plugin — TOTP, backup codes, and a challenge flow you wire into your sign-in UI.
• passkey plugin — WebAuthn-based passkey registration and sign-in, with cross-device discoverable credentials.
• multiSession plugin — lets a single user have multiple active sessions on different devices, switch between them, and revoke individually.
• username plugin — adds a unique username field to the user model (separate from email), with the appropriate sign-in handler.
• phoneNumber plugin — phone-based sign-in and SMS OTP verification, with a hookable SMS send function.
• magicLink plugin — passwordless email sign-in via a tokenized link, the pattern most solo founders reach for first.
• admin plugin — an admin role and helper APIs for impersonation, banning, and listing users.
• jwt plugin — mint signed JWTs for downstream services (useful for pairing with Postgres RLS — see our guide on setting up Supabase RLS for multi-tenant SaaS).
• bearer plugin — bearer token auth for mobile or third-party API clients that cannot use cookies.
• Access-control / RBAC primitives — the organization plugin includes role definitions and permission checks, and a standalone access-control utility lets you define resource-action grants outside organizations.

Each plugin is opt-in. You only pay the bundle-size and complexity cost for what you load. That matters for solo founders — the “everything in one” libraries (Auth0, Clerk) bundle the entire feature surface even if you only need email and Google sign-in.

Database adapters

Better Auth does not ship a database. It ships adapters that let it speak to whichever Postgres, MySQL, SQLite, or document store you already use. Per the official adapter docs at better-auth.com/docs/adapters:

• Drizzle ORM — first-class adapter, generates the auth schema as Drizzle table definitions you own and migrate yourself.
• Prisma — adapter that maps the auth tables onto Prisma models, suitable for teams already on Prisma.
• Kysely — lightweight query-builder adapter for projects that prefer a thin SQL layer.
• MongoDB — document-store adapter for teams on Mongo.
• Memory adapter — in-process, ephemeral, for tests and local prototypes.

The adapter abstraction is intentionally narrow: Better Auth defines a small set of operations (find user, insert user, find session, etc.) and the adapter implements them. If you want to use a database that does not have a first-party adapter, writing one is a few hundred lines of TypeScript. The schema is also yours: the migrations land in your repo, the tables sit alongside your application data, and you can join against them freely. That is structurally different from Clerk, where the user table is on Clerk’s servers and you reference users by ID.

Pricing: free, MIT-licensed, and the hosted-vs-DIY tradeoff

Better Auth is free. There is no metered tier, no per-MAU charge, no “upgrade to unlock organizations” gate. Every plugin and adapter listed in the docs is included in the open-source package. The cost you do pay is operational: you host the server, maintain the database, monitor failures, rotate secrets, and own the user table.

This is the central trade-off against Clerk. Clerk’s Pro plan starts at $25/month and meters per MAU above 10K (full breakdown in our Clerk pricing explained guide). At 50K MAU, the Clerk bill is $825/month; at 100K, $1,825/month. Better Auth at the same scale is $0 in software cost — but the database, server, email provider, and your time to maintain the stack are real line items. For a solo founder running on Supabase or Neon Postgres with already-provisioned compute, the marginal cost of adding Better Auth is essentially zero. For a team that wants someone else to be on-call for an auth incident at 3 a.m., Clerk’s SLA is what they are paying for.

The other thing the hosted option buys you is a polished UI out of the box. Better Auth ships no pre-built components in the core, no hosted sign-in page, no <UserButton/>. Some community-maintained component kits exist, but you assemble the UI yourself or use a third-party kit. If “auth UI in 10 minutes” matters more than the bill, that is a real cost.

When Better Auth fits

• You want full control over the user table. User records live in your database, joinable with your application data, exportable on day one.
• You don’t want to pay per-MAU. Past 10K MAU, the math against any hosted auth provider works strongly in Better Auth’s favor.
• You’re on a non-Next.js framework. Auth.js feels Next-shaped; Better Auth was built framework-agnostic from the start.
• You want organizations, passkeys, or RBAC without a paid plan. Each is a one-line plugin import.
• You’re building with Drizzle. The Drizzle adapter is the most polished path; the schema generation is genuinely good.
• You’re comfortable wiring your own UI. Custom-branded sign-in screens are the default, not an upsell.

When it doesn’t fit

• You want zero-config UI. No drop-in <SignIn/> or <UserButton/> components in the core. If you want polished pre-built auth pages, Clerk is faster to ship.
• You need SOC 2 or SAML enterprise-grade compliance from a vendor. Better Auth is a library; it cannot hand a customer a SOC 2 Type II report. SAML SSO support is also less mature than Clerk Enterprise or Auth0.
• You want someone to be paged when auth breaks. A hosted vendor owns the uptime; with Better Auth, that is you.
• Your team has no TypeScript depth. Configuring the auth handler, the plugins, and the adapter is a typed-object exercise. Without TypeScript fluency, you will fight the types instead of shipping.
• You need long-tail OAuth providers Better Auth doesn’t cover. The generic OIDC provider works for most, but the “every social provider on earth” coverage is broader on Auth.js.

Better Auth vs Auth.js vs Clerk vs Supabase Auth

The four are the most common picks in the solo-SaaS-on-TypeScript bracket. They differ on philosophy more than features:

The cleanest mental model: Better Auth and Auth.js are libraries, Clerk is a vendor, and Supabase Auth is a vendor that lives inside a database. If you want to write less code and pay a vendor, Clerk wins. If you want to keep the user table inside Postgres and pair it with RLS, Supabase Auth wins. If you want a TypeScript library with the modern feature surface (organizations, passkeys, RBAC) without the Next.js ergonomic baggage of Auth.js, Better Auth is the answer.

For solo founders building Next.js apps, the practical decision tree we walk through in the best auth library for Next.js roundup tends to land here: pick Clerk if you value time-to-launch over per-MAU cost, pick Supabase Auth if you are already on Supabase Postgres and want RLS-native auth (see Clerk vs Supabase Auth), and pick Better Auth if you want the library route without Auth.js’s rough edges. The setup pattern for magic links is similar across all three — we cover the Supabase variant in how to add magic link auth with Supabase, and the Better Auth equivalent is structurally the same: configure the plugin, hook in your email send function, ship.

Bottom line

Better Auth is a credible, modern, free alternative to Auth.js for TypeScript projects of any framework. The plugin system covers the features that drove founders to paid vendors a few years ago — organizations, passkeys, multi-session, RBAC — and the database adapters keep the user table in your own infrastructure. The trade-off is that you write your own UI, run your own server, and accept that compliance attestations come from your hosting and processes rather than a vendor’s SOC 2 report.

For solo founders who already self-host Postgres and write TypeScript daily, it is the lowest-friction path to feature parity with Clerk at $0/month in software. For founders who would rather pay $25/month and never think about it again, Clerk Pro remains the faster ship.

Related reading

• Best auth library for Next.js in 2026
• Clerk vs Supabase Auth — which to pick at each scale
• Clerk pricing explained — the per-MAU math
• How to add magic link auth with Supabase
• How to set up Supabase RLS for multi-tenant SaaS