Skip to main content
Full schema reference: https://www.getbifrost.ai/schema
config.json lets you configure every aspect of Bifrost through a single declarative file. It is the right choice for GitOps workflows, CI/CD pipelines, headless deployments, and multinode OSS setups where a central configuration file is shared across all replicas.

Configuration Sources

Bifrost stores runtime configuration in a config database by default, so settings can be edited through the Web UI or API. You can also provide a config.json file to seed or reconcile that database at startup. To run with only config.json, set config_store.enabled: false.
By default, DB-backed config.json uses source_of_truth: "split": unchanged file-backed rows preserve UI/API edits, while changed file-backed rows are applied on the next startup. Use source_of_truth: "config.json" only when explicitly present file sections should replace matching DB state. See Source of Truth & Reconciliation for the full rules, including missing-vs-empty section behavior.

Minimal Working Example

This example uses file-only configuration for the smallest self-contained setup.
Save this as config.json in your app directory and start Bifrost:
Make your first call:

Environment Variable References

Never put secrets directly in config.json. Use the env. prefix to reference any environment variable:
Set the actual values through your deployment platform - shell environment, Docker -e, Kubernetes Secrets mounted as env vars, or a .env file. For Enterprise deployments, vault.<path> references are also supported. See Secret Management.

Schema Validation

Add $schema to every config.json for IDE autocomplete and inline validation:
Editors (VS Code, JetBrains, Neovim with LSP) will show completions and flag invalid fields as you type.

Production Example

A production-ready file with PostgreSQL storage, multi-provider setup, governance, and common plugins:

Enterprise Example: Postgres + etcd + Access Profiles

Use this pattern when you want enterprise access-profile configuration to be seeded directly from config.json, while running clustered nodes with etcd discovery.
access_profiles is an enterprise capability. For OSS-only deployments, use governance.virtual_keys and related governance resources instead.

Example Configs

Ready-to-use reference configurations from the examples/configs directory on GitHub:

Configuration Guides

Schema Reference

Every top-level key, its type, default, and where it is documented

Client Configuration

Pool size, logging, CORS, header filtering, compat shims, MCP settings

Provider Setup

OpenAI, Anthropic, Azure, Bedrock, Vertex, Groq, self-hosted

Storage

config_store, logs_store, vector_store - SQLite, PostgreSQL, object storage

Plugins

Semantic cache, OTel, Maxim, Datadog, custom plugins

Cluster

Cluster mode with static peers or discovery backends (enterprise)

Governance

Virtual keys, budgets, rate limits, routing rules, admin auth

Alerting

Alert channels, CEL rules, history retention, webhook network controls

Guardrails

Content moderation providers and CEL-based rules (enterprise)

Secret Management

AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault - vault references in provider keys and credentials (enterprise)

Next Steps

  1. Configure provider keys
  2. Enable plugins
  3. Set up observability
  4. Configure governance
  5. Deploy multiple nodes with a shared config.json