Choose a retained release
Run locally with access to the target workspace: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 opaquenext_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 withrig 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.
Verify the result
List apps and runrig 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.