Roll back to a previous deployment

A bad deploy is one API call from being over. Production is a pointer to one deployment, and rolling back moves the pointer to an older one. Nothing is rebuilt, so the fix is live in seconds and it does not depend on your build still working.

Rolling back and promoting are the same operation. There is no separate undo.

From the dashboard

Open the project, find the deployment you want in the list, and press Promote to production. It is live by the time the page refreshes.

From the CLI or API

Find the deployment to go back to:

curl "https://api.deploybase.eu/api/v1/deployments?project_id=$PROJECT_ID&status=deployed" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY"

Promote it:

curl -X POST "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/promote" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"deployment_id": "'"$DEPLOYMENT_ID"'"}'

Only a deployment with status: deployed can be promoted, and only one belonging to that project. The response confirms the new live deployment.

What changes, and what does not

Promotion repoints your sites.deploybase.eu production URL at the target deployment and purges the edge cache, so visitors stop getting the old build.

A custom domain does not follow a rollback yet

A custom domain is pointed at a specific deployment when that deployment is published, and promotion does not currently move it. After rolling back, your sites.deploybase.eu URL serves the older build while your custom domain keeps serving the one you rolled away from.

Until this is fixed, the way to move a custom domain is to deploy again with the code you want live. If you are rolling back an incident on a custom domain, revert the commit and push rather than promoting.

Promotion does not touch your repository, your default branch or your project settings. The deployment you rolled away from is still there and can be promoted straight back.

Which matters for what happens next: the next push to your default branch builds and auto-promotes as usual, and will put the broken code back. A rollback buys you time, it does not pause deploys. Fix forward, or revert the commit, before the next push lands.

Roll forward again

Promote the newer deployment. Same call, different ID. You can move back and forth as often as you like, because every deployment stays complete and independent.

What a rollback cannot undo

Deployments are immutable files, so a rollback restores files, and only files.

• Environment variables are not part of a deployment. Promoting an old deployment does not restore the variables it was built with, and it does not rebuild with today’s values either. The old deployment keeps whatever was baked into it when it was built, and its functions run with the variables as they are set today
• Data written by a form, an API or a third-party service is unaffected. Rolling the site back does not roll back anything it did
• A redirect cached by a visitor’s browser stays cached. If the bad deploy served a permanent redirect, rolling back does not reach the people who already followed it

When rollback is not enough

If the newest deployment is failed, production never moved: the previous deployment is still serving. There is nothing to roll back, and the site is fine while you fix the build.

If you need the site to stop serving entirely, remove its custom domains. There is no maintenance mode, and deleting the project is not a way to get one, because it is not reversible.