Rootfs Image Design for Fast-Booting AI Agents

A rootfs image built to run AI agents has to be architecturally different from a general-purpose OS image. Layer composition, init sequence, and filesystem layout are not hygiene details here: each one directly decides whether the agent boots in under 200ms or whether it simply, eventually, comes up running. Containers are too porous to trust with untrusted model-generated code, and traditional VMs are too slow to spin up on demand, so rootfs design inside a microVM is the place where isolation, speed, and completeness all have to be reconciled at once.

The stakes are measurable. A cold boot of a template VM takes on the order of seconds. After a snapshot exists, DeltaBox research out of Shanghai Jiao Tong University and Huawei shows rollback achievable in approximately 1.86 milliseconds. The distance between those two numbers comes almost entirely from how the rootfs was built.

What the Firecracker execution model requires from the rootfs

Firecracker gives each sandbox its own Linux kernel, and that kernel mounts a sealed root filesystem, not a general-purpose disk image. For an AI agent that needs to respond to a user or kick off a tool call the instant it wakes up, there is no room for a boot-time dependency resolution step.

Firecracker's VMM is deliberately stripped down: it exposes only six device types, compared to the hundreds QEMU supports. That narrows the attack surface and removes most legacy device code, but it also means the rootfs can't assume the devices a general-purpose Linux distribution takes for granted. So the image has to describe itself at boot, with no kernel module fallbacks to paper over gaps.

The payoff for getting this right is the copy-on-write restore model. Firecracker restores the rootfs as a reflink clone, an operation that costs O(metadata) rather than O(disk), and guest memory restores copy-on-write as well, so pages shared across many agent instances are never re-copied until something actually writes to them. A rootfs laid out to maximize that sharing is what turns a seconds-long cold boot into a millisecond-scale restore. Maritime's infrastructure approach exemplifies this principle: each AI agent runs inside its own Firecracker micro-VM with a rootfs designed specifically for snapshot-restore scheduling, where the gap between cold boot (seconds) and snapshot restore (single-digit milliseconds) is almost entirely rootfs design, so an agent built on this rootfs responds instantly, while one without it merely eventually works.

Image minimization: stripping order and rationale

Minimizing a rootfs is about ensuring that everything the agent needs at runtime is already present, so nothing has to be resolved at boot, because every deferred resolution adds latency directly to the restore path.

Package managers, documentation, locale data, unused kernel modules, and any init-time service devoted to hardware discovery are the first candidates for removal, since none of them serve the agent's actual workload and all of them add boot time. A missing directory or device node at mount time is a boot failure. Because removing one package can silently break the dynamic linkage of another, the right discipline is to audit linkage after every removal pass, not once at the end when the causes have piled up and become hard to separate.

The Red Hat fedora-bootc agentic OS project is a useful anchor here. The OS layer is defined exactly once, at build time, and stays read-only at runtime, containing precisely the declared set and no more. That is the discipline minimization is actually asking for: a dependency set declared in advance, not discovered through trial and error in production.

Init stripping: why a full init system is the wrong default for an agent rootfs

A general-purpose init system like systemd earns its keep on a general-purpose server, where it has to handle hardware probing, network configuration, and service ordering. An agent rootfs that will be restored from snapshot has usually already done that work once, during template creation, so it gains nothing when it repeats it on every restore. A full systemd target graph built for a general-purpose server can add hundreds of milliseconds of sequential service startup before the agent process even begins, and you pay that cost on every single boot unless you design it away.

The model that fits snapshot-restore workloads runs init exactly once, at template-creation time, to bring the system into a fully-booted state, and then snapshots that state directly. Every subsequent restore skips init altogether, so the agent lands in a system that is already running. What a minimal init still needs to handle is narrow but non-negotiable: process reaping, since PID 1 cannot be the agent process itself without risking zombie accumulation, signal forwarding, and mounting whatever agent-specific state directories sit outside the sealed rootfs.

