State history & restore

managed keeps a record of your infrastructure — which servers exist, what runs on them, their addresses and credentials — in each project's state. The dashboard stores that state, and every time it changes (an apply finishes, a server is imported or removed, the CLI syncs), the previous version is saved as a snapshot first. Nothing overwrites the record without keeping what it replaced.

Viewing history

The project's Activity page shows the state timeline: when each change happened, how many servers and services the project had at that point, and what changed (servers added, removed, or changing status).

The dashboard keeps the most recent 50 snapshots per project.

Restoring a snapshot

Every history entry on the Activity page has a Restore button. Restoring rewinds managed's record to that point — useful when a bad sync or a mistaken server removal has left the record wrong.

Two things make restore safe to try:

• The current state is snapshotted first, so a restore is itself undoable — restore the newest entry to get back to where you were.
• Restoring never touches real infrastructure. It only changes what managed knows about your servers; nothing is created or destroyed. If the restored record disagrees with reality, run managed refresh to reconcile it against the cloud provider, or managed apply to converge the servers.

Restore is blocked while a deploy is running (the deploy is actively reading and writing the state).