FTL 0.1 can run a multithreaded Tokio web server before it has its planned filesystem. That sequence sounds backwards until you look at the workload it is built for: short-lived cloud containers whose operating-system services live in a replaceable library. The October 3 release adds Linux threads, futexes and epoll, while the project roadmap puts filesystem work in November.
For developers, the immediate result is narrower than the phrase "new operating system for clouds" suggests. FTL can boot an x86-64 image, run an unmodified Linux binary and serve a real website from Google Compute Engine. It cannot yet take an ordinary container image and run a general production workload. Creator Seiya Nuta called the first release "very alpha quality", a label that still fits version 0.1.
That gap is part of the story. FTL is testing whether a small Rust kernel plus a different placement of familiar Linux machinery can make each container easier to change and harder to escape. Version 0.1 is useful evidence that the design can support a modern asynchronous runtime. It is not evidence that the security or performance goals on the project page have been met.
What version 0.1 actually runs
FTL's first tagged build, 0.0.1, appeared on September 15. Version 0.1 followed on October 3 with the system calls and primitives needed by a multithreaded Tokio runtime. The changelog in the repository names clone(2), futex, epoll, signals, TTY support, mmap, pipes and eventfd, along with a wall-clock API, lazy allocation of anonymous pages and x86-64 SMEP/SMAP hardening.
The most concrete demonstration is the project's own site. According to the 0.1 release note, ftl-os.org is served by a Tokio-based HTTP server running on FTL in Google Compute Engine. This is a better test than a boot screen or a hello-world binary because Tokio depends on threads, synchronization and event notification working together. The project does not publish request-rate or latency results, so the demo establishes compatibility, not speed.
Trying it locally is deliberately plain. The README asks for Rust, LLVM tools and QEMU, then reduces the first boot to these commands:
git clone https://github.com/nuta/ftl.git
cd ftl
./run.sh
A prebuilt ISO is also available. The v0.1.0 release provides a QEMU command that assigns 32 MB of memory and forwards a host port to the guest web server. That is an invitation to inspect an early system, not a supported deployment recipe. The public roadmap still lists container images, symmetric multiprocessing and 64-bit Arm support for January 2027.
Resource figures need careful reading at this stage. The September introduction reported a 100 KB kernel working in 2 MB of RAM, while the downloadable 0.1 ISO is roughly 18 MB because it contains more than the kernel alone. Neither number tells an operator how much memory a real service will need under load. Without published workload benchmarks, the small footprint is a design target rather than a sizing guide.
The operating system moves into each container
On Linux, processes ask one shared kernel to create processes, manage memory, handle files and move network packets. FTL keeps a much smaller kernel responsible for resources such as virtual CPUs, address spaces and virtual networking. A Linux compatibility library inside each container handles the familiar interface above it. The FTL design document says concepts including Linux processes, the virtual filesystem and TCP live in this userspace OS library.
When a Linux binary makes a system call, the FTL kernel redirects that event to the container's userspace OS handler. One container can therefore carry a different version of that library from another. In the project's proposed workflow, an operator could add tracing, change a TCP implementation or apply an OS-level fix by starting a new container rather than modifying the host kernel and rebooting the machine. The launch essay describes Linux as the first "personality" on this interface, with custom application kernels also possible.
The source tree makes this split visible. The public repository keeps low-level scheduling, memory, network multiplexing and architecture code under kernel/. Its lx/ directory contains the Linux personality, including process tables, file descriptors, futexes, signals and individual system-call handlers. The demo server lives separately under apps/httpd/. That layout does not prove the boundary is secure, but it gives developers specific code to inspect when the architectural diagram feels too neat.
This arrangement comes from a long-running operating-systems idea. The 1995 Exokernel paper from MIT proposed separating secure hardware multiplexing from higher-level abstractions supplied by library operating systems. FTL applies that split to cloud containers: the kernel supplies a narrow hardware-facing boundary, and a library reconstructs the Linux environment a workload expects. The lineage matters because the project is combining established ideas rather than claiming that library operating systems appeared in 2026.
FTL also resembles gVisor, though the layers sit in different places. gVisor's architecture guide describes a userspace application kernel called the Sentry that reimplements Linux system calls, process management, filesystems and networking while running over a host Linux kernel. FTL boots its own Rust kernel and uses ordinary CPU user mode to isolate a userspace OS instance. It aims to get a hypervisor-shaped boundary without requiring hardware virtualization.
That last sentence needs the word "aims." FTL says its smaller kernel interface should reduce attack surface and make containers as isolated as virtual machines, but the current materials provide no security audit or comparative benchmark. The repository is explicit about the tradeoff: processes inside one container share the userspace OS library and can interfere with it. Software such as Chromium, which expects process isolation between components, would need more protection. Intel Memory Protection Keys are mentioned as one possible future mechanism.
The device-driver design shows the same preference for a narrow core, with a limit. Virtio network support currently remains inside the kernel. Nuta's technical introduction says the driver is split into a small privileged Rust binary and a no_std, no-allocation library that receives an explicit I/O interface. This makes resource requests visible and much of the driver unit-testable, but the author also notes that Rust cannot rule out every implicit panic in dependencies. Memory safety improves the starting point; it does not turn unfinished isolation into a guarantee.
Why the filesystem comes later
Building thread and network support before a filesystem makes sense for stateless services. A request handler can accept traffic, compute a response and keep durable data somewhere else. Kubernetes already treats this as a normal workload shape: its ephemeral-volume documentation covers storage whose lifetime follows a Pod and data that applications do not need to preserve across restarts. FTL is prioritizing the execution path for that kind of service before filling out the rest of Linux.
The order also exposes the project's limits without much detective work. November's planned release is supposed to add a filesystem optimized for stateless workloads, dynamic creation of Linux userspace OS instances and a better sandbox for untrusted code. The published roadmap then targets Node.js and Go in December, followed by container images, SMP and Arm in January. Dates on a young OS are intentions, so each item should be judged when code and tests arrive.
Compatibility will be the harder test. Version 0.1 implemented enough Linux behavior for one Tokio server, but a drop-in cloud OS must deal with the strange assumptions accumulated across runtimes, language libraries and container tooling. gVisor's documentation points out the consequence of reimplementing Linux: if a kernel feature has not been recreated, the workload cannot use it. FTL inherits the same practical burden even though its lower layer is different, as the current list of implemented calls makes clear.
The November release is the useful checkpoint. A filesystem, dynamic container creation and stronger treatment of untrusted code would turn the present web-server proof into something developers can probe at the boundary FTL cares about. Until then, the telling detail remains the one at the start: Tokio runs, the site answers, and the operating system around it is still being assembled one Linux assumption at a time, in public, in the FTL repository.