Rollbacks

Compute deployments retain immutable container images in the cloud registry. Static-site deployments retain immutable site versions. Rolling back reactivates a retained version without rebuilding.

Rolling back

ske rollback

Rollback 7246201118733279233 started for my-app/production.

Deployment succeeded (sequence #43) in 38s

By default, ske rollback reverts to the latest deploy before the one that built what runs now, skipping any that ran the same version or can no longer be rolled back to. Running it again after a rollback goes further back, never forward. Rolling back to the deployment that runs now is refused (#42 is already live.).

Rolling back to a specific version

Use --to to target a specific deployment:

ske rollback --to 7244893016512790529

Rollback 7246201118733279233 started for my-app/production.

Deployment succeeded (sequence #43) in 41s

Find the deployment ID with ske deploy list:

ske deploy list

ID                   TYPE      STATUS     INITIATOR        CREATED
7246183051948032011  deploy    succeeded  you@example.com  2026-09-20T14:30:12.000000Z
7245860719322145803  deploy    succeeded  you@example.com  2026-09-19T09:15:40.000000Z
7245517348101873667  rollback  succeeded  you@example.com  2026-09-18T16:00:03.000000Z
7245207731180494857  deploy    succeeded  ci@example.com   2026-09-17T12:00:55.000000Z
7244893016512790529  deploy    succeeded  ci@example.com   2026-09-16T14:00:21.000000Z

How rollbacks work

A rollback creates a new deployment record of type rollback. It does not delete the deployment you’re rolling back from — its version remains available while it is retained.

For compute deployments, the rollback process:

1. Locates the target deployment’s container image in your registry
2. Updates the compute configuration (Lambda function or Cloud Run service) to use that image
3. Routes traffic to the rolled-back version

Because the image already exists in your registry, rollbacks take under a minute instead of the full build-push-provision cycle.

For a GCP static site, rollback creates a new Firebase Hosting release pointing to the target deploy’s finalized version. It uses the retained files and hosting configuration; it does not rebuild or read the GCS staging uploads.

How far back you can roll back

Static sites (early access)

SKE retains the live deployment plus the last 10 successful static deployments. On GCP these are finalized Firebase Hosting versions. Temporary GCS staging is cleaned up after finalization and is not rollback storage. The live version remains protected when you roll back to an older retained deployment; versions outside the retained history are removed after successful deployments.

A static rollback must target a retained successful deploy, rather than another rollback or the version that is already live. Once its site version has been removed, a deployment can no longer be used as a rollback target.

Compute deployments

Your registry keeps the 25 most recent images: per project on AWS (ECR lifecycle policy), per environment on GCP (Artifact Registry cleanup policy). The image each environment runs now is tagged ske-live-<environment> and is never expired, however many images are pushed after it.

On AWS, each Lambda function also keeps its 25 most recent versions. Every deploy, redeploy, env sync and maintenance toggle publishes a new version. On GCP, Cloud Run caps how many revisions a service keeps and deletes the oldest past that.

You can roll back to a successful deploy as long as its image and its function versions (or Cloud Run revisions) are all still there. A rollback must target a deploy, not another rollback, env sync or maintenance toggle. A rollback to an older deploy is refused, because there would be nothing left to run.

Each deployment’s static assets stay in the environment’s assets bucket for as long as you can roll back to it. After a successful deploy, SKE deletes the assets of deployments you can no longer roll back to. The assets of what runs now are never deleted.

What rollbacks don’t revert

Rollbacks revert the application code, or a static site’s published files and hosting configuration. Static build variables are already baked into those files; changing a variable affects the next build, rather than rewriting an old version. Compute rollbacks do not revert:

• Secrets — secret values are applied at container startup from your cloud provider’s secret store. A rollback uses the current secrets, not the ones that were set at the time of the original deployment.
• Infrastructure — databases, caches, networks, and their configurations are not affected.
• Database migrations — if the deployment you’re rolling back from ran migrations, those changes remain. Make sure your migrations are backward-compatible.

Rollbacks in CI

# Roll back production to a given deployment
ske rollback --to 7244893016512790529 --env production --json

The --json flag outputs machine-readable JSON for pipeline integrations.