Better Auth on Cloudflare Workers with D1, without Drizzle

Summary

Current State

• package.json already includes better-auth. @better-auth/infra is present, but is explicitly out of scope for this implementation and should be removed unless a separate planned feature needs it.
• wrangler.jsonc already binds D1 as env.DB and uses migrations in ./migrations.
• src/lib/auth.ts currently constructs betterAuth({ database: new Database() }) from better-sqlite3. That should be removed for the Cloudflare D1 implementation.
• src/lib/auth-client.ts references createAuthClient without importing it, so the client setup is incomplete.

Findings

Drizzle Tradeoffs

For this project, the non-Drizzle path is the better fit because the application already uses direct D1 APIs, already has SQL migrations, and the stated requirement is to avoid Drizzle. Drizzle becomes more attractive only if the broader application wants to standardize on an ORM/query-builder workflow.

Current Better Auth docs also distinguish the migration workflow: the built-in Kysely adapter can generate SQL or apply migrations directly, while the Drizzle adapter generates Drizzle schema and expects drizzle-kit to generate/apply migrations. That is a useful Drizzle advantage only if the project wants Drizzle's schema as the source of truth.

Implementation Plan

import { betterAuth } from "better-auth";

export const createAuth = (env: Env) =>
    betterAuth({
        database: env.DB,
        secret: env.BETTER_AUTH_SECRET,
        baseURL: env.BETTER_AUTH_URL,
        trustedOrigins: [env.BETTER_AUTH_URL],
        emailAndPassword: {
            enabled: true,
        },
        plugins: [],
    });

export default {
    async fetch(request: Request, env: Env): Promise<Response> {
        const url = new URL(request.url);

        if (url.pathname.startsWith("/api/auth/")) {
            return await createAuth(env).handler(request);
        }

        return await serverEntry.fetch(request);
    },
};

import { createAuthClient } from "better-auth/react";

export const authClient = createAuthClient({
    baseURL: "/api/auth",
});

Migration Plan

Add a migration such as migrations/0009_add_better_auth_tables.sql. The base Better Auth schema uses user, session, account, and verification. SQLite accepts these table names, but quoting them is safer because user can be confusing in SQL tooling.

CREATE TABLE IF NOT EXISTS "user" (
    "id" TEXT PRIMARY KEY NOT NULL,
    "name" TEXT NOT NULL,
    "email" TEXT NOT NULL UNIQUE,
    "emailVerified" INTEGER NOT NULL DEFAULT 0,
    "image" TEXT,
    "createdAt" INTEGER NOT NULL,
    "updatedAt" INTEGER NOT NULL
);

CREATE TABLE IF NOT EXISTS "session" (
    "id" TEXT PRIMARY KEY NOT NULL,
    "expiresAt" INTEGER NOT NULL,
    "token" TEXT NOT NULL UNIQUE,
    "createdAt" INTEGER NOT NULL,
    "updatedAt" INTEGER NOT NULL,
    "ipAddress" TEXT,
    "userAgent" TEXT,
    "userId" TEXT NOT NULL,
    FOREIGN KEY ("userId") REFERENCES "user" ("id") ON DELETE CASCADE
);

CREATE INDEX IF NOT EXISTS "session_userId_idx" ON "session" ("userId");

CREATE TABLE IF NOT EXISTS "account" (
    "id" TEXT PRIMARY KEY NOT NULL,
    "accountId" TEXT NOT NULL,
    "providerId" TEXT NOT NULL,
    "userId" TEXT NOT NULL,
    "accessToken" TEXT,
    "refreshToken" TEXT,
    "idToken" TEXT,
    "accessTokenExpiresAt" INTEGER,
    "refreshTokenExpiresAt" INTEGER,
    "scope" TEXT,
    "password" TEXT,
    "createdAt" INTEGER NOT NULL,
    "updatedAt" INTEGER NOT NULL,
    FOREIGN KEY ("userId") REFERENCES "user" ("id") ON DELETE CASCADE
);

CREATE INDEX IF NOT EXISTS "account_userId_idx" ON "account" ("userId");
CREATE INDEX IF NOT EXISTS "account_provider_account_idx"
    ON "account" ("providerId", "accountId");

CREATE TABLE IF NOT EXISTS "verification" (
    "id" TEXT PRIMARY KEY NOT NULL,
    "identifier" TEXT NOT NULL,
    "value" TEXT NOT NULL,
    "expiresAt" INTEGER NOT NULL,
    "createdAt" INTEGER NOT NULL,
    "updatedAt" INTEGER NOT NULL
);

CREATE INDEX IF NOT EXISTS "verification_identifier_idx"
    ON "verification" ("identifier");

Confirm the final schema against the exact Better Auth options and plugins used. Plugins such as organizations, admin, 2FA, passkeys, or database-backed rate limiting add more tables or columns. As a pre-implementation aid, run npx auth@latest generate --config src/lib/auth.ts --output schema.sql against the final auth config and compare the generated SQL with the hand-written D1 migration before applying it.

Validation

1. Run npm exec -- wrangler types after adding BETTER_AUTH_SECRET or other vars to Wrangler config, if they are declared there.
2. Apply migrations locally with npm run db:migrate:local.
3. Start local dev with npm run dev or npx wrangler dev depending on the preferred local runtime path.
4. Verify GET /api/auth/ok returns { status: "ok" }.
5. Exercise /api/auth/sign-up/email, /api/auth/sign-in/email, /api/auth/get-session, and /api/auth/sign-out through the Better Auth client.
6. Run npm run build, npm run test, and npm run check before deploying.
7. Apply remote migration with npm run db:migrate:remote before deploying auth-dependent code.

Open Questions

• Should the whole application require login, or only settings and mutation/server-function paths?
• Which sign-in methods are required: email/password, magic link, OAuth, or invite-only accounts?
• Should @better-auth/infra be removed from package.json now, or is it needed by another planned feature outside this auth implementation?
• Should sessions stay in D1, or should a secondary storage option be considered later if session read volume becomes high?