Cloud launching May 2026. The library is MIT and shipping today.
kavachOS

00/kavachOS vs Clerk

Clerk built the components. You built the agent.

Clerk's sign-in card is the benchmark for drop-in React auth. It also stops at human sessions. kavachOS keeps the sign-in flow and adds the primitives agents need: scoped tokens, delegation, M2M, MCP OAuth 2.1. You trade some UI polish for a longer runway.

Managed SaaSkavachOS · MIT

01/Why people land on this page

Three spots where Clerk runs out of runway.

Clerk is built for logged-in humans. That is a feature, not a flaw. It becomes a problem the day you ship an agent, the day your customer's IT team asks about data residency, or the day your B2B invite flow multiplies by your customer count.

  • B2B org billing compounds with customer growth

    Clerk Pro charges $1 per organization member per month on top of the MAU fee. A product with 50 customers averaging 20 seats each is paying an extra $1,000 a month before anything else. kavachOS charges per MAU and leaves org membership flat.

  • No machine-to-machine token support

    Clerk has no M2M token primitive. If a service calls another service, or an agent calls a tool, you end up using long-lived API keys with no delegation metadata and no revocation by scope. kavachOS ships OAuth 2.0 client credentials as a first-class flow.

  • Cloud only, no self-host

    Healthcare, fintech, and any buyer with a VPC requirement will ask. Clerk does not self-host. kavachOS is MIT and runs on Node, Bun, Deno, and Cloudflare Workers, so the answer is not a block on the deal.

02/Where they beat us

Clerk wins these. We are saying so out loud.

If any of these matter more than the reasons above, stay on Clerk. The migration will still be here when the trade-off flips.

Clerk is better at

Prebuilt React components

Clerk's SignIn, SignUp, UserButton, and OrganizationSwitcher are polished to a level most teams will not match on their own. They handle loading states, error states, passkeys, and social in one drop. kavachOS ships headless primitives and shadcn-compatible components. Functional parity, not visual parity on day one.

Clerk is better at

Hosted dashboard maturity

Clerk's dashboard has had two more years of product polish. Impersonation, session inspection, and webhook testing tools are noticeably more developed. kavachOS has the same features in the primary workflow, but the edges are newer.

Clerk is better at

Magic link flow defaults

Clerk's magic link and OTP user experience is dialed in. Redirect handling across devices, code-copy-paste fallback, and rate-limit messages are all thought through. kavachOS covers the same surface area, but you may notice rougher edges in the first month of use.

03/Side by side

The facts on one row each.

No checkmark theater. Each row is a value you can verify against the public docs on either side.

Row

kavachOS

Clerk

  • Starting price

    Clerk free tier excludes organization features and SSO.

    $0 up to 1,000 MAU
    $0 up to 10,000 MAU
  • Org member fee

    Runs alongside the per-MAU charge.

    None
    +$1 per member / month on Pro
  • Open source license

    MIT
    Proprietary
  • Self-host option

    Yes
    No
  • Machine-to-machine tokens

    Client credentials flow
    Not supported
  • Agent identity primitive

    First-class
    None
  • MCP OAuth 2.1 server

    RFC-compliant
    None
  • Enterprise SSO (SAML / OIDC)

    Included on Growth
    Pro or Enterprise plan only
  • SCIM provisioning

    Included on Growth
    Enterprise plan only
  • Prebuilt React components

    Headless plus shadcn set
    Yes, highly polished
  • Cloudflare Workers runtime

    Supported
    Supported with caveats

04/Pricing

Run the number you actually care about.

Everyone argues about pricing in the abstract. Pick the MAU count that matches next quarter and compare the two columns. Ignore the rest.

Clerk

Free up to 10,000 MAU. Pro adds per-MAU and per-member charges. Enterprise SSO and SCIM are gated to higher tiers.

  • Free

    10,000 MAU

    No organizations, no SSO, no custom domains.

    $0

  • Pro

    10,000 MAU

    +$0.02 per extra MAU, +$1 per org member.

    $25 / mo base

  • Enterprise

    SCIM, advanced SSO, dedicated support.

    Custom

kavachOS

Flat monthly. No per-member fee. Agent identity, M2M, and SSO are included where you'd expect them.

  • Free

    1,000 MAU

    Full features, no credit card.

    $0

  • Starter

    10,000 MAU

    Agent identity and M2M included.

    $29 / mo

  • Growth

    50,000 MAU

    SSO, SCIM, priority support.

    $79 / mo

  • Scale

    200,000 MAU

    SLA, dedicated support.

    $199 / mo

  • Enterprise

    Self-host assist, custom terms.

    Custom

