Cloudflare adds built-in cache for Workers without origin

Cloudflare has introduced a new caching layer for its Workers platform that removes the need for an origin server or separate cache setup. The feature, called Workers Cache, positions Cloudflare’s global cache directly in front of a Worker, allowing responses to be served from cache without invoking the Worker code on every request. Configuration is handled through a single line in the Wrangler configuration file, and caching behavior is controlled using standard HTTP Cache-Control headers. The cache is available to all Workers users regardless of plan tier and can be enabled immediately via Wrangler CLI or configuration updates.

How it works

Workers Cache operates as a tiered cache across Cloudflare’s network, automatically serving cached responses when available. If a request misses the cache, the Worker executes, generates the response, and populates the cache for subsequent requests. The system supports programmatic cache purging by tag or path prefix, allowing developers to invalidate cached content when underlying data changes. Cache keys are multi-tenant safe, and the cache follows the Worker across all entry points, including custom domains, workers.dev subdomains, service bindings, and Workers for Platforms tenants.

The feature is designed to address a long-standing limitation for server-rendered applications built on Workers. Previously, developers had to choose between prerendering content at build time—resulting in slow redeploys for large sites—or rendering every page on every request, which incurred latency and CPU costs. Workers Cache introduces a third option: server-rendering on demand, caching the rendered response, and refreshing it based on a configurable time-to-live (TTL). This approach eliminates build-time delays while reducing the computational overhead of rendering identical responses repeatedly.

Performance and cost implications

The new cache layer is expected to reduce both latency and CPU usage for server-rendered applications. When a request hits the cache, the Worker does not execute, and no CPU time is billed. Cloudflare estimates that for high-traffic sites, this could significantly lower operational costs, particularly for applications with large, frequently accessed content libraries. The system also supports the stale-while-revalidate directive, which allows Cloudflare to serve stale content immediately while refreshing the cache in the background. This ensures that users rarely experience cache-miss latency, even when content is being updated.

Framework compatibility and use cases

Workers Cache is framework-agnostic and works with any application built on Cloudflare Workers, including those using Astro, TanStack Start, Next.js, Remix, and SvelteKit. These frameworks already ship with Cloudflare adapters that compile applications into Workers, and the new cache layer integrates seamlessly with them. The feature is particularly beneficial for content-heavy sites such as e-commerce platforms, documentation hubs, and blogs, where rendering costs can accumulate quickly under high traffic.

Cloudflare has also emphasized the cache’s support for content negotiation via the Vary header, allowing the same URL to serve different representations (e.g., HTML for browsers, JSON for APIs, or localized content) while maintaining separate cached versions for each variant. This makes the feature suitable for applications with dynamic or personalized content that still benefit from caching at the edge.

What’s next

Cloudflare has not announced specific roadmap items for Workers Cache but indicated that the feature is part of a broader effort to improve the platform’s support for server-rendered applications. The company has previously stated that it views Workers as a full-fledged application runtime, not just a request transformation layer, and the new cache layer aligns with that vision. Future updates may include additional cache control primitives or deeper integration with Cloudflare’s other edge services, such as Durable Objects or R2 storage.