The Auth Stack Devs Are Ditching Auth0 For

The Golden Handcuffs of Managed Auth

Managed identity sounds like a shortcut until the bill arrives. Services like Auth0 and Okta charge per Monthly Active User, so a product that jumps from 10,000 to 100,000 users can see auth costs spike from hundreds to tens of thousands of dollars a month. For B2C apps with spiky traffic, that MAU meter becomes a tax on growth rather than a predictable line item.

Vendor lock-in amplifies the pain. Once you wire your login flows, rules, and user metadata into a proprietary rules engine, migrating off looks like open-heart surgery. Custom actions, proprietary tokens, and hosted login pages all nudge teams to keep paying rather than refactor core authentication logic.

Tightly controlled ecosystems promise safety but often deliver rigidity. Many providers force you through their hosted UIs, their SDKs, and their opinionated flows, making even simple customizations—like adding a new verification step or supporting a weird legacy SSO—feel like fighting the platform. When you need a nonstandard login journey, you discover how little room you actually have.

Data ownership adds another layer of discomfort. User identities, sessions, and audit logs sit in someone else’s cloud, governed by opaque internal policies and rate limits. Export APIs exist, but they rarely give you low-level control over schemas, indices, or how long data actually persists in backups.

For startups in regulated industries, those constraints collide with reality fast. Strict data residency rules in the EU, healthcare, or fintech often demand that user tables live in a specific region or even a specific database cluster. When your provider’s answer is “our roadmap” or an enterprise-only region, your compliance team starts asking why auth is outsourced at all.

Developers are responding by demanding more control, more transparency, and the ability to own the entire stack. Open-source systems such as Ory Kratos flip the model: you run the identity server yourself, define your own schemas, and keep user data in your own database. Managed auth still has a place—but the golden handcuffs are starting to feel a lot tighter.

Meet Kratos: Your Self-Hosted Identity Server

Managed auth platforms want to be your everything. Ory Kratos only wants to be your identity engine. It ships as an API-first, backend-only identity server that sits behind whatever UI, framework, or device you throw at it—Next.js, mobile, SPAs, even legacy monoliths—without forcing you into a proprietary widget or dashboard.

Kratos exposes every major auth operation through HTTP APIs: registration, login, profile management, recovery, and settings. Your frontend never has to store password logic or craft magic links; it just orchestrates flows that Kratos defines and secures. That separation makes auth feel like any other internal microservice, not a black box SaaS product.

Out of the box, Kratos handles the core flows most apps end up rebuilding badly. You get user registration with schema-based validation, password-based login, and optional multi-factor authentication (MFA) for higher-risk accounts. It also manages email verification, account activation, and robust session handling, including session revocation and rotation.

Flows behave like state machines you control via config. You can define where users land after registration, which fields they must fill in, and how recovery or verification links behave. For most apps, that means no custom glue code for “forgot password,” “verify your email,” or “update profile” beyond wiring the UI.

Self-hosted by design, Kratos runs anywhere Docker runs: a laptop, a Kubernetes cluster, or a bare-metal box in a closet. The official quickstart uses a single `docker-compose` file, but the same container image scales up to multi-node deployments. No region lock, no forced migration path, no opaque maintenance windows.

Storage stays under your control. Kratos supports databases like SQLite for local development and PostgreSQL for production, wired through a simple DSN in its YAML config. You own the user table, the audit trail, and the backups, which matters for GDPR, SOC 2, and customers who ask, “Where exactly is my data stored?”

Self-hosting also kills MAU-based pricing anxiety. Instead of paying Auth0 or Okta every time your user graph spikes, you pay for CPU, RAM, and disk. If you need social login, OAuth2, or advanced permissions later, Kratos plugs into the wider Ory stack without forcing a platform rewrite.

Kratos vs. Auth0: A Head-to-Head Tussle

Managed identity starts to look different when you zoom in on deployment. Ory Kratos ships as a Docker-native service you run wherever you like—your Kubernetes cluster, a bare-metal box, or a cheap VPS. Auth0, by contrast, lives primarily as a fully managed SaaS, with infrastructure, scaling, and upgrades abstracted away behind its dashboard and APIs.

