One good thing about doing your own personal IT in the small is you can always try new things.

Curious about some upstart server daemon? Backup the config file for the old one and deploy the new one. Maybe your last disappointed you? Maybe you’re just curious.

First, we need to configure the new sweetness for our needs. No matter how good the documentation and how basic your use case may seem, most good things require some assembly.

Today we are trying the Caddy http(s) server. Because I’m entering my Go-curious era.

The configuration I have put together does the following:

• Statically serves files from the webroot for my site.
• Handles 404 errors with a custom page for the Humans and any sufficiently evolved bots to digest
• Logs access requests
• Redirects www. to not have that

From my own /etc/caddy/Caddyfile, and yes… Caddy’s configuration file capitalizes the C in Caddyfile for reasons that evade my understanding:

aaronrogier.net {
        root * /var/www/html/aaronrogier.net
        file_server
        handle_errors {
                @404 {
                expression {http.error.status_code} == 404
                }
        rewrite @404 /404.html
        file_server
        }
        log {
                output file /var/log/caddy/caddy.log {
                roll_uncompressed
                }
                format json
        }
}

www.aaronrogier.net {
        redir https://aaronrogier.net{uri}
}

I will note that the memory footprint I am seeing isn’t too different from what I saw with Lighttpd, but I have not exactly been stress testing these daemons. The memory footprint of the daemon itself seems chonkier than Lighttpd’s was, but Lighttpd also required a larger supporting cast to get running with certificate autorenewal.