Read-through: keep your origin where it is
Until now there was one way onto yourspace: yourspace deploy packs your build output and uploads it, and we serve the bytes. That's the push model, and it stays — it's the simplest path for a static site that lives nowhere yet.
Read-through is the other way on. You keep your site exactly where it is — your existing host, your existing deploy — and point yourspace at it as an origin. We pull from your origin on the first request, cache the response at the edge, and serve every request after that from cache. No re-upload, no migration, no second copy of your site to keep in sync. Your host stays the source of truth; we become the fast layer in front of it.
What's live today
Read-through origin-pull is rolling out as early access — an operator points yourspace at an origin for you; it is not yet a self-serve toggle in the dashboard. What's real and serving today: the pull-on-miss, cache-to-disk, serve-from-edge path, with request coalescing and a strict SSRF-safe fetcher (below). The edge optimise pipeline (minify, compress, image transforms) and per-site / multi-origin routing are planned — today a configured origin fronts a single site. If read-through fits your setup, get in touch and we'll switch it on.
How it serves
The flow is the one you'd expect from a cache in front of an origin:
- A request arrives. We check the edge cache.
- Cache hit — we serve the stored response. Your origin never sees the request.
- Cache miss — we pull the page from your origin once, store it, and serve it. The next visitor gets the hit.
Every response carries an X-Yourspace-Cache header so you can see what happened: HIT (served from cache), MISS (we pulled your origin for this one), or MISS-COALESCED (a miss that joined a fetch already in flight — see the shield below).
$ curl -sI https://my-site.yo.urspace.net/ | grep -i x-yourspace-cache
x-yourspace-cache: MISS
$ curl -sI https://my-site.yo.urspace.net/ | grep -i x-yourspace-cache
x-yourspace-cache: HIT
Caching follows your origin's own Cache-Control: we honor s-maxage / max-age, and we respect no-store, no-cache, and private — those responses are served straight through and never stored. When your origin says nothing, GET responses get a short default freshness window so a quiet page doesn't re-hit your origin on every visit. The cache is disk-backed and survives a restart, so a deploy of ours doesn't cold-start your traffic back onto your origin.
The origin shield
A cache miss under load is the dangerous moment: a thousand visitors hit a cold or just-expired page at once, and a naive cache turns all thousand into a thundering herd against your origin. Read-through coalesces them. When several requests miss on the same URL at the same time, exactly one of them pulls your origin; the rest wait for that single fetch and share its result. That's the MISS-COALESCED you'll see in the header. A traffic spike on a cold page costs your origin one request, not the spike.
SSRF-safe from the first request
Pointing a cache at an arbitrary origin URL is, structurally, asking a server to make outbound requests to a destination someone else controls. Done carelessly, that's a server-side request forgery (SSRF) vector — a misconfigured or hostile origin coaxing our fetcher into reaching somewhere it should never reach: a loopback address, a private network, or a cloud provider's metadata endpoint.
We built the fetcher to refuse that from the start. Before connecting, it resolves the origin's hostname and checks the actual IP it would connect to — not just the name — against a blocklist of internal ranges: loopback, private networks, link-local, and crucially the cloud-metadata address (169.254.169.254). If the resolved address is internal, the fetch is rejected. The check runs at connection time and connects to exactly the address it validated, so the classic "resolve to a safe IP, then swap it for an internal one" rebinding trick is closed. This is the only path our origin-pull traffic takes — there's no unguarded fetcher behind it.
It's a quiet property — you'll never see it fire on a correctly configured origin — but it's the kind of thing that has to be right before a feature like this can exist at all.
What's next
Read-through ships first as the serving mode: pull, cache, serve, safely. The optimise pipeline — minifying HTML and CSS, compressing responses, and transforming images at the edge so your origin doesn't have to — is the planned next layer that rides on top of it.
For now: if you've got a site on a host you're happy with and you want it faster and closer to your users without moving it, read-through is the path. It's early access today — reach out and we'll get you set up.