Skip to main content
A release is an immutable record of what ran: an image digest plus its run-config. Every reproducible rig deploy (one with a Dockerfile or prebuilt image in rig.yaml) auto-records a release, giving you a linear history you can roll back to at any time. Because the image is content-addressed and frozen, activating an old release boots the workspace from the exact environment that release captured — not an approximate rebuild.

​
How releases are recorded

When rig deploy takes the reproducible path, it freezes the environment into a content-addressed image and records a release pointing at that digest. Standard (rsync-only) deploys do not produce releases — there is no frozen image to pin.

​
List release history

For a specific workspace, pass --workspace:

​
Roll back to a previous release

To return to a known-good version, activate its release. rig rollback is an alias for rig release activate:
Activating a release boots the workspace from that release’s frozen image digest. Your app code for that release rides on top exactly as it did originally.
Rolling back changes the image and run-config, not your persistent volumes. Data under $DATA_DIR is unaffected by an activate — only the environment and code revert.

​
Pin a release manually

If you have an image digest in hand — for example, from a rig build — you can create a release that points at it without going through a full deploy:
This is useful for promoting an image you built and tested separately, or for codifying a specific digest as a named release before activating it.

​
rig build: the explicit image build

rig build is the explicit, standalone image build. It builds an image from your Dockerfile (the same content-addressed mechanism rig deploy uses) and returns a digest and cache key:
To build against a specific workspace and base image explicitly, pass the flags:
rig build is complementary to the auto-build inside rig deploy: deploy builds and mounts in one step, while rig build lets you produce a digest first and then pin it as a release with rig release create --image-digest.

​
Putting it together

A typical reproducible workflow:
1

Deploy

rig deploy builds (or reuses) the image and records a release automatically.
2

Inspect history

rig release ls shows the linear history and which release is active.
3

Roll back if needed

rig rollback --release <id> boots the previous release’s frozen image — instant, no rebuild.
4

Pin a tested image

Build separately with rig build, then rig release create --image-digest <d> to capture it as a release before activating.

​
Next steps