> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tape.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Serving Tapedrive Content Through a CDN

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](/apis/rate-limits), [running a gateway](/protocol/node-setup/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](/protocol/architecture/tracks)). 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](/protocol/architecture/objects)), so name-addressed URLs are the ones that need short TTLs.

## Two cache policies

| Content                                                                                     | Policy                                                                                                             |
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Track-addressed URLs (`/object/{track_id}`, `/v1/tracks/...`)                               | Cache indefinitely. Revalidation is never needed.                                                                  |
| Name-addressed URLs (the [site route](/tools/hosting), the [S3 gateway](/tools/s3-gateway)) | Short TTL or revalidate, so renames and replacements propagate. The site route already sends revalidation headers. |

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](/apis/gateway/objects/get-object)).

## Origin setup

Point the CDN at your gateway as a pull-through origin:

```text theme={null}
origin:            https://gw.example.com
cache key:         default (URL)
honor headers:     yes   # don't override Cache-Control or ETag from the origin
range requests:    pass through to 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](/protocol/architecture/gateways)).

## 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](/sdks/reading), 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](/apis/rate-limits)).