If you have built authentication in JavaScript over the past few years, you have probably touched Auth.js—born as NextAuth.js and adopted across everything from hobby apps to high-traffic products. The Auth.js team and Better Auth have now announced that Auth.js will be maintained and overseen by the Better Auth team. The maintainers framed the move as continuity with a clearer future: Auth.js will continue to receive security and urgent fixes while new projects are encouraged to start on Better Auth.
For a project that helped a generation of developers “own their auth,” this is less a hard pivot and more a handoff to a team focused full-time on modernizing the primitives. As you weigh your own roadmap, keep that continuity-vs-evolution tradeoff in view.
How we got here
Auth.js (NextAuth.js originally) made OAuth flows, sessions, and provider integrations accessible without dedicated identity teams. As app complexity grew—multi-tenant orgs, SAML/SSO, passkeys, global session stores—the surface area outpaced what a volunteer-led library could reliably maintain. Better Auth emerged to address those gaps with a framework-agnostic TypeScript core and a plugin model aimed at advanced features such as 2FA, SAML SSO, and multi-team support.
When the Auth.js maintainers acknowledged slowing velocity and widening scope, a shared goal—letting teams own their auth without surrendering to proprietary black boxes—made consolidation the pragmatic next step. In short, the backstory is less about replacement and more about aligning stewardship with ambition.
What changes today (and what doesn’t)
Practically, nothing breaks for existing Auth.js users: the project remains available, and security and urgent fixes will continue. The material change is strategic guidance: new builds should prefer Better Auth unless you depend on a specific gap, most notably stateless session management without a database.
The Auth.js docs now point directly to Better Auth (at the time of writing, a redirect is not yet set in place) and include a migration path that maps common schema fields and swaps handlers and client utilities with minimal churn.
On GitHub, there’s a notice in the Auth.js docs that says:
Auth js is now part of Better Auth. We recommend new projects to start with Better Auth unless there are some very specific feature gaps (most notably stateless session management without a database).
The implication is clear: plan for steady operations now, plus a low-friction path to a more actively developed core when you’re ready. From here, your decision shifts from “if” to “when.”
Why Better Auth became the destination
Better Auth’s design centers on three pressures developers feel immediately: breadth of features, predictable extensibility, and long-term maintainability. First, the library ships with the kinds of capabilities that typically force teams to stitch together services: email/password, social sign-on, 2FA, and organization-aware user models.
Next, the plugin ecosystem lets you add higher-order primitives—think SAML SSO or multi-tenant controls—without scattering custom code through your app. Finally, the project’s governance and pace (including an open-source MIT license and an actively maintained release train) match the expectations of teams who want to avoid vendor lock-in while still moving quickly. Taken together, you get an identity foundation that scales from prototype to enterprise patterns without swapping tools mid-flight.
Migration in brief
The recommended path starts by introducing Better Auth alongside your existing stack and mapping schema fields rather than renaming tables. On Next.js, you replace the legacy [...nextauth] handler with Better Auth’s toNextJsHandler, and on the client you move to a generated authClient that exposes signIn, signOut, and useSession.
Most changes are mechanical: expires becomes expiresAt, sessionToken becomes token, and account fields like providerAccountId map to accountId. Because the guide leans on adapters and field mapping, you can stage the work behind feature flags and migrate route by route.
As noted earlier, if you rely on stateless sessions, hold until that lands on the Better Auth side—or scope a hybrid rollout.
Community reaction and governance signals
Early community chatter has mixed the relief of a maintained path with the usual open-source anxieties about sustainability. Better Auth recently announced a $5M seed round, which some see as resourcing for long-term stewardship and others view warily given past experiences with commercial pivots.
The maintainers’ public stance is straightforward: keep Auth.js stable for existing users, concentrate feature development in Better Auth, and keep the core MIT-licensed and community-driven. For most teams, that governance model reduces risk compared with a starved maintenance cycle; for others, it’s a reminder to keep migrations reversible and contracts well-bounded.
What this means for your roadmap
If you’re maintaining a production app on Auth.js, stay the course and schedule a structured review: inventory custom callbacks, session storage, and provider surface, then estimate a migration window that aligns with upcoming refactors. If you’re starting fresh—or re-platforming—choose Better Auth by default and design against its primitives so future features (SAML, orgs, passkeys at scale) remain additive rather than disruptive. Finally, watch the stateless-session thread; if that’s your blocker, treat today’s announcement as a planning marker rather than an immediate action item. From here, the safest posture is “migrate when it helps you deliver,” not “migrate because the logo changed.”
