Our 60-Line Trade Secret

Or: the CDN you already own.

Our blog listing took 1.5 seconds to answer. The reflex the industry has trained into everyone at that moment is: add something. A CDN subscription, an edge platform, a caching service with a dashboard and a monthly invoice.

We went the other way. Same VPS, same nginx that was already installed, about sixty lines of config. The same page now answers in 89 milliseconds — and most of that is the speed of light, not the server.

The forgotten layer

Every self-hosted app already has a proxy in front of it. For most teams it does exactly one job — TLS termination — and then passes every request through to the application like a doorman who checks your coat and nothing else.

That proxy is a full cache engine. It can hold your rendered HTML in memory, answer without waking the app, refresh entries in the background, and keep serving during the exact moments an origin is weakest: cold starts, GC pauses, deploy restarts, traffic spikes. The capability has been in nginx for well over a decade. The industry just stopped configuring it around the time renting it back became a product category.

What "next level" actually looks like

The pattern is called a micro-cache, and its trick is that it barely caches anything. Thirty seconds, forced. But for those thirty seconds, every anonymous visitor is served from memory — and when the entry expires, the next visitor still gets the stale copy instantly while nginx refreshes it behind the scenes. Nobody, ever, waits for the render.

The numbers from hyperdrift.io, measured before and after, same machine:

before   blog TTFB (cold)   1.50 s
after    blog TTFB          0.073–0.089 s   x-hd-cache: HIT
burst    20 requests        min 73 ms · median 89 ms
session  cookie present     x-hd-cache: BYPASS (never cached)

A 17× improvement, from a layer we already owned.

The config that does it

One proxy_cache_path zone (16 MB of keys, 256 MB on disk), then per-vhost:

proxy_cache_valid 200 30s with proxy_ignore_headers Cache-Control Expires — the TTL is forced and short, so a page can never pin itself stale and deploys self-heal within thirty seconds.
proxy_cache_use_stale updating error timeout http_5xx + proxy_cache_background_update on — stale-while-revalidate at the proxy; the origin can restart mid-deploy and visitors never see it.
proxy_cache_lock on — one render per expiry, not a thundering herd.
Only GET/HEAD are cacheable; any session cookie bypasses; responses with Set-Cookie are never stored; Vary is honored so React Server Component payloads and HTML stay separate entries.
add_header X-HD-Cache $upstream_cache_status — every response tells you whether it was a HIT, MISS, or BYPASS.

It ships as an opt-in flag per app in our Ansible inventory (microcache: true), so the whole fleet inherits the pattern one line at a time. Alongside it, the stack this rides on: HTTP/3 + TLS 1.3, keepalive upstream pools, tuned gzip — all on one VPS.

Honest edges

This makes one origin fast, not one planet. If your audience is genuinely global, a real CDN still earns its keep on geography. And the pattern is strictly for anonymous pages — the moment a request carries a session, it goes straight to the app, full stop. What it removes is the default assumption that fast HTML is something you rent.

Take it with you

Before adding a service to fix a slow page, ask what the proxy you already run is doing all day. For most self-hosted products the answer is "checking coats." Sixty lines of nginx turn it into the edge node you were about to pay for.

The full config lives in our open infra patterns. If you're running a fleet on your own metal and want to compare notes, talk to us.