Installing Caddy Server on Ubuntu

TLS is important for all the websites and web apps out there. If there is an app that uses HTTP or does email, it needs TLS. TLS ensures privacy, integrity and authenticity of your content. With free TLS certificate authorities like Let’s Encrypt and CloudFlare, TLS is turning more into a norm rather than a special case.However, turning on TLS is often is a massively complicated process. It also has massive security ramifications, if the configurations are mishandled, or heaven forbid, you accidentally leak your private TLS key. To mitigate some of these risks and also to make our lives much easier, there’s a new web server in the town. Caddy speaks HTTP/2, and it comes with TLS enabled out of the box. This means that you don’t have to manually set up HTTP to HTTPS redirects or worry about a gallizion cipher suites that you have never seen before.

With Caddy web server, you get HTTPS or nothing. So let’s see how you can install Caddy on Ubuntu and configure it to serve your web app. We will be getting our TLS certificates from LetsEncrypt.

Setup

Assume you have a VPS with IP address: 10.20.30.40 and a FQDN subdomain.example.com who’s A record is pointing at this IP.
The VPS is running Ubuntu 18.04 LTS server edition and following configurations are done as the root user.

Step 1: Installing the Caddy Web Server

Caddy is written in Go, and can run as a standalone executable binary. However, there are various plugins that you can build into it for specific DNS servers, etc. We will be installing the the plain binary without any plugin so it works across all customizations.

To get your binary visit their official downloads page and select all the plugins and telemetry that you require. Below it will be a bash command to download and place the caddy server binary in the right location. As root user, run:

Once that is done, we can locate the binary, by running:

If you ever need to remove the server, or update it with newer executable, you now know where to look.

Step 2: Testing Your Website

If you don’t have a website, just create an empty folder and run the commands in there. You may get an Error 404 on your browser but the server setup can still be tested. If you do have a website traverse to the directory where the webroot of your website is located at. As a typical example, I will be selecting the /var/www/mysite as an example with the following index.html stored inside it.

This is enough to get us started. Now in the same directory as this index.html page, run the following commad:

WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with `ulimit -n 8192`.

Leave caddy running in this state.

You can go to your server’s public IP at port number 2015 to test this: http://10.20.30.40:2015 make sure that your firewall is not blocking this port.

And you will see that index.html is automatically served. This follows the age old convention that any website’s first page is named index which most web servers like Nginx, Apache and even Caddy serves up as the first page, even when you don’t specify this page by using /index.html at the end of the URL.

Step 3 : Setting up HTTPS

Now that you have confirmed that your website does indeed work with Caddy and can be served with it, it is time to setup HTTPS. To do this you can use the command line interface, or use a config file called as Caddyfile. We will use the command line first.

In the same directory as your website, run the following command:

Output:

That’s it! Your website is now up and running. You can visit subdomain.example.com and it will be automatically redirected to HTTPS without any custom port number or other nuances.

It is that easy! You can CTRL+C to stop the server, the next time it will just reuse this certificate.

Step 4: Writing your Caddyfile

The above method is good for experimental use cases where you are just testing the water. But if you want a running web server as a background process you need to write a Caddyfile and tell the web server to use this configuration to run your server.

This is the simplest example for the same website we hosted above:

The root directive tells the web server where the website is located. You can’t get out of this directory from client side. It is generally a good idea to place your caddy file anywhere but inside this webroot. You can place it in /etc/ folder or your home directory. For example, if the file is created at /etc/Caddyfile, you can tell the server to use this configuration, by running the command:

There are multiple directives that you can use to fine tune your server. You can enable logging, compression, reverse proxy, etc. The official documentation is a good place to start looking for directives related to your use case. Here’s another example where two websites with two different domain names are being served:

The directive gzip enables compression, if the client supports it. This improves performance as more data can be sent over the bandwidth and same interval of time. Logging helps with debugging and keeping track of network activity.

Conclusion

The greatest strength of Caddy web server is its easy to write and read config file and its flexibility across multiple platform. However, due to its weird licensing, the server is not strictly open source. The source code is open source, and you can totally compile it yourself and use the resulting executable, but the binary that you receive from the official site is not meant to be use for commercial purposes without proper license.

This brings us back to the issue of complications where instead of dealing with just config files, we also have to deal with the source code compilation defeating the purpose of easy to use web server. Let us know if you have any thoughts on Caddy, and if any of your websites run on top of it.