A kernel-level RFC circulating in July 2026 pushes this logic further: it proposes that the kernel mount the root image directly, taking over the initramfs's job. Under that design, the initramfs's remaining job, parsing the command line, loop-mounting the image, and calling switch_root, moves into the kernel itself. That direction is where the Linux kernel community is heading, ahead of most production agent infrastructure today.

Read-only root and immutable image layout as a correctness guarantee, not just a security posture

A mutable rootfs breaks the snapshot-restore model at a structural level, because any in-place modification made between two snapshots creates a divergence the restore process has no way to reason about. Immutability is what gives the snapshot-restore cycle a well-defined meaning in the first place: restore a given digest, and the result is always the same state.

Red Hat's fedora-bootc agentic OS mounts the OS image content, specifically /usr, read-only, while /etc and /var remain mutable. So no mechanism is left through which configuration drift could occur, and it becomes structurally impossible.

That guarantee compounds at fleet scale. If every machine boots from the same image digest, the agent comes up in exactly the same configuration on every machine. Updates become atomic: pull new layers, compare digests, reboot. Rollbacks are just as simple, since the prior image remains available and bootable.

Mutable state still has a legitimate place, confined to a dedicated directory for credentials, agent memory, and session files, explicitly excluded from the sealed rootfs and managed on its own path. You inject secrets at runtime through Podman secrets or an equivalent mechanism, and they're never baked into the image itself. That three-way separation, an immutable OS layer, a mutable state layer, and injected secrets, is also what makes per-user agent deployment safe: one image, many instances, each with its own state directory and its own credential namespace.

Dependency layering: structuring the image so the snapshot-restore path stays fast as the agent's toolchain grows

An agent rootfs has to be complete enough to run its toolchain without any network fetch at restore time, but every byte you restore from storage adds latency. Those two pressures pull in opposite directions, so layer ordering is the main lever you use to resolve the tension between them.

The working strategy puts slow-changing, large dependencies (the base OS, the language runtime, heavyweight libraries) into lower layers shared across many agent images, and reserves the top layer for fast-changing, agent-specific code unique to a given agent type. If the image is well-layered, a restore only touches the top layer's unique pages, and the shared foundation underneath costs almost nothing per instance.

Browser sessions and similar large runtime assets, Chromium installs and Node module trees among them, test this principle directly. They're large, they change slowly, and the agent needs them at its very first action. The right place for them is a lower, shared layer, pre-warmed directly into the snapshot rather than fetched on demand the first time the agent reaches for a browser. The anti-pattern is a single-layer rootfs that concatenates everything into one undifferentiated blob: any change to the agent's own code then invalidates the entire layer cache and forces a full re-restore on the next snapshot cycle, even though nothing about the base OS or runtime actually changed.

DeltaFS and DeltaCR: how OS-level change tracking reduces checkpoint cost as agent workloads deepen

Agent workloads that involve tree search or reinforcement learning rollouts move through many consecutive sandbox states, and those states typically differ only slightly from one checkpoint to the next: a few new files, a handful of modified memory pages. Checkpointing the full state at every step wastes most of its effort duplicating data that never changed.

DeltaBox, developed by researchers at Shanghai Jiao Tong University and Huawei in 2026, proposes a new OS-level abstraction called DeltaState that checkpoints only the changes between consecutive states. DeltaCR forks from a frozen template process backed by a CRIU dump, rather than reconstructing process state from scratch.

The measured results make the case concretely. On coding-agent and RL micro-benchmarks, DeltaBox hides its checkpoint work, roughly 10.83ms, underneath inference time, and rolls back in approximately 1.86ms, against a regime of hundreds of milliseconds to full seconds for conventional full-state checkpoint and restore. Each checkpoint simultaneously produces two artifacts: an asynchronous CRIU incremental dump, durable and suited to crash recovery or slow-path restores, and a frozen fork template, suited to millisecond-scale fast-path restores.