That split matters when you need control. With Kratos, your auth stack sits inside your network perimeter, next to your app and databases, wired into your existing observability and CI/CD. Auth0 gives you a polished cloud console and SLAs, but you accept its regions, rollout cadence, and opaque performance tuning in return.

Cost models diverge just as sharply. Auth0 prices on Monthly Active Users, gating features and tenants behind subscription tiers that can spike when signups surge or inactive users briefly return. Kratos is open source: you pay for compute, storage, and ops time, not per-identity rent.

For products with spiky or seasonal traffic—think gaming launches, ticketing platforms, or education tools around exam season—MAU pricing turns into a volatility tax. A self-hosted Kratos cluster can sit quietly on minimal resources and scale horizontally when needed, without a surprise invoice tied to user behavior. You trade predictable infra bills for unpredictable SaaS bills.

Flexibility is where Kratos leans hardest into its API-first design. Every flow—registration, login, recovery, verification, MFA—exposes JSON APIs that any client can call, whether that’s a Next.js SPA, a native mobile app, or a CLI. Identity schemas live in config, so you define traits like company IDs, custom roles, or region flags without waiting for a provider to bless your use case.

Auth0 counters with an enormous catalog of pre-built integrations and rules, but those come with guardrails. You wire into their “universal login” pages, their action triggers, their tenant model. Deeply nonstandard flows—progressive profiling, multi-tenant B2B with custom routing, or complex per-organization policies—often require workarounds or brittle glue code.

Kratos slots into a modular stack: pair it with Hydra for OAuth2/OIDC, Keto for permissions, Oathkeeper as an identity-aware proxy, and Ory Elements for drop-in UI components. Auth0 bundles many of those capabilities behind one brand, but that bundle also reinforces vendor lock-in. For teams willing to own their infrastructure, Ory Kratos - Documentation reads less like product marketing and more like a blueprint for an auth system they actually control.

The Full Ory Ecosystem: Beyond Basic Login

Kratos sits at the center of something bigger: a modular Ory stack that tries to unbundle what platforms like Auth0 and Okta sell as one opaque box. Instead of one monolith, Ory splits identity into focused services you can run, scale, and swap independently. Kratos handles identities and sessions, but it hands off tokens, permissions, and edge enforcement to its siblings.

For OAuth2 and OpenID Connect, Ory Hydra steps in. Hydra acts as your authorization server, issuing OAuth2 access tokens and OIDC ID tokens that standards-compliant clients already understand. You wire Kratos as the login provider, then let Hydra manage consent flows, token lifetimes, and client registrations across web, mobile, and machine-to-machine workloads.

Fine-grained authorization comes from Ory Keto, which implements Google Zanzibar–style relationship-based access control. Instead of hard-coding roles in app logic, you model relationships like “user X can edit document Y” and ask Keto for decisions. That pattern scales from simple RBAC to complex, multi-tenant setups where thousands of permissions change every minute.

Sitting at the edge, Ory Oathkeeper acts as an identity-aware proxy in front of your APIs and services. Oathkeeper validates tokens from Hydra, pulls identity traits from Kratos, and enforces access rules that can delegate to Keto for the final yes/no. You define rules as config, not code, so you can update policies without redeploying your app.

Combine them and you get a full-stack alternative to enterprise suites: Kratos for identities, Hydra for OAuth2/OIDC, Keto for authorization, Oathkeeper as the gatekeeper. Each runs as a container, speaks HTTP/JSON, and stays open-source, so you can deploy on bare metal, Kubernetes, or a single Docker Compose file. Instead of paying per MAU, you pay for infrastructure and keep every piece of the auth pipeline under your control.

From Zero to Login: Your First Kratos Setup

Spinning up Ory Kratos from zero starts with Docker, not a web dashboard. You create a `kratos-demo` folder, drop into a `docker` subdirectory, and wire up a `docker-compose.yml` that pulls the official Ory Kratos image, mounts a local `users.db` SQLite file, and binds a `config/kratos.yml` plus an `identity.schema.json`. One `docker compose up` later, Kratos boots in dev mode, exposing its public and admin APIs on localhost.

