Reset, snapshot, baseline

Rebuild a world, save one, or make one the default for everybody.

Three operations change which world a sandbox starts from. Pick by how far the change reaches.

Operation	What it does	Who starts from it	Undo
Reset	Rebuilds every twin’s default world	This sandbox	Not needed
Snapshot	Saves this world as a named image	Only runs that ask for it by id	Delete it
Promote	Makes this world the environment’s default	Every future sandbox	Reset the environment

Reset

Rebuilds every twin in the sandbox at once, around one shared instant, and returns the clock to live time.


veris sandbox reset


curl -X POST "$API/v1/environments/$ENV/sandboxes/$SANDBOX/reset" \
  -H "X-API-Key: $VERIS_API_KEY" -H 'Content-Type: application/json' -d '{}'

Use it at a suite boundary. Not mid-suite: it briefly freezes the clock, pauses callback delivery, clears the request trace, and drops open database connections. Save anything you need from /veris/requests first.

To reset one twin alone, POST /veris/reset on its control URL. That does not touch the others and makes no promise they still agree with each other.

A sandbox that booted from a snapshot or a promoted baseline refuses reset with a 409, since reseeding would discard the world it was told to start from. Delete it and create a new one.

Snapshot

Saves this sandbox’s current world as a named image. The environment keeps booting whatever it booted before, and snapshots coexist. Capturing freezes and scrubs the source sandbox, which is left for you to delete unless you pass --delete-source.


veris snapshot create --name expired-trial


curl -X POST "$API/v1/environments/$ENV/snapshots" \
  -H "X-API-Key: $VERIS_API_KEY" -H 'Content-Type: application/json' \
  -d '{"sandbox_id": "'"$SANDBOX"'", "name": "expired-trial"}'

Boot one with veris up --boot snapshot --snapshot expired-trial. The flag takes a snapshot’s name or its id.

Use it for a world that was expensive to build: a tenant mid-migration, an account with three years of history, the state that reproduced a bug.

A snapshot cannot be deleted while a sandbox that booted from it is still alive.

POST /veris/snapshot on a twin’s control URL is unrelated. It dumps that twin’s current state as JSON for inspection, saves nothing, and creates no environment snapshot.

Promote

Copies this sandbox’s world, files included, into the environment’s default. Every later sandbox of that environment starts from it, including the throwaway ones a run creates. The source sandbox is left frozen and scrubbed, and is deleted afterwards unless you pass --keep-source.


veris baseline promote

Use it for a world you deliberately built to be the default: a production-shaped fixture set, a standard test tenant, the accounts everyone’s tests assume. Check it reads back correctly first, since every later boot inherits it.

To undo, clear the pin. New sandboxes go back to default seeding and running sandboxes are untouched.


veris baseline clear


curl -X POST "$API/v1/environments/$ENV/reset" \
  -H "X-API-Key: $VERIS_API_KEY" -H 'Content-Type: application/json' -d '{}'

Never promote a sandbox you used for a task. Whatever your test left behind becomes what your whole team boots into. The build and fix commands never promote, for that reason.

In the console

All three are on the sandbox page , as Reset to seed data, Promote to baseline, and Delete. An environment’s config page shows which baseline is pinned and lets you clear it or roll back.