Ory Kratos: self-hosted identity flows behind an HTTP API

The identity work Kratos removes from your application

Most applications end up with the same code: a registration handler, a password reset email, a verification link, a profile update endpoint, a second factor prompt. Ory Kratos takes those flows out of the application and exposes them over HTTP. The README lists the scope plainly: self service login and registration, account verification and recovery, multi factor authentication, profile and account management, identity schemas and traits, and admin APIs for lifecycle management. Your services consume those flows rather than reimplementing them.

The audience follows from that shape. If your frontend is a browser app, a native mobile app, or a set of internal services that each need to know who is calling, and you would rather not own the credential storage and the recovery email pipeline, Kratos is aimed at you. The README also positions it for cloud native environments such as Kubernetes, and notes that the same APIs back Ory Identities on the Ory Network. That matters for the decision: you can start self-hosted and move to the managed service, or the reverse, without changing the protocol your application speaks.

API first identity: how the server is put together

Kratos is written in Go and ships as a server binary plus an admin API and a public API. The repository layout reflects that split: identity/, persistence/, courier/, driver/, cmd/ and proto/ sit at the top level alongside go.mod. The courier directory is where outbound messages live, which is consistent with the README's promise of verification and recovery flows that need to send mail or SMS. Persistence is abstracted, and the install guide covers PostgreSQL, MySQL and CockroachDB as backends.

Identity data is not a fixed table. The README calls out identity schemas and traits, so the shape of a user record is defined in configuration rather than hardcoded, and the flows read and write against that schema. Credentials live with the identity, and the login flows include passkeys, social sign in, OIDC, magic links, TOTP and SMS as listed in the project description. The admin API is the lifecycle surface: create, read, update and delete identities outside the user-facing flows.

One architectural detail is worth noting for anyone planning to replace an existing provider. The README recommends running Ory Hydra alongside Kratos when migrating from Auth0, Okta or a similar OAuth2 / OpenID Connect provider. Hydra is the authorization server and token issuer; Kratos holds identities, credentials and the user-facing flows. The README describes the pair as often a drop-in replacement at the protocol level: you repoint client configuration and endpoints at Hydra, migrate identities into Kratos, and keep speaking OAuth2 and OIDC. That is a two-component deployment, not a single binary, and the operational cost should be counted accordingly.

Installing Kratos and running a first flow

The README's quickstart does not install the server directly. It installs the Ory CLI and creates a project, which is the path into Ory Identities on the Ory Network. The README gives this sequence, and the command names and flags are copied from it exactly:

