Amutable OS: image-based Linux with no shell, no SSH, signed images only

Amutable opened a private preview of its Foundations product on 22 October 2026, and on 6 November Lennart Poettering, Michael Vogt and Joaquim Rocha published a technical overview of the two halves: Amutable OS (AOS), an image-based Linux built from Fedora packages, and the Amutable Control Plane (ACP), which manages a fleet of it. The pitch is blunt. AOS ships no shell, no SSH daemon and no language interpreters by default, activates only images whose Verity data carries a signature from a key in the kernel's Verity keyring, and reports its measured composition to a control plane that keeps a ledger of what every node runs.

Immutability is not new — Flatcar, Talos and Bottlerocket have shipped variants of it for years. What is new here is that configuration is also an image: encrypted per node, sealed to the TPM against the last report the control plane saw, and therefore measurable. That closes the hole most immutable distributions leave open, because /etc is usually where signed images stop and hand-edited reality starts. The design is worth taking seriously and worth arguing with, because its trade-offs show up on call at 3am rather than in a slide deck.

What Amutable is shipping, and the drift argument

As of this writing there is no downloadable image, no price list and no third-party audit, so what follows describes a design and a set of vendor claims rather than measured behaviour. That distinction matters more than usual, because most of the properties claimed are architectural: either the kernel refuses to activate an unsigned image or it does not.

The two components are easy to confuse. AOS is the operating system on the node. ACP is the service that enrolls nodes, receives their reports, verifies them, records the results in a ledger, and hands back per-node configuration images. Neither is much use alone: AOS without ACP is an immutable system with an unusual amount of cryptography attached, and ACP without AOS has nothing trustworthy to verify.

AOS takes Fedora packages and composes them into disk images at build time instead of installing them on the target machine. Amutable is explicit that the point is to keep the distribution's integration work — the patches, unit files and dependency resolution that a distro does once and nobody wants to redo — while changing when composition happens. A deployed system combines "typically < 5" images rather than thousands of packages. Modularity survives in two narrow forms: system extensions (sysexts), which overlay /usr and carry large optional pieces like GPU drivers and cloud vendor agents, and configuration extensions (confexts), which overlay /etc. Which sysexts get installed is partly automatic, driven by a local hwdb database that matches enumerated hardware or a hypervisor's identification.

The absence of a package manager on the node is stated plainly in the announcement post: "There's no package manager and no SSH or interactive shell. The only way to change a machine is to give it a new signed image." That sentence is the product in one line, and it is also where most of the operational risk lives.

ACP itself is a fairly conventional control plane wearing unusual clothes: an enrollment service using hardware-backed trust, a report receiver and validator, a confext generator that encrypts images per node, an identity service issuing short-lived node credentials, a TUF image repository, a CVE scanner that works from the SBOMs attached to images, and a web UI over the lot. It is multi-tenant, with per-tenant signing keys, storage and roles.

The motivating argument for all of this is drift, and it is worth stating in the authors' own terms. In a package-based system, "even with an identical selection of packages for the target system, the installation/update order, the stateful update logic and the file system data structures generally mean that the bytes that hit the disk on each machine are always different." Anyone who has run a large fleet has seen this: a rollout that takes six hours crosses a repository push, so the first hundred hosts get library version n and the last hundred get n+1; an installer that ran two years ago left a default file that a fresh install no longer writes; a config management tool skipped a task because a file already existed.

The steelman is strong. If you cannot enumerate what a machine is running, you cannot answer "which hosts still have the vulnerable library" without scanning them, and a scan is a guess about state rather than a statement of it. Amutable's answer is that composition should be an artifact you distribute, not a recipe you replay.

The weaker part is the sentence that follows, which says systems built this way are "hence not reproducible, not predictable, and hard to compare and analyze". That does not follow. Several commenters on the LWN discussion made the obvious objection: a mirrored repository plus version locking plus idempotent configuration management gets you most of the way, and Debian with Salt or RHEL with Satellite is not the lawless place the post describes. Others pointed out the symmetry that hurts the most — an image is a giant package, and a fleet mid-rollout still has two or more image versions live at once. The drift does not vanish; it moves up a level and becomes enumerable.

I think the honest version of the claim is narrower and better than the one written. Image-based composition gives you reproducible deployment without requiring reproducible builds. You do not need bit-identical output from the compiler; you need bit-identical bytes on the wire, which a signed artifact gives you for free. That is what makes the test matrix tractable: one artifact to test rather than a combinatorial explosion of install orders. It is also what makes the security question answerable, since a Verity root hash is a name for a filesystem.

