How to Build Your Own Low‑Latency CDN from Scratch

CDN Basics

Before optimizing front‑end assets, understand that a CDN is not a magic fix; it only helps after the site itself is fast. When the site is already optimized, the next step is to improve content delivery across the globe.

Latency Problem

The author’s server was hosted in Frankfurt, causing Australian users to experience 2‑3 seconds of additional latency due to over 300 ms round‑trip time and multiple ISP hops, similar to a slow WordPress site.

Why Traditional Pull‑CDN May Slow You Down

Commercial pull‑CDNs cache content for a period of time. For low‑traffic blogs, cached content may be evicted quickly, making the pull‑CDN slower than direct access. Push‑CDNs avoid this but are often expensive.

Accelerating DNS Lookups

Fast content delivery starts with routing users to the nearest edge node. This can be achieved with an intelligent DNS server that performs GeoIP lookups and returns the IP address of the closest server, a technique used by most commercial CDNs.

Why Not Use BGP Anycast?

Anycast would route a single IP to the nearest node, but it requires a pool of at least 256 IP addresses and hardware control, exceeding typical budgets. Moreover, BGP routes can be unstable; HTTP connections may break if the route changes mid‑transfer, adding complexity. Finally, fewer hops do not always mean lower latency, as a single long‑haul hop can dominate round‑trip time.

Setting Up Your Own DNS

Since running a private Anycast network is impractical, the author chose a DNS provider that supports latency‑based routing. After testing, Amazon Route 53 was selected (Dyn was too costly; DNS Made Easy also supports latency routing). For each edge node, a DNS A record pointing to that node’s IP was created, and health checks were added to remove failed nodes.

Tip: Create a health check for every edge node so that failed nodes are automatically removed.

Distributing Content

All edge nodes must host identical content. For static sites generated by Jekyll, a simple rsync copies the generated HTML to each server. Dynamic sites like WordPress are harder to distribute because they cannot run directly on a CDN; a distributed storage solution would be required.

SSL/TLS Certificates

Each edge node needs a valid X.509 certificate for the domain. LetsEncrypt can generate certificates automatically, but rate limits may cause temporary outages (e.g., the London node was taken down when the weekly limit was reached). The author used Traefik as a reverse proxy, which supports distributed key‑value stores and Apache Zookeeper for backend synchronization.

Results and Observations

Performance testing showed significant improvement, though the author plans to add nodes in Asia and South America for further gains. After publishing the project on Hacker News, Google Analytics confirmed that the Singapore node reduced load times, while the India node still exceeded the target of one second.

FAQ

Common questions include why not use CloudFlare, S3/CloudFront, or Google AMP. CloudFlare’s cache eviction and limited header control make it less suitable for a constantly‑available blog. S3 + CloudFront cannot customize cache headers or nice URLs without Lambda@Edge, which suffers cold‑start delays. Google AMP only benefits traffic from Google Search, which is not the primary source for the author’s site.

Conclusion

Building a personal CDN is feasible for DevOps engineers who need global, low‑latency access to their sites. The source code is available on GitHub for anyone to clone and adapt.