# Install the Ory CLI if you do not have it yet:
bash <(curl https://raw.githubusercontent.com/ory/meta/master/install.sh) -b . ory
sudo mv ./ory /usr/local/bin/

# Sign in or sign up
ory auth

# Create a new project
ory create project --create-workspace 

After `ory auth` completes you are signed in or signed up, and `ory create project --create-workspace` provisions a project you can point an application at. This route gives you the managed service, not a local server.

For a self-hosted deployment the README points at the install guide rather than embedding steps, saying it explains how to install Kratos on Linux, macOS, Windows and Docker, how to configure PostgreSQL, MySQL or CockroachDB, how to deploy to Kubernetes, and how to build from source. The repository also carries quickstart-latest.yml, quickstart-crdb.yml and quickstart-debug.yml at the top level, and a Makefile with targets such as `make lint`, `make docs/cli` and `make docs/api`. The Makefile's own tooling targets show the pinned versions the project builds against, for example golangci-lint v2.10.1 and buf v1.39.0. Because the README does not inline the self-hosting commands, follow the install guide for your platform rather than guessing at flags.

The open source edition is not the whole product

This is the limitation that decides most evaluations, and the README states it without hedging. The self-hosted open source distribution is described as a good fit for individuals, researchers, hackers and companies that want to experiment, prototype, or run unimportant workloads without SLAs. For a business-critical system, the README says you should use a commercial agreement to reduce operational and security risk.

The Ory Enterprise License layers specific things on top: SCIM, SAML, organization login ("SSO"), CAPTCHAs and other features not available in the open source version; regular security releases including CVE patches with service level agreements; support for advanced scaling, multi-tenancy and complex deployments; premium support with SLAs and direct access to engineers; and a private Docker registry with enterprise builds. For guaranteed CVE fixes and current enterprise builds in production, the README says you need a valid Ory Enterprise License and access to the Ory Enterprise Docker registry.

Read that as a boundary, not a defect. If your product needs SAML or SCIM, the open source server does not provide them, and no amount of configuration will change that. If you need a contractual patch cadence for a login system that every user depends on, the open source build does not carry one. Teams that treat Kratos as a free Auth0 replacement and only discover the SSO requirement during procurement have misread the deployment options section.

Kratos against a hosted identity provider

The obvious alternative is a hosted provider such as Auth0, Okta or Firebase, and the README addresses it directly. The difference is where the identity data and the flow logic live. With a hosted provider you call someone else's API and they operate the credential store, the email delivery and the uptime. With Kratos you run the server, choose the database, and own the mail or SMS path through the courier. The README's migration guidance is that Hydra plus Kratos can replace most authorization server and token issuing capability at the protocol level, so the switching cost sits in client configuration, endpoint changes and identity migration rather than in rewriting application code.

A second alternative is the Ory Network itself, which the README presents as the fastest way to production and as API compatible with the open source server. That is not a competitor so much as the same engine under someone else's operations, and it is the honest comparison: self-hosting buys control of infrastructure and data locality, and costs you the operational work the managed service absorbs. A third option is writing the flows yourself, which is what Kratos exists to replace. That choice is defensible for a single internal tool with one login method; it stops being defensible once you add recovery, verification, MFA and social sign in, because each of those is a flow with its own failure modes.

Maintenance, releases and the licence

The repository is not archived, and the last push was on 2026-07-29, which is recent. Releases are not on a tight cadence: v26.2.0 was published on 2026-03-20, v25.4.0 on 2025-11-07, and v1.3.1 on 2024-10-28. The gap between v1.3.1 and v25.4.0 shows a versioning scheme that changed rather than a project that went quiet, but anyone pinning a version should check the CHANGELOG.md in the repository rather than assume a monthly drop.

Upgrade cost is dominated by two things visible in the repository. First, the module is Go 1.26 and the go.mod carries replace directives, including a local replacement for github.com/ory/client-go pointing at ./pkg/client-go and one for github.com/ory/x pointing at ./oryx. Building from source therefore depends on the vendored oryx and client-go trees in the same checkout, so a naive `go get` against the published module is not the supported path. Second, the APIs are the contract, and the generated OpenAPI artifacts under spec/ are what the CLI and SDKs consume.

The licence is Apache-2.0 for the open source distribution, which permits commercial use and modification. That is separate from the Ory Enterprise License, which the README describes as layering on top of self-hosted Kratos for the enterprise features and the vetted builds. Apache-2.0 on the code does not grant you SAML, SCIM or the enterprise registry. If your legal or compliance team needs to know what you are actually entitled to run, that distinction is the one to put in front of them.

Editorial conclusion

Adopt Ory Kratos if you want identity flows as an HTTP API you can run yourself and you accept that the open source distribution is positioned for experiments, prototypes and unimportant workloads without SLAs. Do not adopt it as the login system for a business-critical product on the open source build alone, because the README ties guaranteed CVE fixes, current enterprise builds and advanced features such as SAML, SCIM, organization login and CAPTCHAs to a valid Ory Enterprise License. Before committing, read the install guide for your platform, check whether the identity schema and the database you already run (PostgreSQL, MySQL or CockroachDB) are supported, and decide whether you are deploying the open source server or Ory Identities on the Ory Network, since the two are API compatible but only one of them puts operations on someone else.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. ory/kratos on GitHub
3. Project website
4. README
5. Releases