How Hostney Handles WordPress Cache Purging Automatically

Nginx page caching is one of the most effective ways to speed up a WordPress site. When it works correctly, cached pages are served directly by Nginx from memory or disk without invoking PHP-FPM or touching the database. A cached response that takes 15 milliseconds replaces a dynamic response that takes 300-800 milliseconds. For a site handling concurrent traffic, the difference is not incremental – it is the difference between a server that handles load comfortably and one that runs out of PHP workers and returns 503 errors.

The problem is keeping that cache consistent. Every time a post is published, updated, or a comment is approved, the relevant cached pages need to be purged so visitors get fresh content. Stale cache means visitors see outdated content. Overly aggressive purging defeats the purpose of caching. Getting the balance right requires the caching layer and the application to communicate.

On a standard VPS, setting this up is a multi-step process. You configure Nginx cache zones, write a purge location block, choose or write a WordPress plugin that knows how to call it, handle Gutenberg’s duplicate save requests, and decide what to do about object caching on top of that. None of it is particularly difficult, but it all has to be wired together correctly and maintained as WordPress and Nginx are updated.

On Hostney, this is handled at the platform level. When you install the Hostney Cache plugin, the connection between WordPress and your Nginx cache is established automatically. There is nothing to configure.

Why Server-Level Caching Matters#

Before getting into how the plugin works, it is worth understanding why server-level page caching is fundamentally different from plugin-based caching.

WordPress caching plugins like W3 Total Cache or WP Rocket generate static HTML files and serve them through PHP or through .htaccess rewrite rules. This is faster than generating the page dynamically, but PHP still loads on every request to determine whether a cached file exists and whether it should be served. The WordPress bootstrap still runs, at least partially.

Nginx page caching operates at the web server level, before PHP is involved at all. When a cached page exists, Nginx serves it directly – the request never reaches PHP-FPM, never loads WordPress, never touches the database. The web server reads the cached response from disk (or memory, if the cache fits) and returns it. PHP workers remain available for requests that genuinely need dynamic processing: admin pages, WooCommerce cart and checkout, logged-in user sessions, and AJAX requests.

This is why server-level caching has an outsized impact on capacity. Each request that hits the cache is one fewer request consuming a PHP-FPM worker. On a hosting plan with a fixed number of workers, the cache hit rate directly determines how much concurrent traffic the site can handle before workers are exhausted.

On Hostney, Nginx FastCGI caching is built into the server configuration for every account. Cached pages are served with the X-FastCGI-Cache response header, which shows HIT for cached responses and MISS for responses that were generated dynamically. You can verify caching is working by checking this header in your browser’s developer tools or with a curl request.

What Gets Purged and When#

The plugin registers hooks for the events that matter:

• Post publish, update, and unpublish via  transition_post_status
• Post deletion
• Taxonomy term edits and deletions
• Comment approval and status changes

When any of these events fires, the plugin does not immediately call the purge endpoint. Instead it queues the affected URLs and executes the purge at WordPress shutdown , after the response has already been sent. This means saving a post does not block on the cache purge, which would add latency to every save operation in the editor.

Purge scope

The scope of each purge is calculated based on what changed. Publishing a post purges:

• The post permalink
• The homepage
• The RSS feed
• The sitemap
• Category, tag, and author archive pages associated with the post

Archive pages are purged by path prefix rather than exact URL, which covers paginated archive pages without needing to enumerate them. If you publish a post in a category with five pages of archives, all five pages are invalidated by a single prefix purge rather than five individual purge requests.

If more than 15 URLs and prefixes accumulate in a single request, the plugin falls back to a full cache clear rather than making dozens of individual requests. This threshold handles bulk operations – like importing posts or running a batch update plugin – where targeted purging would generate more overhead than simply clearing everything.

Gutenberg deduplication

Gutenberg sends multiple concurrent REST API requests when saving a post. Without handling this, a single save would trigger the same purge several times in parallel. The plugin prevents this with a short transient lock per post ID, so duplicate purge calls within a five-second window are deduplicated automatically. One save, one purge – regardless of how many REST API calls Gutenberg makes behind the scenes.

How the Purge Endpoint Works#

The purge request is sent to 127.0.0.1/.well-known/hostney-cache-purge with the Host header set to your domain. Calling localhost directly is intentional. Nginx on Hostney restricts the purge endpoint to internal requests only, so calling it via the public domain name would arrive from an external address and be blocked. By calling localhost with the correct Host header, Nginx matches the right server block and accepts the request.

The request body is JSON and supports three operations:

• Exact URL purge – removes specific cached pages by their full URL path
• Prefix purge – removes all cached pages under a path prefix (used for archives and paginated content)
• Full cache clear – removes every cached page for the domain

The WordPress plugin builds these payloads based on what changed and what WordPress knows about the post’s related URLs and taxonomy terms.

Because each Hostney account runs in its own container with isolated resources, the cache purge affects only your site’s cache. There is no shared cache pool where one account’s purge could affect another account’s cached pages.

