Self-hosted Ory Kratos or Nautilus: when each fits

Sign-in in Nautilus is Ory Kratos — the open-source identity server, Apache 2.0, version 26.2, unmodified. So this is not a choice between two engines. It is a choice between running Kratos yourself and having us run it, with a layer of our own around it. Both are reasonable, and for some projects running it yourself is plainly the better one. This page tries to say which is which.

Run Kratos yourself when

You need your own identity schema. In Kratos you write the JSON schema of a user: a phone number, a username, required fields, what counts as an identifier. The schema in Nautilus is fixed — email and locale — and anything else goes into custom metadata, which is free-form JSON that Nautilus does not validate and the user can read.

You need a sign-in method Nautilus does not offer. Kratos can do passkeys and WebAuthn, SMS codes, and username logins. Nautilus offers a password, a six-digit code by email, ten social providers, authenticator-app two-factor with backup codes, and Telegram through a separate API. There is no SAML and no enterprise SSO in Nautilus.

You want Kratos' browser flows or your own configuration. Self-hosted, you choose session lifetimes, the password policy, the hashing algorithm, the mail templates, the hooks that run after a registration, and you can use Kratos' browser flows with cookies and CSRF protection. The Gate API exposes Kratos' API flows — your backend starts a flow and posts the user's details — and a fixed set of identity endpoints; the rest of the Kratos admin API is not reachable with a Nautilus key.

Your data has to be somewhere specific. Nautilus runs in one place: on servers in France, at OVHcloud, with one shared Kratos for all accounts. Verne Software is registered in Serbia, which is outside the EU. If your users' data must stay on servers you run, in another country, or with a processor registered in the EU, run Kratos yourself.

You need an OAuth 2.0 or OpenID Connect server. If other applications must be able to "sign in with your product", that is Ory Hydra's job, next to Kratos. Nautilus is not an authorization server: it issues signed tokens for your own users, for your own backend and platforms such as Supabase, not for third-party clients.

You already run this kind of infrastructure. If you have PostgreSQL, backups, monitoring, mail delivery and someone on call, Kratos is one more stateless service among them, and at a large number of users your own servers can cost less than any per-user plan.

You want the exit fully in your hands. On your own Kratos you own the database, password hashes included. On Nautilus the database is ours, but you can have it: write to support and you get an export of all your users with their password hashes, social links, metadata, organizations and roles within 7 days, as one encrypted file (how it works). It is a request to a person, not a button or an API call, and you do not hold the data in between.

Use Nautilus when

You would rather not run an identity server. Self-hosting Kratos means a SQL database and its backups, schema migrations on every upgrade, Kratos releases to follow, a mail server or provider for verification and recovery codes, TLS, secrets, monitoring, and the sign-in pages themselves — Kratos ships no production UI. With Nautilus you call an API with a key; the operations are ours, and the Nautilus dashboard covers the admin screens (the sign-in screens stay yours).

You want what sits around the engine. These are our own, built next to Kratos, and they are what you would build yourself on a self-hosted Kratos:

You want to start small. The Free plan covers 1,000 active users a month; paid plans are a flat monthly price by active users, not by request. See Plans, Limits and Refusals.

What is the same either way

• The flows. A login or registration through the Gate API is a Kratos API flow: the same flow object, the same ui.nodes, the same message ids (4000006 for wrong credentials, 4000007 for an address that is taken). What you learn about Kratos flows applies to Nautilus, and a front end built for one is most of the way to the other.
• The password hashes. Nautilus stores passwords the way Kratos does. A bcrypt hash from elsewhere can be imported when a user is created, so the user keeps their password — this is how the Auth0 migration works, and it is also the way from a self-hosted Kratos to Nautilus. We have tested bcrypt; for any other hash format, ask us before importing.

What you give up either way

Moving between them

• From a self-hosted Kratos to Nautilus: create each user through POST /v1/gate/identities with their bcrypt hash as hashed_password. The Auth0 guide has a complete import script; replace the part that reads Auth0's export with a read of your Kratos identities. Social accounts can be linked the same way, provided the provider gives Nautilus the same account id.
• From Nautilus to a self-hosted Kratos: ask support for the export: one encrypted file within 7 days with every user, their bcrypt hashes, social links, metadata, organizations and roles. Its page shows the jq that turns it into Kratos admin POST /admin/identities bodies, so your users keep their passwords. Kratos wants your own identity schema, so check the traits first.

Sign-in and users is part of Nautilus by Verne Software, together with webhooks, scheduled jobs and Telegram sign-in, in one plan priced by active users and hosted in France. Create a free account or see the plans.