Deploy and Host Logto on Railway

Logto is a modern, open-source identity and authentication platform — a self-hosted alternative to Auth0 and Clerk with sign-in flows, social and enterprise SSO, multi-factor auth, RBAC, and multi-tenancy built in. It's OIDC-compliant with SDKs for every major framework, so you add production-grade auth to your apps without building it yourself or paying per active user. This template deploys Logto with PostgreSQL and — critically — the two-port core/admin split configured correctly for Railway.

What This Template Deploys

Both run on Railway's private network. Logto exposes two ports that each need their own domain, and this template wires them so the core endpoint and Admin Console both resolve — the step most Logto deployments get stuck on.

About Hosting

Logto has an architecture worth understanding before you deploy, because it's the source of the most common Railway failure.

Logto runs two ports, and each needs its own domain. Port 3001 serves the core — the OIDC provider and API your apps authenticate against — and port 3002 serves the Admin Console where you configure everything. On Railway, a service gets one domain bound to one port, so a naive deployment leaves one of them unreachable, showing an error page instead of the Admin Console. This template configures the two-port split so both the core endpoint and the Admin Console resolve to the correct ports. If you add a custom domain later, bind the core to 3001 and the admin domain to 3002.

ENDPOINT and ADMIN_ENDPOINT must be your real HTTPS URLs. ENDPOINT sets the OIDC issuer identifier every integrated app validates against, and ADMIN_ENDPOINT sets the Admin Console's redirect URIs. Wrong values cause authentication failures that are hard to diagnose, so set both to your actual Railway domains.

TRUST_PROXY_HEADER=1 is required on Railway, because Railway terminates HTTPS with a proxy in front of Logto. Without it, Logto can misjudge whether requests are secure and break redirect and cookie behavior.

The database is seeded on first run and holds your identity data. Logto seeds its schema on initial startup and stores all users, applications, and roles in PostgreSQL. Back up the volume before relying on it — this is production identity data.

Typical cost: ~$10–15/month on Railway for Logto and Postgres. Logto OSS is free with no per-user pricing; Auth0 and Clerk bill per monthly active user, which scales painfully as you grow.

How It Compares

Auth0 and Clerk are polished but bill per monthly active user, so costs climb as you scale. Keycloak is the established open-source option but heavier and dated in developer experience. Logto's appeal is a modern, developer-friendly auth platform with multi-tenancy and RBAC built in, self-hosted with no per-user fee and your identity data on infrastructure you own.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — Logto and PostgreSQL build, and the database seeds on first run (~3 minutes)
2. Confirm ENDPOINT and ADMIN_ENDPOINT are set to your Railway domains (core and admin)
3. Confirm TRUST_PROXY_HEADER=1 and the two ports (3001 core, 3002 admin) are bound to their domains
4. Open the Admin Console domain (port 3002) and create your first admin account on the welcome page
5. Create an application, configure connectors and RBAC, and integrate with a Logto SDK

If the Admin Console shows a Railway error page, bind its domain to port 3002 under Settings → Networking.

Common Use Cases

• Auth0/Clerk replacement — production auth with social and enterprise SSO, MFA, and RBAC without per-user billing
• Multi-tenant SaaS auth — built-in multi-tenancy for products serving multiple organizations from one deployment
• Centralized identity — one OIDC provider securing all your apps and APIs, with users and roles in one place
• Role-based access control — define roles, permissions, and scopes and enforce them across applications
• Privacy-first identity — keep user credentials and personal data on infrastructure you fully control

Configuration

The two ports each need a domain. Core (3001) and Admin Console (3002) are separate. On Railway, bind each to the correct port under Settings → Networking, or the Admin Console shows an error page — the most common Logto deployment issue.

ENDPOINT and ADMIN_ENDPOINT must be correct HTTPS URLs. They set the OIDC issuer and Admin redirect URIs; wrong values break auth in confusing ways. Set TRUST_PROXY_HEADER=1 since Railway proxies HTTPS, and back up the Postgres volume — it holds your identity data.

Dependencies for Logto Hosting

• Railway account — ~$10–15/month for Logto and Postgres
• PostgreSQL 14+ (included in the template)
• Two domains or Railway subdomains — one for the core endpoint, one for the Admin Console
• Optional: SMTP for email verification and password-reset flows

Deployment Dependencies

• Logto GitHub Repository
• Logto Self-Hosting Documentation
• Deployment & Configuration Reference
• Railway Private Networking

Implementation Details

The template runs the official Logto image against a Railway PostgreSQL service, with the database seeded on first startup via Logto's CLI before the app starts. Logto exposes two HTTP listeners: the core service on 3001 (the OIDC provider and management API) and the Admin Console on 3002. Because Railway maps one domain to one port per service, both are configured so each resolves to the correct listener rather than leaving the Admin Console unreachable.

ENDPOINT and ADMIN_ENDPOINT are set to the deployment's HTTPS URLs because they determine the OIDC issuer identifier and the Admin Console's redirect URIs — values that integrated apps and the console validate against. TRUST_PROXY_HEADER=1 makes Logto trust Railway's forwarded protocol headers. All identity data lives in PostgreSQL, so the database volume is the critical thing to back up, and Logto provides SDKs and OIDC compliance for integrating apps against the core endpoint.

Frequently Asked Questions

Why does the Admin Console show a Railway error page? Logto runs two ports — 3001 for the core and 3002 for the Admin Console — and Railway binds one port per domain. Bind the Admin Console's domain to port 3002 under Settings → Networking, and the core's to 3001. This template configures the split, but custom domains may need this step.

Why are ENDPOINT and ADMIN_ENDPOINT important? ENDPOINT sets the OIDC issuer identifier every integrated app validates, and ADMIN_ENDPOINT sets the Admin Console's redirect URIs. Incorrect values cause authentication failures, so both must be your real HTTPS URLs.

Why do I need TRUST_PROXY_HEADER=1? Railway terminates HTTPS with a proxy in front of Logto. This setting tells Logto to trust the forwarded headers and treat requests as secure, which keeps redirects and cookies working.

How does Logto compare to Auth0 or Clerk? Similar modern features — SSO, MFA, RBAC, multi-tenancy — but self-hosted with no per-active-user billing and full data ownership. For growing apps, the flat cost is a major saving.

Does my identity data persist? Yes, in the PostgreSQL service, which persists across redeploys. Because it's production identity data, back the database up on a schedule.

How do I integrate it with my app? Create an application in the Admin Console and use a Logto SDK for your framework, pointing it at the core ENDPOINT. Logto is OIDC-compliant, so standard OIDC clients work too.

Does it support multi-tenancy? Yes — it's built in, which is why Logto suits SaaS products serving multiple organizations from a single deployment.

Why Deploy Logto 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 Logto on Railway you get a modern auth platform with the tricky parts solved — the two-port core/admin split configured, the OIDC endpoints and proxy header set, PostgreSQL wired, and automatic HTTPS. SSO, RBAC, and multi-tenancy without per-user fees, and your users' identity data on infrastructure you own.