Caddy is a modern, open-source web server known for its automatic HTTPS and simple configuration. Learn about its pros, cons, and how to set it up on your Linux server.
Publish date: 8/2/2025
If you’ve ever set up a web server, you’re probably familiar with the usual steps: install Apache or NGINX, write a lengthy configuration file, and then go through the separate, often tedious, process of setting up SSL certificates with a tool like Certbot. While this process works, it can feel a bit clunky. What if a web server could handle most of that for you, right out of the box?
That’s the core idea behind Caddy. It’s a modern, powerful web server that prioritizes ease of use and security by default. It takes a different approach to web hosting, one that might save you a lot of time and configuration headaches.
In this article, we’ll explore what Caddy is, discuss its strengths and weaknesses, and walk through how to get it running on a Linux server.
Caddy is an open-source web server written in the Go programming language. It launched with a groundbreaking feature that has since become its main selling point: automatic HTTPS.
Unlike traditional web servers that require you to manually acquire, configure, and renew SSL/TLS certificates, Caddy does it all for you automatically. If you have a domain name pointed at your server, Caddy will seamlessly provision a certificate from Let's Encrypt and keep it renewed. This "secure by default" philosophy is central to its design.
Beyond that, it’s a capable and fast web server, reverse proxy, and load balancer, all configured with a remarkably simple file format.
Caddy has gained a loyal following for several good reasons, especially among developers and those who value simplicity.
This is Caddy’s killer feature. As long as your domain’s DNS A/AAAA records point to your server’s IP address, Caddy handles the entire lifecycle of your TLS certificates.
Anyone who has wrestled with NGINX’s server blocks or Apache’s .htaccess files will appreciate the Caddyfile. It’s a clean, human-readable configuration format that is easy to learn.
For example, here’s all you need to serve a static website from the /var/www/html directory with automatic HTTPS:
example.com {
root * /var/www/html
file_server
}
That’s it. Those three lines accomplish what might take a dozen or more lines and a separate Certbot command in NGINX.
Caddy isn’t just a simple file server. It comes with modern features that often require extra modules or complex configuration in other servers.
No tool is perfect for every job, and Caddy has a few trade-offs to consider.
Getting Caddy running on a Linux server, such as one running on a V.PS instance, is very straightforward. We’ll use Debian/Ubuntu as an example.
The developers of Caddy maintain an official APT repository, which makes installation easy.
First, add the Caddy repository’s GPG key:
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
Next, add the repository itself:
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
Finally, update your package list and install Caddy:
sudo apt update
sudo apt install caddy
Caddy's main configuration file is located at /etc/caddy/Caddyfile. Let's edit it to serve a simple static site. Make sure you have a domain name pointed at your server's IP address first.
Open the file with a text editor:
sudo nano /etc/caddy/Caddyfile
Replace the default contents with the following, substituting example.com with your actual domain:
example.com {
# Set this path to your website's directory
root * /var/www/mysite
# Enable the static file server
file_server
}
Create the directory for your website and place an index.html file in it for testing:
sudo mkdir -p /var/www/mysite
echo "<h1>Hello from Caddy!</h1>" | sudo tee /var/www/mysite/index.html
A very common use for Caddy is as a reverse proxy. For example, if you have a Node.js app running on localhost:3000, you can expose it securely with this configuration:
app.example.com {
reverse_proxy localhost:3000
}
Caddy will handle the HTTPS certificate for app.example.com and securely forward all traffic to your application.
Caddy is installed as a systemd service, so managing it is simple. After editing your Caddyfile, you just need to reload the service for changes to take effect.
Enable Caddy to start on boot and start it now:
sudo systemctl enable --now caddy
You can check its status to make sure everything is running correctly:
sudo systemctl status caddy
If you made changes to your Caddyfile, just reload the service:
sudo systemctl reload caddy
Congrats! You now have a Caddy web server running. If you visit http://example.com in your browser, Caddy will automatically redirect you to https://example.com and serve your page over a secure connection.
Caddy offers a fresh, modern take on what a web server should be. By bundling security and simplifying configuration, it lowers the barrier to hosting secure, fast websites and applications.
Why not give it a go? Worst case scenario, you can always go back to Apache or NGINX.
Thanks for reading! xTom provides infrastructure related products and services, such as dedicated servers, colocation, scalable KVM VPS, and more. We'd love to help you next! Just reach out to us today, and we'll configure a custom tailored solution for you.
Yes, Caddy is open-source software distributed under the Apache 2.0 license. It is completely free for both personal and commercial use.
Caddy is an ACME client that integrates with public certificate authorities like Let's Encrypt. When it starts, it scans your Caddyfile for domain names, performs the ACME challenge to prove ownership of those domains, and then obtains and installs TLS certificates. It also handles renewing them automatically before they expire.
Absolutely. Caddy is written in Go, a language known for concurrency and performance. It can serve thousands of requests per second and is suitable for the vast majority of production workloads.
It depends on your needs. For many use cases, especially where simplicity and automatic HTTPS are top priorities, Caddy is an excellent replacement. For enterprise environments with extremely complex legacy configurations or where squeezing out every last bit of performance is critical, NGINX might still be the more established choice.