<!-- StarterPick AI-readable guide source -->
<!-- Canonical: https://starterpick.com/guides/better-auth-v1-stable-saas-boilerplate-migration-2026 -->
<!-- Raw Markdown: https://starterpick.com/guides/better-auth-v1-stable-saas-boilerplate-migration-2026/raw.md -->
<!-- Source path: content/guides/better-auth-v1-stable-saas-boilerplate-migration-2026.mdx -->

---
title: "Better Auth v1 Stable: What Changed for SaaS Boilerplate Adopters in 2026"
description: "Better Auth v1.0 for SaaS boilerplates: stable APIs, plugins, organizations, 2FA, and upgrade paths from 0.x, Auth.js, Lucia, and Clerk."
date: "2026-04-26"
tier: 1
authors: ["team"]
tags: ["better-auth", "authentication", "nextjs", "saas-boilerplate", "migration", "2026"]
---

## TL;DR

Better Auth's v1 milestone made it a credible authentication foundation for SaaS boilerplates, but v1.0 is historical context rather than the current package version. The npm registry reported `better-auth` 1.7.4 on September 11, 2026. Greenfield teams should evaluate the current documentation and plugin schema; migrating teams should inventory users, accounts, sessions, organization data, cookies, and recovery flows before changing handlers or tables.

## Key Takeaways

- Treat “v1 stable” as a release-line milestone, not proof that every early v1 example still matches the current package.
- Organizations, two-factor authentication, passkeys, and bearer-token support are documented plugins with their own schema and security requirements.
- Better Auth's CLI can migrate its built-in Kysely adapter or generate schema for other adapters; adapter-specific migrations remain your responsibility.
- Auth migrations are data migrations. Plan account linking, session invalidation, rollback, and support before changing the login route.
- Self-hosting removes a hosted identity vendor from the path, but it adds operational ownership for secrets, email, abuse controls, backups, and incident response.

## What “v1 Stable” Means in 2026

Better Auth's first-party [v1.0.0 release record](https://github.com/better-auth/better-auth/releases/tag/v1.0.0) marks the historical v1 milestone and links the change set from v0.8.8 to v1.0.0. That matters to boilerplate authors because package adoption no longer depends on a pre-1.0 API. It does not justify a promise that every public interface is frozen or that minor releases cannot require migration work.

