Docs / dflux EdgeGuard
ContactGet started

Versioning and rolling back policy

A policy snapshot is a named, immutable capture of the entire live policy — rules, rate limits, transformation rules, routing rules, and the global filter settings. Take one before a risky change, restore it if the change goes wrong. This guide covers the operator flows: capture-before-deploy and break-glass restore.

How snapshots work

Snapshots are deliberate and manual — dflux EdgeGuard does not version every write to the control-plane store automatically. You capture a snapshot when you want a save point, and it stays exactly as captured until you restore or delete it. Each snapshot records:

  • An autoincrement id.
  • A required name and an optional description.
  • A created_at timestamp.
  • The version (the store's config-change counter) at the moment of capture.
  • The full config document, so a restore can replay the exact state.

Snapshots live on the EdgeControl gRPC admin surface (the same listener d3x-edgectl uses). The RPCs are CreatePolicySnapshot, ListPolicySnapshots, GetPolicySnapshot, DeletePolicySnapshot, and RestorePolicySnapshot. There is no d3x-edgectl subcommand for snapshots today — use the console, or a gRPC client against admin.grpc_listen. Auth is the same API-key / JWT model as every other admin call; see Admin API overview.

Capture a snapshot

Capture the current live policy with CreatePolicySnapshot. name is required; description is optional but worth filling in for break-glass clarity later. The response includes an autoincrement id, the store version at capture time, created_at, and the full captured config document.

List and fetch snapshots

ListPolicySnapshots returns snapshot metadata (newest first) without the full captured config. GetPolicySnapshot fetches one snapshot by id including the full config. DeletePolicySnapshot removes a snapshot you no longer need — deleting never touches the live policy.

Break-glass restore

When a policy change causes a production incident, RestorePolicySnapshot replays a known-good snapshot as the live policy in one call.

Restore overwrites the live policy in place
Restore replays the captured config as the new live policy with no restart and no dropped requests — the same hot-reload guarantee as any other policy write. It does not capture the current state first, so if you want a rollback point, take a snapshot of the live policy before you restore.

Restore is an admin-role operation because it replaces the entire live policy. Listing, fetching, and capturing follow the usual viewer/operator split.

GitOps via per-resource CRUD

Snapshots are a save/restore point, not a deployment mechanism. To drive policy from a repository, keep YAML manifests in Git and apply them with d3x-edgectl apply. Capture a snapshot first so a bad apply has a one-call recovery path:

Bash

Per-resource CRUD (policy-rules add / update, and the matching commands for rate limits, transformations, and routing) is still the right tool for a single rule. Use apply when a directory of manifests is the source of truth.

Mutations land in the structured log
Snapshot creation, deletion, and restore are emitted as structured decision logs (with the snapshot id and name) and surface in your log pipeline. There is no separate per-mutation history store; ship these logs to your SIEM as described in Setting up observability.