Phenquestions
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:
$ curl https://getcaddy.com | bash -s personalOnce that is done, we can locate the binary, by running:
$ whereis caddycaddy: /usr/local/bin/caddy
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.
/var/www/mysite/index.htmlThis page is servered by Caddy Server
This is a paragraph.
This is enough to get us started. Now in the same directory as this index.html page, run the following commad:
$ caddyActivating privacy features… done.
http://:2015
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:
$ caddy -host subdomain.example.com## For the first time it will ask you for your email address so you can get
certificate renewal notification from LetsEncrypt
Output:
Activating privacy features…Your sites will be served over HTTPS automatically using Let's Encrypt.
By continuing, you agree to the Let's Encrypt Subscriber Agreement at:
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
Please enter your email address to signify agreement and to be notified
in case of issues. You can leave it blank, but we don't recommend it.
Email address: [email protected]
…
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:
subdomain.example.comroot /var/www/mysite
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:
$ caddy -conf /etc/CaddyfileThere 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:
subdomain.example.comroot /var/www/mysite
subdomain2.example.com
root /var/www/mysite2
gzip
log… /access.log
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.
