```bash title=".env"
DATABASE_URL="postgresql://demo:demo@127.0.0.1:5432/badb"
BETTER_AUTH_SECRET="at-least-32-random-characters"   # openssl rand -base64 32
BETTER_AUTH_URL="http://localhost:3000"

```ts title="src/lib/auth.ts"
import { betterAuth } from "better-auth";
import { prismaAdapter } from "better-auth/adapters/prisma";
import { nextCookies } from "better-auth/next-js";
import { prisma } from "./prisma";

export const auth = betterAuth({
  database: prismaAdapter(prisma, { provider: "postgresql" }),
  emailAndPassword: { enabled: true },
  plugins: [nextCookies()], // keep this last
});

export type Session = typeof auth.$Infer.Session;

```ts title="src/lib/auth-client.ts"
import { createAuthClient } from "better-auth/react";

export const authClient = createAuthClient();

Run `prisma generate` first. With no generated client, `auth generate` could not load `src/lib/auth.ts` and hung for three minutes until I killed it. Once the client existed, it finished in seconds and wrote four models, `User`, `Session`, `Account` and `Verification`, mapped to the tables `user`, `session`, `account` and `verification`. The CLI only writes the schema. As the [Better Auth Prisma adapter docs](https://www.better-auth.com/docs/adapters/prisma) say, migrations are left to Prisma.

Better Auth 1.7 also checks the schema at startup. Before the migration ran, it logged `Prisma schema mismatch` and listed the missing tables. That is a useful early warning in CI.

## How do I sign in with a server action?

Call `auth.api.signInEmail()` or `auth.api.signUpEmail()` inside a `"use server"` function, and keep the `nextCookies()` plugin in your config. Without it the server action succeeds but sets no cookie. In my test the user stayed signed out and was redirected back to the sign-in page. With it, the session cookie was set and the redirect to `/dashboard` worked.



```ts title="src/app/actions.ts"
"use server";

import { headers } from "next/headers";
import { redirect } from "next/navigation";
import { APIError } from "better-auth/api";
import { auth } from "@/lib/auth";

export type SignInState = { error: string; email: string } | null;

export async function signIn(_: SignInState, form: FormData): Promise<SignInState> {
  const email = String(form.get("email"));
  try {
    await auth.api.signInEmail({ body: { email, password: String(form.get("password")) } });
  } catch (e) {
    // Return the email: React 19 resets the form after an action.
    if (e instanceof APIError) return { error: e.message, email };
    throw e;
  }
  redirect("/dashboard");
}

export async function signOut() {
  await auth.api.signOut({ headers: await headers() });
  redirect("/sign-in");
}

