CI/CD
One-click rollbacks
StackBlaze retains the container image digest for every successful deployment. A rollback is instant, it updates the running Deployment's image spec to a previous digest and executes the same rolling update strategy. No rebuild required. A typical rollback completes in 15“45 seconds.
You can trigger rollbacks from the dashboard, or from the CLI with stackblaze rollback --service my-app --to v2.4.0. Both methods are equivalent and show the same live log view.
Deployment history
Deployment history UI
Deployments, my-api
fix: null pointer in checkout flow
2 hours ago
feat: add loyalty points display
1 day ago
chore: bump dependencies
3 days ago
fix: correct tax rounding
5 days ago
Rollback log
00:00 Initiating rollback to v2.4.0
00:00 Resolving image digest for v2.4.0...
00:01 Image: registry.stackblaze.internal/my-api@sha256:a1b2c3d4e5f6
00:01 No build required, reusing existing image
00:01 Rolling update starting (3/3 replicas)...
00:08 replica-1: image updated, waiting for readiness probe...
00:14 replica-1: ready ✓
00:14 replica-2: image updated, waiting for readiness probe...
00:19 replica-2: ready ✓
00:19 replica-3: image updated, waiting for readiness probe...
00:23 replica-3: ready ✓
00:23 Rollback complete in 23s. All traffic now on v2.4.0.
CLI rollback
$ stackblaze rollback --service my-api --to v2.4.0
Rollback started. Watching progress...
✓ Rollback complete in 23s
# list available versions
$ stackblaze deployments --service my-api
Under the hood
- Image digest registry: StackBlaze records the immutable OCI image digest (
sha256:...) for every successful deployment. Unlike image tags (which are mutable), digests are cryptographically pinned to a specific image layer tree. Rolling back to a digest is guaranteed to run exactly the code that was deployed originally. - kubectl rollout equivalent: a rollback patches the Kubernetes Deployment's
spec.template.spec.containers[0].imagefield to the previous digest. Kubernetes then executes its standard rolling update controller, replacing pods one at a time while enforcingmaxUnavailable: 0. - No rebuild: because the image already exists in the internal registry, no build Job is spawned. The rollback only involves the Deployment update, this is why rollbacks are 10× faster than a fresh deploy.
- Audit trail: every rollback is logged in the project's audit trail with the triggering user, the source version, the target version, and the timestamp. You can query this log from Project → Audit or via the StackBlaze API.
Step by step
Go to Service → Deployments
Open your service in the StackBlaze dashboard and click the "Deployments" tab. You'll see a reverse-chronological list of every successful deployment, including its version tag, commit SHA, commit message, deploy timestamp, and status.
Find the version to roll back to
Scan the deployment history for the last known-good version. You can click any deployment row to expand it and see more detail, the full commit message, which user triggered the deploy, and a link to the GitHub commit.
Click "Rollback to this version"
Click the "Rollback to this version" button on the row. A confirmation modal will appear summarising what you're about to do: the current version, the target version, and a reminder that the existing container image will be reused (no rebuild).
Confirm the rollback
Click "Confirm rollback" in the modal. The rollback starts immediately. You can also trigger a rollback via the CLI: stackblaze rollback --service my-app --to v2.4.0.
Watch the rolling update complete
The Deployments tab switches to a live log view. You'll see the rolling update progress pod-by-pod, identical to a normal deploy. The rollback typically completes in 15“45 seconds because no build step is needed, StackBlaze reuses the previously stored image digest.