Caching

Caching is built in and tuned on every plan — there’s no add-on to buy and no plugin to install and configure. Two layers do the work: a full-page cache in front of the FrankenPHP runtime that serves rendered pages without touching PHP, and a persistent object cache behind it that backs WordPress queries and transients. This page covers how each behaves, what gets cached or bypassed, and how to purge.

The two layers

Layer	Sits	Caches	Skipped for
Full-page cache	In front of the runtime	Rendered HTML responses for anonymous visitors	Logged-in users, POST requests, and non-cacheable routes
Object cache	Behind the runtime	Query results, transients, and other WordPress cache groups	Nothing — it’s a persistent backing store

Full-page cache

The full-page cache holds the rendered HTML for a URL and serves it directly to anonymous visitors. A cache hit never invokes WordPress, which is why it pairs so well with FrankenPHP’s worker mode: the warm PHP process is reserved for the requests that genuinely need it — misses, logged-in traffic, and dynamic endpoints.

Cached: GET responses for anonymous visitors on cacheable routes.

Bypassed: requests from logged-in users (the platform respects WordPress login and common auth cookies), POST/PUT/DELETE requests, wp-admin, and the typical non-cacheable surfaces (login, cart/checkout-style routes, the REST API, and anything your code marks no-cache via headers).

Logged-in users always get fresh pages

A request carrying a WordPress auth cookie bypasses the full-page cache and is served by the runtime, so editors and logged-in customers never see another user’s cached page.

Object cache

The object cache is a persistent store for WordPress’s internal caching — the results of expensive queries, transients, and cache groups that a page render touches. Without it, WordPress recomputes those on every miss; with it, a cache miss still runs PHP but is backed by a shared store instead of hitting the database for everything. It’s enabled and managed for you — there’s no object-cache.php drop-in to install.

Purging the cache

You can clear cached content by site/environment, by type (page or object), or by tag, from the dashboard, over SSH, or through the API.

Dashboard

The Cache panel for an environment in the app.managed.dev dashboard, showing a “Purge cache” control with options to clear the full-page cache, the object cache, or both, plus a field to purge a specific cache tag.

1. Open the environment in the dashboard and go to its Cache panel.
2. Choose what to purge — the full-page cache, the object cache, or both.
3. Optionally narrow to a tag to purge just the related entries instead of everything.
4. Confirm. The purge takes effect immediately for new requests.

WP-CLI

Over the SSH gateway, the standard WordPress cache commands work:

Purge caches over SSH + WP-CLI

# Flush the persistent object cache for this environment
ssh acme-store@ssh.managed.dev "wp cache flush"

# Flush rewrite + transient state
ssh acme-store@ssh.managed.dev "wp transient delete --all"

See WP-CLI for connecting and scoping commands to an environment.

API

Purge programmatically with the cache resource. The call returns a job you can tail.

Purge by type and tag

curl -X POST https://api.managed.dev/v1/environments/env_01J8.../cache/purge \
  -H "Authorization: Bearer mfk_live_..." \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{ "type": "page", "tag": "product-listing" }'

This needs a cache write scope; see cache & secrets for the endpoint, parameters, and the job envelope.

Purge by tag, not the whole site

When you update one section — say a product or a menu — purge the matching tag rather than flushing everything. A full purge means the next visitor to each page pays for a cold render; a tagged purge clears only what changed.

TTLs and configuration

The cache ships with sane defaults, so most sites need no tuning. Where you do want to override behavior — adjust page-cache TTLs or mark additional routes as bypass — you set it in your environment’s managed.dev config, which inherits down from the site to each environment. See config & secrets for where config lives and how inheritance works.

Default TTLs

Exact default page-cache and object-cache TTLs are tuned per platform release. Check the Cache panel for the values applied to your environment rather than assuming a fixed number here.

Next steps

The FrankenPHP runtimeThe application server the page cache sits in front of — and why worker mode and caching compound.

Config & secretsWhere TTLs and bypass rules live, and how config inherits to each environment.

Cache & secrets (API)Purge the cache by type and tag programmatically, with scopes and the job envelope.

Web vitals & performanceSee the effect of a cache hit vs a PHP-served request in your timings.