Deploy and Host OpenLivery on Railway

Built for an LLM agent to deploy and use. The deploy form has nothing to fill in: the owner password, the database password and every signing key are generated, the owner account is created at first boot, public signup is closed, and data survives redeploys. OpenLivery is an open-source white-label platform for agencies to build AI agents that answer customers on WhatsApp, with a shared inbox, per-client portals, a web chat widget, knowledge bases and custom tools.

About Hosting OpenLivery

This template runs five services from the upstream OpenLivery images (version 0.4.0) plus Caddy and Postgres, each pinned by digest. proxy is the public front door on one domain and routes /api to the backend and everything else to the web app. web is the Next.js interface. api is the FastAPI backend: agencies, clients, agents, conversations, the REST API and the owner account. postgres holds every record and the WhatsApp session on a volume. whatsapp is the WhatsApp bridge, private, which pairs a phone by QR code from the OpenLivery interface.

No default login. The owner is the email ADMIN_EMAIL (admin at the proxy domain) with the generated ADMIN_PASSWORD, created at first boot. This is a single-agency instance, so registration is closed and nobody else can create an account.

What the template fixes for Railway. Services reach each other over Railway's private network, which is IPv6, so every service listens on ::. The proxy listens on Railway's injected PORT and trusts Railway's edge so the real client address is kept. The api container fixes ownership of its storage volume, waits for Postgres, runs the database migrations, then starts. Cookies are marked secure for the HTTPS domain.

Using it. Open the proxy domain, sign in with ADMIN_EMAIL and ADMIN_PASSWORD (read them from the api service variables), add an AI provider key under settings, create a client and an agent, then connect WhatsApp by scanning the QR code.

Agent contract

Public URL: https://RAILWAY_SERVICE_PROXY_URL (the generated domain of the proxy service, also the part of ADMIN_EMAIL after the at sign)
Private URL: http://proxy.railway.internal:8080 (the backend itself is http://api.railway.internal:8000)
Credentials: the variable ADMIN_PASSWORD on the api service
Login name: the variable ADMIN_EMAIL on the api service (a public identifier, not a secret)
Auth: POST /api/auth/login with JSON email and password sets the session cookie access_token (HttpOnly, secure); every other /api call sends that cookie. A request with no cookie or a wrong one answers 401.
Health: GET /api/auth/status returns 200

#!/bin/sh
# needs: ADMIN_EMAIL, ADMIN_PASSWORD (variables of the api service); also curl. ADMIN_EMAIL is admin@ plus the proxy's public domain.
D="${ADMIN_EMAIL#admin@}"; R="https://$D"; J="Content-Type: application/json"; B=$(mktemp); C=$(mktemp)
n=0; until [ "$(curl -s -o /dev/null -w '%{http_code}' "$R/api/auth/status")" = 200 ]; do n=$((n+1)); [ "$n" -le 90 ] || break; sleep 5; done
# sign in as the owner created at first boot; the session is the access_token cookie
n=0; while :; do c=$(curl -s -c "$C" -o "$B" -w '%{http_code}' -H "$J" -d "{\"email\":\"$ADMIN_EMAIL\",\"password\":\"$ADMIN_PASSWORD\"}" "$R/api/auth/login"); if [ "$c" = 200 ]; then break; fi; n=$((n+1)); [ "$n" -le 12 ] || break; sleep 10; done
echo "login: $c"
curl -s -b "$C" -o /dev/null -w "read with session: %{http_code}\n" "$R/api/clients"
curl -s -b "$C" -o "$B" -w "write with session: %{http_code}\n" -H "$J" -d '{"name":"Railway Check","industry":"test"}' "$R/api/clients"
ID=$(sed -n 's/.*"id":"\([0-9a-f-]*\)".*/\1/p' "$B" | head -1)
curl -s -b "$C" "$R/api/clients" | grep -c '"name":"Railway Check"' | sed 's/^/client found after write: /'
curl -s -b "$C" -o /dev/null -w "delete with session: %{http_code}\n" -X DELETE "$R/api/clients/$ID"
curl -s -o /dev/null -w "read without key: %{http_code}\n" "$R/api/clients"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST -H "$J" -d '{"name":"Anonymous"}' "$R/api/clients"
curl -s -o /dev/null -w "write wrong key: %{http_code}\n" -X POST -H "$J" -b "access_token=wrong" -d '{"name":"Anonymous"}' "$R/api/clients"
curl -s -o /dev/null -w "public signup: %{http_code}\n" -X POST -H "$J" -d '{"agency_name":"Intruder","name":"Intruder","email":"x@example.com","password":"Intruder-pass-123"}' "$R/api/auth/register"
curl -s -o /dev/null -w "web app: %{http_code}\n" "$R/"

A fresh deploy prints login: 200, read with session: 200, write with session: 201, client found after write: 1 and delete with session: 204. The refusals print read without key: 401, write without key: 401, write wrong key: 401 and public signup: 403: a request with no session or a wrong one creates nothing, and nobody can register an account from outside. web app: 200 is the interface itself.

Why Deploy OpenLivery 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 OpenLivery 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 - a generated owner password, a contract block and one script that proves sign-in, an authenticated write, read-back and delete, and the refusal of a read and a write with no session or a wrong one.
No setup form and no default login - the owner is created at boot and registration is closed.
Data survives redeploys - records and the WhatsApp session sit in Postgres on a volume, uploads on a second volume.
Pinned - every upstream image is pinned by digest.

Common Use Cases

WhatsApp AI agents for clients - an agency builds and runs one agent per customer business.
Shared support inbox - operators and agents answer WhatsApp conversations in one place.
White-label client portals - each client gets a branded portal and a web chat widget.
Self-hosted alternative to hosted chatbot platforms - own the conversations and the keys.

Dependencies for OpenLivery Hosting

The five services above, created by the template. An OpenAI or Anthropic API key is added inside OpenLivery afterwards to power the agents.

Deploy OpenLivery | (Just Updated) White-Label WhatsApp AI Agent Platform With Postgres, Owner Login Generated