Rollback and Recovery

Sometimes a deployment introduces a bug, a performance regression, or an unexpected error that you need to resolve immediately. Rolling back restores a previous working version of your application while you investigate and fix the issue. Devpilot makes rollback a guided operation that redeploys a known-good release and tracks the full rollback history.

What is a rollback

A rollback in Devpilot creates a new deployment that uses the commit from a previous successful deployment. When you roll back, Devpilot does not reverse the lifecycle of the failed deployment — it runs a full new deployment using the target commit. This means all your current hooks execute again, ensuring the application is built and activated through the same pipeline as any other deployment.

The key difference between a rollback and a normal deployment is the source: a normal deployment pulls the latest commit on a branch, while a rollback targets a specific earlier deployment's commit.

When to use rollback

Rollback is the right choice when:

• A deployment introduces a critical bug that affects users and you need to restore service immediately. Rollback puts the previous working version back in front of users while you fix the underlying issue.
• Performance degrades after a deployment. Rolling back eliminates the new code as a variable so you can investigate.
• A dependency update breaks your application. Rolling back returns you to the version that worked with the previous dependency state.
• A configuration change breaks the deployment. Rolling back restores the previous pipeline output.

Rollback recommendations

Devpilot can recommend a rollback automatically for a failed deployment. When a recommendation exists, it records:

• The source deployment (the failed deployment being rolled back from).
• The target deployment (the known-good deployment Devpilot suggests rolling back to).
• An AI recommendation explaining why this target was chosen.
• A confidence score for the recommendation.
• A health check result describing the state of the target when the recommendation was generated.

Rollback recommendations move through these states:

Open the failed deployment and check the rollback panel to see whether a recommendation is available.

How to perform a rollback

What happens during a rollback

When you execute a rollback, Devpilot:

1. Creates a rollback history record. This record ties together the source deployment (what failed), the target deployment (what you want to get back to), the rollback deployment (the new deployment that was created), the reason, and who initiated it.
2. Creates a new deployment using the target deployment's commit, provider, repository, and branch.
3. Runs your current deployment hooks through all five stages. Dependencies are reinstalled, build commands run, and any post-release hooks execute.
4. Marks the new rollback deployment Live when it completes successfully, replacing the previous live release.

Handling database migrations during rollback

Database migrations are a common source of complexity during rollbacks. When a deployment runs migrations that alter your schema, rolling back the application code does not automatically undo those schema changes.

Consider these strategies:

• Write reversible migrations. Include a "down" method in every migration so you can undo it manually via the Web Terminal before rolling back.
• Make migrations backward-compatible. Design migrations so the previous version of the application still works with the new schema. For example, add new columns as nullable and avoid renaming or dropping columns in the same deployment that starts using them.
• Separate migration deployments. Deploy migrations independently from code that depends on them. Verify the migration first, then deploy the code. If the code deployment fails, the migration is already in place and does not need to be reverted.

Recovery best practices

Act quickly

When you identify a problem, execute the rollback rather than debugging on the live server. Getting a working version in front of users is the priority; you can investigate afterward using the failed deployment's logs and AI diagnosis.

Know your rollback target

Track which deployment is known-good. The deployment history makes this visible — the most recent Completed deployment that was previously Live is usually your target. When Devpilot has generated a rollback recommendation, it picks this target for you.

Test rollbacks before you need them

Run a rollback in a staging environment to verify the process works end-to-end with your current hook configuration. This confirms compatibility between older code and the current pipeline.

Keep enough releases

Devpilot keeps a configurable number of recent releases. If you only keep two, you can only roll back one deployment. Configure a retention that matches how far back you might realistically need to roll back.

Record a reason

Enter a clear rollback reason. It is stored on the rollback history record and shows up in audit trails and the failed deployment's diagnosis view.

Diagnose after recovery

After rolling back, run Deployment Diagnosis on the failed source deployment. The AI analysis categorizes the failure (for example, dependency failure, Git failure, or configuration error) and suggests fixes to apply before your next deployment.

Rollback vs. redeployment

The typical recovery flow is: execute the rollback to restore service, diagnose the source failure, push a fix, and then redeploy through the normal flow.

Next steps