All articles
🚀 DevOps & Deployment 10 min read

Caddy vs Nginx for Beginners: Which Web Server Should You Use in 2026?

If you have ever deployed a web app to a VPS, you have probably faced the question: which web server should I use? For years, Nginx was the default answer. But in 2025 and 2026, a newer contender called Caddy has been winning over developers with its simplicity and automatic HTTPS. In this guide, I will break down both web servers, compare them head-to-head, and help you decide which one fits your projects best.

What Is Nginx?

Nginx (pronounced "engine-x") is an open-source web server that was first released in 2004 by Igor Sysoev. It was designed to solve the C10K problem, which refers to handling ten thousand concurrent connections efficiently. Today, Nginx powers over 34 percent of all websites on the internet.

At its core, Nginx uses an event-driven, non-blocking architecture. Instead of spawning a new thread for every request like older servers did, Nginx handles thousands of connections within a small number of worker processes. This makes it incredibly memory-efficient and fast under heavy load.

Nginx serves three primary roles:

  • Web server for serving static files (HTML, CSS, JS, images)
  • Reverse proxy for forwarding requests to backend applications
  • Load balancer for distributing traffic across multiple servers

What Is Caddy?

Caddy is a modern, open-source web server written in Go by Matthew Holt. It was first released in 2015 with a radical idea: HTTPS should be automatic and on by default. No more wrestling with Certbot, cron jobs, or certificate renewals.

Caddy ships as a single binary with zero dependencies. You download one file, write a few lines of configuration, and you have a production-ready web server with automatic TLS certificates from Let's Encrypt or ZeroSSL.

Like Nginx, Caddy can serve as a web server, reverse proxy, and load balancer. But it also supports HTTP/3 (QUIC) out of the box, offers a JSON API for live reconfiguration, and includes a plugin system for extending functionality.

Why Caddy Is Great for Beginners

If you are new to server management, Caddy removes almost every barrier to getting started. Here is why:

1. Automatic HTTPS With Zero Configuration

This is the single biggest reason to choose Caddy. When you point Caddy at a domain name, it automatically:

  • Obtains a TLS certificate from Let's Encrypt
  • Configures HTTPS with modern cipher suites
  • Redirects HTTP to HTTPS
  • Renews the certificate before it expires

With Nginx, you need to install Certbot separately, run a command to generate certificates, edit your Nginx config to reference the cert files, set up a cron job for renewals, and troubleshoot when renewals fail silently. Caddy eliminates all of this.

2. Simple Configuration

A Caddy reverse proxy config is remarkably concise. Compare a basic setup for both servers and the difference is striking. What takes 15 or more lines in Nginx can be accomplished in 3 lines with Caddy.

3. Single Binary Deployment

Caddy has no dependencies. No package conflicts, no library version issues. Copy one file to your server and you are ready to go. Nginx typically requires installing from a package manager and managing its dependencies.

4. Sensible Defaults

Caddy comes preconfigured with security best practices. TLS 1.2 and 1.3 only, strong cipher suites, HSTS headers, and OCSP stapling are all enabled by default. With Nginx, you need to configure each of these manually or use a tool like Mozilla's SSL Configuration Generator.

Setting Up Both: Caddyfile vs nginx.conf

Let me walk through setting up a reverse proxy for a Node.js app running on port 3000. This is one of the most common use cases for both servers.

Caddy Setup

First, install Caddy on Ubuntu or Debian:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf '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' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Now edit /etc/caddy/Caddyfile:

mysite.com {
    reverse_proxy localhost:3000
}

That is the entire configuration. Start Caddy:

sudo systemctl enable --now caddy

Caddy will automatically obtain a TLS certificate for mysite.com, set up HTTPS, and start proxying requests to your Node.js app. Done.

Nginx Setup

Install Nginx:

sudo apt update
sudo apt install nginx

Create a server block at /etc/nginx/sites-available/mysite.com:

server {
    listen 80;
    server_name mysite.com www.mysite.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Enable the site and test the configuration:

sudo ln -s /etc/nginx/sites-available/mysite.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Now add SSL with Certbot:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d mysite.com -d www.mysite.com

Certbot will modify your Nginx config to add the SSL directives and set up automatic renewal via a systemd timer. But you should still verify the renewal works:

sudo certbot renew --dry-run

The Nginx setup works perfectly well, but you can see the difference in effort. Caddy required 3 lines of config and one command. Nginx required 15 lines of config, symlink management, Certbot installation, and certificate generation.

Deep Dive: Auto-SSL, Reverse Proxy, and Multi-Site Hosting

Automatic SSL in Practice

Caddy's auto-SSL is not just convenient. It is also more reliable in my experience. Certbot renewals can fail silently if your server's port 80 is blocked, if your DNS changes, or if Certbot itself has a bug after an update. Caddy handles renewals internally using the ACME protocol, and it will retry with exponential backoff if something goes wrong. It also supports the TLS-ALPN-01 challenge, which means it can renew certificates even if port 80 is unavailable.

For local development, Caddy is equally helpful. If you use localhost as your domain, Caddy automatically generates a self-signed certificate and trusts it in your system's certificate store. No more browser warnings during local development.

Reverse Proxy Headers

When proxying requests, both servers need to pass certain headers to the backend so your app knows the original client's IP address and protocol. Caddy handles this automatically. It sets X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host without any configuration.

With Nginx, you must manually add proxy_set_header directives for each header. Forget one and your app might not know whether the original request was HTTP or HTTPS, which can cause redirect loops or security issues.

Multi-Site Hosting

Hosting multiple sites is where Caddy's simplicity really shines. Here is a Caddyfile that serves three different applications:

blog.example.com {
    reverse_proxy localhost:3000
}

api.example.com {
    reverse_proxy localhost:4000
}

dashboard.example.com {
    reverse_proxy localhost:5000
}

Each site automatically gets its own TLS certificate. With Nginx, you would need three separate server block files, three Certbot commands, and you would need to manage symlinks and test the configuration after each change.

For a real-world example, my own VPS runs multiple sites with Caddy. The Caddyfile looks similar to the example above, with each domain block pointing to a different port where PM2 manages the Node.js processes. Adding a new site takes about 30 seconds.

Serving Static Files

Caddy can also serve static files directly. This is useful for hosting a built Astro site, a React SPA, or any static content:

mysite.com {
    root * /var/www/mysite
    file_server
    encode gzip zstd
}

The equivalent Nginx configuration:

server {
    listen 443 ssl;
    server_name mysite.com;

    root /var/www/mysite;
    index index.html;

    gzip on;
    gzip_types text/plain text/css application/json application/javascript;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Again, Caddy is shorter and handles SSL automatically.

WebSocket Support

Both servers support WebSocket proxying. With Caddy, it works out of the box with no additional configuration. Caddy detects the Upgrade header and handles the protocol switch automatically.

With Nginx, you need to explicitly configure the Upgrade and Connection headers in your location block, as shown in the reverse proxy example earlier. This is a common source of confusion for beginners who find that their real-time features break after deploying behind Nginx.

Common Mistakes to Avoid

Mistake 1: Not Opening Firewall Ports

Both Caddy and Nginx need ports 80 and 443 open. On cloud providers like DigitalOcean, Hetzner, or AWS, you might also need to configure security groups or firewall rules in the provider's dashboard. Caddy's auto-SSL will fail silently if port 80 is blocked because Let's Encrypt cannot reach your server for the HTTP-01 challenge.

sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

Mistake 2: Running as Root

Both Caddy and Nginx can bind to privileged ports (80 and 443) without running as root. Caddy handles this automatically when installed via the official package. For Nginx, the master process runs as root but worker processes run as the www-data user. Never run your backend applications as root.

Mistake 3: Forgetting to Reload After Config Changes

With Nginx, editing the config file does nothing until you reload:

sudo nginx -t && sudo systemctl reload nginx

Always test with nginx -t first. A syntax error in any config file will take down all your sites when you try to reload. Caddy is more forgiving here. You can reload with sudo systemctl reload caddy, and Caddy validates the config before applying it. If the new config is invalid, the old config keeps running.

Mistake 4: Ignoring Log Files

When something goes wrong, logs are your first diagnostic tool. Check these locations:

  • Caddy: journalctl -u caddy --no-pager -f
  • Nginx: /var/log/nginx/error.log and /var/log/nginx/access.log

Mistake 5: Using Outdated Tutorials

Many Nginx tutorials online were written years ago and reference deprecated directives or insecure SSL configurations. Always cross-reference with the official documentation at nginx.org. For Caddy, the official docs at caddyserver.com are well-maintained and should be your primary reference.

When to Choose Nginx Over Caddy

Caddy is excellent for most use cases, but Nginx still has advantages in specific scenarios:

  • Extreme traffic: If you are handling tens of thousands of requests per second, Nginx's C-based architecture gives it a slight edge in raw throughput. For most sites, this difference is negligible.
  • Complex configurations: Nginx's module ecosystem is vast. If you need advanced features like GeoIP-based routing, custom rate limiting rules, or integration with third-party WAFs, Nginx has more options.
  • Team familiarity: If your team already knows Nginx well, switching to Caddy just for simplicity may not justify the migration effort.
  • Memory-constrained environments: Caddy's Go runtime uses roughly 50 MB of baseline memory. Nginx typically uses less than 10 MB. On a 512 MB VPS, this difference matters.

Frequently Asked Questions

Is Caddy production-ready?

Yes. Caddy v2 is stable and used in production by many companies. It has been around since 2015 and the v2 rewrite in 2020 was a major improvement. I run my own production sites on Caddy without issues.

Can I migrate from Nginx to Caddy?

Absolutely. The migration is usually straightforward because the core concepts (server blocks, reverse proxy, static file serving) map directly between the two. Start by rewriting your Nginx server blocks as Caddy site blocks and test in a staging environment.

Does Caddy support HTTP/3?

Yes. Caddy supports HTTP/3 (QUIC) out of the box with no additional configuration. Nginx added experimental HTTP/3 support in version 1.25, but it requires compiling with specific flags and is not enabled by default.

Is Caddy free?

Yes. Caddy is open source under the Apache 2.0 license. There are no paid tiers or feature restrictions. The company behind Caddy (ZeroSSL/Apilayer) offers commercial support, but the server itself is completely free.

Can I use Caddy with Docker?

Yes. Caddy has an official Docker image. You can mount your Caddyfile as a volume and expose ports 80 and 443. For Docker Compose setups, make sure your services are on the same network so Caddy can reach them by container name.

Conclusion

For beginners deploying their first web application to a VPS, I recommend starting with Caddy. The automatic HTTPS alone saves hours of configuration and eliminates an entire class of security mistakes. The simple configuration format means fewer opportunities for errors, and the sensible defaults mean your server is secure from the first request.

That said, learning Nginx is still valuable. It powers a massive portion of the internet, and understanding its configuration will help you in many professional environments. My suggestion is to start with Caddy for your personal projects and side projects, then learn Nginx when you encounter a specific need for its advanced features.

The best web server is the one that lets you focus on building your application instead of fighting with server configuration. For most developers in 2026, that server is Caddy.

#Caddy #Nginx #VPS #SSL