Deploy and Host Evolution CRM on Railway

Built for an LLM agent to deploy and use. The deploy form has nothing to fill in: every secret is generated, the administrator account is created at first boot, and the database, cache and uploads survive redeploys. Evolution CRM is the open-source customer support and sales CRM: a shared inbox for conversations, contacts, pipelines, and AI agents that answer and route messages, with a REST API in front of all of it.

About Hosting Evolution CRM

This template runs nine services from the upstream Evolution CRM community images, each pinned by digest. gateway is the public API front door on one domain and routes to the other services. frontend is the web interface and points at the gateway. auth is the account service (users, tokens, MFA) and creates the administrator at first boot. crm holds conversations, contacts and pipelines, with its background worker in the same container. core and processor run the AI agents. bot-runtime runs chatbots. postgres (pgvector, one database shared by the services) and redis carry the state, each on a volume.

No default login. The administrator is ADMIN_EMAIL (admin at the gateway domain), created from the generated ADMIN_PASSWORD. The public gateway refuses the first-run setup route, so nobody can claim the instance by posting to it; the administrator is created from inside the auth service within seconds of it starting.

What the template fixes for Railway. Services reach each other over the private network, so every internal address is the service's railway.internal name. The gateway listens on Railway's injected PORT and resolves names through Railway's own DNS. The shared secrets (token signing keys, the agent encryption key, the service-to-service token) are generated once and referenced by every service that needs them, so a redeploy keeps every session and every stored credential valid.

Using it. Open the frontend domain, sign in with ADMIN_EMAIL and ADMIN_PASSWORD (read both from the auth service variables), then connect an inbox, add contacts and build a pipeline. The API is on the gateway domain; the same account signs in there.

Agent contract

Public URL: https://RAILWAY_SERVICE_GATEWAY_URL (the generated domain of the gateway service, also the part of ADMIN_EMAIL after the at sign); the web interface is on the frontend service domain
Private URL: http://gateway.railway.internal:8080
Credentials: the variable ADMIN_PASSWORD on the auth service
Login name: the variable ADMIN_EMAIL on the auth service (a public identifier, not a secret)
Auth: POST /api/v1/auth/login with JSON email and password returns a bearer token in data.token.access_token; every other /api/v1 call sends it as Authorization: Bearer TOKEN. A request with no token or a wrong one answers 401.
Health: GET /setup/status returns 200 with "status":"active" once the administrator exists

#!/bin/sh
# needs: ADMIN_EMAIL, ADMIN_PASSWORD (variables of the auth service); also curl. ADMIN_EMAIL is admin@ plus the gateway's public domain.
D="${ADMIN_EMAIL#admin@}"; R="https://$D"; J="Content-Type: application/json"; B=$(mktemp)
n=0; until curl -s "$R/setup/status" | grep -q '"active"'; do n=$((n+1)); [ "$n" -le 90 ] || break; sleep 5; done
n=0; until [ "$(curl -s -o /dev/null -w '%{http_code}' "$R/api/v1/contacts")" = 401 ]; do n=$((n+1)); [ "$n" -le 90 ] || break; sleep 5; done
curl -s "$R/setup/status" | grep -o '"status":"[a-z]*"' | sed 's/^/setup /'
# sign in as the administrator created at first boot; the answer carries a bearer token
curl -s -o "$B" -w "login: %{http_code}\n" -H "$J" -d "{\"email\":\"$ADMIN_EMAIL\",\"password\":\"$ADMIN_PASSWORD\"}" "$R/api/v1/auth/login"
T=$(sed -n 's/.*"access_token":"\([^"]*\)".*/\1/p' "$B"); A="Authorization: Bearer $T"
curl -s -o /dev/null -w "read with token: %{http_code}\n" -H "$A" "$R/api/v1/contacts"
curl -s -o "$B" -w "write with token: %{http_code}\n" -H "$A" -H "$J" -d '{"name":"Railway Check","email":"check@example.com"}' "$R/api/v1/contacts"
C=$(sed -n 's/.*"contact":{"id":"\([^"]*\)".*/\1/p' "$B")
curl -s -H "$A" "$R/api/v1/contacts" | grep -c "$C" | sed 's/^/contact found after write: /'
curl -s -o /dev/null -w "delete with token: %{http_code}\n" -X DELETE -H "$A" "$R/api/v1/contacts/$C"
curl -s -o /dev/null -w "read without token: %{http_code}\n" "$R/api/v1/contacts"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST -H "$J" -d '{"name":"Anonymous"}' "$R/api/v1/contacts"
curl -s -o /dev/null -w "write wrong token: %{http_code}\n" -X POST -H "Authorization: Bearer wrong" -H "$J" -d '{"name":"Anonymous"}' "$R/api/v1/contacts"
curl -s -o /dev/null -w "public bootstrap: %{http_code}\n" -X POST -H "$J" -d '{}' "$R/setup/bootstrap"

A fresh deploy prints setup "status":"active", login: 200, read with token: 200, write with token: 201, contact found after write: 1 and delete with token: 200. The refusals print read without token: 401, write without key: 401, write wrong token: 401 and public bootstrap: 404: a request with no token or a wrong one creates nothing, and first-run setup cannot be reached from outside.

Why Deploy Evolution CRM 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 Evolution CRM 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 secrets, 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 token or a wrong one.
No setup form and no default login - the administrator is created at boot from a generated password.
Data survives redeploys - conversations and contacts sit in Postgres on a volume, uploads and the cache on their own volumes.
One public API domain - the gateway fronts auth, CRM and agent services.
Pinned - every upstream image is pinned by digest.

Common Use Cases

Shared customer support inbox - one place for conversations from every channel, with assignment and history.
Sales pipelines and contact management - track leads through stages and keep one record per customer.
AI agents that answer and route messages - agents read a conversation, reply or hand it to a person.
CRM automation for AI agents - an agent signs in, creates contacts and reads conversations over the REST API.

Dependencies for Evolution CRM Hosting

The nine services above, created by the template. Channel connections (WhatsApp, email, chat widgets) and AI provider keys are added inside Evolution CRM afterwards.

Deploy Evolution CRM | (Just Updated) Open Source Customer Support Inbox And AI Agent CRM With REST API, Admin Generated