The `docker-compose.yml` largely mirrors the official quickstart.yml, but tuned for a laptop. The file sets `KRATOS_PUBLIC_URL` and `KRATOS_BROWSER_URL` to `http://localhost:4433` and `http://localhost:4455`, mounts the config directory, and links a mail server container for verification emails. Ports stay at the defaults—4433 for public, 4434 for admin—so any example client code from the docs works unchanged.

Configuration then moves into two core files: `kratos.yml` and the identity schema JSON. The identity schema, copied from email-password/identity.schema.json, defines a JSON Schema with traits like `email`, `first_name`, and `last_name`, plus password credentials. You can extend it with custom fields—company IDs, roles, or feature flags—without touching Kratos’ core.

The `kratos.yml` file glues everything together. You point `selfservice.default_browser_return_url` and allowed origins at your Next.js app on `http://localhost:3000`, and whitelist HTTP methods and CORS headers. Each flow—`login`, `registration`, `recovery`, `verification`, `settings`—gets a `ui_url` that maps directly to a frontend route such as `/auth/login` or `/auth/register`.

Secrets and email settings live in the same YAML. Demo configs use placeholder secrets, but production setups must rotate strong keys for `secrets.cookie` and `secrets.cipher`. SMTP credentials configure the mail server so Kratos can fire off verification and recovery links, which then bounce users back to those same `ui_url` routes.

On the frontend, a Next.js app ties into Kratos using `@ory/nextjs` and Ory Elements. Environment variables like `NEXT_PUBLIC_KRATOS_PUBLIC_URL=http://localhost:4433` and `KRATOS_BROWSER_URL=http://localhost:4455` go into `.env.local`, matching the Docker URLs. A small `ory.config.ts` wires the SDK to those endpoints.

Next.js middleware does the heavy lifting at runtime. A `middleware.ts` file intercepts requests, calls Kratos’ session API, and either passes authenticated users through or redirects anonymous visitors into the Kratos-driven login flow. With that, you get fully wired registration, login, email verification, and MFA screens running on your own stack, not Okta’s or Auth0’s.

Unpacking the UI: How Ory Elements Saves You Weeks

Managed identity stacks usually fall apart on the front end. You either surrender to a vendor’s hosted login box, or you sink days into wiring form state, validation, and error handling for every auth edge case. Ory Elements exists specifically to kill that grind.

Instead of shipping a single widget, Elements is a full UI component library for React, Next.js (including the App Router), and other modern frameworks. You install it like any other npm package, drop its components into your routes, and point them at your Ory Kratos public endpoint.

The trick: Elements doesn’t hardcode what a “login form” looks like. Kratos exposes each flow—login, registration, recovery, settings, verification—as a JSON schema describing fields, methods, CSRF tokens, and messages. Elements reads that schema at runtime and renders the right UI automatically.

Hit the login route in the demo Next.js app and Elements fetches the login flow from Kratos, then builds the form: email field, password field, submit button, validation messages, plus any extra traits you defined in your identity schema. Toggle on multi-factor authentication or add a username field in Kratos, and the rendered UI updates with zero front-end rewrites.

That dynamic behavior applies across flows. Out of the box, Elements can render: - Login and registration - Account settings and profile management - Password recovery and email verification - MFA enrollment and challenge screens

Developers get full control over presentation. Components ship unstyled or lightly styled, so you can wrap them in your own layout, apply Tailwind or CSS Modules, and brand every screen without reimplementing the logic. You keep your design system while outsourcing the gnarly protocol details.

Time savings compound fast. A typical team might spend 1–2 weeks building and polishing auth forms, then more time maintaining them as requirements change. With Elements, most of that collapses into wiring a few routes and environment variables, as the Better Stack demo shows.

For deeper customization—like changing identity traits, flows, or security policies—you adjust Kratos itself. The official Ory Kratos Docs walk through how those backend changes automatically flow through to your Elements-powered UI.

Security That's Built-In, Not Bolted-On

