Deploy Keycloak | (Just Updated) Auth0 Alternative With A Working Admin Login
Keycloak 26 SSO with an admin login that exists. Postgres, prebuilt, pinned
postgres
Just deployed
/var/lib/postgresql
keycloak
Just deployed
Deploy and Host Keycloak on Railway
Keycloak is the open-source identity and access management server behind Red Hat SSO — an Auth0, Okta and Clerk alternative you run yourself. It gives your applications OpenID Connect and SAML single sign-on, user registration and login pages, multi-factor authentication, social and enterprise identity brokering, LDAP and Active Directory federation, fine-grained authorization and a full admin console and REST API.
This template deploys Keycloak 26.7.2 with a PostgreSQL database, and — the part that is easy to get wrong — an administrator account that actually exists on the first boot.
About Hosting Keycloak
Keycloak keeps every realm, client, user and credential in a relational database, so a production deployment is the server plus PostgreSQL. It is a Quarkus application: the stock container re-runs its build step on every start unless the image was built ahead of time, and it needs to be told the public hostname it is reached on, because every issuer URL, redirect URI and back-channel URL it hands to your applications is derived from that value.
There is one further trap that is specific to Keycloak: it has no HTTP setup
route. The administrator account is created once, at the moment the master
realm is bootstrapped, from environment variables. If a deploy starts without
them, the server comes up completely healthy — it serves the OIDC discovery
document, it answers /realms/master, the platform reports a successful
deployment — and there is no page anywhere that lets you create the first
administrator. This template refuses to start without an administrator password
rather than handing you a running server you cannot administer, and it
generates one for you so there is nothing to fill in.
It also builds the Quarkus image ahead of time with the PostgreSQL driver, health and metrics baked in, so the container starts optimized instead of augmenting itself on every deploy, and it derives the public hostname and proxy headers from the deployment itself.
Why Deploy Keycloak on Railway?
Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.
By deploying Keycloak on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.
Keycloak in particular is a natural fit: it is a long-running, memory-resident server with a managed PostgreSQL beside it, both of which Railway provisions and networks privately for you.
Common Use Cases
- Single sign-on across your own web, mobile and API services with OpenID Connect or SAML.
- Replacing a paid identity provider (Auth0, Okta, Clerk) with a self-hosted one you control the data for.
- Adding social login (Google, GitHub, Apple, Discord) and multi-factor authentication without writing auth code.
- Federating an existing LDAP or Active Directory user store into modern applications.
- Issuing and validating JWTs for a microservice or agent fleet, with per-client scopes and roles.
Dependencies for Keycloak
- A PostgreSQL database (deployed as part of this template).
Deployment Dependencies
What this template does differently
- An administrator account that exists. The admin password is generated per deployment and the container refuses to boot without one. Keycloak offers no way to create the first administrator over HTTP, so a deploy that starts without credentials is a healthy server nobody can log into.
- Keycloak 26.7.2, pinned. Not a moving tag, and not a year-old release — this is an identity provider, and the version it runs on is a security property.
- Prebuilt.
kc.sh buildruns when the image is built, so your deploy starts--optimizedinstead of spending your build minutes augmenting the server on every deploy. - A healthcheck that reads the database.
/realms/masterexercises the realm and its data store, rather than serving a static asset from disk. - Nothing to fill in. Every value the deploy needs is generated or derived — the deploy form has no blank required fields.
Template Content
postgres
postgres:17.10-alpinePOSTGRES_DB
KC_DB
KC_DB_USERNAME

