Why Cloudflare Replaced Nginx with Pingora: Faster, Safer, and More Efficient Backend Proxy

Introduction

Cloudflare announced last year that it would retire Nginx in favor of its home‑grown next‑generation proxy service Pingora, claiming it is faster, more efficient, and more secure.

Why Build a New Proxy

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

Architectural Limits Hurt Performance

Nginx’s worker‑process model locks each request to a single worker, causing load imbalance across CPU cores and slowing down heavy CPU or blocking I/O tasks.

Connection reuse suffers because each worker maintains its own connection pool; adding more workers spreads connections across isolated pools, reducing reuse efficiency and increasing handshake overhead.

Some Features Are Hard to Add

While Nginx excels as a web server and load balancer, Cloudflare’s needs go far beyond that. Adding capabilities such as per‑request header manipulation or custom retry logic would require extensive modifications to Nginx’s upstream code.

Moreover, Nginx is written in C and lacks memory safety guarantees, making it prone to bugs and crashes.

Choosing to Build Our Own

Cloudflare evaluated three options over several years:

Continue investing in Nginx with customizations, which would require massive effort to meet all needs.

Migrate to another third‑party proxy such as Envoy, but risk repeating the same cycle.

Build an internal platform from scratch, demanding the largest upfront engineering investment.

After repeated assessments, the team decided that creating a bespoke proxy offered the best long‑term ROI.

Pingora Project

Design Decisions

The project is written in Rust to achieve C‑level performance with memory safety. Instead of using existing Rust HTTP libraries like hyper, Cloudflare built its own library to maximize flexibility and enable rapid innovation.

Pingora must handle many non‑standard, RFC‑violating HTTP cases encountered on the open internet, requiring a tolerant and customizable HTTP stack.

The scheduler uses a multithreaded model with work‑stealing, allowing easy sharing of resources such as connection pools via the Tokio async runtime.

Pingora exposes a programmable request‑lifecycle API similar to Nginx/OpenResty, enabling developers to write request filters that can modify or reject requests.

Pingora Is Faster in Production

Pingora now handles virtually all HTTP requests that need to talk to origin servers. Performance data shows a median TTFB reduction of 5 ms and a 95th‑percentile reduction of 80 ms, mainly due to shared connection pools across threads and better connection reuse.

New connections per second are one‑third of the legacy service, and connection reuse for a major client rose from 87.1 % to 99.92 %, cutting new connections by a factor of 160 and saving an estimated 434 years of handshake time per day.

More Features

The developer‑friendly interface removes previous limitations, allowing rapid addition of core features such as new protocols. For example, HTTP/2 upstream support was added without major effort, paving the way for gRPC.

Cache Reserve, which uses Cloudflare R2 as a storage layer, is another new capability enabled by Pingora.

Higher Efficiency

Compared with the legacy service, Pingora reduces CPU usage by ~70 % and memory usage by ~67 % under the same traffic load.

Rust code runs faster than the previous Lua implementation, and the multithreaded model enables more efficient shared‑state access without heavy mutex contention.

Greater Security

Rust’s memory‑safety guarantees protect Pingora from undefined behavior, allowing engineers to focus on feature development rather than debugging crashes.

Since its launch, Pingora has processed billions of requests without a single crash caused by its own code.

Conclusion

In summary, Cloudflare has deployed Pingora as a faster, more efficient, and more flexible internal proxy platform that will serve current and future products. An open‑source release is planned after further maturation.