Immutable and image-based operating systems

Part: Engineering · Chapter: Immutable and image-based operating systems · Edition: 2026-11-13
Keywords: immutable OS, image-based updates, OSTree, bootc, NixOS, Fedora Silverblue, measured boot, TPM, SELinux, atomic update
Glossary: immutable OS, OSTree, bootc, verification mode — see GLOSSARY

At a glance

• An immutable, image-based operating system treats the running host as a versioned image: you replace it as a unit, and you can roll back.
• The design questions are what is frozen, what remains state, how an update is identified, and how a claim about that system can be checked.
• Public systems such as OSTree, bootc, Fedora Silverblue and NixOS appear here only as illustrations.

Online references (live)

• Operating system
• OSTree
• NixOS
• Fedora Silverblue
• Trusted Platform Module
• SELinux
• bootc

Offline snapshots (link-rot shield)

Offline snapshot omitted in this web edition. Offline snapshot · Operating system · https://en.wikipedia.org/wiki/Operating_system · retrieved 2026-07-12

Operating system

Offline snapshot omitted in this web edition. Offline snapshot · Computer security · https://en.wikipedia.org/wiki/Computer_security · retrieved 2026-07-12

Computer security

Offline snapshot omitted in this web edition. Offline snapshot · Zero trust · https://en.wikipedia.org/wiki/Zero_trust_security_model · retrieved 2026-07-12

Zero trust security model

This chapter is a general account of immutable and image-based operating systems: the principles, the usual architectures, the trade-offs, and a small reference model for talking about what can actually be checked. It is orientation, not a product prospectus and not an installation manual.

Applications at Keyne Digital Assets

Integrity of the boot path, of system images, and of conservative change control matters in any environment that stores evolving knowledge. Situation Monitor and the services we offer — software engineering, data science, and consulting — depend on careful handling of sources and of write-paths; this chapter orients that concern. We do not add an operating-system product to the public Situation Monitor offering, and we do not claim that a particular image-based distribution is part of that product.

Engineering index — a short map of the same ideas: image identity, atomic updates, and four verification modes. Index card: Engineering.

---

1. Principles

In the conventional package-based model, a running machine is the residue of many incremental installs and upgrades. Two hosts that started from the same installer can drift. In the immutable, image-based family, the running system is closer to a versioned artifact: a tree, image or generation that can be named, compared, replaced as a unit, and rolled back.

A few principles recur.

Identity is a digest, not a nickname. A serious update path pins a content hash, an OSTree commit, a Nix generation, or an image digest. Tags such as latest or stable are conveniences, not identity.

The image is read-only; state is explicit. Typically /usr (and often most of /etc as shipped) is immutable at runtime. Mutable data lives in designated places — /var, /home, perhaps a writable overlay or a set of bind mounts. The design question is not “can anything ever change,” but “which changes are part of the image, and which are local state.”

Updates are transactions. The next tree is assembled fully, then the bootloader (or an equivalent switch) points at it. A failed update leaves the previous generation bootable. This is the operational meaning of atomicity here: the host does not spend time in a half-upgraded package set.

Policy is more useful when it is structural. A kernel that still refuses a write after reboot, after an update, and after a process is privileged inside its sandbox is a stronger claim than a log line that says a path was read-only. Mount options such as noexec,nosuid,nodev, SELinux (or an equivalent MAC), and deny-by-default access to personal stores are examples of structural policy. They do not solve every problem — in particular they do not, by themselves, contain semantic steering of a model — but they are the kind of control an auditor can sit down and try to break.

Composition needs a named artifact at each boundary. If one system pins a package set, another produces a derivation store, and a third deploys a bootable tree, “reproducible” is not yet a procedure until you publish the function that turns the first into the second into the third. A rebuildable host needs one artifact that an outsider can hash and compare.

---

2. Architectures and public illustrations

These are reference models, not a catalogue of products we ship.

OSTree stores filesystem trees by content hash and checks out a deploy that the bootloader can boot. Fedora Silverblue is the well-known desktop illustration: the OS is a tree, layered packages are an escape hatch, and everyday software often lives in containers or a pet toolbox rather than in a mutated /usr.

bootc takes the habit of building and signing OCI images and uses it for the host itself. The practical unit you pin and transport is an image digest; OSTree remains the on-disk deploy mechanism in the current design. For a single workstation, pinning that digest is usually enough to say “this machine booted that tree.” A large estate that already mirrors RPMs for many machines may still want a content factory in front; a single host does not.

