Versions & rollback

Every deploy captures an immutable snapshot of your indexer. That snapshot is a version, and it is what makes it safe to change a running indexer: if the new definition is worse than the old one, the old one is still there, exactly as it was.

What a version contains#

• your transform source and the compiled Wasm modules;
• the program, instruction and account filters;
• the trigger definitions and their payload code;
• the database schema and the DDL generated from it;
• the platform runtime it was deployed onto.

A version is never edited. Changing anything and deploying produces a new one, which is why the number in the toast after a deploy is worth noting.

Retention#

Each indexer keeps ten versions. When you deploy an eleventh, the oldest evictable one is permanently deleted to make room, and the deploy preview names it before that happens.

Keep Forever#

Mark a version Keep Forever — the star on the versions page, or from the eviction warning itself — and it becomes ineligible for eviction. Use it on the version you would actually want to roll back to: the last one you know was correct in production.

Deploying an unchanged canvas#

Redeploying without having changed anything does not burn a slot. The platform hashes the definition to decide, and the hash ignores things that do not affect behaviour — internal ids, timestamps, and where you dragged the nodes on the canvas. Move a node, redeploy, and you get “Redeployed version N (no new version)” rather than a duplicate.

Comparing and restoring#

The Versions tab lists every retained version with the actions you would expect:

• View — inspect what a version actually contained.
• Compare — select two versions and see the difference. Selecting a third replaces the older of the pair.
• Restore — load a version back onto the canvas. This replaces your current canvas, so anything unsaved is lost; you are asked to confirm.
• Keep Forever — protect it from eviction.
• Delete — remove it, freeing a slot.

Runtime versions are a different thing#

Your versions record what runs. The runtime version— labelled “Indexer Version” in the UI — records how it runs: the worker image and the WebAssembly ABI your compiled transforms must satisfy. The platform publishes these; you pin one per indexer.

The pin is soft. If the runtime you pinned is later deprecated or removed, your deploy falls back to the current default rather than failing. You get a working deploy instead of a broken one, but it is worth knowing that the runtime you thought you pinned may not be the one you are on. Check the selector in the toolbar if behaviour changes without your canvas changing.

A workable habit#

1. Deploy freely while iterating — slots are cheap and reused.
2. When a version proves itself in production, mark it Keep Forever.
3. Keep at most two or three protected, so eviction always has somewhere to go.
4. If a deploy misbehaves, restore the protected version and deploy it.