Pull Zone / Push Zone

A pull zone and a push zone are the two ways to get content into a CDN. A pull zone points the CDN at your origin. An edge server fetches the file from it on a cache miss. A push zone has you upload files into the CDN’s own storage. The CDN then serves that storage as its origin. The difference is who writes content into the CDN: you, or the CDN itself. It is not about how a request is served. In both models the edge caches the object and serves later requests from its cache. These are not protocols or standards. They are vendor deployment models. KeyCDN is the vendor that names them literally: “The available types of Zones are a Pull Zone and Push Zone.” (KeyCDN)

How it works

In a pull zone you configure an origin URL and little else. KeyCDN’s entire setup is to set the Zone Type to pull and define the Origin URL (KeyCDN). On each request the edge checks its cache. On a cold-cache miss it fetches the file from the origin, caches it, and serves the cached copy. A miss is by definition a resource that “was not found in cache and was served from your origin” (Cloudflare). The origin stays the source of truth. The CDN is a cache in front of it. Each network location caches independently, so the first request at each location is a miss. But whether that miss reaches your origin depends on whether a mid-tier sits in between. Under Cloudflare Tiered Cache a lower tier must ask an upper tier first: “only the upper-tier can ask the origin for content” (Cloudflare). KeyCDN’s Origin Shield works the same way: “Predefined shield servers, instead of our edge servers, will pull the content from your origin server if enabled.” (KeyCDN)

In a push zone you upload files into the CDN’s storage. The CDN serves that storage as its origin. There is no upstream server for it to pull from. KeyCDN accepts push uploads “through FTP(S) and rsync over SSH”. It says “New content is instantly uploaded to our storage cluster and is immediately available.” Pushing does not put the file on the edges, though. “Although your content has been uploaded to our storage cluster, data is only deployed to a POP if it has been requested.” (KeyCDN) So a push zone pre-stages content one hop from the edge, inside the CDN. That content does not reach every edge.

Here are both flows side by side:

Pull zone flow:
  User -> CDN Edge -> (miss) -> Your Origin Server -> response cached at edge

Push zone flow:
  You upload files -> CDN Storage
  User -> CDN Edge -> (miss) -> CDN Storage -> response cached at edge

Why it matters for a CDN

Zone type decides who absorbs the first request. It also decides what a miss costs you. In a pull zone every cold cache, every purge and every newly added location turns into traffic on your origin. Your origin must be reachable for the CDN to serve anything it has not already cached. In a push zone that traffic terminates in the CDN’s own storage instead. There is therefore no origin server to keep online, and no origin upload for the first user to wait on. But publishing becomes a deployment step you own, because nothing reaches the CDN until you upload it. Zone type can also decide what is cacheable at all. KeyCDN recommends a push zone for files over 10 MB and requires one above 100 MB, “because Pull Zones do not cache anything larger than 100 MB” (KeyCDN). Push buys this at the cost of freshness and paid storage, so it suits content that changes rarely. KeyCDN’s own guidance is that “A Push Zone should be used for larger files (> 10 MB), which do not change frequently.” (KeyCDN)

What CDNs do