05/Migration

The helpers are named to match Clerk. Most files only change the import path.

Before · Next.js with Clerk

ts
// middleware.ts
import { clerkMiddleware } from "@clerk/nextjs/server";
export default clerkMiddleware();

// app/page.tsx
import { auth, currentUser } from "@clerk/nextjs/server";

export default async function Page() {
  const { userId } = await auth();
  if (!userId) return <SignIn />;
  const user = await currentUser();
  return <p>Hi {user?.firstName}</p>;
}

After · Next.js with kavachOS

ts
// middleware.ts
import { kavachosMiddleware } from "kavachos/next";
export default kavachosMiddleware();

// app/page.tsx
import { auth, currentUser } from "kavachos/next";

export default async function Page() {
  const { userId } = await auth();
  if (!userId) return <SignIn />;
  const user = await currentUser();
  return <p>Hi {user?.firstName}</p>;
}
01

Export

Pull the Clerk user objects

Use the Clerk Backend API to page through /v1/users. Pipe the output into kavachos import clerk users.ndjson. External account links (google_oauth_google, etc.) map onto kavachOS provider accounts, so social sign-in keeps working on the next login.
02

Swap

Replace @clerk/nextjs with kavachos/next

The server helpers (auth, currentUser) have matching names and matching return shapes. Most server components compile against both without changes beyond the import statement.
03

Components

Swap SignIn, SignUp, UserButton

import from kavachos/react/clerk-compat during the transition period. The compat components accept the Clerk prop names so your JSX does not have to change while you migrate. When you are done, switch to the native components and delete the compat layer.
04

Org billing

Drop the seat-count tracking code

Any code that clamped seats, pre-billed customers for Clerk's per-member fee, or surfaced the fee in your own UI can come out. kavachOS does not meter org membership.
05

Webhooks

Point Clerk webhook consumers at kavachOS events

The event taxonomy is close. user.created, user.updated, session.ended, organization.membership.created. Update your webhook handler's discriminator and keep the rest of the handler.

06/Decide in thirty seconds

Two columns. Honest test.

Stay on Clerk

  • prebuilt react components
  • hosted dashboard maturity
  • magic link flow defaults

Switch to kavachOS

  • b2b org billing compounds with customer growth
  • no machine-to-machine token support
  • cloud only, no self-host

07/FAQ

Questions people actually ask before they switch.

Short answers. Link to the docs if the long version matters.

Are kavachOS components as nice as Clerk's?
Functionally yes. Visually, Clerk is ahead on polish today. kavachOS ships headless primitives plus a shadcn-compatible component set. They are themeable with Tailwind tokens and match the rest of your app by default. Closer to headlessui than to Clerk's opinionated full-page login, by design.
Does kavachOS have organization support?
Yes. Multi-tenant orgs with roles, invitations, and member management. No per-member fee. An org with 500 members costs the same as an org with 5.
What about Clerk's hosted sign-in page?
kavachOS supports a hosted universal login route if you want one. Most teams embed the components directly because they want the login page to look like the rest of their app. Both options work.
We use Clerk's JWT templates for Supabase integration. Does kavachOS cover this?
Yes. kavachOS issues templated JWTs for third-party services with the same audience-and-claims pattern Clerk uses. Supabase, Hasura, and custom downstream services are supported.
Is the migration compat layer permanent?
No. It exists so you can ship the migration in hours, not days. We remove the compat package after you cut over and you import from the native paths. The compat layer is versioned against Clerk API shapes from the year you migrated so future Clerk changes do not affect you.
What happens to our existing Clerk sessions when we cut over?
Sessions issued by Clerk expire on their existing clock. kavachOS begins issuing fresh sessions at cutover. Most users see a sign-in prompt once. You can pre-warm the database with user records ahead of time so the first sign-in is just a password check, not a signup.
Ship the agent primitive now. Keep the Clerk-shaped DX.
Switch story · Clerk → kavachOS

kavachos/next reads like clerkMiddleware because we wrote the helpers to match. Install the library, import the compat components, and get the M2M and agent pieces you needed. If you want to stay on Clerk for the UI, stay. The migration waits.