Containers, microVMs, and the sealed host

Overview: Root Lock by HeartSuite seals what a host may run. The default install is a sealed appliance — a backup receiver, a fixed server, a closed device — not a general container host. Overlay filesystems and user namespaces stay off on that baseline because they are the sandbox-bypass and privilege-escalation class the design removes. When you do need containers, two shipped paths cover them: the Container-host install for a long-lived, steady set of images, and Root Lock as the guest kernel inside a Firecracker microVM, a Kata Container, or a plain KVM or cloud VM for untrusted or disposable work.

Why Docker is not the default

Docker, containerd, Podman, and runc isolate processes on the host kernel. That stack needs OverlayFS and user namespaces. On a Standard-host install those primitives are compiled out — they are the attack surface, path to root, and bypass the allowlist model removes. See System Requirements.

A backup receiver that only accepts Restic over SFTP does not need Docker. The Container-host install and microVMs matter when a second job would otherwise force a shared-kernel runtime onto a sealed host.

What Firecracker and Kata are

Industry pattern: platforms that run untrusted or multi-tenant code put Firecracker or Kata under the workload. Everyday microservices still ship Docker/OCI images on a shared-kernel runtime. Firecracker is a trust badge for isolation, not a mass-market brand that replaces Docker.

Two shipped shapes

Container host — a long-lived set on this kernel

The installer detects Docker, containerd, Kubernetes, or CRI-O and offers a Container host or Standard host install. Container-host installs enable overlay filesystem support and adapt Setup Mode for container runtimes. You review the runtime, overlay mounts, and each image in the Dashboard queues, then engage Lockdown. Containers running at that moment continue. New containers, image pulls, and restarts after exit each need a maintenance window.

This is the path for long-lived service containers, Kubernetes nodes with a stable pod set, and batch jobs that finish before Lockdown. Continuous scheduling, autoscaling, and pod rescheduling after node loss are not a fit — Lockdown refuses the new mounts those moves need.

See Deployment Scenarios → Container hosts.

Guest — Root Lock inside the microVM

  Host (standard Linux or cloud VMM)
       │
       ▼
  Firecracker / Kata / KVM microVM
       │
       ▼
  Root Lock guest kernel
  Setup Mode → allowlist → Lockdown
  (known / trusted workload only)

Run Root Lock as the guest kernel inside a per-task virtual machine — a Kata Container, a Firecracker microVM, or plain KVM. Build the allowlist once: run a representative task in Setup Mode, review and approve the tools through the Dashboard queues, then bake that allowlist into the VM image. Each task VM boots from that image into Lockdown. The allowlist holds for the life of the task. Then the VM is gone.

An attacker who already has root inside the guest cannot turn this off. There is no LSM to unload, no userspace shim to detach, and no agent to kill. This is the path for AI agent sandboxes, fixed-tool automation, and disposable task VMs. See AI agent and automation sandboxes.

Root Lock is not a hypervisor host. Running Firecracker or Kata on a Root Lock kernel so this box becomes the VMM for untrusted tenants is not a supported configuration. KVM host mode is compiled out; the product protects workloads inside a kernel. See Where Root Lock is not a fit.

What to run

Comparison

Root Lock’s job is that programs only do what you approved. MicroVMs are an optional wall next to that seal.

Operator FAQ

Related pages

• Deployment Scenarios — fit / not-fit, AI guest VMs, container hosts
• System Requirements — deliberate omissions (eBPF, FUSE, overlay, KVM host)
• How Root Lock Compares — gVisor and enforcement peers
• FAQs — who it is for; container reference architecture