GitOps: Config Export / Import

Enterprise only

Not included in DVARA Open Source.

DVARA lets you snapshot and replay the entire gateway configuration — workspaces, routes, policies, pricing, budgets, webhooks, MCP servers, users, schemas, and prompt templates. Open user menu → Import / Export in DVARA Flightdeck as an owner. This is the supported bulk-configuration workflow; the former Automation API was removed in 1.7.0.

Export

Returns a JSON snapshot of all workspaces, routes, policies, pricing, budgets, webhooks, MCP servers, users, schemas, and prompt templates. Sensitive fields (webhook secrets and MCP or A2A credential references) are redacted to "***" only when a value exists; an empty reference stays empty. Other connection settings remain in the export. 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

Exports run in parallel across every entity type, so a snapshot is fast even for large deployments.

A workspace-scoped export records scope_workspace_id and contains that workspace's configuration, including its budget caps and prompt templates. Routes, model pricing, and output schemas remain platform-wide and are not part of the workspace scope.

Import

The import operations are POST /config/import/preview and POST /config/import/apply. Preview validates the uploaded content and returns the staged change set with a SHA-256 contentHash. Apply must echo that exact hash; Flightdeck refuses changed or stale content that was not reviewed.

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 for an unscoped export: upsert and delete entities not present in the file. A scoped export is refused in this mode; use merge. The signed-in account is always kept.

Choose Preview to inspect every proposed create, update, and delete before anything is written.

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. Invitation emails are sent only after a successful commit. On a non-dry-run import, a CONFIG_IMPORTED audit event is written with the actor, mode, counts, and the full change list.

For an existing MCP server or A2A agent, an imported "***" keeps the stored credential reference. For a new server or agent it fails preview because there is no stored value to keep; replace the mask with the real reference before restoring to a fresh install. Files exported before 1.8 can also omit newer connection settings, so take a new export before a round trip.

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

Accounts, teams and team members

From 1.8.3 an export also carries accounts, teams and team_members (each a user_id and a team_id). A full export carries all of them; an export of one workspace carries its team, that team's account, and the memberships of the people in the file.

On import, accounts and teams are saved before the workspaces and people that name them. The preview refuses the file when a team names an account, or a membership names a team or person, that is neither in the file nor on the install, so an import never brings in a team that does not exist. New accounts and teams meet the licence limit for the whole file. REPLACE never deletes an account or a team.

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 because import is the only supported bulk-configuration path. 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.

From 1.8.4 the import keeps one route per model pattern, matching Flightdeck's route form. Preview and apply refuse a file that gives one pattern two routes. In merge mode they also refuse a route that takes a pattern a stored route keeps, and name that stored route. In replace mode the file is compared with itself, because every stored route it does not list is deleted. The apply checks the rule at commit, so one file can move a pattern from one route to another.

API-key agent bindings ("Acts as agent"). From 1.8.4 an export leaves out a binding whose API key has been deleted, and marks a binding whose agent is deleted or not active with "stale": true. The import skips a stale binding and lists it under Skipped in the result instead of refusing the file. Before 1.8.4 an export that held such a binding could not be imported again. Deleting an API key now deletes its binding too, and the 1.8.4 upgrade removes bindings that deleted keys had left behind.

From 1.8.5 a binding can carry mayStartChains: true, for a key whose agent may start a delegation chain of its own (see the hardened preset). An export leaves the field out when it is false. The import also refuses an active A2A agent whose endpoint is not https://, with A2A_ENDPOINT_NOT_HTTPS.

Preview also compiles every policy definition. A malformed policy names the policy and fails the preview before any row is written or invitation is sent. In full replace mode, dropping a workspace deletes its workspace-scoped data through the same cascade as deletion in Flightdeck while retaining audit chains and MCP tool-call evidence.

Workflow example

1. Export — open Import / Export in Flightdeck, 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 Flightdeck, 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 supported HTTP endpoint for a CI job to post configuration to. The Automation API was removed in 1.7.0. Do not automate Flightdeck's session-protected browser route.

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.

The supported 1.8 workflow is the Flightdeck import page; there is no public automation endpoint for apply.