Security sits at the center of Ory Kratos, not bolted on as an afterthought. Out of the box, Kratos runs every password through Have I Been Pwned’s massive breach corpus, rejecting credentials that have already shown up in real-world leaks. That check alone quietly kills off entire classes of account-takeover attempts that thrive on password reuse.

Kratos also bakes in rate limiting, session hardening, and CSRF protection so you do not have to reinvent them in middleware. Password policies, session lifetimes, and multi-factor authentication live in configuration, not scattered across controllers and plugins. You get a consistent security posture across web, mobile, and API clients because everything flows through the same API-first engine.

Instead of ad-hoc “best practices,” Kratos tracks guidance from NIST, the IETF, and major research groups at Microsoft and Google. That means support for modern hashing algorithms, transport security defaults that favor TLS everywhere, and login flows that avoid anti-patterns like arbitrary password complexity rules. The project’s maintainers explicitly cite work from Troy Hunt and others on usable security, so the defaults lean toward “secure and humane,” not “secure and hostile.”

Compliance teams care less about buzzwords and more about control, and self-hosted Kratos gives you that by design. User identities, sessions, and audit trails live in your own database, in your own region, under your own retention rules. You pick the cloud, the encryption at rest, the backup strategy, and the data residency story that maps to your regulator, not to a vendor’s shared SaaS cluster.

For GDPR, that control translates into practical wins. Data processing agreements become simpler when you are the processor, not just a tenant on someone else’s auth silo. Right-to-erasure, data export, and purpose limitation become implementation details in your own stack instead of support tickets with a third party.

Auth0 and Okta can be configured to meet similar standards, but you always operate inside their guardrails. With Ory Kratos, those guardrails are your own policies, expressed as code and config, and audited alongside the rest of your infrastructure.

Next-Level Features: 2FA in Minutes

Multi-factor authentication usually means juggling SDKs, QR code libraries, and a custom settings UI. With Ory Kratos, you flip a couple of flags in a YAML file and suddenly your app speaks TOTP like a seasoned security product. Kratos exposes the entire 2FA flow through its API, so your backend stays clean and your frontend doesn’t need bespoke security plumbing.

Turn on TOTP in the Kratos config and the server immediately adds a new “2FA” section to the identity flows. When a user opts in, Kratos generates a secret, encodes it as an `otpauth://` URI, and returns a ready-to-render QR code payload. Your app doesn’t touch the secret directly; Kratos stores and encrypts it, then enforces verification on every subsequent login.

The video’s Next.js demo shows how Ory Elements turns that backend capability into a fully managed settings screen. Drop the Elements components into a `/settings` route, point them at your Kratos public URL, and you get a live user dashboard with no extra React state machines. Users can:

• Update profile traits (email, first name, last name)
• Change their password
• Enable or disable TOTP-based 2FA

All of that ships from Elements as pre-built, accessible components that talk to Kratos using its typed flows. You are not wiring custom forms to random endpoints; you are rendering a declarative form model that Kratos defines at runtime. When Kratos adds or changes a field, the UI updates automatically.

During 2FA setup, Kratos walks the user through QR code scanning and first-code verification. The server validates the TOTP against its stored secret, handles clock skew, and marks the second factor as active on the identity record. When users log back in, Kratos upgrades the session from single-factor to multi-factor only after a valid TOTP, and your app just reads the resulting session state.

That separation of concerns is the point: Kratos owns QR generation, secret storage, and TOTP verification; Ory Elements owns the UX. Your app simply consumes a secure, fully managed MFA pipeline that you can stand up in minutes instead of weeks.

The Developer Verdict: Who Should Use Kratos?

Managed identity platforms keep bleeding developers on Hacker News, and Ory Kratos shows up in those threads as the “I wish we’d started with this” option. Commenters consistently call out its API-first design, clean HTTP flows, and the fact that you can run it anywhere Docker runs, from a $5 VPS to Kubernetes. For startups staring down Auth0 or Okta quotes that scale with MAUs, the appeal is blunt: predictable infra costs, no per-user tax, and no proprietary rules engine to unwind later.

