Back to The Gateway

Rollback and recovery

Risky network changes need a known-good path back.

The Gateway release readiness requires rollback notes before applying routing, DNS, firewall, fallback, or remote access changes.

Before apply
  • Record admin access, DNS, route, firewall, fallback, backup, and out-of-band recovery state.
  • Confirm what change is safe to roll back without losing operator access.
During recovery
  • Stop new changes, restore firewall/DNS/routes, verify local connectivity, then verify management access.
  • Run route and DNS checks before declaring recovery complete.
After recovery
  • Document the failed change, observed behavior, evidence, remaining risk, and next safe attempt.
  • Keep public reports redacted.

Recovery evidence

Rollback proof should show the state before and the path back.

Redacted Gateway backup and recovery screen
Backup Known-good state.

Shows the recovery surface that should identify the restore point and rollback owner before apply.

Redacted Gateway routing policies screen
Policy Changed surface.

Shows the route or fallback policy that should be compared against the known-good state.

Redacted Gateway dashboard showing route, DNS, tunnel, device, and backup status cards
Validation Recovered posture.

Shows the summary view used to verify route, DNS, tunnel, and backup state after recovery.

Next action

Attach rollback evidence to install readiness.

Public install claims should wait until recovery behavior is documented for the target deployment mode.

Open install readiness Open production checklist