Skip to main content
Bifrost runs as a long-running Linux container. To deploy it, choose a container platform, decide where Bifrost will store its configuration and logs, provide its secrets, and expose its HTTP port. Start with Bifrost Deployment Requirements to understand the image, storage, database, ports, health checks, and scaling behavior. Then use the guide for your platform.

​
Deployment support matrix

The Kubernetes guides begin with an existing cluster. If you need to create a cluster, each page links to the cloud provider’s setup documentation before continuing with the Bifrost installation.

​
Choose where Bifrost stores data

Bifrost stores provider configuration, encrypted credentials, application settings, and request logs. Choose one of these storage models before deploying: When using PostgreSQL, Bifrost requires version 16 or later. It can be an existing database, a self-managed server, or a managed database such as Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL, Render Postgres, or Railway Postgres. Use whichever service fits your infrastructure and connect Bifrost using the host, port, database name, username, password, and TLS mode. When both config_store and logs_store use PostgreSQL, Bifrost does not use SQLite and does not need persistent storage mounted at /app/data. The application directory and config.json must still be available to the running container.
Bifrost Enterprise does not support SQLite. Configure both Enterprise stores with PostgreSQL 16 or later. SQLite is available only for OSS deployments and belongs to one Bifrost process; do not mount the same SQLite database into several containers. OSS instances using a shared PostgreSQL configuration store also do not automatically update each other’s in-memory configuration; use the OSS multinode setup or Enterprise clustering.

​
Prepare configuration and secrets

Every deployment needs:
  • A versioned Bifrost image.
  • An application directory at /app/data; persist it only for an OSS deployment whose configuration store or log store uses SQLite.
  • A stable encryption key when persisted credentials are encrypted.
  • Credentials for the LLM providers and integrations you configure.
  • Database connection values when using PostgreSQL.
  • Network access to the database, model providers, MCP servers, and observability endpoints in your configuration.
Kubernetes users normally place these values in Helm values and Kubernetes Secrets. Hosted-container users normally supply them as environment variables and secret values. See Bifrost Deployment Requirements for the exact names and defaults.

​
Expose Bifrost

Bifrost listens for HTTP traffic on port 8080 by default and provides GET /health on the same port. You can place it behind any ingress, gateway, reverse proxy, or load balancer that:
  • Routes traffic to the Bifrost HTTP port.
  • Forwards streaming responses without buffering them.
  • Allows long-lived requests.
  • Supports WebSocket upgrades when you use the Realtime or WebSocket APIs.
  • Preserves the host and forwarded-protocol headers when TLS terminates at the proxy.
The platform guides show one example for exposing the service. You can replace that example with another compatible implementation.

​
Deploy and verify

The installation sequence is the same on every platform:
  1. Create or select the container service or Kubernetes cluster.
  2. Create the Bifrost encryption key and provider secrets.
  3. For OSS with SQLite, prepare persistent /app/data storage. For PostgreSQL-only storage, including every Enterprise deployment, prepare the database connection instead.
  4. Supply the image, configuration, secrets, and database connection to Bifrost.
  5. Expose the Bifrost HTTP port to its intended clients.
  6. Start the service and wait for /health to return 200.
  7. Send one non-streaming request and one streaming request through the same endpoint your applications will use.
  8. Replace or restart the container and confirm that the selected storage preserves the configuration.
Before serving production traffic, complete the deployment verification checklist. For Enterprise deployments with several replicas, continue with Cluster Mode and HA. For deployments spanning clusters or regions, see Enterprise clustering.