What changed

Every deploy now keeps your previous revision warm for 24 hours, automatically. You do not have to opt in, and you do not have to remember to snapshot anything beforehand. The moment a new version goes out, the one before it stays ready to serve, sitting on standby rather than torn down.

This used to be something you had to think about. You would deploy, and if you wanted a way back, you were on your own: keep a note of the last known good image tag, keep it somewhere you could find it in a hurry, and hope the way back still worked when you reached for it. Now it is just there, every time, for every app, without a setting to turn on.

If the new deploy misbehaves, you roll back with a single command:

burrow app rollback website

No rebuild. No waiting for an image to pull. No cold start while something spins back up from scratch. The previous revision is already running and ready, so the switch back is fast, with zero downtime.

What you no longer have to do

The point of making this the default is everything it takes off your plate. Before, a safe rollback story was a small pile of habits you had to keep up. Now none of them are your job:

  • No opt in. There is no flag to remember and no per app setting to enable. Deploy, and the safety net is already under you.
  • No manual snapshot. You do not pause before a risky deploy to capture the current state "just in case". The previous revision is kept automatically.
  • No tracking the last good image. You do not need a note, a pinned tag, or a runbook line that says "the good one is web:1.4.2". Burrow already knows which revision you were running, and it kept it warm.
  • No re running your build to go back. Going back does not touch your build pipeline. There is nothing to rebuild, so a broken or slow pipeline cannot get in the way of recovering.
  • No surprise change to your scale. A deploy no longer resets your replica count, so rolling back does not quietly shrink you either. If you had scaled web up, you come back at that same scale. Which version is live and how many copies are running are separate facts now, and rollback only touches the first one.

That last one is worth underlining. Rollback used to risk trading one problem for another: you got the old code back, but at whatever replica count a fresh deploy defaulted to. That is fixed. Scaling is its own concern, handled by burrow app scale and burrow app autoscale, and it stays put across a rollback.

Why it is the default now

A safety net that you have to remember to hang up is not much of a safety net. It is missing at exactly the moment you need it, because the moment you need it is precisely the moment nobody was thinking about setup.

Rollback only helps if it is already there when the deploy goes wrong. Making it opt in meant that the people most likely to skip the setup, the ones moving fast and shipping often, were the people most exposed when a deploy went bad. Making it the default flips that. The faster you move, the more this protects you, with no extra discipline required.

So we stopped treating "keep a way back" as something you configure and started treating it as something Burrow just does. You deploy. The previous version stays warm. If you need it, one command brings it back.

There is a quieter benefit to making it the default, too. When a safety net is optional, you have to think about it, and thinking about it costs a little confidence every time you ship. You hesitate. You double check. You put off the deploy until you have a calm hour to babysit it. A default rollback takes that tax away. You can ship a small change on a Friday afternoon because the cost of being wrong is one command, not an evening. Making the recovery cheap is what makes the shipping feel light.

What this replaces

It is worth being concrete about the old shape of this, because that is what the change removes. The careful version of "be able to roll back" used to look something like: before a risky deploy, write down the tag of the image currently running. Keep that note where you will find it fast. If the deploy goes bad, deploy that old tag again, wait for it to build or pull, wait for it to come up, and hope your replica count did not get reset along the way.

Every step in that list was a place to slip. You could forget to write the tag down. You could write it down and lose it. The old image could be gone from your registry by the time you reached for it. The redeploy could get stuck behind a build. And even when it all worked, it was slow, precisely because it was a full cold deploy of the old version rather than a switch back to something still warm.

The change collapses all of that into nothing you have to do. The note is automatic. The old version is kept for you, warm. Going back is one command. The list above is not a list you shortcut now; it is a list you never open.

Why 24 hours

We picked 24 hours because that is the window where most regressions actually surface: the bad deploy that looks fine in the first thirty seconds and then starts erroring under real traffic, the change that breaks one endpoint you did not test, the config you got subtly wrong. Within that day, going back is one command and a moment.

