Build1 publisher2 min readPublished
FTL's user-space kernel runs an unmodified Rust HTTP server without hardware virtualization
FTL ran an unmodified Rust HTTP server on its v0.0.1 user-space kernel in September, with no hardware virtualization underneath. Its claim of VM-grade isolation depends on the small shared kernel that every container still calls into.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Linux binaries run without changes because FTL translates their syscalls into that small vCPU, memory and driver interface.
- Firecracker and Kata Containers use VT-x or AMD-V to boot a full guest kernel in a microVM, whereas FTL relies on the CPU protection rings that already separate processes from a kernel.
- The project's official roadmap schedules filesystem support for November 2026 and Node.js and Go support for December 2026.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure The project diagram keeps drivers in the shared privileged FTL kernel, so a driver bug can still cross containers, the same kind of escape the write-up cites against plain Linux containers.
- capability If the design holds up, VM-style isolation becomes available on hosts that offer neither hardware virtualization nor bare metal, where microVM systems built on VT-x or AMD-V have nothing to run on.
- cost OS patching moves onto application pipelines, and a library OS fix protects a container only after its binary has been rebuilt and redeployed.
- decision Until the filesystem and runtime milestones land, platform teams can review only the architecture, so testing real workloads has to wait for those dates.
FTL adds no new hardware boundary. Each container's library OS runs in user mode, on the same side of the protection rings as any ordinary process [13][12]. What the design changes is how much code is shared across that line. A standard container reaches the host kernel through hundreds of syscalls, network subsystems and drivers, and the dev.to write-up notes that a bug in any of them can let an attacker out [8]. FTL drops the namespaces and cgroups that Docker and Kubernetes use to keep containers apart [16]. According to the write-up, a bug in a container's library OS stays inside that container. The FTL kernel never hands privileged memory or device operations to the library, only a minimal interface for requesting them [9].
Unikernels and microkernels have moved logic out of the shared kernel for decades [14]. Pairing that idea with a Linux syscall translation layer so that existing binaries run is good engineering [4]. It goes after the case the write-up describes, where high-risk multitenant services pick full VMs and pay to boot a whole OS for each workload [8].
The VM comparison holds only if the shared FTL kernel stays small and correct. The write-up says the user kernel is a fraction of the size of a conventional OS, but it does not give a line count, an interface count or an audit [1]. The project's diagram also puts drivers inside the FTL kernel [15]. Drivers are on the write-up's own list of ways out of an ordinary Linux container [8]. I would start any security review with that driver code and the request interface around it.
The evidence so far is one Rust HTTP server, run under v0.0.1 in September 2026 [1][11]. v0.0.1 is an honest version number. The filesystem milestone falls two months after the demo [1]. Compatibility depends on the syscall translation layer [4]. I'd expect most of the effort to go into that layer when the December runtimes arrive [5].
Patching moves to a different owner. Fixing a host's Linux kernel today means coordinating a reboot or using live patching [10]. Under FTL, an OS fix means recompiling a library and redeploying the binary through the pipeline the application already uses [6]. For teams that already rebuild images daily, I think this is an improvement. In a fleet with stale images, the fix reaches only the containers someone rebuilds [6].
What to watch
- Whether the November 2026 filesystem milestone ships on schedule, and which workloads beyond a single HTTP server it lets FTL run.
- Whether unmodified Node.js and Go binaries run in December 2026, which would test the syscall translation layer far harder than one Rust server.
- A published size, interface count or independent review of the FTL kernel, especially the driver code its diagram places on the privileged side.