Workspaces Docs

Snapshots

A snapshot keeps a workspace’s files as they are now. You can go back to it later, or start another workspace from it.

eutonomous snapshot create "before the upgrade"   # a few seconds for a typical project
eutonomous snapshot list                          # --all: every workspace's
eutonomous snapshot restore 12                    # put its files back
eutonomous create experiment --from 12            # a new workspace with its files
eutonomous snapshot delete 12

A snapshot every day

eutonomous snapshot daily on      # off by default
eutonomous snapshot daily off

With this on, the workspace gets a snapshot once a day on the days it is used, and the newest seven are kept. A workspace that sleeps all day changes nothing and gets none. eutonomous snapshot list shows whether it is on and what your snapshots cost to keep; the Credits page lists every snapshot of your account with its size, and lets you delete one.

What is in one

Your home directory, without what can be rebuilt:

  • pixi environments. The lock file is in the snapshot and recreates them exactly the first time you run something;
  • package caches, node_modules, Python bytecode;
  • what the platform installs in every workspace: the editor, the AI tools and their extensions.

That keeps a snapshot small. A project with a 170 MB environment is a snapshot of under 100 KB.

Going back

eutonomous snapshot restore <id> unpacks the snapshot over the workspace. Every file in the snapshot returns to how it was. Files you created after the snapshot are left alone; delete them yourself if you want an exact copy, or start a new workspace from the snapshot.

Starting another workspace from one

eutonomous create <name> --from <id> makes a new workspace and unpacks the snapshot into it. It gets its own address, keys and settings. A deployed app’s files come along, but the app is not started: run eutonomous deploy in the new workspace to serve it.

A snapshot belongs to your account, not to the workspace. It stays when the workspace is deleted, so you can delete a workspace and bring it back later.

Good to know

  • Snapshots need an account that has bought credits. They are stored in your account’s storage and paid from the same credits, by size.
  • A snapshot can be up to 5 GB, and an account keeps up to 20 that you took yourself (daily ones are kept seven per workspace). Large data sets belong in the workspace’s bucket.
  • A running PostgreSQL or MySQL is not copied file by file, which could give a copy that does not start. Each database is dumped instead and the dump goes into the snapshot. Restoring into the same workspace loads the dumps back. In a workspace started from a snapshot, the dumps are in ~/.eutonomous/db-dumps/, ready to load once you add a database.
  • Other engines (Valkey, CouchDB, FerretDB) are copied as files only when they are stopped.
  • Only the workspace’s owner can take, restore and delete its snapshots.

From Python and for agents

snap = ws.snapshot("before the change")
ws.restore(snap["id"])
fork = Workspace.create("experiment", from_snapshot=snap["id"])

The MCP server has snapshot_workspace, list_snapshots and restore_snapshot, and create_workspace takes from_snapshot. An agent can take a snapshot before a risky change and go back if it does not work out.