Roll Back to Any Prior Deployment
When a deployment goes wrong, you need to get back to a known-good state fast. Atmos Pro now supports instant rollback for any infrastructure component — pick a prior successful deployment from the instance's history and roll back to it in one click.
Atmos Pro dispatches your workflow pinned to the exact commit SHA of the target deployment, so you get byte-for-byte the same infrastructure code that was running before. The rollback run is tracked with full lineage — you can see which deployment it replaced and confirm the rollback completed successfully.
Latest Events
Show:
| Event | Ref | Type | Time |
|---|---|---|---|
PR #342 opened | feat/add-rds-module · a1b2c3d | PR | 10m ago |
Drift detection | main · e4f5g6h | Drift | 19m ago |
PR #341 synchronize | fix/vpc-cidr-range · b2c3d4e | PR | 35m ago |
Release v2.4.1 published | main · c3d4e5f | Release | 54m ago |
PR #340 closed | chore/upgrade-provider · d4e5f6g | PR | 1h ago |
Page 1 of 3 (12 total events)
How It Works
Rollback validates three things before dispatching. First, the target instance must be in an
active lifecycle state — you cannot roll back a proposed or archived component. Second, the target SHA must correspond to a prior successful apply for that specific stack-component pair, preventing rollbacks to untested commits. Third, the workflow is dispatched via GitHub Actions workflow_dispatch at the target ref, so your existing CI/CD pipeline handles the actual execution.The resulting workflow run is recorded with
is_rollback: true and a replaces_id pointing to the deployment it supersedes. This gives you a clear audit trail: every rollback is visible in the instance's event history alongside regular deployments, drift checks, and PR-triggered plans.