Deploy Bifrost Gateway (Go)

Deploy and Host Bifrost on Railway

Bifrost is an open-source LLM gateway written in Go. It puts one OpenAI-compatible endpoint in front of OpenAI, Anthropic, Bedrock, Vertex, Azure, Mistral, Groq, Ollama and more, with a built-in dashboard for providers, virtual keys, budgets, fallbacks, semantic caching, MCP tools, and request logs.

About Hosting Bifrost

Hosting Bifrost is a single container. This template uses the official maximhq/bifrost:v2.2.1 image with a Railway volume mounted at /app/data, which is where Bifrost keeps its SQLite configuration store and request logs, the same layout as the upstream Docker Compose example. PORT and APP_PORT are pinned to 8080 so Railway's healthcheck hits /health on the right port, APP_HOST is :: so other Railway services can reach it over IPv6 private networking, and RAILWAY_RUN_UID=0 works around the image's non-root user against Railway's root-owned volumes. The dashboard and admin API are password protected from the first boot: the start command seeds a config.json that turns on admin auth and requires a virtual key on every inference call, with the username and password read from environment variables so no credential is written into the file. An encryption key and the admin password are generated for you.

Common Use Cases

• Unified LLM API: one base URL for every provider, with provider/model naming
• Drop-in SDK replacement: point the OpenAI, Anthropic, or GenAI SDK at /openai, /anthropic, or /genai
• Virtual keys and budgets: per-team or per-app keys with spend and rate limits
• Fallbacks and load balancing: retry across keys, models, and providers
• Observability: request logs in the dashboard, Prometheus /metrics, OTel export
• Private gateway for other Railway services: keep provider keys off your app containers

Dependencies for Bifrost Hosting

• Railway volume at /app/data (included)
• Provider API keys: optional at boot; OPENAI_API_KEY / ANTHROPIC_API_KEY are auto-registered on first boot, or add any provider in the dashboard
• No database service required: SQLite is the OSS default. PostgreSQL 16+ is an optional alternative

Deployment Dependencies

• Bifrost deployment requirements
• Bifrost on Railway (upstream guide)
• Setting up auth
• Bifrost GitHub repository

Implementation Details

The image entrypoint runs /app/main -app-dir "$APP_DIR" -port "$APP_PORT" -host "$APP_HOST", so no custom start command is needed. Key variables:

PORT=8080
APP_PORT=8080
APP_HOST=::
APP_DIR=/app/data
RAILWAY_RUN_UID=0
BIFROST_ENCRYPTION_KEY=${{secret(64,"abcdef0123456789")}}
BIFROST_ADMIN_USERNAME=admin
BIFROST_ADMIN_PASSWORD=${{secret(24)}}Aa1!

First steps after deploy

1. Wait for /health to return {"status":"ok"}.
2. Open the dashboard at your Railway domain and sign in with BIFROST_ADMIN_USERNAME (admin) and the generated BIFROST_ADMIN_PASSWORD from the service variables. Anonymous visitors get a 401.
3. Add a provider under Providers, then create a virtual key under Governance.
4. Call the gateway with that key in the x-bf-vk header. Inference without a credential is refused, so your provider keys cannot be spent by anyone who finds the URL.

Never rotate BIFROST_ENCRYPTION_KEY after first boot; stored secrets become unreadable. Keep one replica: SQLite is single-process and Railway volumes do not support replicas.

Why Deploy Bifrost 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 Bifrost on Railway, you get a pinned, health-checked LLM gateway with persistent storage, generated secrets, managed SSL, and private networking to the rest of your Railway project.