Deploy and Host Authorizer on Railway

Authorizer is a self-hosted authentication server: email and password sign-in, social logins, JWT issuing, roles, and a web dashboard to manage users - running on your own Postgres.

About Hosting Authorizer

This template deploys Authorizer with every secret generated for you, so the deploy form asks for nothing.

That is the difference worth knowing. The Authorizer template most people find declares seven variables with empty values - JWT_TYPE, JWT_SECRET, JWT_PUBLIC_KEY, JWT_PRIVATE_KEY, CLIENT_ID, CLIENT_SECRET and ADMIN_SECRET - and Railway turns every empty value into a required field. Before the Deploy button will even light up you are expected to generate an RSA key pair by hand and paste both halves into a web form. Three quarters of the deployments from it never come up.

Here the token type is HS256, which needs a single symmetric secret rather than a key pair, and every secret is generated at deploy time.

Common Use Cases

Authentication for your own apps, without handing user accounts to a third party
One login shared across several services you run, issuing JWTs they all trust
A drop-in replacement for a hosted auth vendor when the pricing stops making sense

Dependencies for Authorizer Hosting

Postgres, included, on a persistent volume - users, sessions and roles live there
SMTP credentials if you want email verification and password resets. Add them as smtp settings in the dashboard; the server runs without them.

Deployment Dependencies

Documentation: https://docs.authorizer.dev
Source: https://github.com/authorizerdev/authorizer

Implementation Details

After deploying, open /dashboard and sign in with the generated ADMIN_SECRET, which you will find in the service variables. From there you configure sign-up rules, roles, social providers and SMTP.

Variable	Why
ADMIN_SECRET	Generated. This is the dashboard password - treat it as one
JWT_TYPE, JWT_SECRET	HS256 with a generated secret, so no key pair to produce by hand
CLIENT_ID, CLIENT_SECRET	Generated OAuth client credentials
DATABASE_TYPE, DATABASE_URL	The bundled Postgres over the private network
AUTHORIZER_URL	The public address, used in links and as the allowed origin
DISABLE_PLAYGROUND	The GraphQL playground is off in production

One implementation note if you fork this: Authorizer 2.x takes its core settings as command-line flags, not environment variables - --admin-secret, --jwt-type, --jwt-secret, --client-id, --client-secret, --database-type, --database-url. Setting only the matching env vars gets you FATAL: --admin-secret is required. The start command here passes them through, wrapped in a shell so the values expand.

Why Deploy Authorizer on Railway?

Auth is the part you least want to half-configure. This deploys in one click with a database, a domain and generated secrets, and nothing left blank for you to guess at.