When people ask why a small CMS startup wrote its backend in Rust, the easy answer is "speed." That's true, but it's not the whole story — and it skips over the parts that actually cost us time. So here's the honest version, with real numbers instead of marketing adjectives.
The decision
Most CMS platforms are built on PHP, Node, or Python. Those are fine choices. We use Node and TypeScript on the frontend ourselves. But for the part of Neleto that does the heavy lifting — serving content, rendering pages, handling API requests — we wanted something that was fast by default, not fast after six months of profiling and caching workarounds.
The pitch for Rust was simple: predictable performance, low memory use, and a compiler that refuses to let a whole category of bugs into production. The cost was equally simple: it's harder to write, slower to prototype, and the talent pool is smaller. We went in knowing both.
The benchmarks
These are from our own staging environment running on a single Hetzner CX22 instance (2 vCPU, 4 GB RAM, Germany region). Same hardware, same content, same test. We measured time-to-first-byte and requests-per-second under load using wrk with 50 concurrent connections over 30 seconds.
| Metric | Neleto (Rust) | Typical PHP CMS* |
|---|---|---|
| Median TTFB (cached page) | 11 ms | 180–400 ms |
| Median TTFB (uncached, DB hit) | 34 ms | 250–600 ms |
| Requests/sec (single instance) | ~9,400 | ~400–900 |
| Memory under load | 78 MB | 350 MB–1.2 GB |
| Cold start | 0.3 s | n/a (always-on) |
*The PHP comparison is a stock install of a popular open-source CMS on the same hardware, no aggressive tuning. Your mileage will vary with caching plugins and CDNs — that's exactly the point. The Rust numbers are what you get before you add a CDN, not after.
The memory figure is the one that matters most for our economics. At 78 MB under load, we can run a lot of customer sites on one box. That's a big part of why we can charge €24/month and not lose money on it.
Where Rust actually paid off
Three places, concretely:
Page rendering. Neleto has built-in rendering, so we're not just shipping JSON to someone else's frontend. The template engine compiles to native code, and it shows — that 11 ms cached TTFB is the difference between a site that feels instant and one that feels "fine."
Concurrency without drama. The async runtime handles thousands of simultaneous connections without us hand-tuning worker pools. During the agentic-traffic spike we wrote about recently, the backend didn't flinch. Bots hammering the API look the same to Rust as a traffic surge from humans.
The compiler caught real bugs. Hard to put a number on this, but the count of "null reference in production at 2am" incidents since launch is zero. Some of that is luck. A lot of it is the borrow checker yelling at us before we shipped.
Where it hurt (the honest part)
Build-in-public means showing the bruises too.
Development was slower at the start. Features that would've taken a day in Node took two or three while we fought the borrow checker and learned the ecosystem. Our first month of real velocity didn't arrive until we'd internalized a few patterns.
Hiring is harder. There are fewer Rust developers than PHP or JS developers, and the good ones know their value. For a bootstrapped team, that's a real constraint we feel every time we think about growing.
Some libraries are still young. A few things that are one npm install away in the Node world required us to write more ourselves. That's time we didn't spend on customer-facing features.
Would we choose Rust again? Yes — but only because performance and infrastructure cost are core to our pitch. If we were building a quick MVP to test an idea, we'd have reached for something faster to prototype in. The right tool depends on what you're optimizing for, and we were optimizing for the thing customers feel on every page load and we feel on every server bill.
What this means for you
If you're evaluating a CMS, don't take "fast" on faith — from us or anyone. Run the test yourself. Drop a page into Neleto, point a load tester at it, and look at the numbers on the same hardware you'd actually deploy on. We'd rather you trust the benchmark than the brochure.
And if you're a founder weighing a "boring and fast to build" stack against a "harder but faster to run" one: there's no universal right answer. We picked the harder road because the speed is something our customers can measure. Make sure whatever you pick, the payoff is something your customers can feel too.
Try it yourself: Spin up a free Neleto project, publish a page, and benchmark it on your own hardware. If the numbers don't beat what you're running now, we want to hear about it.
Fast websites. Easy content. AI native.
Top comments (0)