Use cases
Everything on the pages below rests on three properties of a savepoint.
- Whole-project — a savepoint is not a database dump. It captures every stateful volume in the project, every container's writable layer, and the compose spec of the project itself. Restoring one puts the environment back, not one service's data.
- Consistent — the project is stopped before a byte is read, so nothing is captured mid-write. The same mechanism covers every service in the project, whatever each of them runs.
- Reversible — a rollback takes a safety snapshot of what it is about to overwrite, and replays it automatically if anything fails. A failed rollback leaves you where you started, not somewhere new.
And on one constraint, which shapes every workflow here:
- Stopped, not instant — a savepoint and a rollback both stop and restart the project. The window is proportional to the data moved plus your services' health-check time. This is not zero-downtime branching, and no page here will pretend otherwise.
Taking one
arcave savepoint create <NAME> # capture
arcave savepoint list # find
arcave rollback <NAME|ID|latest> # restore
arcave savepoint remove <ID> # prune
Four commands. Every workflow below is a way of arranging them. When the savepoints need more than one line — a branch per feature, a baseline kept apart — the arcave session commands add independent lines of savepoints beside the default one; see Sessions and branching.
A workflow for every situation
Agent iteration loops
An autonomous agent modifies schemas, runs migrations, and writes to databases as part of its normal loop. Give it a checkpoint per attempt and a failed iteration costs a rollback instead of a rebuild. arcave mcp puts savepoint and rollback in the agent's tool list directly.
Environment branching
A session per feature branch, forked from a shared baseline and switched by name. It resembles database branching enough to be useful and differs from it enough to be worth stating precisely — that page does both.
Testing destructive migrations
Run the migration for real, against real data, and again, and again, until it is right. The reset is one command and does not involve reloading a dump.
Resetting fixtures and demos
Seed the environment once, snapshot it, and return to that exact state for the rest of the project's life — including the object storage and the cache, not just the database.
Choosing a backend for the loop
How often you snapshot decides which snapshot backend you want.
fullcopy | cdc | |
|---|---|---|
| Cost per savepoint | Full size, every time | Only the chunks that changed |
| Good for | Occasional checkpoints, small volumes | Tight loops, large volumes, many savepoints |
| Dependencies | None beyond Docker | Pulls and runs restic/restic containers |
For the agent and branching workflows, cdc is what makes the loop cheap enough to actually run.
Related docs
- How arcave works — the mechanism behind these properties.
- Examples — the same workflows as complete walkthroughs.
- Limitations — where each of these stops working.