CDN Origin Pull vs Push: Architecture Comparison and Use Cases

CDN origin pull fetches content from your origin server on-demand when an edge node receives its first request, while origin push requires you to upload content to CDN storage beforehand. Pull is ideal for dynamic, frequently updated sites, whereas push excels for large, static assets requiring guaranteed edge availability and reduced origin load.

Understanding the distinction between pull and push is foundational to designing a resilient, cost-efficient content delivery strategy. Every CDN ultimately answers one question: where does the authoritative copy of your content live? In a pull model, your origin remains the source of truth and the CDN acts as a distributed cache. In a push model, the CDN itself becomes the source of truth after you explicitly populate it.

If you are new to content delivery concepts, start with our what is a CDN explainer and the CDN fundamentals guide to ground yourself in edge caching, PoPs, and TTLs before diving into origin strategies. This article builds on those basics with real-world configs and architectural trade-offs I have implemented for e-commerce, media, and SaaS platforms.

What Is CDN Origin Pull?

Origin pull, often called pull CDN or origin fetch, is a lazy-loading architecture where the edge does no work until a user asks for something. On a cache miss, the edge node forwards the request to your origin, caches the response according to your cache-control headers, and then serves it to the user and all subsequent users in that region.

Pull keeps operational complexity low because you never manage CDN storage directly. You deploy content once to your origin — whether that is Nginx, Apache, S3, or an application server — and the CDN mirrors it automatically based on demand. This makes pull the default for 90% of websites, especially those with dynamic or frequently changing content.

A pull CDN respects standard HTTP semantics. Cacheability is governed by headers like Cache-Control, Surrogate-Control, ETag, and Vary. You can fine-tune behavior per content type without redeploying to the CDN. For example, you might cache images for a year, API responses for 60 seconds, and HTML for no-cache with stale-while-revalidate.

The primary trade-off of pull is the first-request penalty. The initial user in each PoP who requests an uncached object will experience higher Time to First Byte (TTFB) while the edge fetches from origin. This is mitigated with tiered caching, origin shield, and pre-warming, but it is inherent to the on-demand model.

What Is CDN Origin Push?

Origin push, also called push CDN or CDN storage, inverts the flow. Instead of the CDN pulling from you, you push content to the CDN's distributed storage cluster via FTP, SFTP, RSYNC, S3-compatible API, or a provider portal before any user request occurs. The CDN then replicates that object to its edge PoPs.

In a push architecture, your origin is not involved in serving cached assets at all. Once uploaded, the asset lives natively on the CDN. This decouples availability from your infrastructure; even if your origin goes offline, pushed assets remain servable. That guarantee is critical for large file distribution where origin bandwidth would be overwhelmed.

Push requires explicit lifecycle management. You decide what to upload, when to update it, and when to delete it. There is no automatic freshness check against an origin. Updates are performed by re-uploading the object or issuing a purge. This explicit control eliminates revalidation requests but adds deployment steps to your workflow.

Push is less common today because modern pull CDNs with persistent storage and tiered cache achieve similar origin offload. However, push still dominates for immutable, large-object workloads such as video-on-demand libraries, software distribution, and game asset delivery where files are gigabytes in size and rarely change.

How Each Architecture Works: Request Flow

In a pull flow, the request path is client → edge PoP → (on miss) → origin shield → origin. The edge checks its local cache, then a regional shield cache, and only then contacts your origin. The origin response is cached at both layers with the TTL you specify, dramatically reducing origin hits for popular content.

In a push flow, the path is simpler at request time: client → edge PoP → CDN storage. Because the object was pre-seeded, the edge can serve it immediately from local disk or SSD without any origin fetch. Replication from central storage to edges may be synchronous on upload or lazy on first request depending on the provider, but it never touches your infrastructure.

The operational flow before any user request also differs sharply. Pull requires zero pre-provisioning; you deploy to origin and configure the CDN origin hostname. Push requires a CI/CD step that uploads artifacts to CDN storage and verifies replication. This difference affects deployment pipelines, rollback strategies, and cache invalidation planning.

Core Architectural Differences at a Glance

Choosing between pull and push is not about which is universally better, but which aligns with your content lifecycle, origin capacity, and operational model. The table below distills the trade-offs I evaluate with clients during architecture reviews.

