Every verified stack secured with Clerk.
Clerk: hosted identity (sign-in UI, sessions, user management) mounted via middleware + provider.
240 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 Clerk gives you
Clerk keeps identity on its own servers. The emitted app has no auth instance, no password column and no session table: the card at /sign-in is Clerk's <SignIn/> component rendered under a [[...sign-in]] catch-all so Clerk can mount its own verification and SSO-callback sub-routes there, and the endpoints behind it belong to Clerk. What does land in your database is a single mirror table. db/auth-schema.ts declares user with id set to the Clerk user id (text; varchar(255) on MySQL, so the app-type FK columns match exactly), plus email, first and last name, image URL, and an updated_at column used purely as a staleness key. It exists so app-type schemas can foreign-key user the way they would under a self-hosted auth.
It is not a source of truth, and application code should never write to it. Filling that mirror is a webhook job, and this fragment emits the whole path. lib/identity/record.ts holds recordClerkEvent; the mount is a Next route handler at src/app/api/webhooks/clerk/route.ts, an action in app/routes/webhooks.clerk.ts on React Router, or a Nitro .post.ts handler on Nuxt. Clerk delivers through svix, so the route verifies the raw body against CLERK_WEBHOOK_SECRET before anything reaches the database, and the record core is written for a delivery channel that retries and reorders: the staleness comparison lives inside the UPDATE's WHERE clause so an older event cannot clobber newer state, the insert path absorbs a concurrent duplicate (onConflictDoNothing on Postgres, an ER_DUP_ENTRY catch on MySQL), and user.deleted removes the row. Session checks never touch your Postgres.
Next's proxy.ts runs clerkMiddleware() and calls auth.protect() for anything matching createRouteMatcher(["/dashboard(.*)", "/settings(.*)"]); Nuxt reads event.context.auth() inside a Nitro middleware that the @clerk/nuxt module populates. Even the package name is framework-specific — @clerk/nextjs, @clerk/react-router, @clerk/nuxt — which upstreamPkgFor resolves per cell. The trade is concrete. You never build, style or maintain auth screens, and breaking changes arrive with Clerk's releases rather than your lockfile. In exchange, your user rows are eventually consistent with someone else's database, and a webhook you never configured is a table of missing foreign-key targets that only shows up when an app-type insert fails.
Built for
requireUser() in src/lib/session.ts calls auth() from @clerk/nextjs/server and redirects when userId is null. It sits behind proxy.ts's auth.protect(), which already bounced the request at the middleware layer — no database round-trip in either place.
recordClerkEvent in lib/identity/record.ts handles user.created / user.updated / user.deleted. The UPDATE's WHERE carries the staleness guard (updatedAt IS NULL OR updatedAt < the event's updated_at), so an out-of-order retry is a no-op rather than a regression.
The webhook route rebuilds a svix Webhook from CLERK_WEBHOOK_SECRET and calls verify(raw, headers) on the unparsed body, answering 403 on a signature mismatch and 500 when the secret is missing — the check runs before recordClerkEvent is ever reached.
The (auth)/sign-in/[[...sign-in]] page renders <SignIn signUpUrl="/sign-up" forceRedirectUrl="/dashboard" />, and src/app/layout.tsx wraps the tree in <ClerkProvider> so the nav-user menu's useUser() and useClerk() sign-out work off the hosted session.
upstreamPkgFor swaps the SDK per framework. On Nuxt that changes the shape too: nuxt.config.ts registers the @clerk/nuxt module, which auto-injects the provider and components, and server/middleware/clerk.ts guards prefixes off event.context.auth() instead of a proxy matcher.
Why Clerk, specifically
Hosted: Clerk owns identity and does NOT create a local `user` table. Store `clerk_user_id` as text without a foreign key, or sync Clerk users into a local table via webhook before relying on FKs to `user`.
Route protection is clerkMiddleware() + auth.protect() in the Next proxy (getAuth() in a React Router loader, or event.context.auth() on Nuxt) — logged-out users bounce to Clerk's hosted sign-in, so there are no self-hosted auth pages to build or maintain.
Keeping the local mirror in sync is a webhook job: a svix-verified webhook route replays user.created / user.updated / user.deleted idempotently into the local `user` row, so app-type foreign keys to `user` resolve even though Clerk is the source of truth.
ClerkProvider (client) wraps the app so the hosted <SignIn/> / <UserButton/> components and hooks work; the publishable key is read client-side, while the secret key is only ever read server-side by clerkMiddleware.
What Clerk pulls in
bun add @clerk/nextjsNEXT_PUBLIC_CLERK_PUBLISHABLE_KEYCLERK_SECRET_KEYCLERK_WEBHOOK_SECRETsvix secret that verifies Clerk webhook signatures