Serve builds from a plain file server

Why this works

Tide stores every build as content-addressed chunks under chunks/<hash> (see The Tide delta engine, in depth). A chunk’s name is the BLAKE3 hash of its bytes, so a chunk never changes and never needs cache invalidation. That makes the read side just static files: anything that can return a file by path over HTTP can serve chunks.

What to serve

The chunk store is a flat tree of immutable files. Expose that directory over HTTP(S) with any static server, and clients read chunks by URL:

chunks/<hash>      # immutable build data, content-addressed

Only the chunk bytes are served this way. Manifests and the channel→build pointer stay gated by nightshipd, which is what authorizes a client before it ever reaches the chunks.

Examples

Any static file server works. For instance, serving the chunk directory as a document root:

# nginx
server {
    listen 80;
    root /srv/nightship-chunks;   # contains chunks/
    location / { try_files $uri =404; }
}

# or Caddy
files.example.com {
    root * /srv/nightship-chunks
    file_server
}

# or a throwaway local mirror
cd /srv/nightship-chunks && python -m http.server 8080

Put a CDN in front

Because chunks are immutable, they are ideal for edge caching. Front the static server with a CDN and set long cache lifetimes — a chunk fetched once can be cached indefinitely, since its hash guarantees the bytes can never change under that name.

When to use it

• You already run a web server or CDN and want to reuse it for build reads.
• You want cheap, cacheable public reads for an open or demo channel.
• On-prem: serve builds from a file server on the LAN, with nothing else to run.

← All guides