Clerk, authentication you can ship in an afternoon
Clerk provides ready made components for sign in, sign up, and account management, so instead of designing forms and handling their states you drop an element into the application and move on to the real work. On top of that comes organisation management, the layer every product sold to companies needs.
What changed in the pricing
This is the first thing to check, because most material online describes the state before the change.
On 5 February 2026 the free threshold rose from ten thousand users to fifty thousand, and unlimited applications moved into every plan. For most projects that means authentication stops being a budget line until real scale arrives.
The billing unit changed too, and that difference is worth understanding. Clerk counts users retained in a month, meaning those with an active session or returning to the application, rather than every account that ever signed in. It is a narrower measure than most competitors use, so when comparing offers, do not put those numbers side by side directly.
| Plan | Cost | What it covers |
|---|---|---|
| Free | 0 USD | Up to 50,000 retained users, unlimited applications |
| Pro | from 25 USD per month, 20 USD billed annually | Production features, 50,000 users included, one enterprise connection |
| Business | from 300 USD per month | Extended team features and compliance |
| Enterprise | annual quote | Corporate requirements, support |
At a hundred thousand retained users the Pro bill reaches roughly a thousand dollars a month, so the break even point against a homegrown implementation sits somewhere around there.
That figure comes from the tiers charged above the fifty thousand users included in the plan. The first fifty thousand of overage cost two cents per person per month, and later bands step down to 1.8, 1.5, and 1.2 cents. The rate falls with scale, then, while the bill still grows linearly, because the discount applies only to subsequent bands rather than to the whole.
Organisation support is priced separately, and on a product sold to companies that item is often larger than the users themselves. The B2B authentication add on costs a hundred dollars a month and includes a hundred organisations, with each one beyond that billed on top. If you are building a tool for teams, price both items together, since the figures quoted in comparisons usually cover only the first.
First deployment
In Next.js the whole thing reduces to a library, two environment variables, and wrapping the application in a context provider.
npm install @clerk/nextjsNEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_...
CLERK_SECRET_KEY=sk_test_...// app/layout.tsx
import { ClerkProvider, SignedIn, SignedOut, UserButton, SignInButton } from '@clerk/nextjs'
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<ClerkProvider>
<html lang="en">
<body>
<header>
<SignedOut><SignInButton /></SignedOut>
<SignedIn><UserButton /></SignedIn>
</header>
{children}
</body>
</html>
</ClerkProvider>
)
}Notice what is absent from that code. There is no sign in form, no handling of its states, no error messages, no post sign in redirect, and no password reset page. All of it lives in the components rather than in your repository, which is simultaneously the largest advantage and the largest limitation of this approach: you gain time and give up some control over appearance and flow.
Those four components cover most interface needs: a sign in button for signed out visitors, an avatar with an account menu for signed in ones, and conditional rendering by session state. You adjust appearance with theme variables or swap a component for your own while keeping the logic.
Route protection goes through the middleware layer.
// middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'
const protectedRoutes = createRouteMatcher(['/dashboard(.*)', '/settings(.*)'])
export default clerkMiddleware(async (auth, req) => {
if (protectedRoutes(req)) await auth.protect()
})On the server you read session data with one call, without threading a token through components.
Organisations, or selling to companies
This is the element that sets Clerk apart from simpler solutions and usually decides the choice for a product sold to teams.
An organisation is a group of users with roles, invitations, and its own settings. One user can belong to several, and the application switches context between them. Invitations, acceptance, and member management ship as components, so you do not build them from scratch.
The practical consequence is that the identifier in your database cannot be the email address alone. The same person can belong to two organisations with different permissions, so you tie data to a pair: user identifier and organisation identifier.
Filtering data by organisation has to happen server side, from the token rather than a parameter supplied by the client. A mistake here is the most serious class of bug in multi tenant applications, since it lets someone read another company's data by swapping one identifier.
Syncing with your own database
Clerk holds accounts on its side, but your application still needs its own records to attach data to. Webhooks handle that.
// app/api/webhooks/clerk/route.ts
import { verifyWebhook } from '@clerk/nextjs/webhooks'
export async function POST(req: Request) {
const event = await verifyWebhook(req)
if (event.type === 'user.created') {
await db.users.create({
clerkId: event.data.id,
email: event.data.email_addresses[0].email_address,
})
}
return new Response('ok')
}Two things deserve doing right from the start. Verify the request signature, since without it anybody can send you an account created event. Handle duplicates, because webhooks can be delivered more than once, and the record creating operation has to survive a repeat call.
The webhook alone is not enough. An event can fail to arrive if your application happens to be down, so for critical records add a fallback path: on the first request from a signed in user, check whether the record exists and create it if it does not. That single condition closes a gap webhooks do not close by themselves.
Plan for the reverse case too: an account deleted on Clerk's side should have an equivalent in your database, otherwise a year later you will find records with no owner.
When to buy authentication and when to write it
This decision returns in every project, and it deserves settling on numbers rather than convictions.
Writing email and password sign in takes a day. The trouble starts afterwards: password resets, lockout after failed attempts, breached password detection, one time codes, external account sign in, and when selling to companies, a demand for integration with their system. Each of those is another day or week, and together they add up to a project nobody planned.
Maintenance comes on top. Not the day of work to build it, but reacting to change: a library update after a vulnerability report, a change in an external sign in provider's API, adjustments demanded by an audit, tickets about a broken reset. That is several days a year nobody plans for.
On the other side sits the subscription cost and vendor dependence. At fifty thousand users inside the free threshold that cost is zero, but at a hundred thousand it reaches a thousand dollars a month, so a break even point exists and it pays to know where.
A practical rule: buy authentication while it costs less than a week of team time per month. At larger scale, calculate whether a homegrown implementation with a session library comes out cheaper, remembering that moving accounts between systems is expensive and the decision is better made once.
Separately, consider what happens if the vendor changes pricing or terms. Keeping your own user records synchronised through webhooks is cheap and markedly lowers the cost of any future migration.
Sign in methods and what to start with
The platform supports several ways to authenticate, and the choice affects sign up conversion more than it looks on paper.
Password and email is the default and the one users know best. It costs you reset handling, password strength enforcement, and explaining to people why their password was rejected.
Signing in with an external account, Google or GitHub for instance, performs best on conversion, since it removes the whole password invention step. One condition applies: match the provider to the audience. A developer product without GitHub sign in loses at the door, an accounting department product gains nothing from it.
A one time code sent by email is the passwordless variant, comfortable for the user and cheap to implement. It costs the delay of message delivery and a dependency on whether it lands in spam.
Passkeys built on device biometrics are the most secure, since they resist phishing, but not everybody knows them yet. A sensible rollout offers them as an option alongside existing methods rather than instead of them.
With any of these, separate the choice of method from the choice about a second factor. Two factor authentication is worth mandating for accounts with administrative permissions and leaving optional for everyone else, since forcing it on all users depresses sign up conversion.
Clerk against the alternatives
| Solution | Strength | Weakness | Pick it when |
|---|---|---|---|
| Clerk | Ready made components, organisations, fast deployment | Cost climbs noticeably above the free threshold | SaaS product in React, selling to teams |
| Auth0 | Mature enterprise SSO, SAML, extensibility | Pricing jumps once you need MFA and roles | Selling to large enterprises |
| Supabase Auth | Included with the database, full control over data | You build the interface yourself | Project already built on Supabase |
| Kinde | Simple pricing, generous free threshold | Younger product, smaller community | Startup watching costs |
Migrating between these is expensive, since passwords are hashed and not every vendor exports them. Check the export terms before deciding, because that is what ties you down for longer than the pricing does.
Choosing between Clerk and Auth0 usually comes down to who the customer is. For a product aimed at individuals and small teams, ready made components save weeks of work. For sales into large companies, maturity of corporate directory integration decides.
Permissions and authorisation on your side
Authentication answers who the user is. Authorisation answers what they may do, and the second part usually causes more trouble.
A simple role model, administrator and member within an organisation for instance, belongs on the provider side. The role then rides in the token and you check it without querying your own database.
Resource dependent permissions are a different matter. The statement "this user may edit this particular project" does not fit a global role, since it depends on a user and object pair. Keep such rules in your own database and leave only organisation membership and a coarse role in the token.
// app/api/projects/[id]/route.ts
import { auth } from '@clerk/nextjs/server'
export async function PATCH(req: Request, { params }: { params: { id: string } }) {
const { userId, orgId } = await auth()
if (!userId || !orgId) return new Response('unauthorised', { status: 401 })
const project = await db.projects.findFirst({ where: { id: params.id, orgId } })
if (!project) return new Response('not found', { status: 404 })
return Response.json(await db.projects.update({ where: { id: params.id }, data: await req.json() }))
}Note one detail in that code: the project query carries a condition on the organisation identifier from the token. Without it, a user from one company could read another's project by supplying its identifier. It looks obvious written down, and it is among the most common holes in multi tenant applications.
Returning 404 rather than 403 on missing access is deliberate here. A message saying "you have no access to this resource" confirms the resource exists, which by itself is sometimes information you would rather not disclose.
Common mistakes
The first is verifying the session on the client only. Hiding a button is not a safeguard, and every API route has to check the session independently.
The second is deferring webhooks. Adding synchronisation a year later means migrating existing accounts and reconciling state between two systems.
The third is keeping application data in the provider's user metadata. A field for a few values is convenient, but as the application grows it ends with data split across two systems without transactions.
The fourth is skipping a test environment. Test and production keys are separate, so testing in production creates real accounts and distorts your statistics.
The fifth is having no plan for vendor downtime. Sign in stops working for everyone at once, so decide in advance what you tell users and whether open sessions survive the outage.
The sixth is assuming a user belongs to one organisation. That mistake surfaces with the first customer running two teams and requires a database schema change.
FAQ
What does Clerk cost?
The free plan covers up to fifty thousand retained users a month and unlimited applications, which since February 2026 is a five times higher threshold than before. The Pro plan costs 25 USD a month, or 20 USD billed annually, and the Business plan starts at 300 USD.
What is a retained user?
It is a narrower measure than the monthly active user most competitors meter. It counts people with an active session or returning to the application, rather than every account that ever signed in. When comparing offers, do not put those numbers side by side, since they measure different things.
Clerk or Auth0?
Clerk gives ready made components and fast adoption in a React application, so it wins for products aimed at individuals and small teams. Auth0 has more mature support for enterprise scenarios, so it fits better when selling to large organisations.
Does it work outside React?
Yes, libraries exist for several frameworks, and API access lets you use it with any environment. The biggest benefit comes from the ready made components, though, and those are richest in the React and Next.js ecosystem.
Can I migrate users from another provider?
Yes, by importing accounts along with password hashes, provided the previous vendor exports them and uses a supported algorithm. The alternative is gradual migration, where an account moves across on its first successful sign in. Check the export terms with your current provider before deciding.
Current pricing sits on clerk.com, and the documentation at clerk.com/docs.