None of this works on a rootfs that merges the base layer and the writable agent layer into one undifferentiated space. A rootfs built without that separation defeats incremental checkpointing before it has a chance to run.

Snapshot-friendly filesystem layout in practice: where to put agent state, credentials, and runtime data

Where things live on disk determines what gets snapshotted, what gets excluded, and what has to be restored from a separate store. Get the layout wrong and the result is either over-snapshotting, slow and bloated, or state loss across restores, with no middle ground.

A workable layout separates three zones cleanly. The sealed OS layer is read-only: it gets snapshotted once at template creation, then shared across every instance that boots from it. The agent state directory is mutable, persisted separately per agent instance, and never part of the rootfs snapshot itself. You mount injected runtime data, credentials and API keys among them, at boot from a secrets store, so it never touches disk in plaintext.

Red Hat's fedora-bootc agentic OS embodies exactly this model. The image itself contains nothing sensitive, so you can make it public without exposing anything.

Ephemeral working data, scratch space and intermediate outputs an agent produces mid-task, belongs on tmpfs. That keeps the snapshot small, and you don't persist data that has no value once the agent step finishes. The snapshot-restore constraint that Maritime enforces, that anything not already on disk at snapshot time must be fetched at runtime, means the rootfs cannot defer resolution to boot. It has to be fully constituted and sealed at image build time, turning initialization into a one-time event.

Per-user and multi-tenant agent fleets: how image design choices compound at scale

The per-user agent model, one isolated VM per user session, only works economically if the base image can be shared efficiently across many instances. If an image can't share its lower layers, every instance has to pay full storage and restore cost on its own, and that erases the economics of the model before it even starts.

Copy-on-write restore is what makes the alternative possible: the Nth restore of the same base image does not copy gigabytes of RAM, since pages stay shared until something writes to them, and the rootfs itself restores as a reflink clone costing O(metadata). If you design the image well, a single server can host many agent instances, and each additional instance adds almost no marginal restore cost.

Multi-tenant deployment adds its own requirements on top: tenant separation, resource quotas, deterministic reset, and audit records, all of which have to hold without breaking the shared-image model that supports them. Because every machine in the fleet boots from the same digest, and pulls new layers only when that digest changes, configuration drift has no path into the system once the root is sealed this way.

The flat per-agent economics that result depend on the base image cost being amortized across the whole fleet, which is possible because the image was laid out to share cleanly from the start.

The design checklist: decisions to make before building the first snapshot

Every rootfs image built for a fast-booting agent is the sum of a specific set of decisions, made or left unmade. The ones left implicit don't disappear. They appear later as latency, as storage cost, or as correctness bugs discovered in production.

1. Minimization target: define the agent's complete runtime dependency set before the image is built. Anything not on that list has no place in the image.
2. Init strategy: decide up front whether the agent boots from a cold kernel start, which needs a minimal init, or is always restored from snapshot, where init runs once at template time and every subsequent restore skips it. This decision settles whether systemd units belong in the image design.
3. Layer boundaries: separate slow-changing base layers, the OS and the runtime, from fast-changing agent layers, code and configuration. This boundary falls at the line between what's shared across instances and what's unique to one.
4. Mutable state placement: declare exactly which directories are mutable, which are ephemeral and belong on tmpfs, and which are sealed inside the read-only rootfs. Anything that falls outside those three declared zones is a design error, not an edge case.
5. Secrets policy: decide at design time that no secret ever enters the image, full stop, and define the injection mechanism, whether a runtime mount, a secrets store, or environment injection, before the Containerfile is written.
6. Snapshot cadence: for agent workloads involving multi-step tree search or RL rollouts, plan for incremental checkpoint support from the outset, with overlayfs layer semantics compatible with DeltaFS-style mechanisms built in rather than retrofitted once the full-state checkpoint costs have already become the bottleneck.