Full schema reference:
https://www.getbifrost.ai/schemaconfig.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 aconfig.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.config.json in your app directory and start Bifrost:
Environment Variable References
Never put secrets directly inconfig.json. Use the env. prefix to reference any environment variable:
-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:
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 fromconfig.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:Minimal / File-only
Minimal / File-only
Storage
Storage
Semantic Cache
Semantic Cache
Governance
Governance
Observability
Observability
Plugins & Advanced
Plugins & Advanced
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
- Configure provider keys
- Enable plugins
- Set up observability
- Configure governance
- Deploy multiple nodes with a shared
config.json

