Skip to main content
This page covers every top-level parameter group in the Bifrost Helm chart’s values.yaml, how to supply values via --set vs -f, and where to find ready-made example files.
The full values schema is available at https://getbifrost.ai/schema. All values.yaml fields map directly to config.json fields generated by the chart.

Supplying Values

One-liner with --set

Good for a single field or quick experiments:

Values file with -f

Recommended for anything beyond a couple of fields:

Multiple values files

Later files override earlier ones - useful for a base + environment-specific overlay:

Key Parameters Reference

Image

Replicas & Autoscaling

Resources

Service

Ingress

Probes

Both probes hit GET /health.

Graceful Shutdown

Bifrost supports long-lived SSE streaming connections. The default preStop hook and termination grace period let in-flight streams finish before the pod is killed: Increase terminationGracePeriodSeconds if your typical stream responses take longer than 45 seconds.

Service Account

Pod Scheduling

Spreading replicas across zones and nodes topologySpreadConstraints is rendered into the Bifrost pod spec (Deployment or StatefulSet) to spread replicas across nodes or zones, which reduces the chance that losing one takes every replica down. Unlike a required pod anti-affinity rule, it still lets you run more replicas than you have nodes. It does not guarantee a spread: ScheduleAnyway only prefers one, and DoNotSchedule without minDomains can still place every replica in the only eligible domain.
With DoNotSchedule, a domain whose nodes are cordoned or tainted still counts toward the skew (the default nodeTaintsPolicy: Ignore), so scaling up can leave pods Pending. Use ScheduleAnyway, or set nodeTaintsPolicy: Honor, when that is not what you want.

Extra Environment Variables

Three ways to inject env vars:

Init Containers

Sidecar Containers

Add sidecars the way Kubernetes defines them; the chart has no separate sidecar setting. Every container in the pod shares its network, so a sidecar reaches Bifrost on localhost:8080. Native sidecars (Kubernetes 1.29+) are init containers with restartPolicy: Always, as described in the Kubernetes sidecar docs. Add them under initContainers. Kubernetes starts a native sidecar before the init containers listed after it and before Bifrost, keeps it running beside Bifrost, restarts it if it exits, and stops it only after Bifrost has shut down. Use one for anything Bifrost needs from startup to shutdown, such as a database proxy. This one runs the Cloud SQL Auth Proxy and points Bifrost’s external PostgreSQL at it:
Init containers run in list order, so put a native sidecar before any init container that needs it (for example, a migration step that connects through the proxy). Kubernetes moves on once a native sidecar has started, not once its service is ready: when something depends on the sidecar being ready, give it a startupProbe, and Kubernetes waits for the probe to succeed first. The kubelet sends probes to the pod IP, so a sidecar that listens only on 127.0.0.1 (like the proxy’s Postgres port) needs a probe on a listener the kubelet can reach, such as the proxy’s health endpoint above. On a cluster older than 1.29, the chart refuses to render an init container with restartPolicy: Always rather than leave the pod stuck behind an init container that never exits. Regular sidecars go in extraContainers, which the chart appends to the pod’s containers after Bifrost. They start and stop alongside Bifrost with no ordering guarantee, and work on any Kubernetes version. This one serves Bifrost on a second pod port by forwarding raw TCP:
A TCP forwarder passes every route on port 8080, the full API included, with the same authentication; it is not a metrics-only endpoint. To expose only /metrics on its own port, use an HTTP proxy that allows that path alone. Share files between Bifrost and a sidecar by declaring the volume under volumes, mounting it into Bifrost with volumeMounts, and mounting it into the sidecar in its own volumeMounts.

Values Examples

The chart ships ready-made example files under helm-charts/bifrost/values-examples/: Install from an example file directly:

Helm Operations

View current values

Diff before upgrading (requires helm-diff plugin)

Rollback

Uninstall


All Key Parameters

A quick-reference table of the most commonly used top-level parameters:

Secret Reference Parameters

Use existing Kubernetes Secrets instead of plain-text values. Every sensitive field in the chart has a corresponding existingSecret / secretRef alternative:

Advanced Configuration

Comprehensive Example

A production-ready values file combining the most common settings:

Node Affinity & Scheduling

Deploy to specific nodes and spread replicas across hosts:

Deployment & Pod Annotations

Useful for tooling like Keel for automatic image updates or Datadog APM injection:

Common Patterns

Ready-made values files for the most common deployment scenarios. Each pattern builds on the quickstart.
Simple setup for local testing. SQLite, single replica, no autoscaling.