For most teams, pull offers the best balance of simplicity and performance, which is why it is the default in our CDN fundamentals guide. Push becomes compelling only when origin offload or guaranteed availability outweighs the extra deployment complexity.

Performance Implications: Latency, Hit Ratio, and Core Web Vitals

Performance differences between pull and push manifest primarily in TTFB and cache hit ratio. A pull cache miss adds the round-trip time from edge to origin, which can be 40–200ms depending on shield distance and origin response time. After the first hit, both models serve from edge RAM/SSD in 10–25ms.

Hit ratio is the ultimate equalizer. A well-tuned pull zone with Cache-Control: public, max-age=31536000, immutable for versioned assets and a 95%+ hit ratio will perform identically to push for end users. The key is to version filenames (e.g., app.a3f7c9.js) and use long TTLs, as detailed in our CDN image optimization guide.

For Core Web Vitals, the largest impact is Largest Contentful Paint (LCP). If your hero image is pull-cached with a short TTL and suffers frequent misses, LCP will regress. Push guarantees the image is already at the edge, but the same result is achievable with pull + pre-warming and proper preload hints. I typically recommend pull with tiered caching and early hints over push for web vitals optimization because it avoids storage duplication.

Origin shield and tiered caching narrow the gap further. Instead of 50 edge PoPs each fetching from origin on a cold start, only the shield PoP fetches once and fans out to edges. This reduces origin requests by 90% and makes pull viable even for thundering-herd events like flash sales on e-commerce sites.

Configuration Examples: Real-World Setup

Below are minimal, production-tested configurations for both models. These examples assume an Nginx origin and a generic CDN provider with pull and push storage options. Adapt hostnames and authentication to your provider.

Origin Pull Configuration

With pull, you simply point the CDN origin to your server and set authoritative caching headers. The CDN does the rest. This Nginx snippet sets long-lived immutable caching for versioned assets and short caching for HTML.

# Versioned static assets — cache 1 year, immutable
location ~* \.(?:js|css|woff2|png|jpg|webp|avif)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
  add_header CDN-Cache-Control "max-age=31536000";
  add_header Surrogate-Control "max-age=31536000";
  etag on;
  expires 1y;
}

# HTML — revalidate every time, allow stale while revalidate
location / {
  add_header Cache-Control "public, max-age=0, s-maxage=60, stale-while-revalidate=300, stale-if-error=86400";
  try_files $uri $uri/ /index.html;
}

# Health check for CDN origin monitoring
location = /cdn-health {
  access_log off;
  return 200 "ok\n";
}

On the CDN side, create a pull zone with origin origin.example.com, enable origin shield (e.g., us-central), and set origin timeout to 10s with retry on 5xx. No upload step is required.

Origin Push Configuration

With push, you provision a storage zone and upload assets. The CDN exposes an S3-compatible endpoint or RSYNC target. Your CI pipeline pushes after build.

# Sync build artifacts to CDN push storage (S3-compatible)
aws s3 sync ./dist/ s3://my-push-zone/releases/v2.4.1/ \
  --endpoint-url https://storage.cdn-provider.net \
  --cache-control "public, max-age=31536000, immutable" \
  --content-encoding br

# Alternative: rsync over SSH for providers that support it
rsync -avz --delete ./dist/ [email protected]:/storage/my-zone/

# Purge old version after verification (example API)
curl -X POST "https://api.cdn-provider.net/v1/purge" \
  -H "Authorization: Bearer $CDN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["https://cdn.example.com/releases/v2.4.0/*"]}'

For DNS, both models benefit from proper CDN DNS resolution with Anycast and low TTLs. Push zones often use a separate hostname like assets-push.example.com to isolate storage routing from your main pull zone.

Use Cases: When to Choose Pull vs Push

Choose Origin Pull When:

Pull is ideal for dynamic and frequently updated content where freshness matters more than pre-seeding. This includes e-commerce catalogs, news sites, SaaS applications, and marketing sites where editors publish multiple times per day. The ability to purge by surrogate key or rely on short TTLs keeps workflows agile.

Pull also wins when your origin already has robust storage and you want to avoid duplicating data. If you run an origin on S3, GCS, or a scalable web server, paying for additional CDN storage is redundant. Pull lets you keep one authoritative copy and leverage the CDN purely as a cache.

