Deploy and Host OpenResty Manager on Railway

Built for an LLM agent to deploy and use. The deploy form has no fields. OpenResty Manager, the open-source nginx/OpenResty reverse-proxy control panel (sites, upstreams, TLS certificates with ACME, a web application firewall, access control lists, HTTP flood protection and a REST API), starts with its admin password already replaced by a generated one, so nobody can log in with the upstream default.

This is the official uusec/openresty-manager image, version 2.4.6, pinned by digest. People use it as a Nginx Proxy Manager alternative: a web panel in front of OpenResty that publishes internal services under their own domains, with certificates and basic attack filtering.

About Hosting OpenResty Manager

This template runs one service from a wrapper image. Upstream ships a fixed login (admin / #Passw0rd) and a web terminal behind it, serves HTTPS only, on port 34567 with a self-signed certificate, and scatters its state over three directories. The wrapper starts the panel on loopback only, replaces the default password with ADMIN_PASSWORD through the panel's own API, and only then opens the public listener, so there is no moment at which the default login is reachable from the internet. A small front proxy serves the panel over plain HTTP on Railway's injected PORT (Railway terminates TLS at its edge) and answers 401 for an API call that carries no token, where upstream answers 400. A volume at /data holds the database, the JWT key, certificates and the generated proxy configuration, so a redeploy keeps every site, upstream and certificate.

The password is set once, on first boot. If you change it in the web UI afterwards, the new password stays; changing the ADMIN_PASSWORD variable later does not override it. The admin user name is admin. The proxy ports of the managed OpenResty (80 and 443) are not exposed by Railway's HTTP domain; the panel, its API and its configuration editor are what this template publishes.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the panel and the REST API share it)
Private URL: http://openresty-manager.railway.internal:8080
Credentials: ADMIN_PASSWORD (generated, 32 characters); the user name is admin
Auth: POST /api/v1/login with {"username":"admin","password":"..."} returns {"token":"..."}; send it as Authorization: Bearer TOKEN on every /api/v1/admin/* call. A call with no token returns 401, a wrong token returns 401
Health: GET / returns 200 without authentication (the panel's web UI)

# needs: the service's public URL as URL (https://RAILWAY_PUBLIC_DOMAIN) and ADMIN_PASSWORD from the service variables
U="$URL/api/v1"
TOK=$(curl -s -X POST "$U/login" -H 'Content-Type: application/json' \
  -d "{\"username\":\"admin\",\"password\":\"$ADMIN_PASSWORD\"}" | sed -n 's/.*"token":"\([^"]*\)".*/\1/p')
N="agent-smoke-$(date +%s)"
D="{\"id\":0,\"name\":\"$N\",\"method\":\"ip_hash\",\"servers\":[],\"config\":\"ip_hash;\\nserver 127.0.0.1:8080;\\nkeepalive 320;\\nkeepalive_requests 1000;\"}"
curl -s -o /dev/null -w "health: %{http_code}\n" "$URL/"
curl -s -o /dev/null -w "default login: %{http_code} " -X POST "$U/login" -H 'Content-Type: application/json' -d '{"username":"admin","password":"#Passw0rd"}'; echo "(body must be an error, not a token)"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST "$U/admin/upstreams" -H 'Content-Type: application/json' -d "$D"
curl -s -o /dev/null -w "write wrong key: %{http_code}\n" -X POST "$U/admin/upstreams" -H 'Content-Type: application/json' -H 'Authorization: Bearer wrong' -d "$D"
curl -s -o /dev/null -w "write with key: %{http_code}\n" -X POST "$U/admin/upstreams" -H 'Content-Type: application/json' -H "Authorization: Bearer $TOK" -d "$D"
curl -s "$U/admin/upstreams" -H "Authorization: Bearer $TOK" | grep -o "\"name\":\"$N\""

A fresh deploy prints health: 200, default login: 200 (body must be an error, not a token), write without key: 401, write wrong key: 401, write with key: 200, then "name":"agent-smoke-TIMESTAMP" read back from the upstream list. The upstream returns HTTP 200 with {"error":"Error password"} for a wrong login, so check for a token field, not the status code.

Why Deploy OpenResty Manager 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 OpenResty Manager 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 - no deployer fields, a contract block and one working login, write and read-back script that also proves the write path refuses a missing or wrong token.
No default credential - the upstream admin / #Passw0rd login is replaced before the public listener opens.
Persistent - a volume at /data holds the database, certificates and generated proxy configuration, write-tested at every boot, and the image is pinned by digest.
Health-checked - Railway restarts the service if the panel stops answering.

Common Use Cases

Reverse-proxy control panel - define sites, upstreams and certificates in a web UI instead of editing nginx files.
Nginx Proxy Manager alternative - the same panel idea on OpenResty, with a WAF, ACLs and HTTP flood protection built in.
Config generator for a self-hosted OpenResty - author and test proxy and upstream definitions over the REST API.
Agent-managed edge - agents create and list upstreams and sites with plain curl.

Dependencies for OpenResty Manager Hosting

None. A custom domain for the panel is optional.

Deploy OpenResty Manager | (Just Updated) Nginx Reverse Proxy Manager with WAF, Admin Login Pre-Set