Discovering Caddy Server — Training Setting up a Web server
In this video we will discover Caddy which is an open source web server written in go offering the establishment of SSL certificate automatically.
Advantage over Nginx/Apache
I’ve been using nginx for a while to set up my web servers but Caddy comes up with interesting points on some problematic aspects.
- Nginx and Apache have a configuration that quickly becomes long and verbose for simple cases (reverse proxy, https…). The same configuration only takes a few lines on Caddy
- Generating SSL certificates via let’s encrypt is a bit tricky because you have to configure the server a certain way to accept certificate verification the first time. Caddy has an automated system that requires no intervention for the generation of certificates.
- The priority order of the rules can sometimes be complex to understand on nginx, Caddy has a route system allowing better control.
- Caddy is extensible using modules which can be written in golang (a little easier to learn than C)
Installation of Caddy
Caddy can be used as a simple executable (practical for a docker configuration or in the case of a development server) but also as a service. In the context of Ubuntu, the installation of Caddy is done in the traditional way by adding it to the list of repositories.
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
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
Once installed the service will automatically start and respond on port 80 (HTTP) with the default homepage. Caddy can then be configured using the file Caddyfile
present in the file /etc/caddy/
Configuration
The configuration is very simple thanks to a series of directives
demo.droapp.com {
reverse_proxy 127.0.0.1:3333
encode gzip
}
Then just reload the service systemctl reload caddy
so that Caddy can retrieve the certificate associated with the domain name to support HTTPS. And here is your site working!
If you want to distribute the files in the folder public
without going through the reverse proxy you can use request matchers which allow you to add a condition to certain directives.
demo.droapp.com {
root * /var/www/demo.droapp.com/public
# On passe par le proxy sinon
reverse_proxy @notStatic 127.0.0.1:3333
encode gzip
# On délivre les fichiers directement
@notStatic not file
file_server
}
# Redirection www. -> .
www.demo.droapp.com {
redir https://nodadonis.droapp.com{uri}
}
The order of the directives in the file does not matter and is predetermined by Caddy.
The documentation also shows typical cases of configurations.
The negative points
Obviously everything is not perfect and I encountered some problems (perhaps for lack of knowledge so do not hesitate to correct me).
- The JSON log format is a little less readable than the nginx format (maybe a matter of habit), although more easily parsable by third-party tools.
- There is no pre-integrated anti-burst system (a third-party module exists but I haven’t tested it)