Skip to main content

​
The three shapes

ShapeYou runBest for
Origin onlyOne or more origin-backed nodesYou produce the content; you don’t want to run a pure-cache fleet
Origin + cachesOrigin-backed nodes and pure-cache nodesYou want top-tier control of cache hit rates on your most popular content
Outsourced originNothing on the CDN sideSomeone else runs an origin-backed node pointing at a bucket you control

​
Why always at least one origin-backed node (yours)

Origin-backed nodes set the effective price ceiling — their advertised rate reflects their backend’s real egress cost, and pure-cache nodes cannot charge below what they paid to pull from the origin. If no one is running an origin-backed node for your content, the first cache miss has no canonical source to fall back to. Running at least one origin-backed node gives you:
  • A price floor you control — you’re the one absorbing S3 egress cost, so you set the rate that everyone else must beat on caching efficiency.
  • A seeding guarantee — first deliveries come from your node, warming caches network-wide.
  • A compliance anchor — you remain the authoritative source for takedown compliance on your content (the operator blacklist still binds you, but your local denylist is the first response).

​
When to also run pure-cache nodes

Pure-cache nodes make sense when:
  • You want to hit specific POPs (pair regions) that the independent node fleet hasn’t covered yet.
  • You want to set reputational baseline — your caches start with zero reputation but accumulate it quickly against your own backend’s egress, giving you at-cost seeding while you build reputation.
They do not save you egress unless they run in a region close to your backend. A pure-cache node in London pulling from a London S3 bucket is basically free; a pure-cache node in Singapore pulling from London is the opposite.

​
When to outsource the origin

You can contract with an independent operator to run an origin-backed node against an S3 bucket you own. Trust implications:
  • They hold your hash-to-object-key catalog (so they must be allowed to enumerate your bucket).
  • They hold read credentials to the bucket.
  • They earn the per-MB revenue (subject to whatever commercial arrangement you have with them).
This is equivalent to any CDN outsourcing relationship. The protocol does not distinguish it.

​
What you cannot do

  • Expose your origin URL to the network. The protocol enforces redirect → NodeId, not a URL. If you want the URL used, you’re outside this protocol.
  • Opt out of pull-through without seeding. If you run origin-backed with pull_through: false, peers redirect clients directly to your NodeId — fine, but it means every pull is direct and you miss caching benefits.