The federated wiki server is already a static site plus a small write API. Splitting the two — static reads on cheap or free serving, writes on a small authoring server — makes a wiki site fast, nearly free to host, and calm under any load an agent or a crowd can bring. > Reads are files. Writes are journal actions.
## Reads Are Files
The Read Path audits the server source. Page JSON is read verbatim from disk. Sitemap and search index are prebuilt files. The client is a static bundle. Everything a reader or a federation neighbour fetches can be served by Caddy, a CDN, or any static host — with permissive CORS on page JSON and sitemap, which the federation requires.
## The Write Plane
Writes stay with the wiki server: the journal-action PUT — create, add, edit, remove, move, fork — already is a clean API, and keeping it verbatim keeps every stock client working. The edge routes write and auth paths to the authoring server under the same domain, so the client never notices the split. A read-only site simply has no write route. Bulk authoring — imports, index rebuilds, agentic writers — belongs on a separate batch door that writes many pages, rebuilds the index once, and publishes once. See Federated Authoring.
## Provider Survey
The 2026 field, in one pass: - Cloudflare serves static assets free and unlimited on every tier; one small worker can host-route hundreds of sites from one bucket. See Cloudflare R2. - Bunny costs about a cent a gigabyte with a one dollar monthly floor, and its Perma-Cache holds a permanent edge copy — the paid-but-predictable choice. - Netlify's free tier now pauses a site when monthly credits run out. A federation citizen must not pause. Ruled out. - GitHub Pages suits a frozen site or two — small, no custom headers. - Media belongs in zero-egress object storage — Egress Economics and Cheap Object Storage cover the numbers.
## What About Spin
Wasm on Spin is our trial of Fermyon Spin, now a CNCF project under Akamai's wing. The verdict here: for reads Spin adds nothing — reads are files, and a file server in WebAssembly is just a slower Caddy. For writes it costs the most where care matters: journal semantics, farm routing, and index regeneration would all need reimplementing. Spin stays for greenfield services, not for the wiki's data path.
## Phases
- Serve every GET as static files straight from the data directory, behind Caddy. Writes proxy to the wiki server. No new vendors. - Push the corpus to a CDN or storage zone; the authoring server publishes changed files and purges URLs on write. - Let Embassies mirror the corpus — see Local First Embassy — until the CDN is optional acceleration over the commons. Federated wiki is eventually consistent by nature. Seconds of publish latency cost nothing.
## Links
- wiki-ssg — Wiki Static Site Generator 
- Cloudflare static assets
- bunny.net
- Netlify pricing
- Spin framework
# Assets
read-write-split
# See