Skip to main content

Choose a retained release

Run locally with access to the target workspace:
Choose a known-good retained release that belongs to this workspace. Review its application set and configuration before activation.

Retention

Each deployment owner keeps the newest successful release record for each of its three most recently used distinct artifacts. Repeated rollback records for the same artifact are removed. Releases being prepared or activated remain available while the operation runs; ready candidates and failed releases expire after 24 hours. Retention deletes expired release records, stored configuration, diagnostic logs, and obsolete deployment idempotency records. Cleanup runs after an operation finishes and every ten minutes on the owning compute node, including stopped workspaces. Guest artifact removal waits for the workspace to run. After collection, an expired release ID returns HTTP 404 from the release and logs APIs; deploy again with a new deployment ID when another attempt is needed. The release list API returns up to 50 records by default, with a maximum page size of 200. Pass its opaque next_cursor back as cursor to continue. Results stay ordered by creation time, newest first. The CLI follows each page when running rig app-release ls.

Roll back

The workspace must already be running. If it is inactive, rollback stops with a warning; start it explicitly with rig workspace start --workspace my-project, wait for it to be running, and submit rollback again. History and stored logs remain available while it is stopped. The UI also disables rollback and manual deployment retry while inactive.
Rollback restores app code and configuration and briefly restarts affected services. It does not restart or re-image the entire workspace. It does not revert application data, database migrations, or persistent volumes. Ensure the older code can use the current data schema before rolling back.

Verify the result

List apps and run rig app health --app <APP_NAME> --output json for each affected service. Exercise an application operation that reads existing data. If the release is unavailable or incompatible, prepare a new corrective release instead. rig release activate and rig rollback --release address workspace image releases, not app releases. A snapshot restore is a separate filesystem recovery operation.