GitOps: Config Export / Import

Runs unlicensed

Available with no license, in the Development posture. A license adds the MCP and A2A planes, production rights and support — not this feature.

DVARA lets you snapshot and replay the entire gateway configuration — workspaces, routes, policies, pricing, budgets, webhooks, MCP servers, users, schemas, and prompt templates. It is reached from the DVARA Flightdeck under user-menu → Import / Export (owner-only). Since the Admin API was removed in 1.7.0 this is the only entry point — and, with the API gone, the only bulk-provisioning surface DVARA has.

Export

Returns a JSON snapshot of all workspaces, 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.

Open user menu → Import / Export and use the export form to pick a workspace scope (or leave it blank for the whole fleet):

Figure 1. Config Export — scope to a workspace or download the whole fleet snapshot

Query parameters:

• ?workspace_id=X — scope to a single workspace
• ?download=true — returns the response with Content-Disposition: attachment so 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

Applies a configuration file, uploaded or pasted into the import form.

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:

Figure 2. Config Import — paste or upload a snapshot, pick mode, preview the diff before applying

Import validates before it writes

Preview parses and validates the file and stages a diff; nothing is written until you apply. Earlier releases wrote through the repositories and checked very little, so a malformed file could be applied part-way.

This matters more than it sounds, because import is the only bulk-provisioning path there is — the Automation API was removed in 1.7.0. A file that fails validation is rejected whole, with the reason, rather than leaving the fleet half-configured.

Two collision cases are refused at preview rather than at apply time, because neither has a safe automatic answer: two rows in one file sharing an email address, and a row whose id exists but whose address now belongs to a different account.

Workflow example

1. Export — open Import / Export in the Console, pick the scope (whole fleet, or one workspace), and download gateway-config.json.
2. Edit and commit — change the file and put it through your normal review process. It is a single JSON document, so it diffs cleanly in a pull request.
3. Preview — back in the Console, upload or paste the edited document. The preview is a dry run: it groups the changes per entity type and shows you exactly what would be created, updated or left alone. Nothing is written yet.
4. Apply — confirm the staged diff. The apply is one transaction: it all lands or none of it does.

The apply step is a human action, not a pipeline step

There is no longer an HTTP endpoint a CI job can post to. The Admin API was removed in 1.7.0, and the Console's import route is CSRF-protected and session-based — a script would have to fetch the page, scrape a token and replay it with a cookie, which is a browser pretending to be a pipeline rather than an integration.

What still works well in CI: keeping the exported document under version control, diffing it on a pull request, and reviewing changes there. What moves to a person is the final apply.

If you need automated apply, say so on #1753 — the services behind the page were untouched by the API removal, so the gap is a missing entry point rather than a missing capability.