Transloadit

What is an Image Cache Server?

An image cache server stores previously requested source or transformed images near their consumers. Later requests can use the stored response instead of retrieving the origin asset or repeating its transformation.

How Image Cache Servers work

An image cache server maps a request identity to stored image bytes and response metadata, serving the result without repeating upstream work. It may cache originals, resized derivatives, or both, at a regional edge or within the transformation service. Freshness rules, validators, and explicit invalidation determine when stored content is reused. This layer sits between image URLs and origin storage, reducing transformation pressure and shortening delivery paths.

Key facts

  1. Does an image transformation service cache its own output? Not necessarily, so check before assuming repeat requests are cheap. imgproxy’s maintainer has said the open-source server does no caching by design and leaves that to CDNs and caching servers; its Pro edition documents an optional internal cache and still calls a CDN in front of imgproxy the best practice. Cloudflare’s image transformations cache each transformed result at the edge and also cache the original to speed up later transformations of the same source.
  2. What has to be in the cache key? Everything that changes the bytes: the source image, every processing option, and the output format, which is what imgproxy’s internal cache key is built from. When the format is chosen from the request’s Accept header instead of the URL, the URL no longer identifies the bytes. An HTTP cache then keeps the variants apart only if the response names that header in Vary, or if the CDN or caching proxy is configured to key on it. CDN features for this come with conditions: Cloudflare’s Vary for Images is offered on Pro, Business, and Enterprise plans and works only when the origin sends Vary: Accept, the image URL has a supported file extension in its path, and the variants the origin serves are configured; its custom cache keys, which can include Accept, are Enterprise only. imgproxy warns that headers cannot be signed, so a caller can bypass the CDN cache by changing Accept.
  3. What happens when a source image is replaced under the same URL? Caches keep serving derivatives of the old image until those entries expire or are invalidated, and a purge only reaches the caches it is sent to. Giving a changed source a new URL avoids the problem, because a URL that has not been requested before has no stored response. If the file name has to stay the same, the derivative’s URL can change instead: imgproxy’s cachebuster option does not affect processing, and changing its value bypasses CDN, proxy server, and browser caches. That forces a new transformation but does not refresh the source: if the original is also cached under its unchanged URL, the new derivative can be built from the old file until that entry expires, is revalidated, or is purged. Cloudflare, for example, says requests for different sizes are likely to reuse its cached original. imgproxy’s internal cache has no manual invalidation; its key includes the cachebuster, and its documentation also points to object expiration in the storage backend.
  4. What happens when many requests miss on the same uncached image at once? Unless the cache collapses them, each one triggers its own transformation, which is known as a cache stampede. Collapsing has conditions. Cloudflare collapses concurrent misses per data center, so several locations can each still send one request. NGINX’s proxy_cache_lock is off by default, and a request that waits past the lock timeout is passed upstream without its response being cached. On Fastly, if the response turns out to be uncacheable, the queued requests are sent to the origin one after another.

When Image Cache Servers matter

Cache expensive image variants with keys that include every transformation parameter and relevant source version. An incomplete key can serve the wrong image, while overly short retention increases origin load and processing cost.

How Transloadit helps with Image Cache Servers

In Transloadit’s Smart CDN the image cache is the /tlcdn/deliver Robot, which is used implicitly for tlcdn.com URLs: it caches each transformed result and delivers it close to your users. The /file/serve Robot, which hands the result of a Template to the CDN, only runs when the CDN has no cached copy, and its cache_duration parameter sets how long browsers and CDNs may keep the result. The /file/serve documentation advises against using it without the CDN in front, because every request would then be a new resize.

For signed Smart CDN URLs, the effective cache lifetime of a response is bounded by the remaining signature lifetime. The pages linked here do not describe a purge operation or what happens to a cached result when the original is replaced under an unchanged file path, so test that case on your own Workspace before relying on it.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free