Deploy and Host 9Router on Railway

9Router is an open-source (MIT) self-hosted AI gateway and LLM router. It exposes a single OpenAI-compatible endpoint and routes each request across 40+ providers — OpenAI, Anthropic, Google, DeepSeek, Qwen, OpenRouter and more — by price, quota and availability, with automatic fallback when a provider hits its limit. A web dashboard manages providers, API keys, routing rules and usage, and it works as a drop-in base URL for Claude Code, Codex, Cursor, Gemini CLI and anything else that speaks the OpenAI API.

It is bring-your-own-key: it runs on your infrastructure with your own provider accounts and takes no markup.

This template deploys it as a single pinned service on a persistent volume, and the deploy form has nothing you have to fill in.

About Hosting 9Router

9Router is one container, so the interesting part of hosting it is not the topology — it is that the container holds your provider credentials and answers on a public URL. Three things this template does differently from the other 9Router listings:

• The dashboard password is generated, not left blank. Upstream reads process.env.INITIAL_PASSWORD || "123456" in its login route, and an empty string is falsy in JavaScript — so a deploy that leaves that variable empty is reachable at its public Railway URL with the password 123456, guarding a dashboard that stores your OpenAI and Anthropic keys. Listings that publish INITIAL_PASSWORD as an empty required field put exactly one typo between the deployer and that outcome. Here it arrives as a generated 24-character secret, so the fallback is unreachable: on the reference deploy, 123456 returns 401 Invalid password while the generated value logs in cleanly. Read it in Railway's variables panel, and change it in the dashboard whenever you like.
• The image is version-pinned. This template runs decolua/9router:0.5.45, never latest. 9Router ships often — nine releases in the last six weeks — and on Railway an unrelated restart months from now will happily pull a newer build of a service that is proxying your production traffic and holding your billing-relevant provider quotas. Upgrading here is an explicit change of tag.
• It keeps the image's own entrypoint, so it does not run as root. The upstream image chowns its data directory and then drops to an unprivileged node user before starting. A Railway start command replaces an image's entrypoint instead of adding to it, so any listing that sets one silently loses both that privilege drop and the chown that makes a Railway volume writable in the first place. This template sets no start command.

Sizing: it is a Node/Next.js service with a SQLite database — a few hundred MB of RAM. Comfortable on the Hobby plan.

Why Deploy 9Router 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 9Router 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.

• A gateway that is always up — a router on your laptop stops routing when the laptop sleeps. On Railway your agents, CI jobs and teammates share one endpoint that is always reachable.
• Nothing to configure — every variable arrives pre-filled. The dashboard password and the three signing secrets are generated at deploy time, and the public URL is derived from your Railway domain.
• No surprise upgrades — a pinned image means the version you tested is the version that redeploys.
• Your keys stay yours — provider credentials live in your own container on your own volume, not in a hosted middleman that meters and marks up your usage.

Common Use Cases

• One endpoint for every coding agent — point Claude Code, Codex, Cursor and Gemini CLI at the same base URL and switch the model behind it without touching each tool's config.
• Cutting inference spend — route each request to the cheapest model that will do the job, and fall back to a second or third provider automatically when the first is rate-limited or out of quota.
• A shared team gateway — hand out 9Router API keys instead of your real provider keys, and see per-key usage in one dashboard.
• Surviving provider outages — keep an app serving when a single upstream provider is degraded, without a deploy.

Dependencies for 9Router Hosting

• A persistent volume at /app/data (included in this template). It holds the SQLite database, the persisted machine id, and a random per-install secret that the CLI auth token is derived from. Without it, every redeploy discards your providers, keys and usage history.
• Accounts or API keys for the AI providers you want to route to — added in the dashboard after deploying, not at deploy time. Nothing external is required to get the service running.

Deployment Dependencies

• 9Router — the upstream open-source project (MIT)
• 9Router documentation — provider setup, routing and CLI-tool guides
• decolua/9router Docker image — the upstream image this template pins (0.5.45)

Implementation Details

After the deploy finishes:

1. Open your Railway domain. It redirects to /login.
2. Log in with INITIAL_PASSWORD from the Railway variables panel.
3. Dashboard → providers → add your provider accounts or API keys.
4. Create a 9Router API key.
5. Point any OpenAI-compatible client at https:///v1 using that key.

For CLI tools, the dashboard's CLI Tools section prints the exact per-tool configuration (each one wants a different environment variable or config file).

Health check at any time:

curl https:///api/health

The /v1 surface requires a 9Router-issued API key for remote callers — an unauthenticated request returns 401 {"error":"API key required for remote API access"} — and the dashboard and its /api/* routes are deny-by-default behind the session cookie.

Upgrading. Change the image tag to a newer release (tags) and redeploy; migrations run on boot against the database on your volume. Back the volume up first.