Memcached Object Cache#

Page caching handles the external response – what visitors see. Object caching handles the internal database queries – what WordPress computes to build that response.

WordPress runs dozens of database queries per page load. Many of these queries fetch the same data repeatedly: site options, active plugins, theme settings, rewrite rules, user roles. Without a persistent object cache, WordPress re-fetches this data from MySQL on every single request, even when nothing has changed. With Memcached, the results are stored in memory and served in microseconds instead of querying the database.

The impact is most significant on pages that cannot be fully cached. WooCommerce cart and checkout pages, logged-in user dashboards, and WordPress admin pages all bypass page cache because they contain user-specific content. These pages still benefit from object caching because the underlying queries for site configuration, product data, tax rates, and shipping zones are the same across users and can be served from Memcached.

How it works on Hostney

If your Hostney account has Memcached available, the plugin detects it and manages the object-cache.php drop-in automatically. Each Hostney account runs its own Memcached instance over a per-user Unix socket at /var/run/memcached/memcached-{username}.sock . The plugin resolves your system username at runtime to find the correct socket path, so there is no socket path to configure manually.

Your Memcached instance is isolated to your account. Unlike traditional shared hosting where object cache entries from multiple accounts share a single Memcached instance and can evict each other, your cache entries persist until they expire or you explicitly flush them.

The drop-in is installed through the plugin’s settings page. Before installing, the plugin checks whether an object-cache.php file already exists and whether it was written by Hostney Cache. If another plugin, such as W3 Total Cache or WP Rocket, has installed its own object cache drop-in, the Hostney Cache plugin will not overwrite it unless you explicitly choose to replace it. This makes the plugin safe to install on sites migrated from other hosts that may have had a caching plugin configured.

On deactivation, the plugin removes only its own drop-in. A drop-in installed by another plugin is left untouched.

Installing the Plugin#

Download the plugin from GitHub and install it through the WordPress plugin uploader, or install it via WP-CLI over SSH:

wp plugin install https://github.com/hostney/hostney-cache/releases/download/v1.0.0/hostney-cache.zip --activate

The plugin requires PHP 7.4 or later and WordPress 5.0 or later. After activation, the Nginx cache purge connection is live immediately. If Memcached is available on your account, go to Settings > Hostney Cache to install the object cache drop-in.

There is also a Purge Cache button in the WordPress admin bar for manually clearing the full cache when needed. This is useful after bulk changes that the automatic purge hooks might not cover – like directly editing the database, importing content through a migration plugin, or changing theme settings that affect the layout of every page.

No Other Caching Plugin Needed#

Most WordPress sites install a caching plugin like W3 Total Cache, WP Rocket, or LiteSpeed Cache for two reasons: page caching and object caching. On Hostney, both are handled at the platform level.

Page caching is built into the Hostney stack via Nginx. Every WordPress site on Hostney gets full-page caching out of the box, with cache purging managed automatically by this plugin. There is no need to configure a caching plugin to generate static HTML files or manage cache headers. The cached pages are served at the web server layer, which is faster than any PHP-based caching solution because PHP is never loaded.

Object caching through Memcached is available on all Hostney plans. The plugin installs the object cache drop-in and connects it to your account’s Memcached instance automatically. WordPress core, plugins, and themes that use the wp_cache_* API will benefit from it without any additional configuration.

This means you can run WordPress on Hostney without any third-party caching plugin installed. Removing plugins like W3 Total Cache or WP Rocket also removes a common source of conflicts, stale cache issues, and compatibility problems that come with maintaining a separate caching layer on top of server-level caching. Fewer plugins means a smaller attack surface – one less thing that needs updating and one less potential vector for plugin vulnerabilities.

If you migrated to Hostney with a caching plugin still active, it is safe to deactivate and uninstall it. The Hostney Cache plugin will continue handling both page cache purging and object caching independently.

The one thing third-party caching plugins offer that this plugin does not is asset minification and concatenation of CSS and JavaScript files. If you rely on WP Rocket or W3 Total Cache specifically for minification, you can replace that functionality with a dedicated minification plugin, or disable it and test whether your site’s performance is acceptable without it. Nginx-level page caching typically makes the performance difference from minification less significant for most sites.

What This Replaces#

On a self-managed server, the equivalent setup involves:

• Writing Nginx  proxy_cache_path  and  proxy_cache_purge  directives
• Exposing a purge location block restricted by IP
• Installing and configuring a WordPress plugin that knows how to call it
• Handling Gutenberg’s concurrent save behavior yourself
• Separately configuring Memcached and writing or installing an object cache drop-in
• Maintaining all of it through Nginx and PHP version upgrades

On Hostney, the Nginx configuration is managed by the platform and the plugin connects to it automatically. The only step is installing the plugin.

The plugin is open source and the code is available on GitHub if you want to review how the purge logic and Memcached integration work before installing it.

Explore the hosting plans to see which plans include Memcached, or read more about how NVMe storage and container isolation work alongside caching to deliver consistent WordPress performance.