Instant rollbacks

Revert a storefront by activating an earlier deployment — no rebuild, no DNS change.

When a deployment misbehaves — a runtime error, a regression a reviewer missed, a dependency that broke in production — you don't need to revert code and wait for a build. Any earlier deployment that is still ready can be made active again.

Rolling back doesn't delete, modify, or rebuild anything. The build artifact for the earlier deployment already exists; activating it moves the pointer that says which deployment your domains serve. That's why it's near-instant, and why it needs no DNS change.

The one precondition

The deployment you activate must have status ready. That is the whole gate — there is no age limit, and it doesn't have to be the deployment immediately before the current one. A failed deployment has no artifact to serve, and one still building isn't finished, so neither can be activated.

Roll back from the CLI

Shell
# Find the deployment you want
revenexx sites list-deployments --site-id <SITE_ID>

# Make it the active one
revenexx sites update-site-deployment --site-id <SITE_ID> --deployment-id <DEPLOYMENT_ID>

Roll back over the API

Shell
curl -s -X PATCH 'https://api.revenexx.com/v1/sites/<SITE_ID>/deployment' \
  -H 'X-Revenexx-Tenant: <tenant-slug>' \
  -H 'X-Revenexx-Api-Key: <api-key>' \
  -H 'Content-Type: application/json' \
  -d '{"deploymentId":"<DEPLOYMENT_ID>"}'

The request fails if the target deployment isn't ready, so a script can safely attempt it and treat the error as "not a rollback candidate".

Roll back in Cockpit

Open the site under Experience Studio → Sites. Its deployment list marks the current one as active; every other ready deployment offers an Activate action. Activating it makes it live for the domains pointed at the site's active deployment.

Rolling back a Git-connected storefront

You have two options, and they are not equivalent:

  • Activate an earlier deployment (above). Instant, because it skips the build. But your repository still contains the bad commit, so the next push will rebuild it.
  • Push a revert commit. Slower, since it builds, but it fixes the source of truth.

In an incident, do both in that order: activate the last good deployment to stop the bleeding, then revert in Git so the fix survives the next deploy. Rolling back only the deployment and forgetting the commit is the classic way to have the same outage twice.

What rollback does not change

Environment variables, build settings, and the domains attached to the site are properties of the site, not of a deployment. Rolling back does not restore an earlier environment variable or an earlier build command. If the regression came from a configuration change rather than from code, change the configuration back and create a new deployment.

Related

  • Deployments — statuses and how deployments are created
  • Previews — verifying a build before it becomes active
  • Domains — what a domain serves, and why rollback needs no DNS change
Was this page helpful?