Backend Development 14 min read

Why Cloudflare Replaced Nginx with the Rust‑Based Pingora Proxy

Cloudflare abandoned Nginx for its own Rust‑written Pingora proxy to overcome performance, scalability, and feature limitations, achieving higher throughput, lower CPU and memory usage, better connection reuse, and enhanced security while supporting non‑standard HTTP use cases and enabling faster feature development.

Architecture Digest
Architecture Digest
Architecture Digest
Why Cloudflare Replaced Nginx with the Rust‑Based Pingora Proxy

Introduction

Cloudflare announced last year that it would retire Nginx and replace it with a self‑developed next‑generation proxy service called Pingora, claiming it is faster, more efficient, and more secure.

Why Build a New Proxy

As the world’s largest free CDN, Cloudflare processes over a trillion client requests daily. The existing Nginx‑based architecture could no longer meet performance, scale, and feature requirements.

Architectural Limits Harm Performance

Nginx’s worker‑process model assigns each request to a single worker, causing load imbalance across CPU cores and slowing overall speed.

This single‑worker lock leads to situations where heavy CPU or blocking I/O tasks on one request degrade the latency of others, especially affecting connection reuse. Nginx’s connection pool is per‑worker, so when the number of workers grows, connections become fragmented across isolated pools, reducing reuse efficiency and increasing hardware consumption.

Some Types of Functionality Are Hard to Add

While Nginx is an excellent web server and load balancer, Cloudflare’s needs go far beyond that. Adding features such as request‑header‑based routing for retries or failures would require extensive modifications to Nginx’s upstream code.

Furthermore, Nginx is written in C and lacks memory safety guarantees, making it prone to bugs and security issues. Lua extensions can mitigate some risks but suffer from performance penalties and lack of static type checking.

Choosing to Build Our Own

Over several years Cloudflare evaluated three options: continue investing in a customized Nginx, migrate to a third‑party proxy (e.g., Envoy), or build a brand‑new internal platform from scratch. The latter was ultimately chosen to achieve the best ROI and avoid repeated cycles of re‑engineering.

Pingora Project

Design Decisions

Pingora is written in Rust to combine C‑level performance with memory safety.

Instead of using existing HTTP libraries like hyper, Cloudflare built its own library to maximize flexibility and allow rapid innovation.

Because the internet presents many non‑RFC‑compliant HTTP cases, Pingora needed a tolerant, customizable HTTP stack capable of handling such traffic.

The runtime uses a multithreaded model with Tokio for asynchronous execution, enabling easy sharing of resources such as connection pools and implementing work‑stealing to avoid performance bottlenecks.

Pingora also provides a programmable request‑lifecycle API similar to Nginx/OpenResty, allowing developers to write filters that can modify or reject requests early in the processing pipeline.

Pingora Is Faster in Production

Pingora handles virtually all HTTP requests that require upstream interaction. Real‑world metrics show a median TTFB reduction of 5 ms and a 95th‑percentile reduction of 80 ms, mainly due to shared‑across‑threads connection pools that improve reuse and cut TCP/TLS handshake overhead.

Across all customers, Pingora creates only one‑third as many new connections per second as the legacy service, raising connection reuse from 87.1 % to 99.92 % for a major client—equivalent to a 160× reduction in new connections and saving roughly 434 years of handshake time per day.

More Features

Pingora’s developer‑friendly interface removes previous limitations, enabling rapid addition of core features such as new protocols. For example, HTTP/2 upstream support was added with minimal effort, paving the way for gRPC support—something that would have required substantial work in Nginx.

Recent additions include Cache Reserve, which uses Cloudflare’s R2 storage as a caching layer, unlocking previously impossible product offerings.

More Efficient

Under comparable traffic loads, Pingora consumes about 70 % less CPU and 67 % less memory than the legacy service. The gains stem from Rust’s higher execution efficiency and architectural improvements, such as direct string access to HTTP headers and lock‑free atomic reference counting for shared data.

Reduced connection churn also cuts expensive TLS handshake costs.

More Secure

At Cloudflare’s scale, rapid, safe feature delivery is challenging. Rust’s memory‑safety guarantees protect against undefined behavior, allowing engineers to focus on functional correctness rather than low‑level bugs.

Since Pingora’s inception, it has processed quadrillions of requests without a single crash caused by its own code, and observed failures have been traced to hardware or kernel issues rather than software bugs.

Summary

In summary, Cloudflare has internally deployed Pingora as a faster, more efficient, and more versatile proxy platform that will serve as the foundation for current and future products, with plans to open‑source it after further maturation.

performancebackend developmentRustHTTP proxyPingoraCloudflare
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.