• KeyCDN uses both terms as its two Zone types. It is the reference implementation of the vocabulary. A pull zone is Zone Type pull plus an Origin URL. A push zone is Zone Type push plus content you upload to its storage cluster.
• bunny.net documents one zone type, the Pull Zone. Its origin is either an Origin URL or a Bunny Storage zone. So its push model is a pull zone sitting in front of storage. Its documentation index contains no “push zone” page. The Pull Zone API’s Type field selects a pricing tier (“Premium = 0, Volume = 1”), not a pull-versus-push model. The storage origin is chosen with StorageZoneId, “the ID of the storage zone that will be used as the origin” (bunny.net API). Its Perma-Cache is a third variant: “a secondary permanent cache layer that sits between the CDN and your origin”, filled as misses occur. The CDN does the pushing, not you.
• AWS CloudFront has no “zone”. You specify an origin: “you can use an Amazon S3 bucket, a MediaStore container, a MediaPackage channel, an Application Load Balancer, or an AWS Lambda function URL”. An S3 bucket you upload to is the push-shaped configuration. Your own server is the pull-shaped one.
• Cloudflare is pull-based. It sits in front of your origin. Its cache ratio measures “how often Cloudflare serves content from cache instead of contacting your origin server”. It “respects the origin web server’s cache headers” unless an Edge Cache TTL cache rule overrides them (Cloudflare). There is no zone type you upload into. The push-shaped setup is object storage behind the cache: an R2 bucket on a custom domain, where “domain access through a custom domain allows you to use Cloudflare Cache to accelerate access to your R2 bucket”.
• Fastly is also pull-based. Its Object Storage is “an Amazon S3-compatible large object storage solution that works seamlessly with both CDN and Compute services”. It lets you “store larger file sizes with Fastly” while “reducing egress charges”. This is the closest thing to a push zone, though Fastly documents it as “an add-on” that “is priced in addition to Fastly services”.

Watch out for

• Cold-cache start on pull. Each location fills independently. A purge or a launch therefore means a burst of origin traffic and a cache stampede risk. Cloudflare and Fastly blunt this only for simultaneous misses on the same object. Cloudflare uses “a cache lock to avoid sending duplicate requests to your origin”, scoped to “a single location in Cloudflare’s network” (Cloudflare). Fastly queues all but one so that “only one cache miss causes an origin fetch and the rest wait for that response, a process known as request collapsing” (Fastly). Misses spread over time still each reach the origin.
• Object-size caps are per vendor and per plan, not universal. KeyCDN pull zones “do not cache anything larger than 100 MB”. A KeyCDN push file’s “maximum file size should not exceed 5 GB” (KeyCDN). Cloudflare’s cacheable file limit is 512 MB on Free, Pro and Business. It is 5 GB by default on Enterprise (Cloudflare). Check your own plan’s number before assuming a large file is cacheable.
• Push content changes slowly. On KeyCDN a changed file takes “approximately 15 minutes” to update. A deleted file takes “up to 30 minutes” to leave the edge servers. Worse, “It is not possible to purge the entire CDN cache in a Push Zone. Only Purge URL can be used in a Push Zone.” (KeyCDN) Per-URL purge is your only lever.
• Push has count and cost limits. KeyCDN push zones are “limited to 250,000 inodes (files)”. Push storage is billed, while “Pull Zone storage has no additional cost.” Push storage “starts at $0.12/GB per month and is charged on a daily basis” (KeyCDN).
• Directory listing on push zones. A push zone can generate directory indexes, exposing every object path. KeyCDN documents the feature and states “It is recommended to disable this feature.” (KeyCDN)
• A pull origin stays reachable. KeyCDN lets you “Specify a X-Pull request header key to have the possibility to restrict access to your origin server”. But the documented default is the literal X-Pull: KeyCDN, which any client can send. Set your own key, or the header proves nothing (KeyCDN).
• Terminology drift. Only some vendors use these words, and “zone” does not always mean this at all: on Cloudflare, “domains (or subdomains) that are added to Cloudflare become zones” (Cloudflare). One vendor’s “push zone” is another’s “origin backed by object storage”. Map the model, not the name.

Best practice

• Use a pull zone for anything whose freshness you control on your own servers: HTML, JSON APIs, CSS, JavaScript. Let Cache-Control and TTL drive refresh rather than a deployment step.
• Use a push zone for large files that change rarely (installers, archives, video). Publish changes under new file names. A push zone updates slowly and cannot be fully purged, so immutable names sidestep both problems.
• Put a mid-tier in front of a pull origin (Origin Shield or a tiered cache) before tuning anything else. It converts per-location origin traffic into per-tier origin traffic.
• Warm the cache at the locations that matter before a launch. Neither model fills an edge until something requests the object. So an upload alone is not a warm edge.
• Check the object-size, file-count and purge limits of the exact zone type and plan you are buying. They decide what the zone can actually hold, and they differ per vendor.