Deploy and Host Bifrost on Railway

Deploy Bifrost HTTP v2.3.2, an open-source, high-performance AI gateway for routing requests across OpenAI, Anthropic, AWS Bedrock, Google, Azure, and other model providers.

About Hosting Bifrost

This template runs the official Bifrost container as one public service on port 8080. Its configuration database, gateway settings, logs, budgets, virtual keys, routing rules, and plugin state persist on a Railway volume mounted at /app/data.

Open the generated domain to configure providers and routing in the Bifrost dashboard. The gateway starts without provider credentials, but model requests require at least one configured provider. Configure Bifrost authentication, virtual keys, and governance controls before exposing production provider access.

Common Use Cases

Expose one OpenAI-compatible endpoint for multiple model providers.
Route and fail over traffic by availability, latency, performance, or cost.
Apply budgets, virtual keys, guardrails, and governance policies.
Observe LLM and MCP gateway requests from the built-in dashboard.
Normalize chat, Responses, embeddings, speech, and provider-specific APIs.

Dependencies for Bifrost Hosting

Official maximhq/bifrost:v2.3.2 image, pinned to an immutable multi-architecture OCI index.
One persistent volume mounted at /app/data with monthly backups.
External model-provider credentials for the providers you enable.
Adequate memory and connection capacity for the expected request volume.

Deployment Dependencies

Implementation Details

The service listens on port 8080 and Railway checks /health, including the persistent configuration database ping. RAILWAY_RUN_UID=0 preserves the official image's expected runtime permissions for /app/data. The image is pinned by stable tag and digest; the template does not use latest.

The /v1/models endpoint is available after startup and returns configured models. With no providers configured it returns an empty list, which is expected. Keep the Bifrost dashboard and gateway controls protected when adding real provider credentials.

First run and the setup token

Bifrost v2.3.2 locks the dashboard and management API until an administrator exists. This template generates BIFROST_SETUP_TOKEN: open the dashboard, enter that token, and create the admin account. New deployments also require a key on inference requests by default.

Deployments created from an earlier version of this template do not have the variable. Add BIFROST_SETUP_TOKEN (a long random value) to the service before moving its image to v2.3.2; without it the dashboard and /api answer 403.

Upgrading an existing deployment to v2.3.2

Back up the /app/data volume first: v2.3.2 runs non-reversible configuration database migrations. It also turns on the Warp AI assistant by default and ties objects to the virtual key that created them. Deployments created before the v2.2.6 template update still need BIFROST_SETUP_TOKEN set before upgrading.

Why Deploy Bifrost on Railway?

Railway provides managed HTTPS, health checks, persistent storage, monthly backups, centralized logs, and reproducible image deployment for Bifrost.

Upgrading from v1

Bifrost v2 is a breaking release for API clients: governance endpoints moved to /api/governance, the request cost object became a per-category breakdown, custom plugin downloads are now SSRF-protected (private hosts need a server.plugin_download_private_allowlist entry), custom plugin creation requires admin auth, and legacy observability attribute aliases were removed. The bundled /app/data database migrates itself on startup. See the upstream v2.0.0 migration guide.