Clerk

Quick Verdict

When to use it: You're building a JavaScript/TypeScript app and auth is not your product. Ship faster. Pay later if you scale.

When not to use it: You need to own user data, have data residency requirements, or are building on a non-JS backend.

Best For

• Solo founders shipping fast — <SignIn /> renders a complete auth flow. You're building features while others are debugging session cookies.
• Next.js App Router projects — First-class middleware integration, RSC support, and an auth() helper that works in server components, route handlers, and server actions.
• Teams that don't want to maintain auth — OAuth provider updates, security patches, MFA flows — Clerk handles all of it. You never touch CSRF tokens.
• AI-assisted development — The API surface is small, well-typed, and heavily represented in LLM training data. Code generation works well.

Avoid If

• You need full control over the auth database and session storage — Clerk is a hosted service, your user data lives on their infrastructure
• Your project has strict data residency requirements that Clerk's current infrastructure doesn't satisfy
• You're building a non-JavaScript backend — Clerk's SDK ecosystem is TypeScript-first
• You expect to need deep customization of auth flows (Clerk is opinionated; custom flows require workarounds)
• Budget is a hard constraint long-term — 10k MAU is free, but production SaaS will outgrow this

Why People Choose It

Auth is the feature every app needs but nobody wants to build. Before Clerk, the choices were: build it yourself (weeks of work, ongoing security liability), use Auth.js (flexible but complex setup), or use Firebase Auth (Google lock-in, poor DX).

Clerk found the sweet spot: opinionated enough to "just work" out of the box, flexible enough to customize when needed. The prebuilt components handle 90% of auth UI needs. Middleware integration with Next.js means protected routes require zero boilerplate. You get MFA, social login, magic links, and session management by default.

Hidden Costs

Clerk's free tier is genuinely generous at 10k MAU — but that limit arrives faster than it looks. A viral product launch or SEO win can bring you there quickly.

At scale:

• Pro plan: ~$25/month base + per-seat pricing for organizations
• B2B multi-tenant (Organizations feature): requires a higher-tier plan
• Real-world estimate at 1k paying customers: $50–100/month in Clerk fees alone

If you're building B2B SaaS where each customer has their own org and users, model the Clerk pricing early.

Correct vs Cargo-Culted Patterns

Wrong — manual route protection:

// ❌ Don't add auth() checks in every page/layout
export default async function DashboardPage() {
  const { userId } = await auth()
  if (!userId) redirect('/sign-in')
  // ...
}

Right — middleware-level protection:

// ✅ Configure once in middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'
const isPublicRoute = createRouteMatcher(['/sign-in(.*)', '/sign-up(.*)', '/api/webhooks(.*)'])
export default clerkMiddleware((auth, req) => {
  if (!isPublicRoute(req)) auth().protect()
})

Wrong — ignoring the user sync webhook:

// ❌ Relying only on Clerk's user object everywhere
// Your DB has no local user record — can't create relations

Right — sync users to your DB on creation:

// ✅ Handle user.created webhook from day one
// POST /api/webhooks/clerk
// Store clerkId + email in your users table
// All DB relations use your internal user ID

AI Coding Notes

Claude Code and Cursor handle Clerk well, but watch for these common generation errors:

• Specify the version — the API changed significantly between v4 and v5. Tell your AI tool which you're using.
• Server vs client context — AI tools mix up useAuth() (client) and auth() (server). Server components always use auth() from @clerk/nextjs/server.
• Middleware, not per-route guards — AI sometimes generates individual auth() checks per page. Redirect to the middleware pattern.
• Webhook verification — always check that Svix signature verification is included in generated webhook handlers. Skipping it is a security hole.

Common AI Mistakes

1. useSession() or useUser() in Server Components — client-only hooks. Use auth() from @clerk/nextjs/server.
2. Per-route auth checks instead of middleware — generates repetitive boilerplate. One clerkMiddleware() in middleware.ts is correct.
3. Webhook handlers without Svix verification — AI skips this frequently. Every Clerk webhook handler needs signature verification.
4. Missing user sync to database — Clerk stores users, but your app needs a local users table for foreign key relations. The user.created webhook must insert a local record.
5. Inline component styles instead of appearance prop — generates brittle CSS overrides. Use appearance={{ variables: {...} }} for theme alignment.

Start With / Grow Into / Avoid Until Needed

Start with Clerk if you're building any JavaScript app that needs standard auth (sign-up, sign-in, OAuth, MFA). The cost is an afternoon of setup, the benefit is never writing auth code again.

Grow into Organizations when you add B2B multi-tenant features. The API is consistent — you're extending, not replacing.

Avoid until needed: custom session storage, SAML/enterprise SSO (available but complex), and direct database user management — none of these are Clerk's strength. If you need them from the start, reconsider.

Migration Implications

Migrating off Clerk is moderate pain:

• User passwords don't exist (OAuth only) — migration requires users to re-authenticate or use a one-time migration link
• Session logic, middleware, and all auth() calls need to be replaced
• Your clerkId foreign keys need remapping to your new user IDs
• Allow 3–5 engineering days for a complete migration on a small app

This is the real cost of Clerk's simplicity: the integration is deep. Plan for this trade-off before committing to a large codebase.

Alternatives

• Auth.js (NextAuth) — open-source, self-hosted, full control over session storage and database. Significantly more setup. No vendor cost. See Clerk vs Auth.js.

Final Recommendation

Start with Clerk. If you're shipping a Next.js product and auth is not your product, paying in DX simplicity (and later in dollars) is the right trade. Auth.js is the right answer when you need to own the data or can't accept vendor dependency.

The only mistake is starting with Auth.js for the wrong reason ("it's free") and spending a week on auth you should have shipped in an afternoon.