ReaperCI Documentation

ReaperCI documentation

Production rollback drill

Run this drill in staging before the first production release and repeat it after material deployment or connector changes. ReaperCI rollback is exact-target and creates a new deployment record; it never rewrites history.

Establish two known releases

  1. Deploy release A to staging and verify its health and user-visible behavior.
  2. Deploy release B using the same repository, target, and runtime identity (container name for a single container, Compose path for Compose).
  3. Open release B in Deploys, inspect live state, and record the prior successful deployment ID shown as the rollback target.

With the CLI:

reaperci deploys inspect 18
reaperci deploys rollback-target 18
reaperci deploys compare 18 --base 17

Review image, commit, target, arguments, environment, health policy, and the exact target ID. Do not continue if the displayed target is not release A.

Execute and verify

reaperci deploys rollback 18 --target-id 17 --confirm

Approve the new rollback deployment as a human when the environment is protected. Confirm the health gate passes, live inspection reports release A's image, the public application behavior is restored, and the audit log attributes both request and approval. If another release changed the target after review, ReaperCI rejects the stale confirmation; inspect and compare again.

Automatic rollback

Set autoRollback: true with a meaningful health check. Before a Compose change, ReaperCI must capture a complete running snapshot with an immutable sha256: image ID for every service; otherwise it fails the deployment before mutation. A failed release queues the captured single-container or Compose image snapshot automatically. Compose rollback uses a temporary override with --no-build --pull never, so the previous images must still exist on the target. Protected- environment policy still applies. Automatic rollback does not reverse application database migrations. Use an application-specific compatible schema strategy or a separately reviewed data recovery plan.

Record drill date, release IDs, response time, health evidence, application verification, and any manual step. A rollback button that has not been exercised against the real server is not a release gate.