Kratos fits best when authentication is a core part of the product, not a checkbox. Teams building multi-tenant SaaS, privacy-sensitive apps, or regulated workloads get full control over identity data, schemas, and lifecycle. You own the database, you define the JSON identity schema, and you decide how to wire flows into your React, Next.js, or native clients via Ory Elements or your own UI.

Ideal projects usually share a few traits: - Need for deep customization of registration, recovery, and settings flows - Requirements around data residency, GDPR, or internal auditability - Long-term plan to add OAuth2, SSO, and fine-grained permissions using Ory Hydra, Keto, and Oathkeeper

That modular architecture is exactly what wins over developers burned by “one giant identity product” platforms. You can start with email/password plus TOTP, then add social login or enterprise SSO later without rewriting everything. The Ory Documentation Hub leans into this, with discrete guides for each service rather than one monolithic setup wizard.

Tradeoffs are real, and Hacker News threads do not sugarcoat them. Running Kratos means owning Docker images, configuration, migrations, SMTP, monitoring, and incident response. You replace a SaaS bill with operational overhead: Terraform modules, CI pipelines, log aggregation, and on-call rotations.

Engineering-led organizations tend to see that as a fair trade. If you already run PostgreSQL, Redis, and a service mesh, adding one more Go service is noise, not chaos. For a two-person team shipping a marketing site with login, though, a fully managed service may still be faster, even if the Auth0 invoice stings later.

Kratos is a conscious choice. You buy freedom from vendor lock-in at the price of running your own identity backbone—and for a growing slice of developers, that deal finally looks good.

Your Auth, Your Rules: The Final Takeaway

Control defines modern infrastructure, and Ory Kratos is what control over identity actually looks like. Instead of renting your login box from Auth0 or Okta and praying pricing doesn’t spike with your next traffic bump, you run your own identity server, ship it in Docker, and wire it into any stack—Next.js, React, Go, you name it. Auth stops being a black box and becomes regular app code again.

Kratos flips the script on SaaS dependency. You get an API-first engine that handles registration, login, recovery, email verification, and MFA, while staying agnostic about UI and frontend frameworks. Need OAuth2, fine-grained permissions, or an identity-aware proxy? You plug in Hydra, Keto, or Oathkeeper when you actually need them instead of buying an all-or-nothing platform.

Cost structure changes too. Managed auth bills by MAUs and features; a sudden jump from 10,000 to 100,000 users can turn into a five-figure surprise. Kratos is open source, so your main costs are compute, storage, and ops time, and you can self-host on anything from a $5 VPS to Kubernetes in multiple regions.

Developer experience stays first-class. Ory Elements gives you pre-built React/Next.js components, so you get working login, registration, and settings flows in hours, not weeks. The quickstart Docker Compose file, sample identity schema, and Next.js example app mean you can go from zero to a running stack with email verification and TOTP-based 2FA in an afternoon.

So this is less about swapping one auth provider for another and more about deciding who owns your identity layer. If you’re starting a new SaaS, refactoring a monolith, or trying to escape Auth0 sticker shock, block out a day and wire up Kratos. Audit your current auth: pricing, lock-in, export paths, and flexibility. Then decide if your next project should run on someone else’s roadmap—or on your own.

Frequently Asked Questions

What is Ory Kratos?

Ory Kratos is an open-source, API-first identity and user management server. It handles core authentication flows like registration, login, MFA, and account recovery, allowing developers to self-host and maintain full control over their auth stack.

Is Ory Kratos completely free?

Yes, the core Ory Kratos software is open-source and free to self-host. Ory also offers a paid enterprise license and a managed cloud service (Ory Network) that provide additional features like high-availability, SLAs, and dedicated support.

How does Ory Kratos compare to Auth0?

Kratos offers greater flexibility, control, and cost-effectiveness through its self-hosted, open-source model. Auth0 is a fully managed service that provides faster setup and extensive pre-built integrations but comes with vendor lock-in and potentially higher costs.

Can I migrate my existing users from Auth0 to Ory Kratos?

Yes, Ory provides documentation and guides on how to migrate an existing user base from platforms like Auth0 to Kratos, allowing for a smoother transition.