Day 2 operations, from drift checks to upgrades and rollbacks, and resiliency to recover fast when something breaks.
Drift detection and Day 2 operations ship today. Some recovery capabilities are in early access.
Trusted by leading teams
Drift, failed applies and state, handled after the deploy, with alerts that reach the right people.
Roll a failed deployment back to its last good state, with every run's plan and state on record.
Ask Kyro to prepare a rollback. You see the plan and approve it before anything changes.
Day 2 operations ship today. Recovery capabilities marked Early access are with design partners.
Continuously monitor, detect, and remediate infrastructure drift to maintain desired state after deployment.
Scheduled drift checks with alerts.
State and backends handled for every workflow.
Failures, approvals and drift reach the right people.
Early accessFounding 50 design partners get these first.Apply to join →
StackGuardian rebuilds the infrastructure from code, and your backup platform restores the data into it.
Drift detection flags resources that no longer match code, and Cloud Inventory shows what appeared outside it.
Choose the last run you trust. For resources nobody codified, choose a configuration snapshot.
sg-dr reads your own bucket, rebuilds the working directory with the exact OpenTofu or Terraform version, and plans against what is live.
Policies run against the recovery plan and a named person approves it. Every decision lands in the audit log.
Once the infrastructure exists, StackGuardian starts the restore in your backup platform and reattaches the volumes and databases it returns.
StackGuardian checks the environment against the restore point again and records how long recovery took.
Restoring code and state alone does not restore an application. Data, secret values and identity providers keep their own recovery paths. StackGuardian connects to them and puts the infrastructure in place first.
Agent rollback tools restore prompts, skills and code. Backup platforms restore data. StackGuardian covers what sits in between.
It hooks into the cloud and Git connectors you already have and acts through StackGuardian workflows: roll back to a known-good run, change a configuration as a reviewed plan, or rebuild in another region. It runs on your runner and reads state from your own storage.
Recovery accounts can grant it wider, time-limited permissions during an incident. Every action it takes is still a plan, a policy check and an approval.
We are working with a small group of design partners on the steps marked Early access. Tell us what you run and what you would recover first, and we will set up a 30-minute call.
No. Your backup platform keeps protecting and restoring data. StackGuardian covers the infrastructure that data runs on, and the early-access steps connect the two.
We did not set out to build a recovery product. Customers started using StackGuardian as part of their disaster recovery setup, because the pieces were already there: drift detection on every workflow, state managed and versioned in your storage, and whole stacks recovered from code, in dependency order.
OpenTofu and Terraform state records every resource, its ID and what it depends on, so stacks recover in the order those dependencies require. The module that built production is the module that rebuilds it, pinned to the version the last run used. You see a plan before every restore, and the restore runs through the same workflow you deploy with, so the recovered environment stays under code and keeps its run history.
With private runners, the state, sources, inputs and outputs of every run live in your own S3 bucket or Azure container. sg-dr reads them with your own credentials and does not need the StackGuardian API.
sg-dr uses your own cloud and Git credentials and only reads your storage. Cloud Inventory needs a read connector to the accounts you want discovered. You choose which accounts to connect.
sg-dr rebuilds and plans OpenTofu and Terraform workflows that ran on private runners, including whole stacks in dependency order. For Helm, Ansible, kubectl and CloudFormation workflows, it recovers sources and inputs for you to run. Secret values are listed for you to supply.
Most recoveries are small: a bad change, a module upgrade that went wrong, or a setting someone changed in the console. Point sg-dr at a specific earlier run, including one that failed, and plan it against live infrastructure before you decide. Drift runs and inventory statuses show which resources moved away from code, and when. Rollback from a checkpoint in the platform, with an impact preview, is in early access.
Codify generates OpenTofu or Terraform for them from Cloud Inventory (AWS, Azure and Google Cloud), so they can go through a workflow and become recoverable. Snapshots for uncodified resources are in early access.
Coding agents and Kyro run their changes through the same workflows as yours, with the same policies, approvals and recovery path. In early access, a small resilience agent hooks into your cloud and Git connectors, runs on your runner and reads state from your own storage. Recovery accounts can grant it wider, time-limited permissions during an incident, and every action it takes is still a plan, a policy check and an approval.
The engine StackGuardian customers deploy with every day: the workflow engine, stacks, Tirith, approvals and audit logs, private runners, Cloud Inventory and Codify, the template library, and Kyro with the MCP server. The path you restore with is the path you exercise on every change.
A 30-minute call about what you run and what you would recover first, then access to the early steps that fit, set up with our engineers.
Tell us the systems you would recover first and what your backup platform already covers. Design partners shape what ships next.