Deployment Rollback: How to Undo a Bad Backend Release

A deployment rollback is the rehearsed path that returns a backend to a known-good revision when a release fails in production. Compute is the easy half: point the load balancer or task set at the previous image. Shared state is the hard half, because a forward migration the old code cannot read turns a fast undo into an outage with homework.

This guide covers the common undo patterns for backends, the database rules that decide whether rollback is safe, and what Encore does for environments, deploy visibility and rolling updates without claiming a blue-green traffic switch it does not have.

Rollback options at a glance

Redeploy the previous image

Teams running rolling deploys on ECS, Cloud Run or Kubernetes undo a bad release by deploying the previous container image or git commit. Kubernetes keeps ReplicaSet history so kubectl rollout undo can move the Deployment back. ECS and many CI pipelines do the same by re-applying the prior task definition or image digest.

The requirement is that the previous binary still runs against the current database and message schemas. If the bad release already applied a breaking migration, redeploying the old image fails even though the deploy machinery worked.

Blue-green and canary undo paths

Blue-green deployment keeps an idle production-capable environment so rollback is the same traffic switch in reverse: send users back to blue and investigate green offline. Canary deployments undo by shifting weight from the canary cohort back to stable, often automatically when error or latency alarms fire.

AWS documents weighted target groups on an Application Load Balancer and canary or linear schedules in CodeDeploy for ECS and Lambda. Those paths need the extra target groups, roles and controllers set up before the incident. They are not free side effects of a normal rolling update.

Database expand and contract

Treat schema changes as a sequence the old code can survive:

1. Expand: add nullable columns, new tables or dual-write paths. Deploy code that reads both shapes.
2. Migrate data while both revisions could still run.
3. Contract: remove old columns or dual-write only after every instance of the old revision is gone.

Destructive changes in the same deploy as the code that needs them remove the rollback path. Encore applies up migrations automatically and requires down migrations to be run manually, which is a reminder that database undo is an explicit operation, not a side effect of redeploying compute.

Feature flags as a soft rollback

Feature flags turn off a risky code path without moving traffic or images. They help when the bug is behavioral and the schema is still compatible. They do not reverse a migration that already rewrote rows, and they do not replace health checks or a rehearsed redeploy for process crashes and bad images.

Encore: environments, Deployments and rolling undo

Releases in Encore are infrastructure from code, provisioned and deployed into your own AWS or GCP account. Encore does not document a one-click rollback that flips traffic to an idle blue environment or a weighted canary schedule. Rollback for compute is redeploying a previous commit; safer releases come from preview environments, expandable migrations and rolling updates behind health checks.

Set up the app

Keep a version marker and expandable schema so a redeploy of the previous commit stays valid:

// hello/hello.ts
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("hello", { migrations: "./migrations" });

export const version = api(
  { expose: true, method: "GET", path: "/version" },
  async (): Promise<{ release: string }> => {
    return { release: "2026-11-06" };
  },
);

export const greet = api(
  { expose: true, method: "GET", path: "/hello/:name" },
  async ({ name }: { name: string }): Promise<{ message: string }> => {
    const row = await db.queryRow<{ note: string | null }>`
      SELECT note FROM greets WHERE name = ${name}
    `;
    return { message: row?.note ?? `hello ${name}` };
  },
);

Add columns in a forward migration without dropping the old shape in the same change:

-- hello/migrations/2_add_note.up.sql
ALTER TABLE greets ADD COLUMN IF NOT EXISTS note TEXT;

Link the app to GitHub, and each pull request can get a preview environment with its own API URL so QA hits the change before merge. Production uses Encore's rolling deploy into your account: new tasks come up, pass health checks, take traffic, and old tasks drain. Encore provisions an IAM role for the service. When a release is bad and the schema is still compatible, revert or push the previous commit to the environment branch and watch the new deploy under Deployments. An AI coding agent can ship the /version and migration change in one pull request, run it under encore run, and rely on the preview environment for the shared check before anyone talks about rollback.

Best fit: Teams that want infrastructure from code, preview environments and fast redeploys of previous commits in their own cloud, with expand/contract migrations as the rule that keeps rollback possible.

Good to know

• Rehearse the undo path in a non-production environment, including the migration case you think will never happen.
• Prefer a forward fix when the bad release already wrote data the previous schema cannot express.
• Preview environments validate behavior; they are not a second production blue environment for instant switchback.

Related guides

• Blue-green deployment
• Canary deployments
• Zero-downtime deployment
• Preview environments
• CI/CD pipeline