GitOps: Config Export / Import
DVARA lets you snapshot and replay the entire gateway configuration — tenants, routes, policies, pricing, budgets, webhooks, MCP servers, users, schemas, and prompt templates. Same data is exposed two ways: the Automation API (covered here) for CI/CD pipelines, and the DVARA Flightdeck UI under user-menu → Import / Export (owner-only) for ad-hoc operator use. Both reach the same backend, so a snapshot taken from one round-trips through the other.
Export
GET /v1/admin/config/export
Returns a JSON snapshot of all tenants, routes, policies, pricing, budgets, webhooks, MCP servers, users, schemas, and prompt templates. Sensitive fields (webhook secrets, MCP credentials) are redacted to "***". The response includes a warnings list flagging anything that was omitted or masked.
In the Flightdeck UI, open user menu → Import / Export and use the export form to pick a tenant scope (or leave blank for the whole fleet):


Query parameters:
?tenant_id=X— scope to a single tenant?download=true— returns the response withContent-Disposition: attachmentso your browser saves it as a file
Exports run in parallel across every entity type, so a snapshot is fast even for large deployments.
Import
POST /v1/admin/config/import
Applies a configuration file.
| Mode | Behavior |
|---|---|
merge (default) | Upsert entities; never delete anything missing from the file |
replace | Full sync: upsert + delete any entities not present in the file |
Add ?dry_run=true to preview all changes (created / updated / deleted) without writing anything.
Import is atomic: every entity type is written in a single transaction, and a failure at any point rolls back every prior change in the same request — you never end up with half-applied config. On a non-dry-run import, a CONFIG_IMPORTED audit event is written with the mode, counts, and the full change list.
The Flightdeck UI version of the same flow lives at user menu → Import / Export → Import. Upload a JSON file or paste it, pick merge / replace, and click Preview. The preview stages the diff on your session (a SHA-256 contentHash ride-along prevents DevTools tampering between preview and apply), then Apply commits in one transaction:


Workflow example
# 1. Export current config
curl http://localhost:8090/v1/admin/config/export?download=true -o config.json
# 2. Edit config.json, commit to Git
$EDITOR config.json
git add config.json && git commit -m "Add new canary route for gpt-4o"
# 3. Preview changes (dry-run)
curl -X POST "http://localhost:8090/v1/admin/config/import?mode=merge&dry_run=true" \
-H "Content-Type: application/json" \
-d @config.json
# 4. Apply
curl -X POST "http://localhost:8090/v1/admin/config/import?mode=merge" \
-H "Content-Type: application/json" \
-d @config.json
This pattern maps cleanly onto any CI/CD system: commit a change to config.json, the pipeline runs a dry-run on the PR and applies on merge.