Roll back a deployment

In this guide you put a previous build back live after a bad deploy, without rebuilding.

Prerequisites

The developer role on the app’s team.
An earlier deployment that succeeded and whose release is still on disk.

PANEL=https://panel.example.com
H='Authorization: Bearer gsl_xxxxxxxxxxxxxxxx'
J='Content-Type: application/json'

Steps

1. Find a deployment you can roll back to

curl -s $PANEL/apps/42/deployments/ -H "$H" \
  | jq '.results[] | {id, status, is_active, canRollback, git_commit_sha, created_at}'

canRollback is true for deployments that succeeded, aren’t live, and still have their build on disk.

2. Roll back

curl -sX POST $PANEL/apps/42/deployments/98/rollback -H "$H"
# → a new deployment with "rollback_of_id": 98, "status": "queued"

The worker skips provision and build. It points current back at deployment 98’s release, rewrites the unit with the env vars and settings recorded for deployment 98, restarts the app and runs the health check. It usually takes a few seconds.

3. Fix forward

When the fix is ready, deploy normally. The rollback deployment stays in the history.

Keeping more builds

Each app keeps the releases of its newest 5 successful deployments, plus the live one. Raise or lower that per app (1 to 50):

curl -sX PATCH $PANEL/apps/42 -H "$H" -H "$J" -d '{"releasesToKeep": 10}'

Each release takes disk space under /srv/apps/<user>/releases/.

Rollback is refused with 400 when the target didn’t succeed, is already live, has been pruned, or was made by a panel version that didn’t record releases. Redeploy instead.

Verify it works

curl -s $PANEL/apps/42/deployments/ -H "$H" | jq '.results[0] | {id, status, rollback_of_id, is_active}'
curl -s $PANEL/apps/42 -H "$H" | jq .status   # "running"