Terraform workspaces and Stacks get a 30-day restore in HCP Terraform and Terraform Enterprise 2.0.0

On July 23 HashiCorp shipped a batch of GA promotions to HCP Terraform and Terraform Enterprise 2.0.0 that gives platform teams an undo button on the two objects they have been the most nervous about deleting. Workspaces and Stacks are now recoverable for thirty days from a Recoverable Items page in the UI. Monorepo support for Stacks, project-scoped registry tagging, and scoped policy override permissions all land as GA in the same release. A CLI-guided migration from workspaces to Stacks is in public beta.

The release, item by item

Per the HashiCorp blog:

• Workspaces and Stacks restore, GA. A deleted workspace or stack can be restored to its exact state prior to deletion with a single click. Deleted items sit on a Recoverable Items page for thirty days.
• Monorepo support for Stacks, GA. Working directory support for Stacks lands alongside trigger patterns that filter runs by file change.
• Guided CLI migration from workspaces to Stacks, public beta. HashiCorp calls it a modular toolbox approach that walks operators through the move step by step.
• Registry tagging with project registry view, GA. The project view lists every artifact that shares tags with the project.
• Project and workspace policy override permissions, GA. In Terraform Enterprise 2.0.0 and HCP Terraform, override permissions can be scoped at the project or workspace level.

Why the restore primitive matters

The workspace object is where a Terraform run's state lives. Delete it in a rush and the accepted recovery has been: pull state from a backup if you kept one, otherwise re-import every resource by hand. Neither path is fun when a platform lead has deleted the wrong workspace and the on-call rotation is watching production. A single-click restore that reinstates the state, the run history and the configuration collapses that recovery to seconds.

The equivalent problem for Stacks is worse in shape. A Stack aggregates multiple deployments, so an accidental delete drops more than one state file at once. Restore returns the whole unit intact.

Two operational reads:

• Thirty days is a policy statement, not a floor. HashiCorp is telling you to fold restore into your normal incident response, not to lean on it as archival storage. Past thirty days the item is gone and no support ticket recovers it.
• The Recoverable Items page is a UI in the platform. Verify who can see it and who can restore from it before you assume it is a safety net for every team. In a shared organisation the restore capability is a permission, and permissions drift.

Monorepo Stacks: working directory and triggers

The monorepo change is the smaller ticket that quietly fixes the biggest daily annoyance. Working directory support means a Stack no longer needs to sit at the root of a repository. Trigger patterns let a Stack respond only to changes under a chosen path.

For teams that keep several Stacks in one repo (the usual infra team layout), the pair removes the noisy runs that used to fire on every unrelated commit and lets the file layout track the deployment layout. It is table stakes for anyone considering Stacks as a successor to a workspace-per-service setup.

Migration and policy overrides

The guided CLI migration is in public beta, which is the flag to read carefully. HashiCorp's own framing is a modular toolbox that walks operators through the workspace-to-Stack move. That is not a one-shot converter. Expect to run it in stages against a non-production project, verify state fidelity after each step, and keep the original workspace until the Stack has run at least one full plan and apply against a known change.

Policy override permissions moving to project and workspace scope closes a governance hole that mattered whenever a single platform admin held override rights across an entire org. In Terraform Enterprise 2.0.0 and HCP Terraform the override capability can now sit with the team that owns the affected workspace, and the audit trail follows.

What to watch

Restore lowers the cost of a delete mistake. It does not lower the cost of a bad apply. Nothing in this release changes plan review, state locking, or rollback of a partially applied change. Treat the Recoverable Items page as insurance against fat-fingers, not against a run that half-succeeded across a Stack.

Anyone piloting the workspaces-to-Stacks migration should hold off if their Stacks target production. Two weeks after the CLI enters public beta is the wrong time to move the state file of a customer-facing service into a new object model.