Deploy and Host Logto on Railway

Built for an LLM agent to deploy and use. There is no setup wizard and nothing to fill in: the admin password and a Management API client secret are generated at deploy time, the contract below lists every URL and variable name, and one working script gets an access token and creates an application.

Logto is an open-source identity and auth server: OpenID Connect and OAuth 2.1 sign-in, single sign-on, social and enterprise connectors, multi-factor authentication, roles and organizations, with a Management API and an admin console. This template runs the official Logto image together with a PostgreSQL database and a small proxy that gives the admin console its own public address.

About Hosting Logto

This template runs three services. logto is the official svhd/logto image (pinned by digest). A boot wrapper seeds the database, sets the Management API client secret from M2M_SECRET, creates the first admin user from ADMIN_PASSWORD on first boot only, and then starts the stock server. postgres is the official postgres:17 image (pinned by digest) with a volume at /var/lib/postgresql, reachable only on the private network. console is a Caddy reverse proxy with its own public domain in front of Logto's admin port, because Logto serves its admin console on a second origin.

All Logto state lives in PostgreSQL, so the logto service needs no volume of its own. The admin user and the secret are the same after every redeploy. Allow roughly 90 seconds for the first deploy to turn healthy.

Agent contract

Public URL: https:// plus the RAILWAY_PUBLIC_DOMAIN of the logto service, used as LOGTO_URL. This origin serves the sign-in experience, the OIDC endpoints and the Management API at /api/.
Admin URL: https:// plus the RAILWAY_PUBLIC_DOMAIN of the console service, used as LOGTO_ADMIN_URL. This origin serves the admin console at /console and issues Management API tokens at /oidc/token.
Private URL: http://logto.railway.internal:8080 (core) and http://logto.railway.internal:3002 (admin)
Credentials: admin console user admin with password in ADMIN_PASSWORD; Management API client id m-default with secret in M2M_SECRET (both on the logto service)
Auth: request a token with HTTP basic auth m-default:M2M_SECRET, grant_type=client_credentials, resource=https://default.logto.app/api and scope=all against LOGTO_ADMIN_URL/oidc/token, then send Authorization: Bearer TOKEN to LOGTO_URL/api/
Health: GET /api/status on LOGTO_URL returns 204 with no credentials

# run with LOGTO_URL, LOGTO_ADMIN_URL and M2M_SECRET set; needs curl
TOKEN=$(curl -fsS -u "m-default:$M2M_SECRET" -d grant_type=client_credentials -d resource=https://default.logto.app/api -d scope=all "$LOGTO_ADMIN_URL/oidc/token" | sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p')
curl -s -o /dev/null -w 'health %{http_code}\n' "$LOGTO_URL/api/status"
curl -s -o /dev/null -w 'anonymous %{http_code}\n' "$LOGTO_URL/api/applications"
curl -fsS -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -d '{"name":"my-app","type":"Traditional"}' "$LOGTO_URL/api/applications" -o /dev/null -w 'create application %{http_code}\n'
curl -fsS -H "Authorization: Bearer $TOKEN" "$LOGTO_URL/api/applications" | grep -o '"name":"my-app"'

A fresh deploy prints health 204, anonymous 401, create application 201 and "name":"my-app". Create users, roles, connectors and API resources the same way under /api/, or open LOGTO_ADMIN_URL/console and sign in as admin.

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 are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Agent-ready - generated admin password and Management API secret, a contract block and one working script; no setup wizard and no open first-user registration.
Stable login - the admin password and API secret are the same after every redeploy.
State survives redeploys - users, applications and connectors live in PostgreSQL on a volume.
Private database - PostgreSQL has no public domain and is reached over the private network.

Common Use Cases

Authentication for your own product - OIDC sign-in, social login, MFA and passwordless for a web or mobile app, as an Auth0 or Clerk alternative you host.
Agent-driven identity management - let an AI agent create applications, users, roles and API resources through the Management API.
Single sign-on for internal tools - one login and role model in front of dashboards and self-hosted apps.

Dependencies for Logto Hosting

A PostgreSQL database (included in this template, volume at /var/lib/postgresql).
A second public domain for the admin console (included: the console proxy service).

Deployment Dependencies

logto-io/logto - upstream project
Logto documentation - configuration reference