Immutable deploys

Every deploy in kixctl produces a new, self-contained machine rather than changing one that already exists. A push builds; it never mutates.

When a commit lands, kixctl pins the build to that exact commit — git+<url>?rev=<sha> — and Nix fetches the repository hermetically at that revision, with no working clone to drift. The result is a NixOS image with the application built into it, imported over the Incus API and launched as an instance named <app>-<sha7>: the application's stable name plus the short commit hash. A fresh unit for every push. kixctl never edits a running revision; it only ever adds a new one.

New revisions land on kixctl's own network and profile, reachable only through kixctl's edge — internal by default, never placed on your LAN unless you route them there deliberately.

Build-alongside

The first revision of an application is published straight away, so it is reachable by name the moment it is up. But when a revision is already live, a newer one does not take its place automatically. It lands alongside the running one — built, booted, and holding an address, with the live route left untouched — and surfaces as "update ready."

Promotion is a decision you make, not a consequence of pushing. A green build proves the code compiled; it does not prove the code is correct, and kixctl will not swing live traffic onto an unproven revision on your behalf.

Identical builds are skipped

The commit hash always changes, but a comment-only edit — or a revert to the currently live tree — produces a byte-identical image whose fingerprint the live revision already runs. There is nothing to deploy: the running machine already is that artifact. kixctl detects this from the image fingerprint and stops, rather than launching an identical twin and raising a false "update ready." A commit that genuinely changes the build produces a different fingerprint and deploys normally.