Deploy and Host Authorizer on Railway

Authorizer is an open-source authentication and authorization solution with a built-in login page and admin panel out of the box. Beyond standard auth — email/password, social login, magic links, JWT sessions — Authorizer v2 ships an embedded OpenFGA engine for fine-grained, relationship-based authorization, so the same server that logs users in can also answer "can this user see this?" in-process. That makes it uniquely suited to permission-aware AI and RAG. This template deploys Authorizer with a database, wired correctly for Railway.

What This Template Deploys

Both run on Railway's private network. Authorizer is a single Go binary — no JVM, no app server, no runtime dependencies — storing everything in the database.

About Hosting

Authorizer is a single lightweight binary, but v2 has one Railway-specific deployment detail that determines whether it starts at all.

Authorizer v2 takes CLI arguments, not direct env vars — the ENTRYPOINT must be overridden. In v2, configuration is passed as command-line flags. When you extend the image and use a shell-form command so Railway's injected variables expand at runtime, you must override the ENTRYPOINT to ["/bin/sh", "-c"] — otherwise the base entrypoint receives /bin/sh -c as arguments and the binary fails to start. This is the most common v2-on-Railway failure, and this template wires the ENTRYPOINT and flag mapping correctly so it boots on the first deploy.

The embedded OpenFGA engine is the standout feature. Authorizer v2 bundles OpenFGA — the open-source implementation of Google's Zanzibar relationship-based access control — inside the same server that handles login, answering authorization questions ("can this user view this document?") in-process. That's powerful for AI: you can put the permission boundary inside the retrieval step of a RAG pipeline, so the model can never surface a document the user was never allowed to see — the record never becomes a candidate. That's authorization vector search alone can't provide.

It supports the widest range of databases of any auth server — PostgreSQL, MySQL, SQLite, MongoDB, and DynamoDB. If you already run Mongo or DynamoDB, you don't need a separate Postgres just for auth. This template uses Postgres by default, but DATABASE_TYPE and DATABASE_URL can point elsewhere.

Set the secrets and admin credentials. ADMIN_SECRET protects the admin panel, JWT_SECRET signs tokens, and CLIENT_ID/CLIENT_SECRET identify the instance — set strong values and keep them stable. Add REDIS_URL only if you run multiple instances, so sessions and rate limits stay consistent.

Typical cost: ~$5–10/month on Railway for Authorizer and Postgres. Authorizer is open source and free — no per-user auth tax.

How It Compares

Auth0 and Okta are managed but bill per user and keep your data. SuperTokens is developer-focused but authentication-only. Keycloak is a heavy standalone IdP. Authorizer's distinct edge is combining auth, a built-in login UI and admin panel, broad database support, and an embedded relationship-based authorization engine — the only one here built for permission-aware AI.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — Authorizer and PostgreSQL build automatically (~3 minutes)
2. Confirm DATABASE_TYPE, DATABASE_URL, ADMIN_SECRET, and JWT_SECRET are set
3. Confirm the ENTRYPOINT override is in place so CLI flags expand correctly (handled by the template)
4. Open your Railway domain — the built-in login page and admin panel are available immediately
5. Log into the admin panel with ADMIN_SECRET, configure providers, and integrate via SDK or API

Social logins (Google, GitHub, Apple, and more) are each enabled with a client-id/secret pair.

Common Use Cases

• Auth with a built-in UI — email/password, social, and passwordless login with a ready-made login page and admin panel
• Permission-aware AI and RAG — enforce who can see what inside the retrieval step so AI never leaks unauthorized data
• Fine-grained authorization — model relationship-based permissions with the embedded OpenFGA engine
• Replace per-user auth pricing — self-host and pay only for infrastructure instead of a per-MAU tax
• Drop-in auth component — add the same login experience to a SaaS, dev tool, or e-commerce app, all self-hosted

Configuration

v2 needs the ENTRYPOINT override. Authorizer v2 reads CLI flags, not direct env vars. The image must override ENTRYPOINT to ["/bin/sh", "-c"] so Railway's variables expand into flags at runtime — otherwise the binary fails to start. This template handles it; it's the most common v2 error.

Keep the secrets stable. JWT_SECRET, ADMIN_SECRET, and the client credentials must be strong and kept consistent, or tokens and admin access break. Add REDIS_URL only when scaling to multiple instances.

Dependencies for Authorizer Hosting

• Railway account — ~$5–10/month for Authorizer and a database
• A database — PostgreSQL (included), or MySQL, SQLite, MongoDB, or DynamoDB
• Optional: Redis, only when running multiple instances
• Social provider client credentials for any OAuth logins you enable

Deployment Dependencies

• Authorizer GitHub Repository
• Railway Deployment Guide
• Authorizer Documentation
• Railway Private Networking

Implementation Details

The template runs the Authorizer v2 image (quay.io/authorizer/authorizer) on port 8080 against a Railway database. Authorizer is a single Go binary with no runtime dependencies, configured entirely through CLI flags. Because Railway injects configuration as environment variables, the image uses a shell-form command with an overridden ENTRYPOINT of ["/bin/sh", "-c"] so those variables expand into flags (--database-type, --database-url, --admin-secret, --jwt-secret, --client-id, --client-secret) at startup — without the override, the base entrypoint receives the shell invocation as arguments and the binary exits.

Authorizer bundles a login page, an admin panel, and an embedded OpenFGA authorization engine, so a single deployment provides authentication and fine-grained, relationship-based authorization in one process. It supports PostgreSQL, MySQL, SQLite, MongoDB, and DynamoDB via DATABASE_TYPE, and an optional REDIS_URL keeps sessions consistent across multiple instances. All data lives in the configured database.

Frequently Asked Questions

Why would Authorizer v2 fail to start? Almost always the ENTRYPOINT. v2 uses CLI flags, so the image must override ENTRYPOINT to ["/bin/sh", "-c"] for Railway's env vars to expand into flags. Without it the binary gets the shell invocation as arguments and exits. This template handles the override.

What's the embedded OpenFGA engine? It's Google Zanzibar-style relationship-based access control built into the same server that does login, answering "can this user access this?" in-process. It lets you enforce permissions inside AI/RAG retrieval so models never surface unauthorized data.

Which databases can it use? PostgreSQL, MySQL, SQLite, MongoDB, and DynamoDB — the broadest support of any open-source auth server. If you already run Mongo or DynamoDB, you can use it for auth instead of adding Postgres.

Do I need Redis? Only if you run multiple instances. REDIS_URL keeps sessions and rate limits consistent across them; a single instance doesn't need it.

Is it really free? Yes. Authorizer is fully open source and self-hosted, with no per-user pricing — you pay only for infrastructure.

Why Deploy Authorizer 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 Authorizer on Railway you get authentication and fine-grained authorization in one place, with the deployment trap solved — the ENTRYPOINT override handled, the database wired, and secrets configured. A built-in login page, an admin panel, broad database support, and permission-aware authorization for AI, all self-hosted on infrastructure you own.