For teams practicing continuous deployment, pull integrates seamlessly. You deploy to origin, and the CDN automatically serves the new version after cache expiry or purge. There is no extra step to push artifacts, reducing deployment failure modes.

Choose Origin Push When:

Push excels for large, immutable, and bandwidth-heavy assets where origin egress cost or capacity is a concern. Examples include 4K video libraries, software installers (100MB–4GB), game patches, firmware images, and dataset archives. Pre-uploading guarantees the CDN can absorb a launch-day spike without origin collapse.

Push is also preferable when origin availability cannot be guaranteed. If your origin is a small on-prem server or a build artifact that is deleted after deployment, push ensures assets remain available. Some providers offer push storage with 11 nines durability, effectively replacing origin storage.

Regulatory or workflow constraints can also drive push adoption. When you need explicit control over what is distributed — for example, only approved releases should be on the edge — push provides an auditable gate.

The Hybrid Model: Best of Both Worlds

Most mature architectures I design use both. A typical hybrid setup serves HTML and API responses via pull with short TTLs, while large static binaries are pushed to CDN storage and referenced by immutable URLs. Path-based routing on the CDN directs /api/* and /* to the pull origin and /releases/* to push storage.

Hybrid requires clear cache-key and purge strategies. Use surrogate keys like product-123 for pull content and versioned paths for push content. This separation simplifies invalidation and keeps operational burden low while maximizing origin offload.

Cost, Operations, and Scalability Considerations

Cost modeling differs fundamentally. Pull costs are dominated by origin egress and CDN bandwidth, with no storage fee. Push adds CDN storage and replication fees but can eliminate origin egress entirely for pushed assets. For a 1TB video library served 100TB/month, push storage ($20/TB) is trivial compared to origin egress savings ($70–90/TB).

Operationally, pull is simpler to monitor. You watch origin hit ratio, cache status headers (X-Cache: HIT/MISS), and origin latency. Push monitoring focuses on upload success, replication lag, and storage utilization. Failed uploads must be retried, and replication delays can cause 404s if you switch references too early.

Scalability favors push for massive objects because you avoid the thundering herd problem. With pull, a cold cache for a 2GB file requested by 10,000 users simultaneously can overwhelm origin and shield. Push pre-seeds the file, so no origin fetch occurs. Modern pull CDNs mitigate this with collapsed forwarding and tiered cache, but push remains more deterministic.

Security Considerations for Pull and Push

With pull, your origin is exposed to the internet and must validate that requests come from the CDN. Implement origin authentication via shared secret, signed requests, or IP allowlisting, and always use TLS to origin. Configure Origin Shield to reduce the set of IPs that can contact origin.

With push, the attack surface shifts to storage credentials. Secure your upload endpoint with short-lived tokens, enforce MFA for portal access, and enable object immutability or WORM where available. Since pushed assets are served without origin checks, ensure your CI pipeline signs and verifies artifacts before upload.

Both models benefit from token authentication at the edge, geo-restrictions, and WAF rules. For sensitive assets, use signed URLs with expiry regardless of pull or push, and set Cache-Control: private where appropriate to prevent caching of personalized content.

Decision Framework: Which Should You Choose?

Start by answering three questions: How often does the content change? How large is it? Can your origin handle a spike? If content changes hourly and is under 5MB, choose pull. If it is immutable, over 50MB, and requested by thousands concurrently, choose push. Everything in between can be served by pull with proper caching.

For beginners, default to pull. It is easier to reason about, cheaper to start, and covers 90% of web workloads. You can evolve to hybrid later without re-architecting your origin. Only introduce push when you have measured origin egress costs or availability incidents that justify the extra workflow.

Document your choice in your CDN runbook. Include origin hostnames, cache-control policies, purge procedures, and rollback steps. A clear runbook prevents the most common outage I see: a team purging pull cache but forgetting to re-upload a pushed asset, or vice versa.

Choosing between origin pull and push is a trade-off between simplicity and control. Pull keeps your origin authoritative and your workflow simple, making it the right starting point for most teams. Push gives you deterministic performance and origin independence for large, static workloads. Evaluate your content lifecycle, measure hit ratios and egress costs, and adopt a hybrid model where it clearly reduces risk or cost. For a broader foundation, revisit our CDN fundamentals and what is a CDN guides.