---
id: platform/rollbacks
title: Rollbacks
description: Restore a previously live deployment artifact, follow the new rollout, and understand which state is not restored.
keywords: [bex, rollback, deploy history, revert]
last_updated: 2026-09-23
---

Rollback creates a new deployment using a previously live deployment's
resolved image. It retains the original history and adds a new record for the
rollback attempt. Use it when a known application version is preferable to the
current release and its artifact is still available.

## Check the target first

Choose a deployment from the **same service** that previously went live. An
in-progress, canceled, or failed deployment without a resolved artifact is not
a valid target. The service must be managed by the control plane and must not
be suspended.

Check that the old application is compatible with the database schema and
current credentials. Bex's rollback implementation selects the previous image;
it does **not** restore a complete historical snapshot of environment variables,
health settings, instance count, plan, domains, or other service configuration.
This differs from parts of [Render's rollback behavior](https://render.com/docs/rollbacks).

Disk contents, database data, and external side effects are not rolled back.
A database migration can therefore require a separate recovery or forward fix.

## Roll back from the dashboard

Open the service's deployment history and the eligible target deployment.
Choose **Rollback**, review the confirmation, and follow the new deployment
opened by the dashboard. The dashboard control is implemented; it is not
restricted to API or agent use.

## Roll back through the API

Set `BEX_API_URL`, an authorized `BEX_TOKEN`, and the stable `SERVICE_ID`.
List the service's history and select a previously successful deployment:

```bash
curl --fail-with-body "$BEX_API_URL/v1/services/$SERVICE_ID/deploys" \
  -H "Authorization: Bearer $BEX_TOKEN"
```

Submit the selected id, replacing the example value:

```bash
curl --fail-with-body -X POST "$BEX_API_URL/v1/services/$SERVICE_ID/rollback" \
  -H "Authorization: Bearer $BEX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"deployId":"dep-your-previous-deploy"}'
```

The response is a new deployment object, not merely a `deployId` acknowledgment.
Track its `id` in the dashboard or with
`GET /v1/services/{serviceId}/deploys/{deployId}`. Acceptance does not mean the
rollback has finished.

## Verify and stabilize

Wait for the new deployment's result, then test real requests and inspect
[logs](./logging.md) and [metrics](./metrics.md). Ordinary services follow their
rollout strategy; disk-backed services require an interruption. The selected
image must remain pullable from its registry.

Bex's rollback operation does not disable auto-deploy. Review the service's
source and auto-deploy policy so a later push does not immediately reintroduce
the unwanted version. For a repository-backed service, a subsequent normal
deploy clears the rollback image override and builds the selected source again.

After resolving the incident, commit the intended source change and perform a
normal deployment. See [How deploys work](./how-deploys-work.md),
[Docker deploys](./docker-deploys.md), and
[App lifecycle](./app-lifecycle.md).