Yeap CDN's new edge: why we chose Rust

Over the past year we have moved the Yeap CDN edge from OpenResty (nginx plus Lua) to an in-house edge written in Rust and built on Pingora, the proxy framework open-sourced by Cloudflare. The new edge now carries most of our traffic, and the remaining nodes are being switched over on schedule.

This post skips most of the internals and answers one question: what does the new edge mean for your website?

Why we changed

The old edge combined nginx configuration, Lua scripts, C modules and an embedded JavaScript engine. It was fast, but every per-domain feature had to be changed in several layers at once, and a mistake in configuration often failed silently instead of raising an error. As the feature set grew, we needed a more unified and dependable foundation.

We chose Rust for three reasons:

• Memory safety. Buffer overflows and dangling pointers, the most common source of crashes and vulnerabilities in C code, are ruled out by the language itself.
• Strongly typed configuration. Every domain's configuration is validated when it reaches a node. A misspelled field or wrong type is rejected explicitly instead of being ignored.
• Testability. The whole edge is a single-language program covered by more than a thousand automated tests that run before every release.

What you will notice

Faster connections

The new edge supports HTTP/3 (QUIC), which holds up better on mobile networks and lossy links. TLS session tickets survive node restarts, so returning visitors can skip the full handshake and see the first screen sooner.

Configuration that applies in seconds

When you change cache, firewall or page rules in the console, the new configuration reaches every edge node within seconds and is swapped in atomically. Requests already in flight finish on the old configuration, new requests use the new one, and no node restarts or drops connections.

Precise cache control

Cache keys can normalise, sort, allow-list or block-list query parameters. A purge can target a single variant with specific parameters, or clear every variant of a path at once.

Security at the edge

WAF rule sets, rate limits, bot fingerprinting and geo and IP rules all run on the edge, so malicious requests are stopped before they reach your origin. Every block is logged with the rule that triggered it.

Edge functions with real isolation

Edge Workers run in separate WebAssembly sandboxes, each execution with its own memory and a strict CPU time limit. A misbehaving script from one customer cannot affect others or take down a node.

How fast is it?

Under realistic browser traffic (TLS, HTTP/2 and compression), the new edge delivers higher throughput and better tail latency than an equivalently configured nginx. The main reason is that it caches compressed content directly, so a cache hit does not need to be compressed again.

To get there we did not treat Pingora as a black box. We customised it deeply and optimised the cache-hit path, the hottest path on any CDN.

A transparent migration

The old and new edges share the same control plane and the same configuration, and the access-log format matches field for field. You do not need to change anything: your domains, certificates, cache rules and firewall rules carry over automatically.

What's next

The new edge makes many things possible that were hard to build before. Upcoming posts cover how we implemented HTTP/3 and TLS session resumption, how cache purge works down to individual variants, and how our DNS assigns nameservers to your zone.

If you have not tried it yet, add a site in the console. The free CDN plan already runs on the new edge.