Deployment Gates

License: pro tier and above. See Licensing. Requires: Config Snapshots (always on) for the atomic rollback mechanism.

Open a gate before a risky batch of changes (a capacity ramp, a pool reshuffle, a filter-chain edit) and get a safety net: a snapshot of the config as it stood before you touched anything, and — if you set a soak window — automatic promotion if things stay healthy, or automatic rollback the moment they don't.

How It Works

open a gate ──▶ snapshot captured (this is your undo point)
                    │
        make your changes normally — pools, members, services,
        geo rules — through the API/WebUI/gslbctl exactly as you
        always would. Nothing is intercepted or held back.
                    │
        (if soakSeconds > 0) the background controller watches the
        gate's named pools every 5s:
                    │
        ┌───────────┴───────────┐
        │                       │
   healthy member count      soak window
   drops below minHealthy    elapses with
   at any point               no regression
        │                       │
        ▼                       ▼
   auto ROLLBACK           auto PROMOTE
   (snapshot restored,     (bookkeeping only —
    alert fired)            nothing to "apply")

Or skip the soak window entirely (soakSeconds: 0) and just promote or roll back yourself whenever you're ready — the gate stays open until you do.

A gate does not intercept mutations. This is a deliberate difference from a literal "staging" system: your pool/member/service/geo-rule writes go through the exact same API endpoints they always have, live, immediately. The gate is a snapshot-and-watch safety net around them, not a parallel staging schema. Practically: you can watch the change happen in real time (topology view, dashboards) while it's still gated, and if you decide it's fine, promoting is instant (there's no separate "apply" step, because it was already applied).

Opening a Gate

WebUI: the Deployment Gates banner sits above the topology canvas. "Open a deployment gate" → pick the pool(s) you're about to touch, an optional label, and a soak window.

gslbctl:

gslbctl changes open --pools <pool-id>[,<pool-id>...] --label "capacity bump" --soak 300 --min-healthy 2

API:

curl -X POST https://<api-host>:<port>/api/v1/changes \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"label":"capacity bump","poolIds":["pool-uuid"],"soakSeconds":300,"minHealthy":2}'

Then make your changes as usual.

Resolving a Gate

gslbctl changes promote <id>    # keep the changes
gslbctl changes rollback <id>   # restore the pre-change snapshot, undoing everything since

Or use the Promote / Rollback buttons in the WebUI banner. A rollback saves its own pre-rollback checkpoint first (same as the manual config-history restore flow), so rolling back is itself undo-able.

The Soak Window

• soakSeconds: 0 — manual only. The gate stays open until you explicitly promote or roll it back; no automatic behavior at all.
• soakSeconds > 0 — the no-coordinator controller (the same architecture as Progressive Delivery Rollouts, a 5-second sweep with no leader election, safe to run identically on every node) checks the named pools' health every tick. minHealthy is required in this mode: it's the floor on healthy-member count across each watched pool. A pool with no health data yet never trips a rollback on its own — absence of data isn't treated as failure.
• Auto-rollback always wins a race with auto-promote: a gate that both regressed and reached its soak deadline in the same tick is rolled back, never promoted.

Notes

• A gate's rollback restores the entire config snapshot (every pool, member, service, geo rule, etc. — the same full-cluster restore Config Snapshots already does), not just the pools it was watching. Watched pools are what determines whether to roll back; the rollback itself is necessarily all-or-nothing, matching how config snapshots have always worked.
• Not scoped by resource type — a gate doesn't know or care whether you changed a pool's members, a service's filter chain, or a geo rule. It's a time-boxed safety net around whatever changed while it was open.
• Terraform: not a managed resource. A gate is a short-lived, imperative ops action (open, watch, promote/rollback) — not something you'd want to declare in a .tf file the way a nexus_pool is.