CI/CD
Rollbacks
Every successful deployment is stored as an immutable snapshot. If a new deploy causes issues, you can roll back to any of the last 20 deployments with a single click, no rebuild required. StackBlaze simply re-deploys the previously built Docker image via a rolling update.
Rollbacks complete in 15“30 seconds because the image is already in the internal registry. You can also rollback via the CLI with stackblaze rollback --service my-app.
Database migrations are not rolled back
Rolling back your application code does not undo database schema changes. If your new deployment ran migrations, you'll need to handle that separately. Design migrations to be backward-compatible (additive-only) so that the previous code version can run against the new schema safely.
Deployment history
feat: add rate limiting
2 hours ago
fix: resolve auth bug
5 hours ago
feat: user dashboard v2
1 day ago
chore: update deps
2 days ago
CLI rollback
# Roll back to previous successful deployment
$ stackblaze rollback --service my-api
Rolling back my-api to dep_8e2j1l (b2e8b11)...
Rolling update: 1/3 replicas updated
Rolling update: 2/3 replicas updated
Rolling update: 3/3 replicas updated
Rollback complete. my-api is live at https://my-api.stackblaze.app
# Roll back to a specific deployment
$ stackblaze rollback --service my-api --deployment dep_7d1i0k
Under the hood
- Immutable image tags: each deployment produces a Docker image tagged with the deployment ID. Tags are never overwritten. The internal OCI registry retains the last 20 images per service, so any of them can be re-deployed instantly.
- Kubernetes Deployment patch: a rollback is implemented as a
kubectl patch deploymentupdating theimagefield to the previous tag. Kubernetes then executes the same rolling update strategy (maxSurge: 1, maxUnavailable: 0) as a normal deploy. - Retention policy: the last 20 successful deployments per service are retained in the registry. Older images are garbage-collected automatically. Rollback is only available for deployments still within the retention window.
Step by step
Open the Deployments tab
Navigate to Service → Deployments. You will see a list of the last 20 successful deployments, ordered newest first. Each entry shows the commit hash, commit message, deployer, timestamp, and duration.
Select a previous deployment
Click on the deployment you want to roll back to. A detail panel slides open showing build logs, environment at time of deploy, and the exact Docker image tag. Verify this is the version you want before proceeding.
Click Rollback
Click the "Rollback to this version" button. StackBlaze immediately begins a rolling update using the stored Docker image, no rebuild is required. The rollback typically completes in 15“30 seconds.
Verify the rollback
Watch the Deployments tab as the rolling update completes. Once health checks pass on all replicas, the rolled-back version receives 100% of traffic. The deployment that caused the issue is retained in history for post-mortem analysis.