FTL Bets on Isolating Containers Like a VM

⏱️ Reading time: 15 min

FTL ran its first real application, an HTTP server written in Rust and compiled for Linux, in September 2026, using a userspace kernel that amounts to a fraction of the code of a conventional operating system. It demonstrated this on its own site, ftl-os.org.

📑 En este artículo

1. TL;DR
2. What Is a Userspace Kernel?
3. Why FTL’s Library Operating System Matters
4. How FTL’s Userspace Kernel Works
   1. The Trick: User-Mode Isolation, Not Hypervisor Isolation
   2. A Syscall’s Path Inside FTL
5. Practical Examples with FTL’s Userspace OS
   1. Getting Started
6. Real Use Cases for a Library Operating System
7. Common Mistakes and Best Practices
8. Comparison: FTL vs. Containers, VMs, and Microkernels
9. Going Deeper: The Internal Design of the Userspace Kernel
10. Frequently Asked Questions
    1. Does FTL Replace Docker or Kubernetes?
    2. Do I Need Special Hardware to Run a Userspace Kernel Like FTL’s?
    3. What Applications Can I Run on FTL Today?
    4. Is FTL a Microkernel?
    5. When Will FTL Support Other Languages Besides Rust?
11. References

It’s proof of an unusual design. FTL moves almost the entire operating system into a library that runs in user space and leaves the kernel to do the bare minimum: this isolates containers with the security of a virtual machine, without paying the cost of booting a full VM.

TL;DR

• A userspace kernel moves the operating system into a library that runs alongside the app.
• FTL isolates containers using the CPU’s user mode, without requiring virtualization hardware or bare metal.
• Linux binaries run unchanged: FTL translates their syscalls into a minimal vCPU, memory, and driver interface.
• The official roadmap sets filesystem support for November 2026, and Node.js and Go for December.
• Updating an FTL container’s system means recompiling a library, not patching the shared kernel.

What Is a Userspace Kernel?

A userspace kernel is an operating system layer that implements processes, filesystem, and networking inside a library that runs alongside the application, not in the privileged core. FTL uses it to isolate containers with a CPU’s user-mode isolation, without bare-metal machines.

The idea isn’t new on paper: unikernels and microkernels have spent decades moving logic out of the shared core. What changes with FTL is execution: each container runs its own library operating system, compiled alongside the application, and the FTL kernel limits itself to handing out virtual CPU, memory, and device access, the way a hypervisor would.

Why FTL’s Library Operating System Matters

A normal container shares the host’s Linux kernel with every other container on the machine. If an attacker finds a bug in any of the hundreds of syscalls, network subsystems, or drivers that kernel exposes, they can escape the container and touch whatever runs next to it. That’s why high-risk multi-tenant services prefer full virtual machines over plain containers: a VM isolates with its own guest kernel, at the cost of booting an entire operating system per workload.

FTL bets on closing that gap without paying the VM’s price. Instead of relying on namespaces and cgroups, the mechanisms Docker and Kubernetes use to separate processes within a single kernel, each FTL container brings its own library operating system. If that code has a bug, the damage stays contained within the same container: the FTL kernel never delegates privileged memory or device operations to it, it only gives it a minimal interface to request them.

This also changes how a container’s operating system gets updated. Patching a host’s Linux kernel means coordinating a reboot or using live-patching mechanisms. Patching the library operating system of an FTL container, by contrast, means recompiling a library and redeploying the binary, the same workflow already used for the application.

How FTL’s Userspace Kernel Works

The project’s official diagram sums up the idea in two columns. On the left, Linux: every process calls the kernel through syscalls, and that kernel concentrates process, memory, network, and device handling in a single privileged space. On the right, FTL: every process calls its own library operating system, which in turn uses a minimal interface from the FTL kernel to request vCPU, memory, and drivers.

flowchart TD
subgraph FTL["FTL Architecture"]
    A1["Linux Process"] --> U1["Userspace OS: VFS, TCP/IP, processes"]
    A2["Linux Process"] --> U2["Userspace OS: VFS, TCP/IP, processes"]
    U1 --> K1["FTL Kernel: vCPU, memory, drivers"]
    U2 --> K1
end
subgraph LINUX["Traditional Linux Architecture"]
    B1["Linux Process"] --> L1["Linux Kernel: process, fork/exec, TCP/IP, drivers"]
    B2["Linux Process"] --> L1
end

The Trick: User-Mode Isolation, Not Hypervisor Isolation

Here’s the nuance that sets FTL apart from projects like Firecracker or Kata Containers. Those systems use hardware virtualization extensions (VT-x on Intel, AMD-V on AMD) to run a full guest kernel inside a microVM. FTL does something lighter: it uses the same protection ring mechanism that already separates user processes from the kernel on any modern CPU. Each container’s library operating system runs in user mode, the same way an ordinary application would, and only the FTL kernel needs real privileges.

