Cloudflare New Cache Proxy Pingora 2026: Asynchronous stale-while-revalidate Setup & Performance Guide

What You Will Learn

• What Cloudflare Pingora is and why Cloudflare moved beyond its older NGINX-based proxy infrastructure
• What the documented Pingora framework supports for HTTP, TLS, gRPC, WebSockets, and programmable proxy logic
• How stale-while-revalidate serves cached content while revalidation runs in the background
• How to test Cache-Control behavior without assuming that Cloudflare’s internal architecture is your deployment model

What is Cloudflare Pingora?

Cloudflare Pingora is an HTTP proxy framework built in Rust for Cloudflare’s networked services. Cloudflare describes it as an in-house system designed for its scale and customer-facing use cases. The public project is also available as an open-source framework for building programmable network services and proxies.

The important distinction is between Pingora as a framework and the products that Cloudflare operates with it. A developer can study the public repository and build a proxy or load balancer, but that does not mean an ordinary website can replace its CDN path with Cloudflare’s internal cache architecture. Your own behavior still depends on your origin headers, cache rules, plan features, and application design.

The official Pingora repository documents HTTP/1 and HTTP/2 proxying, multiple TLS options, gRPC, WebSockets, graceful reload, load balancing, failover, observability, and a memory-safety focus. It also marks the repository’s caching integration as experimental, so production teams should check the current documentation and test API stability before relying on it.

Why Cloudflare developed Pingora beyond NGINX

Cloudflare’s published explanation focuses on the limits it encountered at its own scale. In its earlier NGINX-based service, requests were tied to worker processes and connection pools were distributed across those workers. That model can create uneven load and make connection reuse less efficient when a system grows across many cores and origin connections.

Cloudflare also wanted a programmable platform that could handle its broad mix of proxy, CDN, Workers, Tunnel, Stream, and storage-related workloads. Its explanation says Rust offered memory-safety advantages compared with a large C-based codebase while retaining low-level control. Those are engineering reasons for Cloudflare’s architecture, not a blanket statement that NGINX is unsuitable for every reverse proxy deployment.

Cloudflare reported performance results in its Pingora announcement, including lower median and high-percentile time to first byte for the traffic it measured. These figures describe Cloudflare’s production environment. They should not be copied into a site’s performance forecast without a comparable test, because cache hit rate, origin distance, request mix, TLS behavior, and workload shape can dominate the result.

How Pingora differs from a normal website reverse proxy

A reverse proxy sits between clients and an origin server. It may terminate TLS, route requests, reuse connections, balance traffic, enforce limits, and record telemetry. A CDN adds another layer by caching eligible responses at edge locations. Pingora provides building blocks for programmable network services, while a managed Cloudflare zone exposes product controls that abstract away much of the proxy implementation.

This difference matters when reading claims about FL1, FL2, complete cache migration, or the percentage of networks using a particular proxy. Such labels may describe an internal rollout or a dated announcement. They are not settings that a website owner can enable by copying a line into a configuration file. For customer work, use the controls and response headers visible in the current dashboard and documentation.

Teams evaluating a programmable proxy can compare these tradeoffs with our guide to agentic AI systems, which uses the same principle of separating a platform’s documented capability from a product’s specific implementation. The comparison is useful because both infrastructure and AI articles often turn internal architecture into an unsupported universal promise.

What asynchronous stale-while-revalidate means

stale-while-revalidate is a Cache-Control directive set by an origin server. It allows a shared cache to serve an expired response for an allowed window while it fetches or validates a fresh response in the background. The directive does not mean that every expired object can be served indefinitely, and it does not override stricter directives such as must-revalidate or no-cache.

Cloudflare’s cache documentation describes the sequence clearly. After an object expires, the first request can trigger background revalidation and receive the stale object with an UPDATING status. Other requests can receive the same stale response while the origin is checked. After revalidation completes, later requests can receive a fresh response with a HIT status.

Revalidation can use validators such as ETag and Last-Modified so the origin does not need to send the whole object when the cached representation is still current. If the origin provides no usable validator, the cache may need to perform a more complete fetch. The exact result should be confirmed from response headers and Cloudflare’s current cache documentation.

For a broader view of how product behavior changes over time, compare this topic with our review of AI search changes. In both cases, a dated rollout note should be separated from a durable protocol or product concept.

How to configure stale-while-revalidate at the origin

Start with the response that your origin sends for the asset. A simple illustrative header might look like this:

Cache-Control: public, max-age=3600, stale-while-revalidate=86400

This example says that the response can be considered fresh for the stated max-age and may then be served stale during the stated revalidation window. The numbers are examples, not a recommendation for every site. Choose them according to content volatility, privacy, user impact, and rollback needs.

Do not add public caching to personalized pages, account screens, payment flows, or responses containing private data. Review Vary headers, cookies, authorization behavior, cache keys, and purge procedures. A stale response can be acceptable for a public article or asset, but it may be dangerous for a dashboard, inventory count, or security-sensitive result.

When Origin Cache Control is enabled, directives including must-revalidate, proxy-revalidate, s-maxage, and no-cache can prevent Cloudflare from serving stale content. Read the current Cloudflare Cache-Control documentation before combining directives.

How to verify the behavior safely

Use a test URL or a low-risk public asset first. Record the origin response headers, then request the same URL more than once while observing cache status, age, ETag, Last-Modified, and any UPDATING or EXPIRED result. Test after expiry rather than assuming that a browser refresh has caused a cache revalidation.

Compare a cache hit, a cache miss, and a stale response during revalidation. Check that a purge or versioned URL produces the expected new representation. If the result differs by region, review cache rules and tiered-cache behavior before changing application code.

Keep a rollback path. If users receive an incorrect public asset, shorten the cache window or purge the affected URL. If private content is cached, treat it as a security incident and investigate cache keys, authorization headers, cookies, and downstream copies immediately.

For edge workloads that include AI inference, our Cloudflare Workers AI article provides a related platform overview. For broader infrastructure decisions, our AI agent versus assistant comparison illustrates why capability claims should be tied to the exact product and environment.

Common mistakes to avoid

• Presenting a Cloudflare internal migration date or network percentage as a customer configuration requirement
• Assuming stale-while-revalidate works without the origin directive or without checking stricter Cache-Control directives
• Caching personalized responses because a generic public asset example looked successful
• Using old performance figures as a current guarantee for a different origin, region, or request mix
• Treating the open-source Pingora cache modules as stable production APIs without checking their current status

A useful review process separates the protocol, the managed product setting, and the vendor’s internal implementation. That makes the article easier to maintain and reduces the risk of turning a dated announcement into operational advice.

Conclusion: use the documented behavior, not the headline

Cloudflare Pingora is a substantial Rust-based proxy framework designed for programmable, high-scale network services. Its design addresses concerns that Cloudflare identified in its older infrastructure, while the public repository gives developers a way to study and build related proxy services.

For website owners, the practical lesson is narrower. Configure and test Cache-Control at the origin, verify the response headers, protect private content, and treat stale-while-revalidate as a controlled caching behavior rather than a promise of zero latency. Review current Cloudflare documentation whenever rollout status or product settings matter.

Readers comparing infrastructure tools can also see our article on AI carbon accounting for an example of separating a technical capability from its governance and measurement context.