A Keycloak alternative you don't have to operate

This page is for teams who run Keycloak today, or are about to, and would rather not operate an identity server themselves. It's also for teams whose security or legal reviewer wants end-user identity data kept on EU infrastructure. Timonier is a hosted OpenID Connect provider: passwordless sign-in by magic link, optional TOTP second factor, and sessions, run by us on servers we operate in the EU.

Before the comparison, the reasons to stop reading. We don't do SAML. We don't store passwords, and there's no password table to put them in. We don't offer social login ("Sign in with Google" and the like), and that won't change. If SAML, passwords or social login is a requirement, Keycloak supports them and we don't. If you need a certified provider, we hold no certifications today, and the rest of this page won't change that.

Side by side

Claims about Keycloak link to its own documentation or project pages.

	Keycloak	Timonier
Who runs it	You, or a vendor offering a build of it, such as Red Hat build of Keycloak	We do
Where it runs	Wherever you deploy it	Our servers in the EU, or the data plane on your infrastructure (below)
Database	You provision it: "the Keycloak Operator does not manage the database"	Ours to run
Clustering	Distributed caches built on Infinispan, which you configure	Ours to run
Upgrades	Back up the database first; Keycloak doesn't support rolling back its database changes, so rollback means restoring the backup	Ours to run
Protocols	OAuth 2.0, OpenID Connect and SAML	OpenID Connect only
Sign-in methods	Passkey, password, X.509, TOTP/HOTP, recovery codes, social login, LDAP and Active Directory federation	Magic link, optional TOTP. No passwords, no social login
Licence	Apache License 2.0	Hosted service, one flat monthly price, see pricing

What operating Keycloak involves

Keycloak's own guides are specific about the work. The Operator leaves the database to you. By default the server "mandates the configuration of the hostname option and does not dynamically resolve URLs", as a security measure. In production mode, Keycloak uses distributed caches built on Infinispan for clustering. The upgrade guide asks you to shut the server down for minor and major upgrades (rolling updates cover patch releases from 26.6.0), and to back up the database before you start, because, in the guide's words, "Keycloak does not support rolling back the database changes".

None of that is unusual for a server you run yourself, and plenty of teams do it well. It's the work you stop doing if someone else runs the identity server. With us there's no database, cache cluster or upgrade window on your side. You register an app in the dashboard and point an OIDC client at it.

What you give up is control. Keycloak is distributed under the Apache License 2.0 and has been a CNCF Incubating project since April 2023, so you can fork it, patch it and upgrade on your own schedule. You can't do any of that with Timonier. Our self-hosting path isn't publicly documented either: you can't download it this afternoon the way you can download Keycloak.

Where your users' data sits

On the hosted service, end-user records, sessions and TOTP enrolments live in Postgres and Redis on servers we run in the EU. We run the outbound mail relay ourselves too. None of these is a third-party API.

If you need the identity data on your own machines, our data plane, the part that holds end-user records, is built to be deployed onto your infrastructure; that's set up with you, not downloaded. We still run the control plane. It holds configuration and your team's admin accounts. Its audit log records end-user and session IDs when your team acts on them, such as a ban or a session revoke, but never their email addresses or IPs. This post covers how the two planes are separated.

Our price

One flat monthly price for the whole platform. It covers authentication plus our feature flags, customer data and automation, with no usage meter, and every account is paid. Running the data plane on your infrastructure is quoted per engagement and never below the hosted price, because we run the control plane either way.

We don't estimate what running Keycloak would take your team; that depends on your infrastructure and staff.

What migrating off Keycloak involves

The protocol layer is the mechanical part. If your apps reach Keycloak through a generic OIDC client, they need a new issuer URL, client ID and secret. We support discovery, JWKS, userinfo, and the authorization code flow with PKCE (S256 only), for confidential and public clients. Check two things first. Our ID tokens are signed with EdDSA (Ed25519) only, so check that your client library supports EdDSA. A public client can only register loopback redirect URIs, so a browser app on a real domain signs in through our Next.js SDK's server routes.

These don't carry over:

• Users. We have no import path for Keycloak today. Our bulk import accepts rows tagged as coming from Auth0 or Clerk and rejects anything else. If this blocks you, write to us before planning a cutover.
• Passwords. There's nowhere to put them, by design. Every user signs in by magic link.
• TOTP enrolments. Users who had a second factor set it up again.
• Custom claims. Our scopes are openid, profile and email, and ID tokens carry the standard claims for those. Roles or groups mapped into tokens by Keycloak protocol mappers have no equivalent.
• Logout. Our discovery document has no end_session_endpoint.
• SAML clients, social identity providers, and LDAP or Active Directory federation. We have none of these.

Certifications

As of October 2026 we hold no certifications. No ISO 27001, no SOC 2. If that's a gate for you, tell us early.

If you're also looking at Auth0, Authentik or Zitadel

We've written a sourced comparison with Auth0. We haven't done the same for Authentik or Zitadel, so this page makes no claims about them.

Get started

Get started at app.timonier.eu: register an app and point an OIDC client at it. To run the data plane on your own infrastructure, email hello@timonier.eu.