That’s why the project claims a bare-metal machine isn’t needed: if a cloud already offers a normal VM with a Linux kernel, FTL can run inside it without requiring nested virtualization. The separation between containers doesn’t depend on trusting that each library operating system behaves well; it depends on the CPU preventing user-mode code from touching memory or devices that don’t belong to it.

A Syscall’s Path Inside FTL

When an unmodified Linux application calls write(), that syscall never reaches the real Linux kernel. It’s intercepted by the container’s library operating system, which implements its own version of the VFS and the TCP/IP stack. If the operation needs new memory or access to a driver, the library operating system requests it from the FTL kernel through the minimal interface (vCPU, memory, drivers) the project describes.

sequenceDiagram
participant App as Linux Application
participant OS as Userspace OS
participant Kernel as FTL Kernel
participant HW as CPU in user mode
App->>OS: write syscall
OS->>Kernel: vCPU and memory request
Kernel->>HW: executes in isolated user mode
HW-->>Kernel: operation result
Kernel-->>OS: delivers the result
OS-->>App: syscall return

The result is that a normally compiled Linux binary, like the Rust HTTP server FTL uses to serve its own site, runs without recompiling and without knowing its userspace kernel isn’t the real Linux. The project also allows unikernel-style applications that don’t even use POSIX abstractions, for workloads that don’t need full compatibility.

📌 Note: FTL doesn’t replace hardware virtualization, it avoids it. By using only the protection rings any x86-64 CPU already offers, it doesn’t depend on VT-x or privileged access to the host hypervisor.

Practical Examples with FTL’s Userspace OS

The following sketch illustrates, for teaching purposes, what the minimal interface a library operating system would need to handle a write syscall might look like. This isn’t FTL’s official API, the project hasn’t published a complete reference yet; it’s a simplified model to understand the idea of intercepting the syscall before it reaches a real kernel.

// Conceptual sketch: this is what syscall dispatching might look like
// inside a library operating system on top of FTL
struct PeticionSyscall {
    numero: u64,
    args: [u64; 6],
}

fn despachar(req: PeticionSyscall) -> i64 {
    match req.numero {
        1 => vfs_escribir(req.args[0], req.args[1], req.args[2]),
        2 => proceso_fork(),
        _ => -38, // ENOSYS: syscall not implemented yet
    }
}

fn main() {
    let req = PeticionSyscall { numero: 1, args: [1, 0, 13, 0, 0, 0] };
    let resultado = despachar(req);
    println!("syscall returned: {}", resultado);
}

The despachar function receives the syscall number and its arguments, and decides whether to resolve it itself (as would happen with vfs_escribir, implemented inside the library operating system itself) or whether it needs to ask the FTL kernel for something. For a 13-byte write to descriptor 1, the expected output is: syscall returned: 13.

To compare with the mechanism most containers use today, this real Linux command shows the other end of the spectrum: isolation with namespaces, within the same shared kernel.

# Linux namespace isolation: the mechanism used by traditional containers
unshare --fork --pid --mount-proc bash

When you run it, the new shell sees its own process tree: a ps aux inside shows bash with PID 1, even though the kernel handling that syscall is still the same one as the host’s. That’s the central difference with FTL, where each container not only sees its own process tree, but implements it itself, in its library operating system.

Getting Started

FTL is at a very early stage (the first version, v0.0.1, came out in September 2026, and the next one, v0.1.0, with async support, in October 2026, according to the official roadmap), so there isn’t a stable production installation procedure yet. What you can do today, before cloning anything:

• Confirm your architecture: run uname -m. FTL currently runs on x86-64; 64-bit Arm support is planned for January 2027, not yet available.
• Check the roadmap status: the official page lists what runs in each version. As of this article, there’s confirmed support for async Rust applications on Linux (threads, epoll), without a persistent filesystem.
• Clone from the official source: the repository is linked from ftl-os.org. Since the build process changes with each version while the project is under active development, it’s best to follow the README of the cloned version instead of a fixed command.

⚠️ Heads up: there’s no filesystem support yet (arriving in November 2026), nor multiple cores per container (SMP arrives in January 2027). An FTL container today runs on a single virtual core with no persistent disk.

Real Use Cases for a Library Operating System

Today, with only a Rust HTTP server as a public demo, FTL doesn’t replace anything in production. But the design points directly at three scenarios where traditional containers fall short: multi-tenant platforms running code from clients that don’t know each other, serverless functions that need to start in milliseconds without the overhead of a full guest kernel, and low-memory edge environments where duplicating an operating system per workload doesn’t fit the RAM budget.

The closest comparison today is with gVisor and Kata Containers, two projects tackling the same problem from different angles. gVisor intercepts syscalls from a user-space process written in Go, without touching virtualization hardware, but reimplements the entire Linux kernel as a single component shared across containers. Kata, by contrast, does use a microVM with KVM per container, with the boot cost that implies. FTL sits between the two: it isolates per container like Kata, but without requiring hardware virtualization, like gVisor.

