CDN Caching is now built into Wasmer Edge (Beta)

A fast app should not regenerate the same public response for every visitor.

Yet without caching, every request travels back to the application—even when the answer has not changed.

Today, CDN Cache enters beta on Wasmer Edge. Wasmer Apps can now store eligible HTTP responses at the edge and reuse them for matching requests before they reach the application. The result is faster delivery for visitors and less work for your app.

Faster delivery, less work for your app

A CDN cache keeps reusable responses close to the people requesting them. When a fresh copy is available, Wasmer Edge returns it directly. Your app does not need to run the same code, read the same file, or repeat the same database query.

Serving repeat responses from the edge does more than shorten response times:

• Lower application costs. Cache hits avoid repeated compute and database work, reducing the resources—and cost—needed to serve repeat traffic.
• More room for traffic spikes. Cacheable repeat traffic is handled at the edge instead of adding load to the application.

Raising WordPress Hosting to the next level

WordPress is a natural fit for edge caching. A site may serve the same theme assets, media, and public pages thousands of times, while PHP and the database sit behind every uncached request.

WordPress apps on Wasmer now benefit from CDN caching when enabled in the settings. Public pages are cached automatically. Persisting an article automatically purges the cache.

Your app stays in control

Wasmer CDN Cache follows standard HTTP caching rules. Cache-Control or Expires determines whether a response can be stored and for how long. ETag and Last-Modified support revalidation, while Vary controls which requests may reuse the cached response.

Only GET and HEAD requests are eligible. Requests carrying authorization or cookies bypass the shared cache, as do responses that set cookies or return server errors. This makes it practical to cache public pages, assets, generated files, and public API responses while authenticated and personalized traffic remains dynamic.

One platform, no extra plumbing

Caching is usually somebody else's product. You sign up with another provider, put their network in front of your domain, keep their configuration in sync with your app, watch a second dashboard, and remember to invalidate their cache whenever you ship. That plumbing is where stale pages and surprise bills come from.

CDN Cache is part of Wasmer Edge, so there is nothing to bolt on:

• No extra provider to add. Caching ships with your app—no separate account, contract, or CDN layer in front of your domain.
• Deploys and caches stay in sync. Every new app version gets a clean cache namespace, so a release never serves content generated by an earlier build.
• Framework-aware by default. WordPress sites cache public pages and purge automatically when content is published, with no manual wiring.
• Purge from wherever you work. Clear the current cache from the dashboard, CLI, or API—the same tools you already deploy with.
• Metrics next to everything else. Cached and total requests appear alongside the rest of your app's metrics, so you can see how well the cache is working.
• One control plane. Deployment, caching, purging, and metrics all stay inside Wasmer, so there is no second system to reason about when something looks wrong.

Try it now

Ready to put fewer repeat requests on your application? CDN caching is available now. You can enable it in the app dashboard settings, with the CLI, or directly in app.yaml.

Read the CDN Cache documentation for more information.

What’s not in the beta: CDN Cache currently applies to the whole app, while individual responses opt in or out through HTTP headers. Advanced path rules such as “always cache this page” or “never cache this page” are not available yet, and purges clear the current app version’s cache as a whole. We plan to add advanced caching rules in a future release.