# FTL Cloud OS Ships: Linux Containers Get VM Isolation > Source: > Published: 2026-10-04 02:11:51+00:00 A new cloud operating system called FTL shipped v0.1.0 this week and hit 150+ points on Hacker News today. Built by Seiya Nuta, a Vercel engineer, FTL’s premise is direct: Linux containers share a kernel, and in 2026 that shared kernel is a documented liability. FTL’s answer is to give each container its own isolated [userspace OS instance](https://github.com/nuta/ftl) — while keeping full Linux binary compatibility. The project’s own website runs on FTL, served by an unmodified Rust HTTP server on [ftl-os.org](https://ftl-os.org/). ## The Problem Linux Containers Haven’t Solved Standard containers — Docker, containerd, whatever your runtime — package userspace binaries and libraries but share the host kernel. That design choice has always been a theoretical weakness. In 2026, it became a practical crisis. As of mid-September, 5,976 Linux kernel CVEs have been published this year alone. Exploit discovery is accelerating as AI tooling makes vulnerability research faster and cheaper. CVE-2026-80521 makes the stakes concrete. This Linux kernel use-after-free bug in the AF_UNIX socket subsystem lets an unprivileged process inside a container escape and gain root on the host — affecting every other tenant on that machine. It was fixed upstream on August 6. However, it remains unpatched in Ubuntu 26.04 LTS and Ubuntu 24.04 LTS as of late September. One CVE, one unpatched distribution, every container on every affected host exposed. That is the shared-kernel attack model running live, right now. **Related:** [Plugin4Shell: Your AI Coding Agent’s Plugin Store Is an RCE](https://byteiota.com/plugin4shell-your-ai-coding-agents-plugin-store-is-an-rce/) ## How FTL’s Cloud OS Actually Works FTL restructures the OS around a per-container model. The FTL kernel is minimal — hypervisor-shaped — providing only virtual CPUs, virtual address spaces, and virtual networking. It does not interpret Linux system calls directly; instead, it routes them to a userspace OS handler. That handler runs as a library inside each container’s own isolated memory space. The userspace OS library implements what Linux normally puts in the kernel: process management, VFS, TCP/IP, and Linux ABI emulation. Because it is a library, updating or patching OS behavior requires no kernel programming — same workflow as patching a userspace application. The Linux compatibility layer is also a library, which is why unmodified Linux binaries run without changes. Architecturally, FTL is closest to an exokernel: the kernel exposes hardware primitives, and userspace builds OS abstractions on top. Unlike MirageOS unikernels, FTL maintains kernel/user separation, making it far more practical for existing Linux software. ## Where FTL Stands Against gVisor and Firecracker Two solutions already address the shared-kernel problem in production. Google’s [gVisor](https://gvisor.dev/) intercepts system calls in userspace, reducing the syscall attack surface by roughly 85% — from around 450 kernel calls to about 70. [AWS Firecracker](https://firecracker-microvm.github.io/) goes further: it runs full microVMs via KVM, giving each workload its own kernel with hardware isolation and booting in approximately 125 milliseconds. AWS Lambda and Fargate both use Firecracker in production. FTL positions itself between these two: more isolation than gVisor, less overhead than Firecracker, and more programmable than either. The critical caveat is that no independent benchmarks comparing FTL to gVisor or Firecracker exist yet. The [Hacker News discussion](https://news.ycombinator.com/item?id=49944912) flagged this gap immediately — the community wants numbers, not just architecture diagrams. Those will come in later releases. For now, FTL’s architectural claim is coherent even without the data to prove it. ## What v0.1.0 Delivers — And What’s Still Missing v0.1.0 adds async Rust support: Linux threads, epoll, and the multi-thread Tokio runtime. That unlocks serious async workloads — most production Rust servers are async. However, filesystem support does not land until November 2026. Node.js and Go support follow in December. SMP, container image compatibility, and 64-bit Arm arrive in January 2027. Run arbitrary production workloads today? No. Run a Rust HTTP server as a working demo? Yes — the website proves it. The Vercel connection is worth noting. Nuta works at one of the largest serverless edge platforms in existence. Edge functions at that scale run untrusted code from thousands of customers on shared infrastructure — precisely the scenario where per-container OS isolation changes the risk model. If FTL matures into something production-grade, the deployment target is already obvious. That is the difference between a research project and a funded bet on a real problem. ## Key Takeaways - FTL v0.1.0 is live: a cloud OS where each container runs its own Linux-compatible userspace OS instance, eliminating the shared-kernel container escape model - The problem it solves is real: 5,976 Linux kernel CVEs in 2026 and CVE-2026-80521 still unpatched in Ubuntu LTS distributions - FTL sits between gVisor (syscall filtering) and Firecracker (full microVM) — stronger isolation than gVisor, less overhead than Firecracker, no production benchmarks yet - Current gaps: no filesystem support (November), no Node.js/Go (December), no container images (January 2027) — not production-ready today - Watch signal: the creator works at Vercel; if FTL ships production-ready before mid-2027, it changes how edge function isolation works