NixOS is a different substrate with a similar moral. Desired state is declared; the store is content-addressed; generations can be rolled back. Nix can also sit beside an image-based host: a builder that produces a bootc or disk image, without Nix being what the laptop boots. Mixing Nix, an RPM content view, and an OSTree deploy without naming the artifact that crosses each boundary is how “reproducible” becomes prose rather than a procedure.

A/B partitions are the older, hardware-near cousin: two (or more) slots, one live, one updated, then a swap. The idea is the same — replace a unit, keep a fallback — even when the store is not content-addressed.

Other public systems sit in the same neighbourhood (openSUSE MicroOS, Flatcar / Container Linux descendants, Ubuntu Core). They differ in packaging, update servers and default policy; they share the image-or-generation habit.

---

3. Trade-offs

Sealing versus daily work. A host that cannot be mutated in place is easier to reason about and harder to debug with the old reflexes (install this package until it works). Common escapes — package layering, a privileged toolbox, a container with the host filesystem mounted — reintroduce drift if they become the real system. The trade-off is honest when those escapes are named and limited.

State versus image. Home directories, logs, container storage, secrets and databases have to live somewhere. If they are baked into the image, every update is a data-migration problem. If they are unbounded bind mounts, the “immutable host” is a read-only /usr with a writable universe beside it. Good designs enumerate the state volumes and the mount policy on each of them.

Reproducibility versus convenience. Floating tags build quickly and drift. Pinned inputs and a second builder are slower and are what “reproducible” means. The same applies to model weights and policy files if the host runs agents: an unpinned artefact falsifies a bitwise replay even when the OS digest is pinned.

Isolation density. Linux namespaces and cgroups, with a MAC such as SELinux, share a kernel with the host: dense and fast, and a kernel exploit is a host exploit. A microVM (Kata Containers, Firecracker, or a similar guest kernel) raises a stronger boundary at the cost of a VMM, guest kernels, firmware blobs, and a harder story for GPU, USB and shared trees. A full emulator is heavier still. “Namespaces and a microVM and a full emulator” is three products, not a flag. Until a workload needs the extra device model, one daily tier and one stronger tier is usually the whole story — and the reason a workload was placed in a tier belongs in the record.

Topology-bound storage. Keeping data on the machine that runs the workload, without a network filesystem in the path, is a clear design. It quietly implies a placement rule: if the volume lives on node A, the work has to run on node A, and if A fails the volume is not on B. That is a scheduler problem, whether or not Kubernetes is the scheduler.

Firmware and attestation are profiles, not a slogan. “The TPM is the root of trust, so the claim is the same on a desktop, a laptop and a cloud instance” is too quick.

---

4. What can be checked: four verification modes

It helps to say, for each claim, how it is allowed to be true. Softening a claim that does not fit a mode is better than inflating the mode.

Two cuts belong with this vocabulary.

Content-borne code execution is a sandbox problem; content-borne semantic steering is a model problem. A noexec document directory and a narrowed grant bound the first. They do not close a prompt that travels inside a file the agent is allowed to read. Anyone claiming a full close of that second problem from mount policy alone is overclaiming; the honest remainder is blast radius and a reconstructible incident.

Model internals are observed, not attested. Instruments such as sparse autoencoders trained on a model’s activations are real research tools on open weights. They are per model, per layer, per training run; coverage is partial; there is no golden activation; a detector can be optimized against once it is public. That supports an offline decomposition of a suspicious run — pinned weights, recorded seed, saved states — which is a form of replay. It is not an OS control in the sense that mount -o noexec or an SELinux denial is a control. Putting the two in the same sentence mixes a kernel refusal with a statistical hint.

Replay itself splits. Bitwise replay holds only in a closed world: pinned weights, pinned kernels, a recorded seed, frozen retrieval, no live network. A tool call that hits email or the web falsifies “identical result.” A weaker, still useful, form is validatable replay: receipts or logs that a validator still accepts, and that it rejects after a single field is flipped. The second should not be silently sold as the first.

A small, conservative slice that is often enough to reason about — not a product name, just a pedagogical minimum — is: one pinned image digest, deny-by-default mounts with noexec on data, one namespace isolation tier, grants and receipts that a validator can reject, and one TPM2 machine if attestation is claimed. Stronger firmware floors, cluster schedulers, microVMs and model-level instruments can be added when a workload forces them, each with its own mode of evidence.

---

5. Related pages

• Engineering index
• Unix-like systems
• Cybersecurity
• Computer architecture
• Machine learning: LLMs
• Knowledge OS

---

Orientation, 2026-11-13. Public examples evolve; check upstream documentation for current image formats and tooling. Claims about a running system are checkable only in the mode that fits them.