Rollbacks

Roll back when a deploy reached Active but the new code is misbehaving: an elevated error rate, a latency regression, or a missed dependency. A ZopDay rollback re-ships the image of an earlier revision that you know worked. It skips the build, so it is usually the fastest way back to a known-good state.

Before you start

• The deployment:update policy on the service. Viewing revisions needs only deployment:view.
• An earlier revision whose status is Active. A failed revision can’t be a rollback target.
• For the API, a Personal Access Token (see Authentication).

How it works

A rollback creates a new revision that mirrors the one you pick. It never edits or deletes an existing revision. ZopDay creates the next revision using the target’s image, no build runs, and the new revision runs the usual deploy and rollout stages. It becomes current once it reaches Active.

Because the rollback is a new revision, the revision number goes up, not down. The revisions shipped since the target stay in the history, so the record of what ran, and when, stays complete. Rolling back to the revision that is already running still ships a new revision.

ZopDay does not roll back on its own. If a deploy fails before it becomes active, ZopDay retries it up to 3 times and then stops, and the service stays on its last active revision (see When a stage fails). Rolling back is always a deliberate action.

What a rollback changes, and what it doesn’t

A rollback reverts code, not configuration.

• The image is the target revision’s image.
• Configuration and environment variables are the service’s current ones, applied to the old image. If the problem came from a config or environment variable change, change that setting back instead. Saving it ships its own config-only revision.
• Database migrations are not reversed. Persistent data is not touched. For rollbacks that are safe by design, use forward-compatible migrations such as additive columns or expand-then-contract.
• Secrets in your cloud’s secret manager are not touched.

Roll back a service

1. Pick the target

   Open the service’s Revisions tab. It lists every deploy with its revision number, status, image, commit, and who triggered it. Pick a revision whose status is Active.

2. Roll back

   ZopDay creates the next revision using the target’s image. No build runs.

3. Watch the rollout

   The new revision runs the usual deploy and rollout stages and becomes current once it reaches Active.

Roll back from the API or MCP

Roll back over the API with the deployment’s rollback route, naming the earlier revision to return to:

POST /deployments/{id}/rollback

Authenticate with a Personal Access Token in an Authorization: Bearer header. Generate one from Developer Settings → API Tokens in your user menu; see Authentication.

From an AI assistant, the MCP server offers rollback_service, which takes the service and the revision to return to. Like the UI, it ships a new revision, and the rollback is complete only when that revision reports Active (wait_for_deploy follows it).

Reference

Permissions

Audit

Every rollback is recorded in Activity → Audit Logs with the actor, the request, the response status, and the time. The new revision also carries who triggered it on the Revisions tab. You can forward the audit feed to your SIEM. See Audit logs.

Troubleshooting

Next steps