# 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+?rev=` — 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 `-`: 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.