The current [Better Auth introduction](https://better-auth.com/docs/introduction) describes a framework-agnostic TypeScript authentication library with database adapters and plugins. The npm registry's [latest package record](https://registry.npmjs.org/better-auth/latest) reported version 1.7.4 when this guide was refreshed on September 11, 2026. The registry's full [package metadata](https://registry.npmjs.org/better-auth) records 1.7.4 as published on September 10, 2026 at 11:36:06 UTC, and the first-party [changelog](https://better-auth.com/changelog) tracks the later 1.x release history.

For a new boilerplate, pin and test the exact current version. For an existing early-v1 integration, read the current release and migration notes before assuming code written for 1.0 remains unchanged.

## Decide What the Boilerplate Owns

A Better Auth integration gives your application more control over authentication data and flows. It also makes the boilerplate responsible for decisions that a hosted provider may otherwise manage.

Before adoption, assign owners for:

- user, account, session, and verification tables;
- email verification, password reset, and transactional delivery;
- OAuth credentials and callback URLs;
- cookie security, trusted origins, and proxy headers;
- abuse prevention, rate limiting, and bot controls;
- backups, restore tests, data retention, and incident response;
- admin tooling and customer-support procedures.

The library can implement authentication primitives. It cannot decide your support policy or operate the surrounding system for you.

## Headline Plugins

### Organizations

The [organization plugin](https://better-auth.com/docs/plugins/organization) adds organization, member, invitation, team, and role-related capabilities with schema requirements documented on the plugin page.

A server configuration can enable it alongside the selected adapter:

```ts
import { betterAuth } from "better-auth";
import { organization } from "better-auth/plugins";

export const auth = betterAuth({
  database: db,
  plugins: [organization()],
});
```

Do not equate the plugin with a complete B2B authorization model. Decide how an active organization is selected, how every application query is scoped, which roles can invite or remove members, and what happens when the last owner leaves. Test cross-tenant access directly.

For an adoption-focused roundup, keep that job on [boilerplates already using Better Auth](/guides/best-boilerplates-using-better-auth-2026).

### Two-Factor Authentication

The [two-factor plugin](https://better-auth.com/docs/plugins/2fa) documents setup and supported flows. Enabling it affects enrollment, recovery, trusted-device behavior, backup codes, and support. Store recovery material according to the documentation and test lockout handling before requiring it for existing users.

### Passkeys

The [passkey plugin](https://better-auth.com/docs/plugins/passkey) documents WebAuthn-based registration and authentication. Passkeys depend on correct relying-party configuration, origin handling, device behavior, and account-recovery design. Test production domains and preview domains separately; a local success does not validate the deployed relying-party settings.

### Bearer Tokens

The [bearer plugin](https://better-auth.com/docs/plugins/bearer) supports credentials sent through an `Authorization: Bearer ***` header instead of relying only on cookies. The documentation also describes security caveats.

Bearer mode can help non-browser clients, but it changes the threat model. Do not store long-lived bearer tokens in browser-readable storage. Define token transport, rotation, revocation, logging redaction, and expiry before using it for mobile or CLI access.

## Database and Adapter Planning

Better Auth's [database documentation](https://better-auth.com/docs/concepts/database) describes core schema and CLI behavior. The CLI can apply migrations for the built-in Kysely adapter. For other adapters, it can generate schema that you then convert into the repo's normal migration workflow.

The [Drizzle adapter documentation](https://better-auth.com/docs/adapters/drizzle) shows current adapter configuration. Use repo-local schema and migration conventions rather than copying a generated shape directly into production.

A safe sequence is:

1. Pin the exact Better Auth version.
2. Configure the selected adapter in a non-production environment.
3. Generate the required auth schema.
4. Review names, types, indexes, uniqueness constraints, and foreign keys.
5. Convert the result into a normal application migration.
6. Apply and test the schema before deploying code that depends on it.
7. Exercise sign-up, sign-in, account linking, password reset, session expiry, and deletion.
8. Rehearse rollback without discarding newly written identity data.

Schema-before-code is essential. Deploying a handler that expects tables or fields not yet present can break every login path at once.

## Next.js Integration

The current [Next.js integration guide](https://better-auth.com/docs/integrations/next) documents route-handler and server-session patterns. Follow the current guide for the package version you pinned.

A route handler typically exposes the auth handler under a catch-all API route:

```ts
import { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";

export const { GET, POST } = toNextJsHandler(auth);
```

On the server, pass request headers when retrieving the session according to the integration guide. Keep authorization separate from session lookup: a valid session identifies a caller, while application policy decides whether that caller can access a tenant, record, or action.

## Migrating from Another Auth System

No universal migration script can cover Auth.js, Clerk, Lucia, Supabase Auth, and custom systems. Their user identifiers, password material, linked accounts, sessions, organizations, and recovery flows differ.

### Inventory before writing code

Create a field-level map for:

| Existing concept | Better Auth destination | Migration decision |
|---|---|---|
| User ID | User table ID | Preserve, remap, or alias |
| Email and verification | User fields | Normalize and retain verification state only with evidence |
| OAuth account | Account table | Map provider and provider account ID |
| Password credential | Credential/account representation | Verify whether safe export is possible |
| Session | Session table | Migrate or invalidate |
| Organization/team | Organization plugin tables | Map roles and ownership |
| Recovery factors | Plugin-specific data | Re-enroll when migration is unsafe |

Do not copy stale sessions by default. A planned sign-in or recovery event is often safer than attempting to preserve every session across systems.

### Auth.js or NextAuth migrations

For an Auth.js-style integration, compare:

- current route handlers and callbacks;
- user, account, session, and verification schemas;
- JWT versus database session behavior;
- provider account identifiers;
- custom claims consumed by middleware or APIs;
- email verification and password reset flows.

Replace one interface at a time in a test environment. A similar table name does not prove compatible semantics.

### Hosted-provider migrations

A hosted provider may own password credentials, sessions, organizations, or factor enrollment. Use that provider's current export documentation to determine what can be transferred. Do not promise a backup API, password export, or seamless factor migration without an exact current source.

Plan for a controlled cutover:

1. freeze or reconcile writes during the final export;
2. import supported identity and organization data;
3. require recovery or re-enrollment where credentials cannot move safely;
4. keep an audited mapping between old and new identifiers;
5. monitor failed sign-ins and account-link collisions;
6. retain a bounded rollback path and customer-support runbook.

### Lucia and custom-auth migrations

Treat a library deprecation or maintainer opinion as context, not migration proof. Inspect your actual schema and session behavior. Custom auth often has fewer abstractions but more undocumented assumptions, so trace every place the application reads identity or authorization data.

## What Better Auth Does Not Remove

Better Auth does not remove the need for surrounding product and security work. Depending on your application, you may still need:

- bot mitigation and rate limits;
- a customer-support admin interface;
- audit events tied to application actions;
- enterprise provisioning or directory synchronization;
- webhook delivery and retry logic;
- legal and retention controls;
- service monitoring and incident procedures.

Check the current plugin and enterprise ecosystem for available options, then distinguish first-party stable functionality from community or application-specific work. This refresh does not make absolute claims about SCIM, audit logs, webhooks, edge runtimes, or hosted admin features because those boundaries can change.

## Cost Comparison

Better Auth's repository publishes the current [license](https://github.com/better-auth/better-auth/blob/main/LICENSE.md), but software license cost is only one part of the decision. A self-hosted integration also uses engineering time, database capacity, email delivery, monitoring, abuse controls, support, and incident response.

Compare alternatives with a twelve-month worksheet built from current first-party prices:

- active users and organizations;
- required SSO or provisioning features;
- authentication email volume;
- database and compute costs;
- implementation and migration time;
- expected support and on-call load;
- cost of a failed cutover or account-recovery incident.

Do not reuse an old “one-tenth the cost” claim or a fixed vendor price table. Hosted-provider pricing and self-hosted operating cost both change with requirements.

## Migration Checklist

### Before the cutover

- [ ] Pin the exact package version and lockfile.
- [ ] Freeze current Better Auth docs and adapter requirements.
- [ ] Inventory identity, account, session, organization, and factor data.
- [ ] Review generated schema through the repo's normal migration process.
- [ ] Define account-linking and identifier mapping.
- [ ] Decide which sessions and factors must be re-established.
- [ ] Test email delivery and recovery flows.
- [ ] Add secret redaction to logs and traces.
- [ ] Prepare rollback and customer-support runbooks.

### During the cutover

- [ ] Apply and verify schema before dependent application code.
- [ ] Control concurrent writes during export and import.
- [ ] Validate counts and representative records without exposing personal data.
- [ ] Exercise every configured sign-in method.
- [ ] Test cross-tenant authorization, not only authentication.

### After the cutover

- [ ] Monitor sign-in failures, account-link collisions, and recovery volume.
- [ ] Rotate temporary migration credentials.
- [ ] Remove old callbacks and secrets only after rollback expires.
- [ ] Confirm deletion, export, and retention procedures.
- [ ] Schedule package and documentation review.

## Should Your Boilerplate Switch?

Choose Better Auth for a greenfield boilerplate when the team wants a TypeScript auth stack, accepts database and operational ownership, and has verified the required plugins against the current version.

Consider migration when the existing provider blocks a required architecture or creates a cost your measured operating plan can beat. Do not migrate only because self-hosting sounds cheaper. The user-data cutover and recovery burden can outweigh subscription savings.

Stay on the current system when it meets requirements, the migration lacks a safe credential path, or the team cannot own authentication operations. A stable existing login is more valuable than a fashionable rewrite.

## Verdict

Better Auth's v1 line expanded the set of SaaS boilerplates that can reasonably own authentication. The current package, however, is beyond 1.0, and every integration should follow the documentation for its pinned version.

For greenfield work, evaluate the current adapter, organizations, two-factor, passkey, bearer, and Next.js guides as one system. For migration, treat schema, identifiers, credentials, sessions, recovery, and rollback as the primary project. The handler change is the smallest part.

Documentation and package metadata were checked on September 11, 2026. Recheck the current package version, migration notes, plugin schema, adapter behavior, and license before implementation.

---

*Compare auth choices in the [Better Auth vs Clerk vs NextAuth showdown](/guides/better-auth-clerk-nextauth-saas-showdown-2026) and the broader [Auth.js v5 vs Lucia v3 vs Better Auth analysis](/guides/authjs-v5-vs-lucia-v3-vs-better-auth-2026).*

*For a greenfield project, see the [Next.js boilerplate Stripe and auth roundup](/guides/best-nextjs-boilerplate-stripe-auth-2026).*