What it does — and what it deliberately doesn't
Every feature here shipped because our own traffic needed it first. Nothing shipped because a roadmap spreadsheet said it should.
Standard HTTP caching
Cache-Control, ETag, Last-Modified and conditional requests, handled exactly the way the spec describes — see caching rules.
TLS 1.2 / 1.3
Every edge node terminates TLS with certificates that renew automatically. No manual steps, no expiry surprises.
HTTP/2 and HTTP/3
Enabled on every node by default. Nothing to configure on your side.
Vary-aware caching
A small allow-list of Vary headers is supported so responses can differ by encoding without polluting the cache.
Purge API
Two endpoints — purge a path, purge a prefix — both documented with real request/response examples in support.
A status page that isn't for show
Every incident that touched a real request gets logged, however brief. See status.
Automatic failover
A node failing health checks for 30 seconds straight is pulled from rotation automatically.
Warm caches
Popular paths refresh on a rolling schedule instead of waiting for the next cache miss.
What we don't do
We get asked a lot whether we plan to add edge compute, image transformation, or a few hundred more PoPs. Short answer: not soon. Every one of those adds operational surface area, and the whole point of this project was to have infrastructure two people can fully understand and debug at 3am.
No request-level billing, no real-time analytics dashboard, no edge compute runtime. If you need those, there are bigger CDNs that do them well — we optimised for predictability instead.
No edge compute
Not planned. Keeps the failure surface small enough to reason about during an incident.
No image transformation
Cache what your origin sends. If you need resizing, do it before it hits us.
No usage-based billing
Flat tiers only — see the pricing philosophy.
Read the technical details
Response headers, rate limits and the full purge API reference.