Resetting fixtures and demos

Seeding a realistic environment is slow and you should only do it once.

The usual approach — a seed.sh that runs before every test suite, or a dump reloaded between demos — pays that cost repeatedly, and it usually only covers the database. The Redis cache, the MinIO bucket and the files the app wrote to its own filesystem stay dirty, so "reset" quietly means "the database is reset".

Seed once, snapshot, and roll back instead.

Seed once, snapshot once

Pay the cost a single time

docker compose up -d
./seed.sh                 # schema, reference data, fixtures, uploaded files, warm caches
arcave savepoint create clean --description "seeded baseline, do not delete"

The seed does not have to be a script. A masked copy of production gives the demo and the suite realistic data — see Prod-like data.

Reset for the rest of the project's life

arcave rollback clean

That is the entire reset. It covers every stateful volume in the project, plus each container's writable layer, plus the compose spec — so the project comes back on the same images with the same ports, not just with the same rows.

Between test runs

A suite that leaves state behind

arcave rollback clean
./run-suite.sh

Running the rollback before the suite rather than after has two advantages: a crashed suite does not skip its own cleanup, and you can inspect the wreckage of a failed run before the next one wipes it.

For demos

A demo environment drifts. Someone deletes the example order, someone uploads a file with their own name on it, someone leaves the app in a broken state five minutes before the call.

arcave rollback clean

Keep the baseline savepoint permanently and exclude it from pruning by removing explicitly rather than by retention:

arcave savepoint list                          # find the ids you want gone
arcave savepoint remove 019e8488-3ac8-7000-8000-000000000000 019e8497-cf10-7000-8000-000000000000  # and remove only those

warning

Retention rules do not know which savepoint is precious. --retain-recent 5 will delete a clean baseline once five newer savepoints exist. If a savepoint must survive, prune by id, or keep it in a session of its own.

A session for the baseline

Retention works within one session, so a baseline in a dedicated session is out of reach of whatever prunes the session you work in:

Seed once, into a session that holds nothing else

arcave session create --name fixtures
./seed.sh
arcave --session fixtures savepoint create clean --description "seeded baseline, do not delete"

Reset from it, wherever you work

arcave --session fixtures rollback clean

savepoint remove --retain-recent 5 in your working session never sees clean. The rollback runs in fixtures, so its safety snapshot is recorded there and dropped again once the rollback succeeds.

Why the whole project matters here

This is the use case where whole-project capture earns its cost most visibly. After a rollback to clean:

• the database holds exactly the seeded rows,
• the cache holds exactly the seeded keys — not a stale entry pointing at a row that no longer exists,
• the object store holds exactly the seeded files,
• and anything the app wrote outside its mounts comes back with the container's writable layer.

A dump-based reset gets the first of those four.

Related docs

• Prod-like data — seed with a masked production copy instead of a script.
• Testing destructive migrations — the same reset around a schema change.
• How arcave works — precisely what is and is not captured.
• savepoint remove — retention rules and --dry-run.