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.
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:
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:
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 and metrics. 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, Docker deploys, and App lifecycle.