The cost is real and the post does not dwell on it. A single-line fix to a unit file becomes a build, a sign, a repository publish and a rollout. There is no sed -i at 2am, and for some classes of outage that is the difference between fifteen minutes and four hours.

Verity, DDIs, and what signed images actually enforce

The integrity story rests on two artifact formats. The OS image, sysexts and confexts are UAPI.3 Discoverable Disk Images: an EROFS filesystem, a Verity hash tree over it, and a cryptographic signature, all wrapped in a GPT partition table used as an envelope. The kernel and initrd ship as a UAPI.5 Unified Kernel Image, protected by UEFI Secure Boot and by TPM measurements and policies.

It is worth being precise about what dm-verity does, because "signed images" is often used to mean something weaker. Verity builds a hash tree over the filesystem in fixed-size blocks, stores the tree alongside the data, and signs the root hash. The kernel verifies each block as it is read and returns an I/O error if the hash does not match. Verification is therefore continuous, not a check performed once at download time: a block that is altered after the fact fails when a process touches it, not when it is fetched. That is a meaningfully different guarantee from "we verify the checksum after download", and it is the reason the model can survive a compromised root account on the node.

Two consequences follow, and both cut against the marketing. First, tampering becomes an availability event. If an attacker with physical access corrupts /usr/lib/systemd/systemd, the node does not boot into a known-bad state and quietly phone home; it fails to read a page and panics or drops into an error path. Detection is not free, and the failure mode is a machine that will not start rather than one that starts wrong. Second, Verity protects the bytes on disk, not the running kernel's memory. A process with enough privilege to use ptrace or /proc/kcore is outside the model, which is why the W^X and no-SUID properties matter as much as the hashing does.

Confexts add confidentiality on top of integrity. They are LUKS-encrypted with a key specific to the node, and where the hardware supports it, sealed to the TPM under an access policy that mirrors the most recently seen report from that node. The consequence is that configuration can only be unlocked by a machine still in the state the control plane last observed. The post calls the two directions together the Cryptographic Locked Loop: reports go up, confexts come down, and each confext is bound to the report that preceded it. On hardware without a TPM the same loop runs on software signatures, which proves that whoever built the confext held a key — not that the machine is in a good state.

That is a genuinely interesting design, and it is also where the trust concentrates. Every property in the list below reduces to one keyring on the node and one set of tenant signing keys in ACP. Key rotation, revocation and recovery are the parts of this architecture that a technical overview cannot demonstrate and that a private preview will be judged on. A single compromised signing key does not break one host; it authorises an image that every host will accept.

The seven properties, sorted by what they enforce

The overview lists seven "essential security properties". They are not the same kind of claim, and sorting them makes the design easier to evaluate.

No shell, no SSH, no interpreters is a default, not an invariant. The wording is "by default AOS does not install a UNIX shell, nor makes remote access via SSH available", which leaves room for an image that does. That is reasonable — some customers will need a shell — but it means the property is a policy enforced by the image build, not by the kernel. If your threat model depends on there being no shell, you need to verify the image composition, and the ledger is what makes that possible.

Signed images only is architectural. The kernel will not activate a filesystem whose Verity data is not signed by a key in the Verity keyring, so this holds regardless of what a root process on the node wants. This is the strongest claim in the set.

W^X is architectural on the host: code cannot live on writable filesystems and must come from a Verity-protected source. It is worth noting what it does not cover. W^X on the host says nothing about a container payload that maps executable anonymous memory for a JIT, unless the runtime enforces a per-workload policy. The property is about the OS image, and the workloads are somebody else's problem — which is fine, but it is not the same as "no code can execute that was not signed".

Everything is measured is architectural where a TPM 2.0 or a confidential-computing CPU is present, and aspirational where it is not. The post is candid that the loop is opportunistic and degrades to software signatures; ACP's UI is supposed to surface which technology was used. A software signature proves possession of a key, and a key can be copied. That is a weaker statement than "hardware-backed", and it should be read as such.

No SUID/SGID or file capabilities is architectural, and it is the property with the largest hidden cost. Removing the classic privilege-escalation bits means every privileged operation has to be an IPC call to a service that already holds the privilege — which is exactly the systemd model, and exactly why this team can build it. It also means that any third-party agent expecting to setuid its way to root simply will not work.

