Caddy - A simple next generation webserver
Caddy a next generation web server.
This blog is built on top of Jekyllrb, a static web page generator which takes in markdown and spits out static pages, which can then be served by a web server for people to enjoy.
In the past I would have generally looked to use apache2 or maybe nginx as the web server, that is until a colleague of mine introduced me to Caddy.
What is Caddy
Caddy is a super easy to setup web server which also features automatic SSL provisioning using Lets Encrypt.
The learning curve of Caddy is much smaller than something like Apache2 or nginx, which requires the editing of multiple config files, and the installation of additional packages.
Most people would should be able to get Caddy up and serving in a matter of minutes, and whilst Caddy is simple to configure it is not lacking in features.
Features
- Automatic SSL.
- SNI support.
- Static file serving.
- Reverse proxy ability.
- Including setting and modifying headers.
- Support for hosting and exposing PHP applications using fast-cgi.
What am I using it for.
Well for one, the blog post your reading here is being served by Caddy, and is making use of the automatic SSL enablement. I will also be using it as a reverse proxy for Teleport, and anything else I need to host with easy to manage SSL.
Config quick look.
So I wont walk you through the installation of Caddy, its simple enough and there is plenty of documentation available on the Caddy site, but I will quickly show you the Caddyfile used to expose this blog. Hopefully this will help explain why its such an exciting and easy to use product.
Relf.co Caddyfile.
The Caddyfile is the main config file for Caddy, it is written in JSON and contians all the info needed to start and run the Caddy server.
At the very top of the file is the Global config. For a basic setup all that is really needed here is;
{
email "steve@relf.co"
}
This is used to allow Caddy to associate LetsEncrypt certs with your email address. If your not going to use the auto ssl feature, even this is not needed.
After the General Settings block, comes the site directives. These are used to control each of the sites you wish to host. So for example;
relf.co {
root * /usr/share/caddy/relf.co
file_server
encode gzip
log {
output file /var/log/caddy/relf_co_access.log {
roll_size 1gb
roll_keep 5
roll_keep_for 720h
}
}
}
Working line by line; relf.co
is the site name, and any requests from a browser with the host head of relf.co will then fall into this block.
Next we have the line root * /usr/share/caddy/relf.co
this says to Caddy to use the directory /usr/share/caddy/relf.co
as the web root.
The file_server
statement tells Caddy that this is a static page site, and to serve pages from the webroot as they are requested.
encode gzip
just informs Caddy to use the gzip style of compression.
The section log
sets up the logging output for Caddy for this particular site.
And that’s it.
But hang on I hear you say, I thought you were serving this blog with TLS encryption, and if so, where are the lines needed to set the keys and the certificate, and even the cyphers to be used. Well that’s the beauty of Caddy, as long as you use a domain name as the site declaration Caddy will assume you want to try and host the site using TLS, and will automatically head off to LetsEncrypt.org and request a certificate, and as long as DNS is setup correctly, and your Caddy server can be reached on ports 80/443 the cert will be requested, authorised and configured for your site. Caddy will also take care of renewal of the cert every 90 days.
I love the simplicity of Caddy, and its currently my go to webserver for most tasks. Why not give it a try the next time you need to host something.
Until next time. Steve.