Add Email and Password Auth to libSQL with Better Auth
Most "auth as a service" products hand you a hosted black box. The other option is a blank database and a weekend of wiring. libSQL plus Better Auth lands in the middle: a real SQLite-compatible database you own, with email and password sign-in working in minutes.
This post builds an auth server on libSQL locally with the Layerbase CLI (formerly SpinDB), then deploys the exact same setup to Layerbase Cloud, where the database is set up for the Better Auth schema and applies it in one click.
What is the Layerbase CLI? It is a single CLI for running any database engine locally, no Docker required.
Run libSQL locally
npm i -g layerbase
lbase create auth --engine libsql --startThat gives you a libSQL server with an HTTP endpoint. Grab its connection string:
lbase url authhttp://127.0.0.1:8080Wire up Better Auth
Better Auth talks to libSQL through its Kysely dialect. Install the pieces:
pnpm add better-auth @libsql/client @libsql/kysely-libsql kysely// auth.ts
import { betterAuth } from 'better-auth'
import { createClient } from '@libsql/client'
import { LibsqlDialect } from '@libsql/kysely-libsql'
export const auth = betterAuth({
database: {
dialect: new LibsqlDialect({
client: createClient({
url: process.env.LIBSQL_URL!,
authToken: process.env.LIBSQL_AUTH_TOKEN,
}),
}),
type: 'sqlite',
},
emailAndPassword: { enabled: true },
})Better Auth needs four tables (user, session, account, verification). Generate and apply them with its CLI:
npx @better-auth/cli migrateThat is the only migration step, and on Layerbase Cloud it is a single click (more on that below).
Sign up and sign in
The client SDK reads like Supabase's, so if you have used auth.signUp and signInWithPassword before, this will feel familiar:
// client.ts
import { createAuthClient } from 'better-auth/client'
export const authClient = createAuthClient()
await authClient.signUp.email({
email: 'ada@example.com',
password: 'a-strong-password',
name: 'Ada Lovelace',
})
await authClient.signIn.email({
email: 'ada@example.com',
password: 'a-strong-password',
})Passwords are hashed with scrypt and stored in the account table with providerId set to credential. Nothing lands in plaintext, and you never wrote a hashing line.
Go to production without changing engines
Your local libSQL is bit for bit the same engine you run in production. On Layerbase Cloud, the create flow has a Set up authentication wizard that scaffolds exactly this. Pick your sign-in methods (email and password, plus optional Google or GitHub), and it provisions a database set up for the Better Auth schema, which you apply in one click from the dashboard (or run your own migration). libSQL is the default engine; Postgres is a click away if you would rather. You can seed an admin user when you apply the schema and sign in with it immediately.
Swap two environment variables and ship:
# .env
LIBSQL_URL=libsql://your-db.cloud.layerbase.dev
LIBSQL_AUTH_TOKEN=your-tokenSame auth.ts, same client calls, real TLS connection. If you would rather use Auth.js (Drizzle, Kysely, or Prisma) instead of Better Auth, the dashboard ships copy-paste recipes for each.
Once it is running, the Auth console in the dashboard manages the users for you: list accounts, reset a password, ban someone, or delete them, without writing SQL against the user table. It recognizes Better Auth, Supabase GoTrue, Payload, and generic schemas across libSQL, Postgres, MySQL, and MariaDB, so if you migrate an existing auth database in (a Supabase project, say, with its password hashes intact) you manage those users from the same place.
Not just Next.js
Better Auth is framework agnostic, so the same config works behind Express, Hono, SvelteKit, or plain Node. And because libSQL speaks the SQLite protocol, you can connect from Python (libsql-client plus passlib) or hand-roll sessions with the raw @libsql/client if you want zero dependencies.
Layerbase CLI command reference
lbase create auth --engine libsql --start # create + start a local libSQL
lbase url auth # print the connection string
lbase connect auth # open a shell
lbase stop auth # stop when you are done
lbase start auth # bring it backThe Layerbase CLI runs 20+ engines the same way, so the Valkey cache and Postgres database your app also needs are one command each. When you are ready for production, Valkey and Postgres are a click away on Layerbase Cloud. Prefer a desktop app? Grab Layerbase Desktop.
Keep reading
- Cloudflare D1 alternatives: what you are actually coupled toD1 is SQLite, so your SQL is portable. The coupling is somewhere else: there is no wire protocol, the SQL export rounds any integer past 2^53, and you cannot get the file underneath. Here is an honest inventory, the alternatives, and when staying on D1 is the right call.
- Migrating from Turso to LayerbaseTurso meters reads and writes per row, which gets unpredictable on real workloads. Here is how to move your libSQL database to flat-priced managed hosting on Layerbase: dump it, load it, and point the same libSQL client at a new URL.
- Migrating from Supabase to LayerbaseMove your Postgres and your Supabase Auth users to Layerbase in one pass. The password hashes come across untouched, so you skip the forced reset, then you wire login against your own database.
- Turso alternatives: libSQL hosting without row-read limitsTurso is the dominant libSQL host, but its per-row-read pricing surprises many users on real workloads. Here are alternatives, including self-hosted libSQL.