Integrity is mandatory is a restatement of the previous three with a framing argument attached: the post calls it "a conditio sine qua non given the advent of LLM agents". I read that as positioning rather than engineering. The technical content is that all shipped filesystem images carry block-level Verity and, for configuration, encryption.

Factory reset is built in is a mechanism, and its value depends entirely on what it wipes. On a system where /usr is pinned by a root hash and /etc arrives as a sealed image, a reset mostly means discarding /var, the TPM-sealed keys and any enrolled extensions. Commenters on LWN immediately asked the right question — whether a reset helps against an attacker who had physical access and the disk password — and the honest answer is that it helps with configuration and keys, not with firmware or with hardware you no longer trust.

What you give up when the shell is gone

The overview anticipates the obvious objection and offers a partial answer: remote Varlink mode. A node can be put into a mode where it exposes its full Varlink IPC API over HTTPS, authenticated through varlink-http-bridge with mTLS or SSH authentication, brokered by ACP in a zero-trust arrangement where ACP is content-blind. That exposes interfaces such as io.systemd.Hostname, io.systemd.Unit, io.systemd.JournalAccess, io.systemd.SysUpdate and io.systemd.Manager, each with an OpenAPI 3.1 description so you can generate a typed client.

This is a better answer than most no-shell systems give, and it is better for a specific reason: it is the same API the local tools use, not a diagnostic side channel bolted on for operators. Restarting a unit, reading the journal, checking for updates and rebooting are all first-class calls. Automation against a fleet becomes a generated client rather than a pile of expect scripts around SSH.

It is still not a shell, and the gap is easiest to see by listing what disappears. No ps, so you cannot see which process is holding the deleted file. No ss or tcpdump, so a packet-loss investigation moves to the network team's taps. No strace or gdb, so a wedged third-party daemon becomes a core dump you analyse elsewhere. No df, so a full /var is something you infer from logs. Every one of those tools is a binary that would have to be in the image, which means a build, a signature, a CVE to track and a line in the SBOM. That is the actual cost of the model: not that debugging is impossible, but that each diagnostic capability is a supply-chain artifact with a maintenance bill.

Compare the alternatives. Talos makes the same no-shell bet but owns the entire userspace in Go and exposes a gRPC API, which gives it the freedom to design diagnostics as API calls from the start. Bottlerocket keeps the host free of a shell and an SSH server, then ships a control container with the SSM agent and an optional admin container with an SSH server and a sheltie escape hatch into the host — an explicit admission that operators occasionally need a root shell. AOS's Varlink approach is the most general of the three, because it exposes the full systemd surface rather than an exec channel, but it is also the newest and the least battle-tested in an incident.

The deeper operational cost is not tooling, it is latency. In a hand-fixable fleet, an engineer with root and a shell can mitigate in minutes and write the postmortem later. Here, mitigation means either a rollback to the previous image — which the announcement says stays available as a fallback, and which is the right first move for most bad updates — or a new image through the pipeline. Rollback covers the common case. It does not cover the case where the bad thing is a configuration change sealed to a node, or where the node is 400km away with no console.

Fleet management, the ledger, and edge nodes

The part of the design I find most defensible is the ledger. Reports generated by systemd-report carry both runtime state and cryptographic composition: a TPM quote on hardware that has one, a CPU quote from AMD SEV or Intel TDX in a confidential VM, and a plain software signature as a fallback. ACP verifies each report superficially (does the signature check out, does the key map to the enrolling system) and in detail (are the UKI and every DDI recognised), enriches it with SBOM and CVE data, and writes it down. The ledger therefore answers "what is this fleet running" as a database query rather than a scan.

That is a real improvement over agent-based inventory, and it is the strongest argument for the whole architecture. Agents report what they believe; a quote reports what the hardware measured. If you have ever tried to prove to an auditor that every production host runs an approved configuration, the difference is not academic.

Two caveats. First, reports are periodic. A node that goes dark stops updating its ledger entry, and the ledger will happily show a stale good state unless you alert on staleness — which means the ledger is only as honest as your monitoring of it. Second, the control plane is a new dependency with its own availability budget, sitting in front of the thing you use to fix machines. Amutable mitigates this by design: reports and confexts are asynchronous, confexts are fetched from a TUF repository rather than pushed, and a node with a TPM can attest itself locally and boot without reaching ACP. That is the right shape for edge deployments, where connectivity is intermittent and a control plane round trip at boot is not something you can rely on.