Why return the email? React 19 resets a form after its action finishes. In my Chrome test, a wrong password showed "Invalid email or password" and the email field was empty. After returning the email from the action and using it as `defaultValue`, the field kept its value. See [useActionState](https://react.dev/reference/react/useActionState) for the pattern. Keep `redirect()` outside the `try` block, because it works by throwing.

## How do I protect routes with proxy.ts?

Next.js 16 renamed `middleware.ts` to `proxy.ts`, and it runs on Node.js, so `auth.api.getSession()` works there. Use the proxy only to redirect signed-out users early. Then check the session again in every protected page or server action, because the proxy can be skipped by a matcher mistake and it is not a security boundary.



```ts title="src/proxy.ts"
import { NextRequest, NextResponse } from "next/server";
import { headers } from "next/headers";
import { auth } from "@/lib/auth";

export async function proxy(request: NextRequest) {
  const session = await auth.api.getSession({ headers: await headers() });
  if (!session) {
    return NextResponse.redirect(new URL("/sign-in", request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ["/dashboard/:path*"],
};

For a proxy with no database call, the [Better Auth Next.js docs](https://www.better-auth.com/docs/integrations/next) offer `getSessionCookie(request)` from `better-auth/cookies`, and label it "THIS IS NOT SECURE!" I tested why. A request with a made-up cookie, `better-auth.session_token=forged.value`, passed the cookie-only proxy. The page's own `getSession()` call then redirected it to `/sign-in`. With the full check in `proxy.ts`, the forged cookie was redirected at the proxy.

Next.js documents the rename and the codemod (`npx @next/codemod@canary middleware-to-proxy .`) in its [proxy.ts reference](https://nextjs.org/docs/app/api-reference/file-conventions/proxy).

## What did my tests show?

Everything in the core flow worked on the first production build (`next build` then `next start`). I tested with curl against the HTTP API and with headless Chrome 155 through the real forms and server actions:

| Test | Result |
| --- | --- |
| Visit `/dashboard` signed out | 307 to `/sign-in` |
| Sign up through the form (server action) | Redirect to `/dashboard`, "Welcome, UI Tester" |
| Same, without `nextCookies()` | No cookie set, user stays signed out |
| Session cookie | `better-auth.session_token`, `HttpOnly`, `SameSite=Lax`, `Max-Age=604800` (7 days) |
| Wrong password | 401 `INVALID_EMAIL_OR_PASSWORD` |
| Sign-in with `Origin: https://evil.example` | 403 `INVALID_ORIGIN` |
| Forged cookie, full proxy check | 307 to `/sign-in` |
| Forged cookie, cookie-only proxy | Passes proxy, page redirects to `/sign-in` |
| Sign out, then visit `/dashboard` | 307 to `/sign-in` |

Two notes. A curl request with no `Origin` header at all was accepted. That matches the [Better Auth security docs](https://www.better-auth.com/docs/reference/security), which allow requests that carry neither an Origin nor Fetch Metadata headers so that server-to-server and native clients keep working. Also, my cookie had no `Secure` flag over `http://localhost`. The [cookies docs](https://www.better-auth.com/docs/concepts/cookies) say cookies are secure in production mode, and `advanced.useSecureCookies: true` forces it.

## How many database queries does Better Auth make per request?

Each `getSession()` call made 2 queries on Prisma 7: one for the session by token and one for the user. A full check in `proxy.ts` plus a check in the page therefore cost 4 queries per page load. The cookie cache brought that to 0, and a cookie-only proxy to 2. I counted with PostgreSQL statement logging, over two warm dashboard loads per setup.

![Database queries per protected page load with Better Auth and Prisma 7: full proxy and page check 4, joins true without relationJoins 4, with relationJoins 2, cookie-only proxy 2, cookie cache 0](https://res.cloudinary.com/wasicloudinary/image/upload/v1792250133/fabwaseem/blog/better-auth-nextjs/diagram-queries.jpg)

| Setup (proxy + page check) | Queries per load | Median load time (local DB) |
| --- | --- | --- |
| Full `getSession()` in proxy and page | 4 | 7.3 ms |
| + `advanced.database.joins: true` | **4** (no change) | not measured |
| + `joins: true` and Prisma `relationJoins` preview | 2 | 6.8 ms |
| + `session.cookieCache` (5 min) | 0 | 5.9 ms |
| Cookie-only proxy, full check in page | 2 | 6.0 ms |

Times are the median of 300 requests from 2 runs against PostgreSQL on the same machine, so each query cost well under a millisecond. With a database in another region, every query is a network round trip, so the query count matters more than these timings suggest.

### Why doesn't `joins: true` reduce queries on Prisma 7?

Because Prisma 7 still runs `include` as separate queries unless you enable its `relationJoins` preview. With `joins: true` alone, the PostgreSQL log still showed `SELECT ... FROM "session"` followed by `SELECT ... FROM "user" WHERE "id" IN ($1)`. After adding `previewFeatures = ["relationJoins"]` and running `prisma generate`, getSession became one `LEFT JOIN LATERAL` query.



```prisma title="prisma/schema.prisma"
generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  previewFeatures = ["relationJoins"]
}

The Better Auth docs promise "2x to 3x performance improvements" from joins, depending on database latency, without mentioning the Prisma preview flag. Prisma's [relation queries docs](https://www.prisma.io/docs/orm/prisma-client/queries/relation-queries) list `relationJoins` as Preview. One caution: in my [Drizzle vs Prisma benchmark](https://www.fabwaseem.com/blog/drizzle-vs-prisma), `relationJoins` made paginated `include` queries with a deep `OFFSET` much slower. The flag applies to the whole client, so measure your other queries after enabling it.

### Should I enable the cookie cache?

Enable it if your sessions rarely change and you can accept a short revocation delay. With `cookieCache: { enabled: true, maxAge: 5 * 60 }`, Better Auth stores the session in a signed `better-auth.session_data` cookie and skips the database. The [session management docs](https://www.better-auth.com/docs/concepts/session-management) warn that a revoked session "may remain active on other devices until the cookie cache expires."



```ts title="src/lib/auth.ts"
export const auth = betterAuth({
  // ...
  session: {
    cookieCache: { enabled: true, maxAge: 5 * 60 }, // seconds
  },
});