The public roadmap ties those scenarios to concrete dates. Node.js and Go arrive in December 2026, which would open FTL up to two of the most widely used runtimes in serverless functions. Container image and SMP support, planned for January 2027, is the step still missing to truly compete with the packaging Docker and Kubernetes already use.

Common Mistakes and Best Practices

The easiest mistake to make is thinking FTL already offers the full POSIX compatibility of a real Linux. That’s not the case yet: the project runs standard-compiled Linux applications as long as they don’t depend on features its library operating system hasn’t implemented yet, like a persistent filesystem.

Another common misunderstanding is confusing FTL’s isolation with that of a traditional hypervisor. It doesn’t use VT-x or AMD-V, it uses the CPU’s standard protection rings. This makes it lighter, but it also means its threat model depends on the FTL kernel itself having no bugs in that minimal interface: it’s a smaller surface than a full Linux kernel, not a zero surface.

On verification: as of this article, FTL hasn’t published a command or metric of its own to confirm from outside that a container is running isolated by the FTL kernel and not by some other mechanism. There’s no direct way to verify this from outside yet, beyond checking the kernel binary that was launched and confirming, through the official documentation, which version and which guarantees it offers.

Comparison: FTL vs. Containers, VMs, and Microkernels

The table summarizes when each isolation approach makes sense, with FTL’s library operating system as a fourth option between the already known extremes. The diagram below places those four options on a scale of increasing isolation, from a simple process to a full virtual machine.

flowchart LR
P["Simple process"] --> C["Container with namespaces"]
C --> F["FTL container: userspace kernel"]
F --> V["Virtual machine with hypervisor"]

Going Deeper: The Internal Design of the Userspace Kernel

The interface the FTL kernel exposes deliberately resembles a hypervisor’s: vCPU, memory, and drivers. But instead of using it to boot a full guest kernel the way KVM would, FTL uses it to boot something much smaller: a library operating system that only implements what that particular application needs.

This decision has a direct consequence on how the system is extended. Adding a new function to the real Linux kernel means writing C code inside the kernel tree, or relying on eBPF to inject logic without recompiling it. Adding a new function to an FTL container’s library operating system is writing normal application code: you can drop in a printf to debug, apply a security patch, and redeploy, without coordinating with anyone else sharing that kernel, because no one else shares it.

Memory management follows similar logic. A Linux kernel decides which physical pages to give each process and defends that assignment with the CPU’s paging unit. The FTL kernel does something similar, but one level down: it gives pages to each container’s library operating system, and that library operating system decides how to distribute them among its own internal processes.

The cost of that freedom is that each library operating system repeats work a shared kernel would normally centralize: its own TCP/IP stack, its own VFS, its own process handling. FTL bets that this repeated work, compiled alongside each application, costs less in performance than it seems, because the underlying FTL kernel is deliberately minimal: vCPU, memory, and drivers, nothing more.

Your next step: clone the repository linked at ftl-os.org, run uname -m to confirm your machine is x86-64, and follow the README of the latest version to spin up the example HTTP server that serves the project’s own site.

Frequently Asked Questions

Does FTL Replace Docker or Kubernetes?

Not yet. FTL solves isolation at the kernel level, but doesn’t currently offer the image packaging, registry, or orchestration that Docker and Kubernetes provide. The roadmap itself places container image support in January 2027.

Do I Need Special Hardware to Run a Userspace Kernel Like FTL’s?

No. Unlike Firecracker or Kata Containers, FTL doesn’t depend on VT-x or AMD-V. It uses the standard protection rings of any x86-64 CPU, which is why it runs inside a normal cloud VM without requiring nested virtualization.

What Applications Can I Run on FTL Today?

As of version v0.1.0, released in October 2026 according to the project’s roadmap, async Rust applications compiled for Linux that use threads and epoll, like the HTTP server serving ftl-os.org. There’s still no persistent filesystem or support for Node.js or Go.

Is FTL a Microkernel?

It shares the philosophy of moving logic out of the privileged core, but it doesn’t pass messages between servers like a classic microkernel. Each library operating system lives within the same address space as the application, not in a separate server.

When Will FTL Support Other Languages Besides Rust?

The official roadmap sets December 2026 for Node.js and Go. November 2026 comes first, with filesystem support, a prerequisite for many of those workloads.

References

• FTL: A new operating system for clouds: the project’s official page, with the architecture description and roadmap cited in this article.
• Unikernel (Wikipedia): context on the specialized operating system design that inspires part of FTL’s approach.
• Microkernel (Wikipedia): an explanation of the design FTL is often compared to.
• Protection ring (Wikipedia): the hardware mechanism FTL uses to isolate without depending on VT-x or AMD-V.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Patrick Martin en Unsplash