better-auth: a TypeScript auth framework that treats plugins as the unit of scope
The most comprehensive authentication framework
At a glance
- What is it?
- better-auth is an MIT-licensed, framework-agnostic authentication and authorization framework for TypeScript whose plugin ecosystem carries features like 2FA and multi-tenancy. The README positions it against libraries that, in its words, require a lot of additional code for anything beyond basic authentication.
- Who is it for?
- better-auth fits TypeScript teams that want authentication and authorization in the same package and are willing to adopt its plugin conventions rather than assemble separate libraries. It is a poor fit if you need a runtime outside Node-adjacent JavaScript, or if you require published audit artifacts before you can ship.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap better-auth claims in the TypeScript auth stack
The README states the problem directly: authentication in the TypeScript ecosystem is a half-solved problem, and other open source libraries often require a lot of additional code for anything beyond basic authentication. That is a claim about integration cost, not about missing primitives. Session handling, password hashing and OAuth flows exist in plenty of packages. What the maintainers argue is missing is the layer above: two-factor authentication, multi-tenant support, and the other features an application needs once it stops being a demo. The README lists 2FA and multi-tenant support as its examples of complex features, and frames the plugin ecosystem as the mechanism that keeps that code out of your application. The intended audience is therefore a TypeScript team building a product, not a team building an identity provider. If you are writing your own auth primitives for learning purposes, this is not aimed at you. If you are maintaining a product where auth is a dependency rather than a feature, the framing is aimed squarely at your situation.
Plugins as the architecture, not an add-on
The repository describes better-auth as framework-agnostic and TypeScript-first, with a plugin ecosystem that adds advanced functionality with minimal code. The repository topics list authentication, iam, oauth, oauth2, oidc, sso and stripe alongside typescript. That topic list is the clearest signal in the supplied material about what the plugin surface covers: OAuth 2.0 and OIDC flows, single sign-on, and Stripe, which in practice means billing-linked subscription state sitting next to identity. The stated design goal is that 2FA or multi-tenancy arrive as plugins rather than as code you write. What the supplied material does not give is the plugin interface itself: no function signatures, no hook names, no lifecycle diagram. So the honest reading is that the architecture is plugin-shaped by description, and the specifics of how a plugin registers routes, extends the user model, or hooks into session creation are not verifiable here. Treat the plugin boundary as the thing to inspect first in the documentation, because that boundary determines how much of your application ends up coupled to the framework.
Getting it running: what the material actually pins down
The README does not include an installation block, a configuration example, or an environment variable list. It links to better-auth.com and the Discord server, and it names the npm package as better-auth via the npm badge. That is the full extent of the setup information available in the supplied text. Any command line, config object, or secret name I wrote here would be invented, so I am not writing one. Practically, this means the first step for an evaluator is the website, not the README: the README functions as a positioning document and a contribution guide, not as a quickstart. The repository does ship a CONTRIBUTING.md and a LICENSE.md, both referenced by relative path, and security reports are directed to GitHub Security Advisories rather than a private email address. That last detail is worth noting because it tells you the project expects public, tracked disclosure with credit to the reporter, as the README states.
Release cadence and what it implies for upgrades
The release list shows v1.7.4 on 2026-09-10, v1.6.31 on the same day, and v1.7.3 four days earlier. Two lines are being maintained in parallel: a 1.7 series and a 1.6 series receiving patches. The last push to main is timestamped 2026-09-10T11:56:25Z, roughly twenty minutes after the v1.7.4 tag, which suggests tagged releases track the default branch closely rather than sitting on a separate release branch. For an adopter, the practical consequence is that patch releases arrive often. Frequent patches are good for security turnaround and bad for teams that pin loosely and upgrade without reading notes. The material does not include a changelog, a deprecation policy, or a stated support window for the 1.6 line, so I cannot tell you how long 1.6.31 will keep receiving fixes. If you are on 1.6, that question is worth asking in the project's issue tracker before you plan a migration.
Where the framework-agnostic claim gets tested
Framework-agnostic is a strong phrase and the README does not qualify it. In TypeScript terms it most plausibly means the core does not depend on a specific HTTP framework's request and response types, with adapters bridging to whatever server you run. That is a reasonable reading, and it is also the claim most likely to break in practice, because auth touches cookies, headers, redirects, and CSRF handling, all of which are framework-specific surfaces. The supplied material contains no adapter list, no supported runtime list, and no statement about edge runtimes or serverless constraints. If your deployment target is a non-Node runtime, or a framework with an unusual request model, you cannot confirm support from what is here. This is the single largest gap in the material, and it is the first thing I would resolve before writing any integration code. A framework-agnostic core is only as useful as the adapter for the framework you actually deploy.
The MIT licence and the maintenance bargain
better-auth is MIT licensed, and the README states plainly that you are free to do whatever you want with it. There is no open-core split described, no commercial tier mentioned, and no contributor licence agreement referenced in the supplied text. That matters for adopters because it removes the usual ambiguity about which features sit behind a paid boundary. The trade-off is the other side of the same coin: MIT plus a community contribution model means the maintenance burden is shared and the roadmap is not contractual. The README asks for contributions, feature suggestions and issue reports, and describes the project as a community effort. Nothing in the material describes a company backing the project, a support contract, or a security response SLA. For a startup shipping a product, that is usually acceptable. For a regulated environment that needs a vendor to sign something, the README offers no path. I am not giving legal advice here: read LICENSE.md and your own obligations, particularly around the security advisory process if you operate in a sector with disclosure requirements.
When a hosted identity provider is the better call
The clearest alternative is a hosted identity service rather than a library you run yourself. The difference is not feature count; it is where the operational responsibility sits. With a hosted provider you get the login flows, the 2FA enrolment screens, the SSO connections and the compliance paperwork as a service, and you pay per monthly active user. With better-auth you own the database tables, the session store, the migration path when the schema changes, and the incident response when something breaks at 3am. The README's own argument is that the library route avoids pushing third-party services as the solution, which is a position about control and cost rather than about capability. The honest split: choose a hosted provider if your team has no one who wants to own an auth database, or if you need SOC 2 style assurances that a library README cannot provide. Choose better-auth if you want the user records in your own database and you are willing to take the pager. Neither choice is wrong; they price the same work differently.
Editorial conclusion
better-auth fits TypeScript teams that want authentication and authorization in the same package and are willing to adopt its plugin conventions rather than assemble separate libraries. It is a poor fit if you need a runtime outside Node-adjacent JavaScript, or if you require published audit artifacts before you can ship. Before committing, read the plugin documentation for whichever feature you actually need, confirm that the plugin exists rather than assuming it, and check the LICENSE.md and security advisory process in the repository. The README's own framing is the right one to hold onto: this is a community attempt at a half-solved problem, so verify the half you depend on.
Community notes