Every verified stack that runs on Next.js 16 (App Router).
Next.js 16 App Router: file-based routing, server components, and the Edge proxy (Next 16's renamed middleware).
320 verified stacks
Showing 12 across 12 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What Next.js 16 (App Router) gives you
Next 16's App Router keeps the whole application under src/: the scaffold runs create-next-app with --src-dir and --import-alias @/*, so `@/` resolves to src/* and the verified files land on top of a stock project rather than replacing it. initCode writes the database client to src/lib/db.ts, then appends the auth fragment's own files — identity tables at src/db/auth-schema.ts, the auth instance at src/lib/auth.ts, a catch-all handler under src/app/api/auth/, and src/proxy.ts. Each file has exactly one owner; the framework never re-emits the ones auth brought. Server code has two shapes here and they are not interchangeable. A Server Component runs on the server and imports { db } from "@/lib/db" directly, so a page can await a Drizzle query with no API route in between.
Anything that needs a URL — an OAuth callback, a Polar or Clerk webhook, a mutation posted from the client — is a route handler at src/app/api/<path>/route.ts exporting GET or POST. Session checking is split across two tiers on purpose. src/proxy.ts (Next 16's rename of middleware.ts; under --src-dir it must sit beside src/app or Next silently ignores it) runs on the Edge runtime with a config.matcher listing the guarded prefixes — /dashboard/:path* and /settings/:path* out of the box. It only asks whether a session cookie exists and redirects to /sign-in when it does not: no database round trip at the edge. The authoritative check is auth.api.getSession() inside the Server Component or route handler that actually reads rows.
What that means when you build on it: widening the protected surface is a one-line change to the matcher array, but the proxy is not the security boundary — a request carrying any session cookie reaches the page, and the page decides. Keep the real check next to the data. The UI overlay follows the same split, with auth screens under src/app/(auth)/ and the shell and dashboard under src/app/(app)/.
Built for
A Server Component imports { db } from "@/lib/db" — the client initCode writes into src/lib/db.ts — and awaits the Drizzle query inline. No fetch and no API route sit between the page and the row.
The auth fragment owns a catch-all route handler under src/app/api/auth/ (Better Auth's [...all]/route.ts exports GET and POST from toNextJsHandler(auth); Auth.js takes [...nextauth]). The framework composes that file in rather than emitting its own.
src/proxy.ts reads the session cookie on the Edge runtime and redirects to /sign-in when it is missing; its config.matcher — /dashboard/:path*, /settings/:path* — is the list of guarded prefixes, widened per app-type.
auth.api.getSession() from @/lib/auth, called inside the Server Component or route handler that reads rows. This is the real check the Edge proxy deliberately skips, and it is where a protected page's authorization actually happens.
A POST route handler at src/app/api/webhooks/<provider>/route.ts (Polar, Clerk) that verifies the HMAC signature, then delegates to the importable, idempotent record module under src/lib/ — so replays and out-of-order deliveries hit one code path.
Why Next.js 16 (App Router), specifically
Auth runs in proxy.ts (Next 16's renamed middleware) on the Edge runtime: it gates on the session cookie's presence only — full session validation happens in Server Components and route handlers, not in the proxy.
What Next.js 16 (App Router) pulls in
bun add next react react-dom