Deploy and Host FusionAuth on Railway

Built for an LLM agent to deploy and use. There is no setup wizard and nothing to fill in: an admin user and a full-access API key are created at first boot from generated secrets, and the contract below lists every address, variable name and the one script that proves it works.

FusionAuth is a customer identity and access management server. It handles registration, login, OAuth2 and OpenID Connect, SAML, multi-factor authentication, social login and user management for your applications, and exposes all of it through a REST API and an admin UI.

About Hosting FusionAuth

This template runs two services. fusionauth is the official fusionauth/fusionauth-app 1.70.0 image, pinned by digest, started in production runtime mode with silent mode on. postgres is PostgreSQL 17 on an attached volume, so users, applications and keys survive redeploys. FusionAuth creates its own schema and database user on first boot using the generated Postgres password, and uses its database as the search engine, so no Elasticsearch service is needed.

On the first boot against an empty database, a kickstart file registers the admin user admin@example.com with the generated FUSIONAUTH_ADMIN_PASSWORD and creates an API key from FUSIONAUTH_API_KEY. The setup wizard is skipped. Later redeploys find the data and do not run the kickstart again, so credentials stay the same. Change the admin email and password inside FusionAuth after you sign in if you want a human owner.

Agent contract

Public URL: FUSIONAUTH_PUBLIC_URL (https:// plus the service's RAILWAY_PUBLIC_DOMAIN). The admin UI is at /admin.
Private URL: http://fusionauth.railway.internal:8080, exposed as FUSIONAUTH_PRIVATE_URL.
Credentials: admin login admin@example.com with the password in FUSIONAUTH_ADMIN_PASSWORD; REST API key in FUSIONAUTH_API_KEY.
Auth: send the API key in the Authorization header (the key itself, no Bearer prefix). Requests without it get 401; a wrong password on /api/login gets 404.
Health: GET /api/status returns 200 without credentials (the first boot creates the schema, so allow about two minutes).
API: REST under /api (users, applications, registrations, tenants, keys), OAuth2 and OIDC under /oauth2, discovery at /.well-known/openid-configuration.

# run with FUSIONAUTH_PUBLIC_URL, FUSIONAUTH_API_KEY and FUSIONAUTH_ADMIN_PASSWORD set
APP=3c219e58-ed0e-4b18-ad48-f4f92793ae32
curl -s -o /dev/null -w "status: %{http_code}\n" "$FUSIONAUTH_PUBLIC_URL/api/status"
curl -s -o /dev/null -w "anonymous: %{http_code}\n" -G "$FUSIONAUTH_PUBLIC_URL/api/user" --data-urlencode "email=admin@example.com"
curl -s -o /dev/null -w "api key: %{http_code}\n" -H "Authorization: $FUSIONAUTH_API_KEY" -G "$FUSIONAUTH_PUBLIC_URL/api/user" --data-urlencode "email=admin@example.com"
curl -s -o /dev/null -w "login: %{http_code}\n" -H "Authorization: $FUSIONAUTH_API_KEY" -H "Content-Type: application/json" \
  -d "{\"loginId\":\"admin@example.com\",\"password\":\"$FUSIONAUTH_ADMIN_PASSWORD\",\"applicationId\":\"$APP\"}" "$FUSIONAUTH_PUBLIC_URL/api/login"
curl -s -o /dev/null -w "wrong credentials: %{http_code}\n" -H "Authorization: $FUSIONAUTH_API_KEY" -H "Content-Type: application/json" \
  -d "{\"loginId\":\"admin@example.com\",\"password\":\"${FUSIONAUTH_ADMIN_PASSWORD}x\",\"applicationId\":\"$APP\"}" "$FUSIONAUTH_PUBLIC_URL/api/login"
curl -s -o /dev/null -w "create application: %{http_code}\n" -H "Authorization: $FUSIONAUTH_API_KEY" -H "Content-Type: application/json" \
  -d "{\"application\":{\"name\":\"agent-app-$(date +%s)\"}}" "$FUSIONAUTH_PUBLIC_URL/api/application"

A fresh deploy prints status: 200, anonymous: 401, api key: 200, login: 200, wrong credentials: 404 and create application: 200. The APP value is the id of FusionAuth's built-in admin application.

Why Deploy FusionAuth 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 FusionAuth 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 API key, contract block and one working script; no setup wizard.
Login for your own apps - OAuth2, OIDC and SAML, so you do not build password storage yourself.
State survives redeploys - users, applications and keys live in Postgres on a volume.
One API - everything the admin UI does is available over REST with the generated key.
No search cluster - the database search engine is enabled, so there is no Elasticsearch to run.

Common Use Cases

Sign-in for a web or mobile app - register users and issue OIDC tokens from your own domain.
Single sign-on across internal tools - one identity provider in front of several applications.
Machine-driven user management - an agent creates applications, users and roles through the REST API.

Dependencies for FusionAuth Hosting

PostgreSQL 17 with one Railway volume, created by the template.

Deployment Dependencies

Implementation Details

Variable	Purpose
`FUSIONAUTH_ADMIN_PASSWORD`	Password of `admin@example.com`, generated per deploy.
`FUSIONAUTH_API_KEY`	Full-access REST API key, generated per deploy.
`FUSIONAUTH_PUBLIC_URL`	HTTPS address for clients outside Railway.
`FUSIONAUTH_PRIVATE_URL`	Address on the private network, for services in the same project.
`DATABASE_URL`, `DATABASE_ROOT_PASSWORD`, `DATABASE_PASSWORD`	Wiring to the Postgres service, generated.

FusionAuth reads FUSIONAUTH_APP_URL as its own public address. Heap is capped at 768 MB and the JVM is limited to two processors so it does not size thread pools from the host.