docs: add comprehensive config.json reference guide#2790
Merged
Conversation
Contributor
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds a new "Config as Code" docs section with a Quick Start and detailed subpages for configuring Bifrost via a declarative Changes
Sequence Diagram(s)sequenceDiagram
actor Operator
participant Bifrost
participant ConfigFile as "config.json (file)"
participant ConfigStore as "Config Store (DB)"
participant WebUI
Operator->>Bifrost: start
Bifrost->>ConfigFile: check presence and config_store.enabled
alt config_store enabled or config.json absent
Bifrost->>ConfigStore: load configuration (DB-backed)
ConfigStore-->>Bifrost: return config
Bifrost->>WebUI: enable UI
else file-based mode (config.json present && config_store disabled)
ConfigFile-->>Bifrost: provide config (file-only)
Bifrost->>WebUI: disable UI
end
Bifrost-->>Operator: ready (providers, plugins, storage configured)
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Contributor
Confidence Score: 5/5Documentation-only PR; safe to merge — all new findings are P2 suggestions with no blocking issues All new findings are P2 documentation gaps (missing field entries and undocumented sub-keys). No correctness, data-integrity, or security issues were found in the new content. docs/deployment-guides/config-json/governance.mdx (missing pricing_overrides/model_configs sections) and docs/deployment-guides/config-json/plugins.mdx (missing cleanup_on_shutdown in semantic cache table) Important Files Changed
Reviews (5): Last reviewed commit: "docs: add doc for config json" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/deployment-guides/helm/plugins.mdx (1)
3-3:⚠️ Potential issue | 🟠 MajorRemove or correct the false claims that telemetry, logging, and governance are "auto-loaded built-ins".
The page contradicts itself and the Helm chart. Lines 9–13 claim telemetry, logging, and governance are "always active and do not need to be explicitly enabled," but the chart values still require
bifrost.plugins.telemetry.enabled,bifrost.plugins.logging.enabled, andbifrost.plugins.governance.enabledto be set totrue(which default tofalse). The page's own examples at lines 68–83 and 494–513 correctly show these plugins being enabled via thebifrost.pluginsblock.Either remove the incorrect notes (lines 9–13, 47, 102, 139) or update the chart to truly auto-load these plugins. Additionally, update line 3's description to remove telemetry, logging, and governance since they are configured through the plugins block, not as separate concepts.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/helm/plugins.mdx` at line 3, Update the docs to remove or correct claims that telemetry, logging, and governance are "auto-loaded built-ins": remove the misleading text near the top (the description string) and any notes stating they are always active, and instead document that these plugins must be enabled via the bifrost.plugins block using the chart values bifrost.plugins.telemetry.enabled, bifrost.plugins.logging.enabled, and bifrost.plugins.governance.enabled (which default to false); ensure examples that already show enabling them via bifrost.plugins remain and any references that treat them as separate auto-enabled concepts are deleted or rewritten to point to the bifrost.plugins configuration keys.
🧹 Nitpick comments (1)
docs/deployment-guides/config-json/governance.mdx (1)
10-10: Clarify precedence between inference-auth flags.Line [10] and Lines [26-27]/Line [37] describe two knobs that can affect inference-route auth, but precedence is not explicit. Please add one sentence defining which setting wins when both are set.
Also applies to: 26-27, 37-37
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/config-json/governance.mdx` at line 10, Add one concise sentence clarifying precedence: state that client.enforce_auth_on_inference is a global default but any more specific per-route or plugin-level inference auth flag (the other knob referenced in the section) overrides it; if no specific flag is set, client.enforce_auth_on_inference applies.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/deployment-guides/config-json/schema-reference.mdx`:
- Line 27: Update the table row that documents the `vector_store` field in
schema-reference.mdx to include "Valkey" among the supported backends (the row
containing `| `vector_store` | object | Vector database for semantic cache —
Weaviate, Redis, Qdrant, Pinecone |`). Edit that cell so the backend list reads
"Weaviate, Redis, Qdrant, Pinecone, Valkey" (and ensure any
punctuation/formatting matches the existing Markdown table).
- Around line 17-33: Add a missing top-level key row for version in the schema
table: insert a `version` entry (type string) describing the config schema
version used by the file (e.g., "Configuration schema version — see Version
section below") and point its guide link to the documented version section (or
the relevant anchor), so the table aligns with the later `version` documentation
and matches the claim that it lists every top-level key.
In `@docs/deployment-guides/config-json/storage.mdx`:
- Around line 9-13: Update the vector_store backend list in the storage table so
Valkey is included alongside Redis (i.e., change the backends cell for
`vector_store` to list "Weaviate, Redis, Valkey, Qdrant, Pinecone" or similar);
locate the table row with the `vector_store` identifier in
docs/deployment-guides/config-json/storage.mdx and add "Valkey" to the Backends
column, preserving table formatting and ordering.
In `@docs/deployment-guides/helm/guardrails.mdx`:
- Line 157: The Helm guide documents the guardrail rule field `timeout` as
"seconds" but the config-json guide uses "milliseconds" and both show identical
numeric examples; verify the actual runtime unit used by the guardrails
implementation and then update the Helm doc's `timeout` entry and any example
values to match (e.g., if runtime expects milliseconds, change the table unit to
"milliseconds" and convert example values like 5→5000, 10→10000, etc.), and
ensure the `timeout` wording and examples exactly align with the `timeout`
documentation in the config-json guardrails guide.
---
Outside diff comments:
In `@docs/deployment-guides/helm/plugins.mdx`:
- Line 3: Update the docs to remove or correct claims that telemetry, logging,
and governance are "auto-loaded built-ins": remove the misleading text near the
top (the description string) and any notes stating they are always active, and
instead document that these plugins must be enabled via the bifrost.plugins
block using the chart values bifrost.plugins.telemetry.enabled,
bifrost.plugins.logging.enabled, and bifrost.plugins.governance.enabled (which
default to false); ensure examples that already show enabling them via
bifrost.plugins remain and any references that treat them as separate
auto-enabled concepts are deleted or rewritten to point to the bifrost.plugins
configuration keys.
---
Nitpick comments:
In `@docs/deployment-guides/config-json/governance.mdx`:
- Line 10: Add one concise sentence clarifying precedence: state that
client.enforce_auth_on_inference is a global default but any more specific
per-route or plugin-level inference auth flag (the other knob referenced in the
section) overrides it; if no specific flag is set,
client.enforce_auth_on_inference applies.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 52d98f75-f55e-4cb9-851c-0101d76c7ab4
📒 Files selected for processing (11)
docs/deployment-guides/config-json.mdxdocs/deployment-guides/config-json/client.mdxdocs/deployment-guides/config-json/governance.mdxdocs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/config-json/plugins.mdxdocs/deployment-guides/config-json/providers.mdxdocs/deployment-guides/config-json/schema-reference.mdxdocs/deployment-guides/config-json/storage.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/deployment-guides/helm/plugins.mdxdocs/docs.json
BearTS
force-pushed
the
04-17-docs_add_doc_for_config_json
branch
from
73817f9 to
4fd4db8
Compare
BearTS
changed the title
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/deployment-guides/config-json/plugins.mdx`:
- Around line 33-41: The docs currently list `version`, `placement`, and `order`
as config.json fields but those are DB/runtime metadata stored on TablePlugin
(see framework/configstore/tables/plugin.go) while the runtime PluginConfig only
accepts `path`, `name`, `enabled`, and `config` (see framework/plugins/main.go);
update the plugins[] schema by either removing `version`, `placement`, and
`order` from the table entirely or clearly annotating them as
DB-backed/dynamic-plugin metadata (include prerequisites such as UI/DB-only
usage and that they are persisted on TablePlugin rather than accepted in
PluginConfig) so readers aren’t misled about valid config.json keys.
- Around line 55-67: The docs table for Semantic Cache is out of sync with the
actual Config struct in plugins/semanticcache/main.go: update the table rows
(and the similar section around lines 90–105) to exactly reflect all exported
config fields from the Config struct (e.g., keys, vector_store_namespace,
config.dimension, config.provider, config.embedding_model, config.threshold,
config.ttl, config.cache_by_model, config.cache_by_provider,
config.exclude_system_prompt, config.conversation_history_threshold,
config.default_cache_key, etc.), and either document the exact mode-selection
behavior implemented in code (how dimension: 1 triggers hash/exact caching or
whether there is an explicit mode flag) or mark advanced/optional fields and
point to the Config struct as the source of truth; ensure the doc text matches
the code and add a short note to validate Graphite-managed stack docs against
the original stack PR implementations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f6661b3e-93d1-4094-ade1-479fcdc0d7a6
⛔ Files ignored due to path filters (1)
ui/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (11)
docs/deployment-guides/config-json.mdxdocs/deployment-guides/config-json/client.mdxdocs/deployment-guides/config-json/governance.mdxdocs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/config-json/plugins.mdxdocs/deployment-guides/config-json/providers.mdxdocs/deployment-guides/config-json/schema-reference.mdxdocs/deployment-guides/config-json/storage.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/deployment-guides/helm/plugins.mdxdocs/docs.json
✅ Files skipped from review due to trivial changes (8)
- docs/deployment-guides/config-json/schema-reference.mdx
- docs/deployment-guides/config-json/storage.mdx
- docs/deployment-guides/helm/guardrails.mdx
- docs/deployment-guides/config-json/client.mdx
- docs/deployment-guides/config-json.mdx
- docs/deployment-guides/config-json/guardrails.mdx
- docs/deployment-guides/config-json/providers.mdx
- docs/deployment-guides/config-json/governance.mdx
🚧 Files skipped from review as they are similar to previous changes (2)
- docs/docs.json
- docs/deployment-guides/helm/plugins.mdx
BearTS
force-pushed
the
04-17-docs_add_doc_for_config_json
branch
from
4fd4db8 to
9cde781
Compare
BearTS
force-pushed
the
04-17-docs_add_doc_for_config_json
branch
2 times, most recently
from
e29efff to
9d3e0e6
Compare
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
docs/deployment-guides/config-json/plugins.mdx (1)
33-45:⚠️ Potential issue | 🟠 MajorSchema field names appear inconsistent with runtime schema (
name/versionvstype).Line 35 and examples (Line 78, Line 280, Line 300) use
name, and Line 39 documentsversion, but the shown runtime schema (core/schemas/plugin.go:272-291) exposestype,path,enabled,placement,order,configand noversion. Please align docs/examples to the actual accepted keys (or explicitly scope these as DB/UI metadata only).#!/bin/bash # Verify plugin config keys accepted in code and whether `name`/`version` are parsed. rg -n --type=go 'type PluginConfig struct|json:"(type|name|version|path|enabled|placement|order|config)"' rg -n --type=go 'json:"version"' core framework plugins rg -n --type=go '\bconfig\.Plugins\b|LoadPlugins\(' framework coreExpected result: confirm whether
name/versionare actually accepted in config parsing paths used by this stack.Based on learnings, documentation in Graphite-managed stacks should be validated against earlier stack PR implementations before declaring behavior supported.
Also applies to: 78-83, 280-285, 300-304
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/config-json/plugins.mdx` around lines 33 - 45, Docs list plugin fields `name` and `version` but the runtime PluginConfig schema (see PluginConfig struct in core/schemas/plugin.go) exposes `type`, `path`, `enabled`, `placement`, `order`, and `config` and does not parse `name`/`version`; update the documentation and examples to match runtime keys or explicitly mark `name`/`version` as DB/UI-only metadata. Locate references to `name`/`version` in the docs (examples at lines noted) and replace `name` with `type` and remove or mark `version` as metadata-only, and ensure the table and Note align with the PluginConfig struct fields defined in core/schemas/plugin.go (and any parsing/LoadPlugins paths) so docs reflect accepted config keys.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/deployment-guides/config-json/plugins.mdx`:
- Around line 33-45: Docs list plugin fields `name` and `version` but the
runtime PluginConfig schema (see PluginConfig struct in core/schemas/plugin.go)
exposes `type`, `path`, `enabled`, `placement`, `order`, and `config` and does
not parse `name`/`version`; update the documentation and examples to match
runtime keys or explicitly mark `name`/`version` as DB/UI-only metadata. Locate
references to `name`/`version` in the docs (examples at lines noted) and replace
`name` with `type` and remove or mark `version` as metadata-only, and ensure the
table and Note align with the PluginConfig struct fields defined in
core/schemas/plugin.go (and any parsing/LoadPlugins paths) so docs reflect
accepted config keys.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 904c25ef-0a2d-4978-b331-ab3893e0e5c2
⛔ Files ignored due to path filters (1)
ui/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (11)
docs/deployment-guides/config-json.mdxdocs/deployment-guides/config-json/client.mdxdocs/deployment-guides/config-json/governance.mdxdocs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/config-json/plugins.mdxdocs/deployment-guides/config-json/providers.mdxdocs/deployment-guides/config-json/schema-reference.mdxdocs/deployment-guides/config-json/storage.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/deployment-guides/helm/plugins.mdxdocs/docs.json
✅ Files skipped from review due to trivial changes (7)
- docs/deployment-guides/config-json/schema-reference.mdx
- docs/deployment-guides/config-json.mdx
- docs/deployment-guides/helm/guardrails.mdx
- docs/deployment-guides/config-json/guardrails.mdx
- docs/deployment-guides/config-json/governance.mdx
- docs/deployment-guides/config-json/providers.mdx
- docs/deployment-guides/helm/plugins.mdx
🚧 Files skipped from review as they are similar to previous changes (3)
- docs/docs.json
- docs/deployment-guides/config-json/storage.mdx
- docs/deployment-guides/config-json/client.mdx
BearTS
force-pushed
the
04-17-docs_add_doc_for_config_json
branch
from
9d3e0e6 to
10edc5e
Compare
BearTS
force-pushed
the
04-17-docs_add_doc_for_config_json
branch
from
10edc5e to
a3fafe8
Compare
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (2)
docs/deployment-guides/config-json/plugins.mdx (1)
274-283: Consider documenting remote URL support for custom.soplugins.This section currently reads like
pathis filesystem-only. The loader supports HTTP URLs for.soas well, so adding a one-line note/example would prevent under-documenting that capability.Suggested docs tweak
-Load a custom Go plugin binary or WASM plugin at startup using the `path` field. Custom plugins must implement one of the Bifrost plugin interfaces. +Load a custom Go plugin binary or WASM plugin at startup using the `path` field. +For Go `.so` plugins, `path` can be either a local filesystem path or an HTTP(S) URL. +Custom plugins must implement one of the Bifrost plugin interfaces.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/config-json/plugins.mdx` around lines 274 - 283, Add a one-line note in the plugins section clarifying that the "path" field in the plugins JSON (e.g., the "plugins" array entry for "my-custom-auth") can be a local filesystem path or an HTTP(S) URL pointing to a .so binary; include a short example showing an HTTP URL value for "path" and a brief mention that the loader will fetch the remote .so at startup.docs/deployment-guides/helm/guardrails.mdx (1)
192-194: Prefer a pinned image tag in the full deployment example.Using
latestmakes the example non-reproducible and can drift from tested behavior.♻️ Proposed doc change
image: - tag: "latest" + tag: "v1.5.0" # pin to a tested release tag🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/helm/guardrails.mdx` around lines 192 - 194, The example uses image: tag: "latest" which makes deployments non-reproducible; update the full deployment example to use a pinned image tag (e.g., a specific semantic version or a documented release tag) instead of "latest" by replacing image: tag: "latest" with a concrete tag value (or a placeholder like IMAGE_TAG that docs instruct users to set to a specific version) so the example is deterministic and matches tested behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/deployment-guides/config-json/plugins.mdx`:
- Around line 274-283: Add a one-line note in the plugins section clarifying
that the "path" field in the plugins JSON (e.g., the "plugins" array entry for
"my-custom-auth") can be a local filesystem path or an HTTP(S) URL pointing to a
.so binary; include a short example showing an HTTP URL value for "path" and a
brief mention that the loader will fetch the remote .so at startup.
In `@docs/deployment-guides/helm/guardrails.mdx`:
- Around line 192-194: The example uses image: tag: "latest" which makes
deployments non-reproducible; update the full deployment example to use a pinned
image tag (e.g., a specific semantic version or a documented release tag)
instead of "latest" by replacing image: tag: "latest" with a concrete tag value
(or a placeholder like IMAGE_TAG that docs instruct users to set to a specific
version) so the example is deterministic and matches tested behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 278d8a89-3776-4d20-956d-739a4116f0b3
⛔ Files ignored due to path filters (1)
ui/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (12)
docs/deployment-guides/config-json.mdxdocs/deployment-guides/config-json/client.mdxdocs/deployment-guides/config-json/governance.mdxdocs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/config-json/plugins.mdxdocs/deployment-guides/config-json/providers.mdxdocs/deployment-guides/config-json/schema-reference.mdxdocs/deployment-guides/config-json/storage.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/deployment-guides/helm/plugins.mdxdocs/docs.jsontransports/config.schema.json
✅ Files skipped from review due to trivial changes (7)
- transports/config.schema.json
- docs/deployment-guides/config-json/schema-reference.mdx
- docs/deployment-guides/config-json/guardrails.mdx
- docs/deployment-guides/config-json/governance.mdx
- docs/deployment-guides/config-json/client.mdx
- docs/deployment-guides/config-json/providers.mdx
- docs/deployment-guides/config-json/storage.mdx
🚧 Files skipped from review as they are similar to previous changes (3)
- docs/docs.json
- docs/deployment-guides/config-json.mdx
- docs/deployment-guides/helm/plugins.mdx
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/deployment-guides/config-json/plugins.mdx (1)
21-21: Tighten telemetry wording to avoidconfig.jsoncontradiction.“push gateway via
pluginsentry once DB-backed mode is running” conflicts with the page’s “do not add built-ins topluginsarray” guidance and can mislead readers of config-as-code docs. Please explicitly scope this to DB/UI-managed dynamic mode (notconfig.json).Suggested wording tweak
-| **Telemetry** (Prometheus `/metrics`) | Yes, always | `client.prometheus_labels` for custom labels; push gateway via `plugins` entry once DB-backed mode is running | +| **Telemetry** (Prometheus `/metrics`) | Yes, always | `client.prometheus_labels` for custom labels; Pushgateway settings are available only in DB/UI-managed plugin mode (not via `config.json` `plugins` array) |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/config-json/plugins.mdx` at line 21, Update the Telemetry row wording to remove ambiguity about adding built-ins to the config.json plugins array by explicitly specifying that pushing to a Prometheus push gateway via the "plugins" entry applies only to DB/UI-managed dynamic mode (DB-backed mode) and not to static config-as-code (`config.json`); reference the existing terms "Telemetry (Prometheus `/metrics`)", "client.prometheus_labels", and "plugins" in the sentence so it reads clearly like: use client.prometheus_labels for custom labels and use the plugins entry only when running in DB-backed (UI-managed dynamic) mode, not when using config.json.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/deployment-guides/config-json/plugins.mdx`:
- Line 21: Update the Telemetry row wording to remove ambiguity about adding
built-ins to the config.json plugins array by explicitly specifying that pushing
to a Prometheus push gateway via the "plugins" entry applies only to
DB/UI-managed dynamic mode (DB-backed mode) and not to static config-as-code
(`config.json`); reference the existing terms "Telemetry (Prometheus
`/metrics`)", "client.prometheus_labels", and "plugins" in the sentence so it
reads clearly like: use client.prometheus_labels for custom labels and use the
plugins entry only when running in DB-backed (UI-managed dynamic) mode, not when
using config.json.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 641b76e5-1724-4bb4-a72a-a3c83a1a2490
⛔ Files ignored due to path filters (1)
ui/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (13)
docs/deployment-guides/config-json.mdxdocs/deployment-guides/config-json/client.mdxdocs/deployment-guides/config-json/governance.mdxdocs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/config-json/plugins.mdxdocs/deployment-guides/config-json/providers.mdxdocs/deployment-guides/config-json/schema-reference.mdxdocs/deployment-guides/config-json/storage.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/deployment-guides/helm/plugins.mdxdocs/docs.jsonhelm-charts/bifrost/Chart.yamltransports/config.schema.json
✅ Files skipped from review due to trivial changes (11)
- helm-charts/bifrost/Chart.yaml
- docs/docs.json
- transports/config.schema.json
- docs/deployment-guides/config-json/schema-reference.mdx
- docs/deployment-guides/config-json/guardrails.mdx
- docs/deployment-guides/config-json.mdx
- docs/deployment-guides/helm/guardrails.mdx
- docs/deployment-guides/config-json/providers.mdx
- docs/deployment-guides/config-json/governance.mdx
- docs/deployment-guides/config-json/client.mdx
- docs/deployment-guides/config-json/storage.mdx
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/deployment-guides/helm/plugins.mdx
akshaydeo
approved these changes
Apr 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds comprehensive documentation for configuring Bifrost using
config.jsonfiles. This enables GitOps-friendly, no-UI deployments and multinode OSS setups where configuration is managed as code rather than through the web interface.Changes
config.jsondocumentation structure underdocs/deployment-guides/config-json/Type of change
Affected areas
How to test
Verify the documentation builds and renders correctly:
The documentation includes extensive examples and references to the live schema at
https://www.getbifrost.ai/schemafor IDE validation.Screenshots/Recordings
N/A - Documentation only
Breaking changes
Related issues
This addresses the need for comprehensive file-based configuration documentation to support GitOps workflows and multinode deployments.
Security considerations
The documentation emphasizes security best practices:
env.prefixes for secrets rather than hardcoding themChecklist
docs/contributing/README.mdand followed the guidelines