Skip to main content
Serving stored content to the web at scale means putting an edge cache in front of a gateway. Any pull-through CDN that respects origin cache headers works; there’s nothing Tapedrive-specific to install. One thing to settle before configuring anything: a CDN fronts a paid gateway tier or a gateway you run. Cache misses become origin traffic, and origin traffic at CDN volume is more than the hosted free tier is sized for (rate limits, running a gateway).

​
Tapedrive content caches unusually well

Tracks are immutable. Replacing data means writing a new track, and a track-addressed URL can only ever serve one payload; its ETag is the track’s on-chain commitment (how tracks work). Cache invalidation, the classic operational headache of CDN setups, mostly disappears: track-addressed content can be cached indefinitely. The only mutable thing in the system is a name. Object names are pointers that can be re-aimed at new tracks (objects), so name-addressed URLs are the ones that need short TTLs.

​
Two cache policies

The gateway already sends the right headers for the first row: Cache-Control: public, max-age=31536000, immutable with the commitment as ETag (get object).

​
Origin setup

Point the CDN at your gateway as a pull-through origin:
The range-request line matters: the gateway answers ranges on single-track and streamed (multi-segment) objects alike, decoding only the segments the range touches, and the CDN should forward ranges rather than absorb them (how gateway reads work).

​
What a CDN does not do

Verification. A CDN serves bytes without proofs. If your application needs cryptographic assurance of what it received, use the SDK’s verified reads, which either bypass the cache or verify after fetching. Edge caching changes where bytes come from; it never changes what counts as correct. Access. Cache misses still count against the origin gateway’s metering (rate limits).