Caching on your sites

Caching is most of the reason your sites feel fast on BOA, and almost all of it works without you doing anything. But when you're building something of your own — a custom module with its own cache bin, a page that must never be cached, an expensive query you want to protect with a lock — you need to know how the layers fit together, what's guaranteed, and which dials are yours. That's this topic: the single home for everything caching on your sites.

The layers, from the outside in

A request to your site can be answered by any of four caching layers, and each one saves more work than the last:

1. The Nginx front cache ("Speed Booster") — a micro-cache in the web server itself. Anonymous visitors get pages straight from Nginx for a few seconds at a time, without PHP or Drupal running at all. Crawlers are held to much longer times than humans.
2. Drupal's page cache — full pages for anonymous visitors, stored in the fast object cache below, so even requests that miss the front cache rarely rebuild a page from scratch.
3. The Redis/Valkey object cache — every Drupal cache bin (menus, blocks, views, entities, and any custom bins your own modules define) lives in an in-memory store instead of the database. This is the layer with the most dials, and the most interesting guarantees. Drupal 8+ sites add a small per-worker APCu tier in front of it for the hottest bins.
4. PHP's opcache — compiled PHP code cached in memory, which is also why a change you deploy or a setting you save takes about a minute to show up.

Backdrop sites enjoy the same fast in-memory caching through a Backdrop-native integration BOA wires for them — but the Drupal-specific dials in this topic (the redis_* INI settings and the Redis lock) don't apply to Backdrop; see Your Backdrop site for how those sites are cached.

What's yours to tune — and what isn't

Everything you can change lives in the two INI control files you already know from Tuning — boa_site_control.ini for one site, boa_platform_control.ini for a whole platform. The caching settings themselves are documented on the pages of this topic, next to the behaviour they change; the mechanics of creating and editing the files are on Platform and site INI settings.

The sizing of the shared services — how much memory the Redis/Valkey instance gets, Nginx worker settings, opcache capacity — belongs to the server, which your host manages. If you believe your site needs more than the defaults provide, open a support request rather than hunting for a config file.

Seeing your site without caching

When you're developing, you often want the opposite of everything above — a view of the site that skips the caches. BOA gives you two tools, and neither touches what real visitors see:

• The .dev. preview URL. Add an alias with .dev. in the middle (say, www.dev.example.com) and requests through that name run in development mode: errors on screen, PHP's opcache re-checking your code instantly instead of once a minute, and the page-cache and aggregation settings BOA normally hardcodes handed back to you to toggle. On Drupal 8+ one small drop-in file additionally routes the render caches to a null backend, so your edits are never served stale. The full setup lives in Developing your site — it's a development-workflow tool, so that's its home.
• Per-request query switches. For a one-off uncached look at any page, append ?nocache=1 to the URL — that request skips the front cache and Drupal's page cache. Append ?noredis=1 and the request runs with the Redis/Valkey object cache off entirely (everything served from the database), which makes a handy with/without comparison when you're chasing a caching question. Both work for human visitors only, not crawlers, and affect only the request that carries them.

The pages in this topic

• The Redis/Valkey object cache — the deep one: how cache bins (including your custom bins) are routed, how sites are isolated from each other on the shared instance, how cache clearing and wildcard flushes behave, the Redis-backed lock, size limits, the automatic database fallback, and how to confirm it's all working — plus the full table of redis_* INI settings.
• The front cache & Drupal's page cache — the Speed Booster micro-cache TTL, why Drupal's own page cache stays on, and the right way to exempt a single URL from caching.
• PHP opcache & APCu — why changes take a minute to appear, what the per-worker APCu tier does on Drupal 8+, and the self-service graceful PHP-FPM reload that clears both.

Related

• Modules BOA manages — the caching helper modules (Entity Cache and friends) that BOA enables for you on Drupal 6/7 platforms.
• Something looks broken — the troubleshooting side: stale pages, blank pages, and when clearing the cache is the fix.
• Drush basics — drush @site cc all (Drupal 6/7) and vdrush @site cr (Drupal 8+) for clearing caches from your shell.