Deploy and Host OmniRoute AI Gateway on Railway

OmniRoute AI Gateway is a unified AI proxy that routes multiple LLM providers through a single OpenAI-compatible endpoint. Instead of juggling separate provider URLs, request formats, and per-tool client configs, OmniRoute gives you one gateway for connecting models across providers. This template self-hosts it on Railway with a Redis-backed cache layer.

OmniRoute

About Hosting OmniRoute AI Gateway

Hosting OmniRoute AI Gateway on Railway means running two services on Railway's private network: the omniroute app itself, and Redis for session and routing-state caching. The app connects to Redis over REDIS_URL on the private network, so no extra networking setup is needed beyond deploying both services from the template.

A persistent volume on the omniroute service keeps your dashboard configuration, providers, endpoints, and routing setup intact across redeploys. Redis has its own separate volume for its data (--save 60 1 — snapshotting every 60 seconds if at least one key changed).

Once it's up, open the public URL, add your provider credentials from the dashboard, create an endpoint and API key, then point tools like Claude Code, Cursor, Cline, OpenWebUI, or any OpenAI-compatible SDK at the generated /v1 endpoint.

Common Use Cases

Consolidate multiple LLM providers behind one endpoint instead of managing separate configs for OpenAI, Claude, Gemini, and OpenRouter-style APIs
Centralize provider key management — add and rotate credentials from a single dashboard rather than per-tool
Standardize coding-agent config — give Claude Code, Cursor, Cline, and other OpenAI-compatible tools one Base URL and API key
Route across models from a central gateway instead of hardcoding a provider per project
Run a self-hosted AI proxy for a team, an automation pipeline, or internal tooling — without depending on a third-party gateway

Dependencies for OmniRoute AI Gateway Hosting

Component	Details
OmniRoute image	`diegosouzapw/omniroute:latest`
Redis	`redis:8.2.1` — session and routing-state cache, password-protected
Railway private networking	`omniroute` reaches Redis via `${{Redis.REDIS_URL}}`
Two persistent volumes	one per service — see Volumes below
Public URL	required on `omniroute` for dashboard and API access; Redis stays private
Provider API keys	from whichever AI providers you plan to connect (added after deploy, from the dashboard)

Upstream references: OmniRoute GitHub · Docker image

Topology

Service	Role	Volume	Port	Public
omniroute	Dashboard, routing, and API gateway	`/data`	`20128`	Yes
redis	Session / routing-state cache	`/data`	`6379` (internal)	No

Once deployed, omniroute exposes:

Dashboard:
https://your-domain

OpenAI-compatible API endpoint:
https://your-domain/v1

Volumes — what to mount

Attach both volumes before the first successful start. Skip this and configuration or cached state lands on ephemeral disk — the next redeploy wipes it.

Service	Mount path	What lives there
omniroute	`/data`	Dashboard configuration, connected providers, endpoints, routing setup
redis	`/data`	Redis RDB snapshots (session/routing-state cache)

Note: the omniroute service also sets a DATA_DIR environment variable defaulting to /app/data — that's the path the application writes to internally inside the container. The Railway volume backing persistent storage is mounted at /data. Don't confuse the two when checking that persistence is actually wired up.

In Railway: open each service → Settings → Volumes → Add Volume → set the mount path exactly as shown above.

Configuration

Set automatically by the template — no action needed:

Variable	Default	Description
`PORT`	`20128`	App listen port
`HOSTNAME`	`0.0.0.0`	Bind address
`NODE_ENV`	`production`	Runtime mode
`BASE_URL` / `NEXT_PUBLIC_BASE_URL`	`https://${{RAILWAY_PUBLIC_DOMAIN}}`	Public URL the app reports for itself
`DATA_DIR`	`/app/data`	Internal app data path (see Volumes note above)
`REDIS_URL`	`${{Redis.REDIS_URL}}`	Private-network connection string to the Redis service
`JWT_SECRET`, `API_KEY_SECRET`, `MACHINE_ID_SALT`	auto-generated 32-char secrets	Do not set manually — regenerating these invalidates existing sessions and issued API keys
`MODELS_DEV`	`false`	Enables dev-only model listing when `true`
`PRICING_SYNC_ENABLED`	`true`	Keeps provider pricing data synced
`CLOUD_URL`	`https://9router.com`	Upstream cloud service endpoint
`NEXT_PUBLIC_CLOUD_URL`	`https://omniroute.online/`	Public-facing cloud URL shown in the dashboard — intentionally a different host from `CLOUD_URL` above

Optional:

Variable	Default	Description
`INITIAL_PASSWORD`	(empty)	Set this to pre-seed the first dashboard login password; leave blank to set it on first visit instead

Traps

Two things worth getting right before you deploy:

Attach the omniroute volume at /data, not /app/data. DATA_DIR=/app/data is an internal application setting, but the Railway volume itself mounts at /data. Mounting a volume at /app/data to "match" the env var doesn't connect it to what the template actually provisions — follow the Volumes table above, not the env var name.
Don't hand-set the auto-generated secrets (JWT_SECRET, API_KEY_SECRET, MACHINE_ID_SALT). They're generated once at deploy time. Overwriting them later invalidates every active session and every API key issued through the dashboard.

Why Deploy OmniRoute AI Gateway on Railway?

Railway is a single platform for your whole infrastructure stack — it hosts everything so you don't have to manage configuration, while still letting you scale vertically and horizontally as needed.

Deploying OmniRoute AI Gateway on Railway gets you a self-hosted AI routing layer with minimal operational overhead. Host your servers, databases, AI agents, and more, all in one place.