A shorter window would miss the slow burn regressions, the ones that only show up once the app has seen a full cycle of real usage. A much longer window would mean keeping a lot of old versions standing by for cases that, in practice, almost never come up. A day covers the overwhelming majority of "this deploy went wrong" moments without keeping every past version alive forever.

After the window closes, you are not stuck. You can always get back to an older version by deploying its image reference again with burrow app deploy. That path is a normal deploy, so it pays the usual costs of building or pulling and starting cold. The 24 hour warm window is the fast lane; the ordinary deploy is always there as the slow one.

Using it in practice

A realistic sequence looks like this. You deploy, keep half an eye on it, and something is off:

burrow app deploy website --image registry.example.com/website:1.5.0
burrow app status website          # new revision is live
burrow app logs website --tail 100 # errors climbing after the deploy
burrow app rollback website        # back to the warm previous revision

That is the whole loop. Notice, decide, go back. You are not assembling anything under pressure; you are pressing a button that was already wired up.

The same button works whether you press it or your agent does. When you are driving, burrow app rollback website is the one command. When your coding agent is driving, it can reach for the same rollback the same way, and your guardrail policy decides whether that happens on the spot or waits for your sign off. There is not an agent version of rollback and a human version with different rules. There is one action, one warm previous revision behind it, and one policy over it. That is on purpose: the fewer separate paths there are, the fewer places a surprise can hide.

A rollback is recorded like any other change, so it is visible after the fact. Your status shows which revision is live now, and the action lands in your audit record alongside the deploy that preceded it. If you are the sort of person who wants to reconstruct exactly what happened during a bad afternoon, going back does not erase the evidence. It adds a line to the story: deployed this, it went wrong, rolled back to that.

The same thing works when an agent is doing the driving. Your coding agent can propose the rollback the same way you would run it, and if your policy says production changes need a human, it pauses for your sign off before anything happens. The agent moves fast; you keep the final say. Either way, the mechanics underneath are identical: the previous revision is warm, and the switch is quick.

A few questions

Do I need to turn this on? No. It is on for every app, on every deploy, with nothing to configure.

Which version does a rollback return to? The revision you were running before your most recent deploy. That is the one kept warm and ready.

Will a rollback change how many replicas I have? No. Deploys no longer reset the replica count, and neither does a rollback. Your scale is preserved.

What happens after 24 hours? The warm standby for that revision is released. You can still return to an older version by deploying its image reference again, as a normal deploy.

Can I keep production rollbacks behind an approval? Yes, and that is the next section.

Does this work the same in every environment? Yes. The warm window and the one command rollback are not tied to a particular kind of cluster or a particular environment. Prod and staging both keep the previous revision warm; what differs between them is only the policy you set on who can trigger a rollback and whether it pauses for a sign off.

What if the previous revision was also bad? Then rollback gets you off the version that is actively on fire and onto the one before it, which is where you want to be while you sort out a real fix. Warm rollback is a fast step back to your last state, not a claim that the last state was perfect. It buys you a stable place to stand.

The safety net stays yours

Rollback respects the policy you set per environment. If you want prod rollbacks to hold for your sign off, they will. If you want them to just go in staging, they will. The default keeps you fast without taking the decision out of your hands.

If you want the full picture of how those approvals work, who can trigger what, and how a held action flows through to your sign off, that lives in its own writeup on guardrails. Here it is enough to know that going back is fast and that going back can still be gated exactly the way you want.

The mechanics, in one paragraph

Under the hood, "warm" means the previous revision is never torn down when you deploy over it. Its pods keep running, its image is already on the machine, and its health checks are already passing, so a rollback is a traffic switch rather than a rebuild. That is why there is no cold start and no wait. We go deep on that mechanism, the timing, and its edges in a separate engineering post; here the headline is the change itself.

This is the kind of thing we think should be boring and dependable, not a feature you shop for. The best infrastructure features are the ones you stop noticing, the ones that quietly change how it feels to work rather than showing up as a thing you have to manage. A default warm rollback is meant to be exactly that: not a button you admire, just the reason a bad deploy stopped being a big deal. You deploy, and if it goes wrong, you go back, in one command, with the previous version already there. Warm and waiting.