Cache Purge (Nginx)

Short definition

Cache purging is the process of invalidating and removing stored responses from a web server’s cache, forcing nginx to fetch and serve fresh content on the next request.

Extended definition

When nginx is configured as a caching reverse proxy, it stores responses from upstream applications on disk and serves them directly to subsequent requests without hitting the application server. This dramatically reduces latency and backend load, but introduces a consistency problem: if the underlying content changes, the cached version remains stale until it expires naturally or is explicitly purged. Cache purging is the mechanism for forcing immediate invalidation, either for a specific URL, a pattern of URLs, or the entire cache. In production environments, purging is triggered after content updates, deployments, or configuration changes that affect cached responses.

Deep technical explanation

nginx cache storage: nginx stores cached responses as files on disk under the path defined by proxy_cache_path. Each cached item is stored as a file with a name derived from the cache key, typically the request URL and selected headers.

Purge methods: nginx open source does not include a built-in purge endpoint. The common approaches are deleting cache files directly from the filesystem with find and rm, using the proxy_cache_purge directive available in nginx Plus, or using a third-party ngx_cache_purge module compiled into the binary.

Filesystem purge: The most portable approach on open source nginx is a targeted file deletion. A purge script identifies the cache directory, constructs the cache key hash for the target URL, and deletes the corresponding file. A full cache purge simply deletes all files under the cache directory.

Cache key design: How the cache key is constructed determines purge granularity. A key based only on URI allows single-URL purges. A key that includes cookies or headers requires matching those values to purge specific variants.

Purge in a fleet context: In a multi-server fleet, a purge operation must run on every server that may hold a cached copy of the target content. A central orchestration tool executing the purge command in parallel across the fleet is the only reliable way to ensure consistency.

How BlueGrid.io uses it

In BlueGrid.io’s nginx fleet, cache purge operations are executed centrally via the fleet management pipeline. When content is updated or a deployment is pushed, the agent identifies affected servers by tag, executes a targeted filesystem purge in parallel across all of them, and confirms completion before the deployment is considered done. This eliminates the window where some servers serve stale content, and others serve fresh.

Why it matters

Stale cache is one of the most common sources of confusion after a deployment or content update. Users on different servers see different versions of the same page. Support tickets arrive for bugs that were already fixed. Cache purging, done reliably and at scale, is what closes that gap.

Share this post

Share this link via

Or copy link