Service
CDN & Edge Delivery
Your own content network on your own address space — or a sane configuration of someone else's.
- Anycast
- Same prefix announced from every POP
- Multi-POP
- Cloud, bare metal and colo in one fabric
- Own IP
- Portable address space, not a vendor's
We built an anycast CDN for ourselves — our own /24, announced from POPs across AWS and Vultr, with BIRD holding the eBGP sessions and NGINX doing the caching. Not as a demo. As the thing we use and keep running.
That experience is what this service sells. We know where the sharp edges are because we ran into them.
What “anycast CDN” actually means
One prefix, announced from many places. The internet’s own routing decides which POP a user reaches — no DNS tricks, no client logic, no per-request geolocation lookup.
The appeal is operational: to take a POP out of service, stop announcing from it. Traffic moves to the next-closest site in seconds, and you do not have to wait for a DNS TTL to expire.
The difficulty is everything else: TCP connections that must not be rerouted mid-flight, cache coherence across sites that cannot talk cheaply, origin load when a POP drains, and debugging a problem that only exists for users whose packets take one particular path.
How we build a POP
- Routing. BIRD 2 holding eBGP with the local transit provider or cloud BGP endpoint. Health-driven announcement — if the cache tier is unhealthy, the prefix is withdrawn from that site.
- Edge. NGINX or Varnish for caching, HAProxy or Envoy where connection management matters, QUIC/HTTP3 enabled, TLS terminated locally with automated ACME issuance.
- Tiering. Edge caches are small and hot. A mid-tier shield absorbs misses so the origin sees a fraction of the request volume, which is what makes a cold POP safe to bring up.
- Observability. Per-POP hit ratio, origin offload, p99 time-to-first-byte and route-table state in Prometheus, with per-site drill-down in Grafana.
# Edge: cache by a key you control, not by whatever the URL happens to contain.
proxy_cache_key "$scheme$request_method$host$uri$is_args$args$http_accept_encoding";
proxy_cache_lock on;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
add_header X-Cache-Status $upstream_cache_status always;
add_header X-Served-By $hostname always;That X-Served-By header is not decoration. When a customer reports slowness, the first question is always which POP they landed on.
Build versus buy
We will model it with your numbers: egress volume by region, object size distribution, hit ratio you can realistically achieve, and the full cost of running POPs including the engineering time to keep them alive.
Sometimes the answer is “stay on your commercial CDN and fix your cache keys” — that is a two-week engagement, not a six-month one, and we would rather tell you that than sell you a build.
Who this is for
High-egress platforms — video, large downloads, image-heavy commerce, game assets, model weights — and teams with residency requirements that rule out a global shared network.
Questions
Asked often enough to answer here.
Should we really build our own CDN?
Usually no. Commercial CDNs are excellent and cheap at low volume. Building becomes rational at high egress volumes, with unusual cache semantics, under data-residency rules, or when you need the edge to run your own compute. We model both and give you the crossover point before anyone writes code.
Can you run this on top of Cloudflare or Fastly instead?
Yes. A large part of this practice is configuration rather than construction — cache keys, tiering, origin shields, purge strategy and worker logic on an existing provider. Cheaper and faster than a build, and often all that is needed.
What about certificates for thousands of customer domains?
Automated issuance at the edge with ACME, on-demand TLS for long-tail custom domains, and OCSP stapling. Certificate expiry is a solved problem and should never be an incident.
How do you handle a POP going bad?
Withdraw the announcement. Anycast routes traffic to the next-closest POP within BGP convergence time. Health checks drive withdrawal automatically, and we test it on a schedule rather than hoping.
Also
The rest of the estate.
- InfrastructureWe take the estate you already have and make it legible, automated and boring.
- NetworkRouting, peering and address space — designed on paper, built as code, proven by withdrawal tests.
- SecurityReduce the number of ways in, then prove what happened on the ones that remain.
- On-PremA private cloud that behaves like a public one — self-service, API-driven, and yours.
- AI InferenceRun your models on hardware you control — for cost, for latency, or because the data cannot leave.
- Device & MDMEvery laptop and phone enrolled, encrypted, patched and accounted for — from unboxing to offboarding.
- ObservabilityKnow it broke before the customer does — and know which layer, in one click.
- All servicesOverview, delivery method and the things we will tell you not to buy.
Next step
Tell us what breaks at 3am.
A 30-minute call with the engineers who would do the work — not a sales desk. We will tell you whether this is a bolt.sh problem or something you can fix in-house.