DPTCloud
Back to articles
Technology Insight

Building a Multi-Region Private CDN with Caddy and Varnish Cache: An Enterprise Guide

May 29, 2026

Introduction: The Case for a Private CDN in Modern Infrastructure

In the digital-first business landscape, application performance is directly tied to revenue. A one-second delay in page load time can lead to a substantial drop in conversions, lower search engine rankings, and degraded user satisfaction. While public Content Delivery Networks (CDNs) like Cloudflare or Akamai offer robust global infrastructure, they often introduce significant challenges for enterprises: spiraling bandwith costs at scale, rigid caching rules, compliance hurdles regarding data residency, and a lack of granular control over edge server configurations.

Building a Private CDN allows organizations to regain absolute sovereignty over their data delivery pipelines. By deploying a bespoke edge network across strategically chosen geographical zones, businesses can optimize caching policies for their specific workloads, implement strict security compliances, and drastically reduce long-term operational expenditures. In this technical guide, we will design and deploy a production-ready, highly available Private CDN utilizing three virtual private servers (VPS) positioned in distinct geographic regions, powered by the synergy of Caddy Server and Varnish Cache.

---

Architectural Overview: Why Caddy and Varnish?

The architecture of a modern edge node requires two primary capabilities: high-performance HTTP caching and effortless, secure reverse-proxying. To achieve this, we pair two industry-standard open-source technologies on each VPS node:

  • Varnish Cache: Renowned for its unmatched speed, Varnish sits at the core of our caching layer. Operating directly in memory, it intercept inbound HTTP requests and serves cached assets in microseconds, eliminating repetitive, resource-intensive hits to our origin server.
  • Caddy Server: Acting as the external-facing edge proxy, Caddy handles automated TLS orchestration via Let's Encrypt or ZeroSSL. It secures inbound user traffic, terminates SSL/TLS connections, and proxies clean HTTP requests back to Varnish. Caddy's modern architecture, HTTP/3 support by default, and ease of configuration make it the perfect front-door for our edge nodes.

Topology Design

For this deployment, we will utilize three VPS nodes located in distinct regions to ensure optimal global coverage and redundancy:

  1. Node 1 (Asia-Pacific - Singapore): Services traffic for users in Southeast Asia and surrounding markets.
  2. Node 2 (Europe - Frankfurt): Services the EMEA region.
  3. Node 3 (North America - Oregon): Covers the western and central Americas.

A GeoDNS or Anycast DNS service will sit ahead of these nodes, intelligently routing end-users to the closest healthy edge VPS based on geographical proximity.

---

Prerequisites and Environment Setup

Before beginning the installation, ensure you have provisioned three clean VPS instances running a modern Linux distribution, preferably Ubuntu 22.04 LTS or Ubuntu 24.04 LTS. Each server must possess:

  • A public, static IPv4 address.
  • Root or sudo privileges.
  • Inbound ports 80 (HTTP) and 443 (HTTPS) open on the system firewall.

Update the local package index and upgrade existing system packages on all three nodes before proceeding:

sudo apt update && sudo apt upgrade -y
---

Step 1: Installing and Configuring Varnish Cache

Varnish Cache will handle the heavy lifting of caching static and dynamic content. Since Varnish doesn't natively handle SSL/TLS certificate management efficiently at scale, we configure it to listen on the local loopback interface (localhost) on port 6081.

1. Installation

Install the latest stable version of Varnish Cache via the official package manager:

sudo apt install varnish -y

2. Configuring the Backend Origin

Edit the Varnish configuration file located at /etc/varnish/default.vcl. This file defines the behavior of your CDN node and tells Varnish where your actual application server (the origin) is located.

vcl 4.1;

backend default {
    .host = "origin.yourdomain.com";
    .port = "80";
    .connect_timeout = 5s;
    .first_byte_timeout = 10s;
    .between_bytes_timeout = 2s;
}

3. Advanced VCL Optimization Rules

To ensure high cache-hit ratios, append optimization rules within the vcl_recv and vcl_backend_response routines to handle cookies, cache-control headers, and static file optimizations:

Tip: Standard tracking cookies (like Google Analytics) often bypass Varnish caching completely if not explicitly stripped.
sub vcl_recv {
    # Forward client IP headers passed by Caddy
    if (req.http.X-Forwarded-For) {
        set req.http.X-Forwarded-For = req.http.X-Forwarded-For;
    }

    # Strip tracking cookies for static assets to force caching
    if (req.url ~ "\.(png|gif|jpeg|jpg|ico|swf|css|js|webp|mp4|woff|woff2)$") {
        unset req.http.cookie;
    }
}

4. Modifying the Varnish Systemd Service

By default, Varnish listens publicly on port 6081. We need to explicitly bind it to 127.0.0.1 to avoid external exposure. Edit the systemd service override:

sudo systemctl edit varnish

Add the following configuration block:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -a 127.0.0.1:6081 -f /etc/varnish/default.vcl -s malloc,2g

Restart Varnish to apply changes: sudo systemctl daemon-reload && sudo systemctl restart varnish.

---

Step 2: Installing and Configuring Caddy Server as the TLS Edge Proxy

Caddy will act as our public-facing gateway, accepting secure HTTPS connections, handling automatic TLS certificate negotiation, and passing requests directly down to Varnish.

1. Installation

Install Caddy via the official repository to guarantee access to the latest security updates:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf '[https://dl.cloudsmith.io/public/caddy/stable/gpg.key](https://dl.cloudsmith.io/public/caddy/stable/gpg.key)' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf '[https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt](https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt)' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy -y

2. Configuring the Caddyfile

Navigate to /etc/caddy/Caddyfile and replace its contents with an optimized production reverse proxy layout:

cdn.yourdomain.com {
    # Enable automatic HTTPS orchestration
    tls [email protected]

    # Optimize compression for edge delivery
    encode gzip zstd

    # Route all traffic to the local Varnish instance
    reverse_proxy 127.0.0.1:6081 {
        header_up Host {header.Host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }

    # Security headers
    header {
        X-XSS-Protection "1; mode=block"
        X-Content-Type-Options "nosniff"
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    }
}

Restart Caddy to initialize the automated TLS acquisition: sudo systemctl restart caddy.

---

Step 3: Multi-Region Synchronization and Geo-Routing

Repeat the steps above identically across all three regional VPS instances (Singapore, Frankfurt, Oregon).

Configuring Intelligent Routing via GeoDNS

Once all three edge nodes are up and running, you must configure a GeoDNS solution (such as Route 53, NS1, or Bunny DNS) to handle global traffic management. Create latency-based or geographic-based routing tables:

  • Traffic originating from Asia-Pacific: Route to the Singapore VPS IP.
  • Traffic originating from Europe & Africa: Route to the Frankfurt VPS IP.
  • Traffic originating from the Americas: Route to the Oregon VPS IP.

Configure a universal fallback health check. If the Frankfurt node goes offline unexpectedly, your GeoDNS provider must instantly re-route European traffic to the Singapore or Oregon edge nodes to prevent service interruptions.

---

Step 4: Monitoring, Validating, and Maintaining the Private CDN

To verify that your Private CDN is operating correctly, execute a curl command against your edge domain from an external network and inspect the HTTP response headers:

curl -I [https://cdn.yourdomain.com/assets/logo.png](https://cdn.yourdomain.com/assets/logo.png)

Look closely for the presence of the following diagnostic indicators:

  • Server: Caddy (Confirms the TLS edge layer intercepted the request).
  • Via: 1.1 varnish (Varnish/7.x) (Confirms Varnish processed the content caching layer).
  • X-Varnish (Displays unique Varnish lookup transaction IDs. If two numbers appear, the second number confirms a successful **Cache Hit**).

Conclusion: Full Sovereignty Over Global Delivery

By leveraging Caddy Server for streamlined TLS management and Varnish Cache for exceptional low-latency data caching, you have established a highly customized, resilient Private CDN across three critical global marketplaces. This setup not only offers profound performance optimizations tailored precisely to your application's logical requirements but also eliminates unpredictable edge-delivery data egress pricing models, positioning your enterprise infrastructure for cost-effective, scalable international expansion.

Building a Multi-Region Private CDN with Caddy and Varnish Cache: An Enterprise Guide | DPTCloud