Skip to main content

Rollback and the state boundary

This is the page the whole design is built to earn: you can revert an application to its previous version, and its data is untouched — because the data was never inside the version you reverted.

A revision holds no durable state​

Each <app>-<sha7> instance is an immutable image with the application built in and nothing persistent kept inside it. The state an application needs — its database, its persistent files — lives outside the revision. What kixctl carries forward is not the state but the pointer to it: the application's configuration and secrets are declared once, in kixctl, and injected into every new revision at launch, so a brand-new revision comes up already knowing where its state lives. That injection is what makes an update feel continuous even though the running machine is entirely new.

Those injected values arrive as read-only credential files delivered through systemd's credential mechanism — not baked into the image and not visible in the instance's configuration.

Rollback is a cutover to a machine that is still there​

When you revert, kixctl does not rebuild anything or run a migration in reverse. The previous revision is a whole, intact instance that was retired but kept — kixctl starts it if it was stopped, waits for its address, and swings the route back to it. The cutover is bounded by how quickly the resolver refreshes, a matter of seconds.

Because that revision points at the same external state every revision points at, reverting the application does not touch the application's data. That is the difference between rolling back the code and rolling back and hoping.

What is running is legible from the infrastructure​

kixctl keeps no separate ledger of revisions. Which revisions exist is readable from the fabric — the instances named <app>-<sha7>. Which one is live is the route. The single fact that isn't otherwise visible — that a revision was superseded, and when — is written onto the retired instance itself as a timestamp, so it survives a reboot and reads straight back out of the instance's own configuration. A superseded revision is marked, kept intact for as long as the reap window allows (a week by default), and then removed along with its image. Nothing to reverse-migrate, and nothing to drift out of sync with reality.