Rollbacks and recovery
Restore an earlier successful release while accounting for database and configuration changes.
A rollback creates a new deployment using a previous successful release of the same service. It reuses that release's retained artifact and deployment snapshot instead of rebuilding the current branch.
Roll back a service
- Open the service's deployment history.
- Select a successful release that offers Rollback.
- Review the source revision and confirm the service name when prompted.
- Follow the new deployment through readiness checks.
- Verify the public endpoint and a representative application operation.
Only successful releases with a retained image or static artifact are eligible. A failed build is not a rollback target. Rollback can still fail if the artifact is unavailable, the selected configuration cannot be admitted, or the application is no longer compatible with its dependencies.
What a rollback restores
The release captures the source revision, artifact, configuration, and secret snapshot. Restoring it can therefore restore old environment values, commands, and instance settings. Review paid-compute authorization if its resource configuration differs from the current one.
The rollback does not rewrite the current repository branch. A subsequent deployment of the latest commit releases that branch using the service's saved configuration. Update your repository and saved settings deliberately so the next automatic deployment does not reintroduce the problem.
What a rollback does not reverse
- Database migrations, inserts, updates, or deleted records.
- Files changed on a persistent disk or in object storage.
- Emails, payments, webhooks, and other external side effects.
- Credentials you revoked at an external provider.
Use database backups for data recovery, and keep disk or object-storage backups separately. A code rollback should be compatible with the database schema still in use.
Plan backward-compatible migrations
Use additive changes first: introduce a new column, deploy code that can read both formats, migrate existing data, and remove old fields only after old releases are no longer needed.
Pre-deploy commands can run again during a rollback. They must be safe to repeat and must not assume that every release moves forward to a new schema.
Recovery needs attention
If Openstead cannot verify a healthy release after a release failure and recovery attempt, the service can enter Needs attention. Avoid repeatedly queuing deployments against that state. Contact support with the service ID, deployment ID, timestamp, and error text so the retained release can be checked safely.