What “roll back” should mean

Something is wrong in production and you want the previous version back. On most setups the procedure is: revert the commit, push it, and wait for the pipeline.

That works often enough that people stop noticing it has three problems, all of which show up at the worst moment.

It takes a full build

Reverting means building again. Whatever a deploy normally costs you in minutes, a rollback now costs the same, except you are spending them while the thing is broken. The one moment you most need speed is the moment you have chosen the slowest possible mechanism.

The rebuild is not guaranteed to match

Building the same commit twice does not reliably produce the same image. A dependency resolves to a version published since, a base image tag moved underneath you, a build argument comes from the environment. Usually the result is close enough. Occasionally you roll back to fix one problem and ship a second one, which is a genuinely bad half hour.

Plenty of breakage has no commit to revert

If what broke production was an environment variable, a memory limit, a replica count or a port, there is nothing in the repository to revert. Git-based rollback simply has no answer, and you are back to remembering what the value used to be.

What a revision fixes

The alternative is to treat every change to what is running as a numbered, immutable revision: the image and the configuration applied with it, captured together at the moment it went out.

That reframes rollback entirely. You are not rebuilding anything, you are re-applying a state the cluster already ran. It takes as long as a rollout, not as long as a build, and it is exactly the bytes that were running before, because the image reference is part of what was recorded. A configuration-only change gets a revision too, so "the deploy that broke it" can be a config edit and still be undoable.

How this looks in Kaja

Every app has one timeline. Builds from a push, image updates, configuration changes and rollbacks all appear in it, newest first, and the one currently serving is marked Live. Each entry carries its revision number, the commit it came from where there was one, who triggered it and how long it took.

Rolling back is choosing an earlier entry and confirming. That restores the revision's image and its configuration, and rolls it out. An unpublished draft you were in the middle of editing is left alone rather than being silently shipped.

The rollback then appears in the timeline as its own entry. History stays append-only, so the record shows that a rollback happened and when, and rolling forward again is the same operation in the other direction.

None of this is a novel idea. It is the difference between a deploy system that records what it did and one that assumes it can always reconstruct it, and you find out which kind you have on a bad day.