NearlyFreeSpeech.net is not the kind of hosting company that makes impulsive architectural decisions. They have been running the same fundamental business model since 2002: pay for what you use, no contracts, no frills, and a technical blog that reads like it was written by people who actually know what they are doing. So when they published a detailed writeup of rewriting their C++ frontend infrastructure in Rust, it is worth treating as a serious data point rather than just another entry in the ecosystem’s growing list of rewrites.
The angle that interests me is not that they chose Rust. By 2026, that part of the argument is largely settled. The interesting part is what “frontend infrastructure” means in the context of a multi-tenant hosting provider, and why that specific context makes memory safety guarantees matter more than they would for a typical internal service.
What “Frontend Infrastructure” Actually Means Here
In web development circles, “frontend” usually means browsers and JavaScript. In a hosting company’s infrastructure, it means something closer to the opposite: the layer of software that sits between the public internet and thousands of customer applications. This is the code that terminates TLS connections, parses HTTP requests, figures out which customer account owns this domain, applies per-account configuration, and routes traffic to the appropriate backend. It touches every byte of every request before any customer application sees it.
C++ has been a reasonable choice for this kind of work for decades. It is fast, gives you precise control over memory layout and allocation, and has a mature ecosystem for systems programming. The problem is that it requires you to be correct about memory management everywhere, always, and the penalty for being wrong is typically a security vulnerability rather than a crash.
For a hosting provider, the threat model is more demanding than for most infrastructure. You are not just handling traffic from the internet in aggregate; you are handling traffic directed at thousands of individual customer applications, some of which may themselves be serving untrusted content, running buggy code, or be the target of active attacks. The parsing layer has to be robust against everything. A use-after-free in the HTTP header parser is not an internal bug; it is a potential privilege escalation across customer boundaries.
What C++ Gets Wrong That Rust Gets Right
The specific failure modes that Rust eliminates are worth being precise about, because the discussion often collapses into “memory safety good” without explaining the mechanism.
In C++, the most dangerous class of bugs involves object lifetimes. A string_view pointing into a request buffer that gets reallocated, a reference to a connection object that gets closed and freed while a callback is still holding it, a pointer stored in a hash table that outlives the structure it was pointing into. The compiler does not catch these. Sanitizers like AddressSanitizer catch many of them at runtime, but only if the buggy code path is exercised during testing, which is not guaranteed for edge cases in a parser.
Rust’s ownership and borrowing system makes these bugs impossible to express. A reference cannot outlive the thing it references; the compiler verifies this statically. You can still write unsafe blocks, and they appear at FFI boundaries and in certain low-level data structures, but the surface area is small and explicit. Auditing unsafe code is tractable in a way that auditing all of C++ for lifetime bugs is not.
The data from other large systems migration supports this framing. The Android team reported in 2022 that memory safety vulnerabilities, which historically represented around 70% of Android’s high severity security bugs, dropped to zero in code written in Rust. Microsoft has published similar figures for Windows components. These are not small projects, and the consistency across organizations suggests the result is real rather than selection-effect noise.
Cloudflare’s Pingora and the Prior Art
The most prominent precedent for this class of rewrite is Cloudflare’s Pingora, published in 2022. They replaced their Nginx-based proxy infrastructure with a Rust implementation handling over a trillion requests per day. The reported results were significant: CPU usage dropped by roughly 70%, and memory usage was cut to about a third of the Nginx baseline. Connection reuse improved substantially because they were no longer constrained by Nginx’s process model.
What Cloudflare’s scale makes visible is that the performance characteristics of Rust’s zero-cost abstractions are real at the systems level. Rust does not add runtime overhead for safety checks the way a garbage-collected language does. The bounds checks on slice accesses are the main runtime cost, and they are cheap enough that the cache efficiency and allocation patterns tend to dominate.
NearlyFreeSpeech is operating at a different scale than Cloudflare, but the threat model is similar in structure: diverse, untrusted traffic, customer isolation as a hard requirement, and a parsing layer that must be robust against adversarial input.
The Async Question
A rewrite of HTTP infrastructure in Rust in 2025 or 2026 necessarily involves async Rust, and it is worth acknowledging that async Rust is genuinely complex. The Tokio runtime is mature and production-proven; Hyper handles HTTP parsing and framing with careful attention to the spec. But the programming model around async fn, Pin, Send bounds, and the recent stabilization of async functions in traits in Rust 1.75 requires understanding that takes time to develop.
Before 1.75, writing async-capable trait objects required either the async-trait proc macro crate, which boxes every future, or manual desugaring with associated types and explicit Pin bounds. The ergonomics were bad enough that many production systems just avoided dynamic dispatch in async contexts entirely and paid the cost in code duplication. Since 1.75, the situation is substantially better, though the full story around return-position impl Trait in traits still has edges.
For infrastructure code specifically, the ownership model helps more than it hurts. Long-lived connections with complex state machines, where a connection might be in one of a dozen states and you need to ensure that state transitions are always valid, map well onto Rust’s type system. You can encode valid states as enum variants and invalid transitions as type errors rather than runtime panics.
The Build and Maintenance Story
One aspect of C++ to Rust rewrites that gets less attention than it deserves is the toolchain improvement. A mature C++ codebase that has grown over a decade typically has a build system of corresponding vintage. CMake, or something older, with layers of find-package scripts, platform conditionals, and vendored dependencies that have never been cleanly updated. Dependency management in C++ has historically been a manual or near-manual process.
Cargo is not perfect, but it is a massive improvement in ergoverience. Dependency declarations in a single file, reproducible builds via the lockfile, built-in test runner, integrated benchmark support, and first-class cross-compilation. For a small team maintaining production infrastructure, reducing the cognitive overhead of the build system has real value.
The other maintenance factor is the Rust compiler’s error messages. The learning curve is real, but once you are past it, the compiler tells you what is wrong in enough detail that you can usually fix it without reaching for documentation. That is a different experience from a C++ compiler telling you that a template instantiation failed seventeen levels deep with a message that requires working backwards from the end.
What This Signals for C++ Infrastructure
A rewrite of this kind is expensive. It requires a team to develop Rust proficiency while maintaining the existing system, plan a migration that does not disrupt production, and accept a period where new features wait while the underlying layer is being rebuilt. Companies do not do this because Rust is trendy. They do it because the accumulated cost of maintaining correct C++ at a security boundary has exceeded the cost of replacing it.
For hosting infrastructure specifically, that calculation tips earlier than it would for, say, an offline data processing system. The parser sits directly on the attack surface. Every edge case in HTTP handling, every unusual header combination, every malformed request, is something the parser sees before any other system does. Getting that parser wrong has immediate, user-visible consequences in a multi-tenant environment.
NearlyFreeSpeech’s rewrite joins Cloudflare’s Pingora and a growing list of similar projects as evidence that Rust is a viable, production-proven choice for systems that were previously C++ territory. The case is no longer theoretical.