Better Auth: a TypeScript authentication framework with a plugin ecosystem

The half-solved problem Better Auth targets in TypeScript

The README states the premise directly: "Authentication in the TypeScript ecosystem is a half-solved problem." The claim is that other open source libraries require a lot of extra code for anything beyond basic authentication, and that the usual answer is to push a third-party service instead. Better Auth is the response to that, a framework-agnostic authentication and authorization framework for TypeScript. The audience is therefore narrow and specific: teams building a TypeScript application who want password login, sessions and the surrounding features to live in their own codebase and database rather than in a hosted identity provider. The topics list confirms the scope: authentication, iam, oauth, oauth2, oidc, sso, stripe. That is a wide surface for one package, and the README frames the plugin ecosystem as the mechanism that keeps the core small while advanced features stay opt-in.

Plugins as the extension mechanism, not a monolith

The architecture visible in the repository is a pnpm workspace. The root package.json is private and named @better-auth/root; the build script is turbo build --filter=./packages/*, and the test script runs turbo test --continue across packages and a separate test directory. That layout says the published library is assembled from several workspace packages rather than one flat source tree. The README describes the plugin ecosystem as the way advanced functionality is added "with minimal code in a short amount of time," naming 2FA and multi-tenant support as examples. So the data flow is: your application configures the core auth instance, and each plugin registers its own routes, schema additions and hooks against that instance. The demo directory reinforces the framework-agnostic claim: it contains separate entries for nextjs, expo, electron, oidc-client and stateless. A stateless demo is the interesting one, because it implies you can run without server-side session storage, which matters if you are deploying to edge runtimes. The README does not describe the internal request pipeline, so the plugin registration order and hook precedence are things to check in the docs rather than assume.

Installing Better Auth and getting a first session

The README itself gives no install command, no config snippet and no quickstart. It points at the website, better-auth.com, and the docs directory in the repository. So the exact steps below should be treated as the shape of the integration, and you should confirm the current syntax against the docs before copying it. The package is published on npm as better-auth, which is what the npm badge in the README links to.

Start by adding the package to your project with your package manager. The repository uses pnpm at the root, so that is the example here.

pnpm add better-auth

The docs describe creating a server-side auth instance and then mounting a handler on a catch-all route. In a Next.js App Router project the handler lives under app/api/auth/[...all]/route.ts, and the client is created from a separate module so the browser bundle does not import server code. The repository ships a demo/nextjs directory, so a working reference exists even though the README does not reproduce it.

The third piece is the database. The repository has a docker-compose.yml that starts the databases the project tests against: postgres on 5432 with user, password and database better_auth, mongodb on 27017, and redis on 6379. That file is for developing Better Auth itself, not a requirement for your application, but it shows which stores the project exercises. Your own schema is generated through the CLI, and the docs cover adapters for Prisma and Drizzle. If you are wiring Prisma, the CLI generates the models and you migrate them with your normal Prisma workflow.

Finally, the secret. Search data shows people asking how to get the Better Auth secret and what it is. The README does not document a secret generator or a required environment variable name, so treat the value as something the docs define and set it before your first login attempt rather than after a failure.

Where Better Auth is the wrong tool

The framework is TypeScript-first, and the repository reflects that: the root package is TypeScript, the build runs through turbo, and the demos are JavaScript runtimes. Search data includes people looking for Better Auth in Go, and the material lists no Go, Python or Java client. If you are building a service in one of those languages and want a shared authentication layer across polyglot services, a language-neutral identity server is a better fit than a library you cannot call. The second boundary is operational. Because the sessions and user records live in your database, you own the migrations, the backups and the availability of that store. A hosted identity provider absorbs that work. Teams without the appetite to run auth schema migrations should weigh that honestly. Third, the README is a marketing page, not a manual. It states the license, the contribution path and the security reporting process, and it explains the motivation, but it does not document rollback, secret rotation or upgrade procedures. Anyone who needs those answers in writing before adopting will not find them in the README.

How it compares with a hosted identity provider

The alternative most teams actually weigh is a hosted identity service such as Auth0 or Clerk, where user records, sessions and the login UI live with the vendor and you integrate through an SDK and a redirect. The difference in approach is where the state lives and who operates it. With a hosted provider you get a dashboard, managed upgrades and no schema migrations, at the cost of per-user pricing and a dependency on an external service being reachable during login. With Better Auth the user table is in your database, the routes are in your application, and the cost is your own operational work. A second alternative is rolling your own session handling on top of a generic OAuth library. That is the path the README explicitly argues against, on the grounds that anything past basic authentication turns into a large amount of additional code. The honest summary is that Better Auth trades vendor management for code you own; it does not remove the work, it relocates it.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the most recent push recorded is 2026-09-10, with releases v1.7.4 and v1.6.31 both dated 2026-09-10 and v1.7.3 on 2026-09-06. Two release lines are being published in parallel, a 1.7 line and a 1.6 line, which suggests a maintenance branch alongside current development. The repository also carries a .changeset directory and a changeset script, so versioning and changelog entries are generated from changeset files rather than written by hand. For upgrade planning, that means each release should have a corresponding changeset entry describing the change, and you should read those rather than diffing the source. The licence is MIT, stated in the README and in LICENSE.md, which permits commercial and private use and modification. That is a permissive licence, not a copyleft one, so it does not oblige you to publish your own application source. This is a description of the licence text, not legal advice; if your organisation has specific compliance requirements, have counsel read LICENSE.md.

Editorial conclusion

Adopt Better Auth if your application is TypeScript and you want authentication features such as 2FA or multi-tenant support to arrive as plugins rather than as a separate service you operate. Do not adopt it if you need a language-agnostic auth server, since the framework targets TypeScript and the repository lists no Go, Python or Java client. Verify three things before committing: that the docs cover your framework adapter, that your database schema can be generated from the CLI, and that you have a plan for the secret value, because the README does not document how it is produced.

Frequently asked questions

Official sources

1. better-auth/better-auth on GitHub
2. License: MIT
3. Project website
4. README
5. Releases