Deploy and Host Bifrost on Railway

Bifrost is an AI gateway: one OpenAI-compatible endpoint in front of OpenAI, Anthropic, Gemini, OpenRouter and 20+ other providers, with virtual keys, budgets, rate limits, fallbacks, request logs and a dashboard. This template runs version 2.2.4.

About Hosting Bifrost

A gateway holds your provider keys, so a public one has to be locked before anyone finds the URL. A fresh Bifrost is open: until an admin account exists its config API accepts changes without a login, and unless "enforce auth on inference" is on, anyone can send requests through your keys.

Here a start step writes Bifrost's config.json before every start:

the dashboard login is on, with BIFROST_ADMIN_PASSWORD generated at deploy
every model call needs a key; BIFROST_VIRTUAL_KEY is generated and works with every provider you add
browser requests from other sites (CORS) are limited to your Railway domain
each provider key you set as a variable (OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, OPENROUTER_API_KEY) becomes a provider

The file only holds references to the variables, not the keys themselves. Bifrost merges it into its own database at start and keeps changes you make in the dashboard unless the matching part of the file changes. If the password or key is missing the service refuses to start, so it never runs open.

Before publishing I tested it on Railway with an OpenRouter key. /health answered, the config API refused anonymous reads and writes (401), a wrong password got 401, and the admin signed in and saw keys required on inference and OpenRouter as a provider. A chat completion without a key and with a wrong key got 401; with BIFROST_VIRTUAL_KEY it answered in under a second. After a restart the login, the key and the completion worked the same.

It used 0.27 GB of RAM, about $3 a month on Railway's usage pricing, plus what your providers charge.

Common Use Cases

One endpoint and one key for all your apps, with provider keys kept in one place
Switching models or providers without changing app code, with fallbacks when a provider fails
Budgets and rate limits per app or team through virtual keys

Dependencies for Bifrost Hosting

At least one provider key: set it as a variable when you deploy, or add providers later in the dashboard. GROQ_API_KEY, MISTRAL_API_KEY, DEEPSEEK_API_KEY and XAI_API_KEY also work as variables.

Deployment Dependencies

Bifrost: https://github.com/maximhq/bifrost
Docs: https://docs.getbifrost.ai
The start step this template builds: https://github.com/dektionstudio/railway-template-images/tree/main/bifrost

Implementation Details

curl "$BIFROST_OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $BIFROST_VIRTUAL_KEY" -H "Content-Type: application/json" \
  -d '{"model": "openrouter/openai/gpt-4o-mini", "messages": [{"role": "user", "content": "Hello"}]}'

Models are named provider/model, for example openai/gpt-4o-mini or anthropic/claude-sonnet-4-5. In OpenAI SDKs and tools, set the base URL to BIFROST_OPENAI_BASE_URL and the API key to BIFROST_VIRTUAL_KEY. Create more virtual keys, with their own budgets, in the dashboard.

Why Deploy Bifrost on Railway?

Your apps on Railway reach the gateway over one URL, the dashboard is on HTTPS behind a login from the first minute, and the config and logs stay on a volume across redeploys.