Product

Rollbacks

A Stackap rollback re-activates the previous deployment with one command, health-checking it first, using the same switch a normal deploy uses.

What it does

After each successful deploy, Stackap keeps the previous version as a rollback target. If the new version turns out to be wrong in a way a health check cannot see, run stackap rollback <slug>. The previous deployment is re-activated, checked, and only then given traffic.

A rollback is not a special emergency mode with its own risks. It is the ordinary swap from a deploy, pointed backwards. That means it inherits the safety of the forward path: if the older version will not start or fails its health check, routing does not change and the current version keeps serving.

It is worth separating rollback from a different protection that is easy to confuse with it. A build that fails, or a container that is unhealthy, never goes live in the first place, so there is nothing to roll back. Rollback is for the case where the new version was healthy by every automated measure and was still the wrong version.

How it works

The sequence is short and every step is recorded in the audit log with who ran it:

1. You run the command for a project. Stackap looks up the previous deployment of that project.
2. It re-activates that deployment and polls its health endpoint until it answers or times out.
3. If healthy, the routing table is updated inside a database transaction and Caddy sends traffic to it.
4. If not healthy, nothing changes, and the command reports why.

In practice

$ stackap deployments my-app      # see what is available
$ stackap rollback my-app         # go back to the previous deployment
$ stackap logs my-app --source runtime

Early-access scope

• Rollback restores application code only. It does not undo database changes or uploaded files. If the newer version ran a migration, the older code runs against the migrated schema, so keep migrations backward compatible or restore from a backup deliberately.
• The command takes a project and goes to the previous deployment. There is no argument for choosing an older one.
• A daily maintenance job removes build images beyond the newest three per project, so older builds are not kept around to roll back to.
• There is no automatic rollback on a rising error rate. Rollback is a human or agent decision, not a reaction to metrics.
• There is no gradual or percentage rollout. Traffic moves from one version to the other at once.

Questions

Last updated 2026-10-03.