Ory Kratos: the HTTP surface, the forked modules, and what the license gates

Your application owns the screens, Kratos owns the flows

The design goal is stated as removing identity logic from application code and exposing it over HTTP APIs. What lands in your service is a set of flows you call: 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. Alongside them sit integration goals rather than features: working with any UI framework through browser based and native app flows, scaling to large numbers of identities and devices, fitting into Kubernetes and managed platforms, and integrating with the rest of the Ory stack for OAuth2, OpenID Connect and access control. The division matters because the screens are not part of the open source engine. You render the flow, the service returns the next step, and the framework choices stay yours. What you give up in exchange is the piece teams most often rebuild badly, and what you inherit is a dependency you have to operate and secure.

Migrating off Auth0 or Okta means adding Hydra and moving identities by hand

The migration section recommends a pair rather than a swap. Ory Hydra acts as the OAuth2 and OpenID Connect provider and can replace most authorization server and token issuing capabilities of the existing provider. Ory Kratos supplies identity, credentials, and the user facing flows. The pair is described as often a drop in replacement at the protocol level, and then three sentences take that back: you update client configuration and endpoints to point at Hydra, you migrate identities into Kratos, and your applications keep speaking the OAuth2 and OpenID Connect protocols they already use. That third part is the easy part. The README does not document a bulk import path, a credential rehash strategy, or what happens to accounts that have not logged in since the move, so identity migration is a project you schedule and test rather than a step you configure. Budget for it before treating the protocol compatibility as the whole story.

SAML, SCIM and organisation login sit behind the enterprise license

The self host path is real and complete enough for experimentation: the install guide covers Linux, macOS, Windows and Docker, PostgreSQL, MySQL and CockroachDB, Kubernetes and other orchestration systems, and building from source. The open source distribution is positioned for individuals, researchers, hackers and companies running unimportant workloads without SLAs, and you are free to inspect, extend and build it. The catch is stated in the same breath. The Ory Enterprise License layers on top of self hosted Kratos and adds features that are not in the open source version, named as SCIM, SAML, organization login, CAPTCHAs and more, plus regular security releases including CVE patches with service level agreements, support for advanced scaling and multi tenancy, premium support with SLAs and direct access to engineers, and access to a private Docker registry. If your requirement list contains SAML or SCIM, the open source build does not meet it and the README does not offer a partial path.

The only shell commands in the README create a project on the Ory Network

The quickstart block installs the Ory CLI, moves it into /usr/local/bin, signs in, and creates a project. Read the context around it before copying it: it is a path to Ory Identities, the managed product powered by the open source server and API compatible with it.

# 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 "Ory Open Source" --name "GitHub Quickstart"  --use-project
ory open ax login

So the README's quickstart command sequence sends you to a hosted account, not to a Kratos process on your own machine, and it needs root for the move into /usr/local/bin. Self hosting has its own entry point, the install guide, which is where the Linux, macOS, Windows, Docker, database and Kubernetes instructions live. The practical consequence for an evaluation is that the fastest route to a working login screen and the route to owning the data are different routes, and only the first one is written out as copyable shell.

go.mod redirects five upstream modules to Ory forks and two in-tree copies

Before you build anything, read the replace block, because it changes where your dependencies actually come from.

replace (
	github.com/coreos/go-oidc/v3 => github.com/ory/go-oidc/v3 v3.0.0-20250124100243-69986dfaf891

	github.com/go-swagger/go-swagger => github.com/aeneasr/go-swagger v0.19.1-0.20241013070044-bccef3a12e26 // See https://github.com/go-swagger/go-swagger/issues/3131
	// github.com/go-swagger/go-swagger => ../../go-swagger/go-swagger

	github.com/gorilla/sessions => github.com/ory/sessions v1.2.2-0.20220110165800-b09c17334dc2

	// Use the internal httpclient which can be generated in this codebase but mark it as the
	// official SDK, allowing for the Ory CLI to consume Ory Kratos' CLI commands.
	github.com/ory/client-go => ./pkg/client-go

	github.com/ory/x => ./oryx
)

Three well known modules are pinned to forks, one of them to a commit hash chosen to work around a named upstream issue, and two resolve to directories inside the repository, oryx and pkg/client-go. The module declares go 1.26. Consequences reach your pipeline: vulnerability scanners see fork paths rather than the upstream advisories you may have mapped, updating a dependency means tracking an Ory fork rather than upstream releases, and a shallow copy of the source without those directories does not build.

The Makefile fetches its own linters, and one target calls itself deprecated

The build is Make driven and the Makefile fetches tools with curl into a .bin directory that it puts at the front of PATH, under a shell set to /usr/bin/env bash -o pipefail. One target is already flagged in the file itself:

.bin/clidoc:
	echo "deprecated usage, use docs/cli instead"
	go build -o .bin/clidoc ./cmd/clidoc/.

Other targets pin their versions the same way, golangci-lint at v2.10.1 and buf at v1.39.0 for the lint target, hydra at v2.2.0 and ory at v0.2.2, and the API documentation is previewed with npx @redocly/openapi-cli preview-docs spec/api.json. Two consequences for automation. The lint path needs network access on the first run, so it fails in a sealed builder. And the image tag is defined as latest unless you set IMAGE_TAG, while the repository ships three quickstart files, quickstart-crdb.yml for CockroachDB, quickstart-debug.yml and quickstart-latest.yml, so a quickstart run tracks whatever the latest tag points at rather than a digest you pinned.

Tags jump from 1.3.1 to 25.4.0, so version numbers are not an upgrade ladder

The releases on record for this repository are v26.2.0 on 2026-03-20, v25.4.0 on 2025-11-07 and v1.3.1 on 2024-10-28. Between the last two there is a version gap of more than twenty years of numbering and a year of calendar time, which tells you the scheme changed rather than that your dependency is stale. The repository is not archived and the last push to master is 2026-07-29, so work continues after that March release. Read this against the licensing section rather than separately. The README states that guaranteed CVE fixes, current enterprise builds, advanced features and production support all require a valid Ory Enterprise License and access to the Ory Enterprise Docker registry, so the cadence of tags on the public repository is not the signal that your running deployment receives security updates. Track the build your registry actually serves, and treat the tag history as a release channel rather than a compatibility statement.

Editorial conclusion

Ory Kratos suits a team that wants identity flows owned as HTTP APIs rather than library calls inside its own services, and that is prepared to choose deliberately between the managed Ory Network, a plain self hosted open source build, or a licensed one. It does not suit a team expecting SAML, SCIM, organisation login or CAPTCHAs from the open source build, because the README places those behind the Ory Enterprise License, nor a team assuming the public image carries guaranteed CVE fixes, since those are tied to the enterprise registry. Before committing, check which of the two you are running, read the replace block in go.mod so your dependency tooling sees the forks, and confirm that you can rebuild from source with Go 1.26 and the in-tree oryx and pkg/client-go directories present.

Frequently asked questions

Official sources

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