Edge is where the trade-offs get sharpest. A sealed, encrypted configuration image on a device in a field cabinet is a genuine improvement over a /etc partition that anyone with a screwdriver can read. The same device with no shell, no console and a factory reset that discards its keys is a device you had better be able to re-provision remotely, because the alternative is a truck. And on the class of hardware where TPMs are optional — cheap ARM boards, older industrial PCs — the loop degrades to software signatures, at which point much of the security argument rests on key custody rather than hardware.

Where it fits: Flatcar, Talos, Bottlerocket, and the distro you already run

The table shows that "immutable Linux" covers four quite different bets. Flatcar is the most conventional: a minimal container host that keeps the operator's familiar tools, including SSH, and adds atomic updates and read-only system images. It is the easiest migration from a normal distribution and the least opinionated about how you manage it. Talos is the most radical: no shell, no SSH, no GNU utilities, no systemd, an 80MB SquashFS image, everything through one gRPC API, and an explicit assumption that the machine exists to run Kubernetes. Bottlerocket sits between them, with dm-verity on the root filesystem, TUF-secured updates, an API for settings, and containers as the sanctioned way to get a shell when you need one.

AOS differs from all three in two places. It keeps the Fedora userspace and systemd, so existing unit files, existing packaging knowledge and existing operational habits transfer; that is a deliberate bet that semantic compatibility is worth more than a smaller image. And it treats configuration as a signed, measured artifact rather than as data in an API store, which is what lets it claim that a node's entire composition — code and config — is attested.

That second difference is the one to watch, because it has a workflow cost that the overview does not discuss. Configuration as an image means configuration changes follow the same build, sign and publish path as code. Teams that expect to change a timeout and see it applied in thirty seconds will not get that. Teams that already review infrastructure changes through pull requests will find the model natural, and will get a cryptographic answer to "was this change applied everywhere" that they currently get from a config management dashboard and a certain amount of faith.

Against a conventional RHEL or Ubuntu fleet, the comparison is not close on either axis. A conventional distro lets you install a patched package on one host in minutes, which is the correct response to an actively exploited CVE in a single component. It also gives you a system whose exact composition you cannot state. Most organisations live with the second problem because the first one is urgent. Amutable's wager is that attestation requirements — regulatory, contractual, or simply the consequence of running AI infrastructure on hardware you do not own — will make the second problem urgent enough to pay for the first.

What to watch

The overview is a design document for a product in private preview, and it should be read that way. There are no benchmarks, no update success rates, no boot-time numbers and no published audit. The claims that matter will be settled by the first design partners, and the specific things I would want to see are unglamorous: how long a build-sign-publish-rollout cycle actually takes when a CVE lands; whether the "by default" in the no-shell property survives the first customer who needs a JVM on the host; what a TPM firmware update does to a fleet of sealed confexts; and whether the debugging story holds up when the failing component is a vendor agent that assumes setuid and a shell.

What is already clear is that this is the most concrete statement yet of where the systemd camp thinks server Linux should go, and that it is coherent. Signed images, continuous Verity verification, no writable path for code, no SUID, configuration as an image, and a ledger built from hardware measurements are not a random pile of hardening features; each one removes a specific way that a fleet stops being what you declared. The price is a build pipeline on the critical path of every change, a control plane in the critical path of every boot decision, and an on-call rotation that reads APIs instead of terminals.

Whether that price is worth paying depends on what you are defending. For a five-server shop with a competent sysadmin, a conventional distribution and a backup regime is cheaper and better. For a fleet where you must prove composition, where the hardware is not under your physical control, and where an unexplained binary on a node is an incident rather than a curiosity, the design is aimed squarely at you — and the argument is strong enough that the competition will have to answer it.

Sources

• Amutable Foundations: A Technical Overview — Lennart Poettering, Michael Vogt and Joaquim Rocha, 6 November 2026. Primary source for AOS, ACP, the Cryptographic Locked Loop and the seven security properties.
• Introducing Amutable Foundations — Amutable, 22 October 2026. Announcement, preview terms, and the "no package manager" statement.
• Amutable Foundations: A Technical Overview — LWN, 7 November 2026, with reader discussion of drift, factory reset and image-based trade-offs.
• Talos Linux philosophy — Sidero Labs. No shell, no SSH, no GNU utilities, immutable SquashFS images.
• Bottlerocket README — AWS. dm-verity, TUF updates, A/B partition flips, control and admin containers.
• Flatcar Container Linux documentation — minimal immutable container host, atomic updates, systemd extensions.
• dm-verity — Linux kernel documentation for the block-level integrity target.

← back to posts