Hosting the index

If your host can serve a file and honor a Range header, it can serve rangefind. Here's how to do it well — and what it costs.

The one requirement

The runtime issues Range: bytes=start-end requests and expects 206 Partial Content responses. Netlify, Vercel, GitHub Pages, Cloudflare Pages, S3, R2, GCS, nginx, Caddy, and virtually every CDN support this out of the box. If a host answers 200 with the full file instead, queries still work — they just transfer more than needed.

Two things to verify on exotic setups:

Cache headers that make it fast

Everything except the manifests is immutable and content-addressed:

/rangefind/manifest*.json      Cache-Control: max-age=60, must-revalidate
/rangefind/**/*.bin            Cache-Control: public, max-age=31536000, immutable
/rangefind/**/*.bin.gz         Cache-Control: public, max-age=31536000, immutable

With those headers, incremental updates are CDN-friendly by construction: unchanged packs keep their filenames, so a site update invalidates only the small manifests.

Small sites

For a docs or marketing site the index is usually a few megabytes — host it with the site itself and stop thinking about it. This site does exactly that on GitHub Pages.

Large indexes on object storage

Multi-gigabyte indexes (Wikipedia-scale corpora, geo datasets) belong on object storage with a CDN in front:

For comparison: hosted search APIs charge per request (commonly ~$5 per 1,000). A million queries a month against a static index is a few dollars of CDN traffic — or zero on free tiers.

Offline and embedded

Because the index is plain files, it also works where servers can't: download a region's index directory and query it locally with rangefind/node, bundle one into an Electron or mobile webview app, or mirror it wherever your users are. No key management, no rate limits, no phoning home.