Caddy notes

Software
1

Interesting article about Caddy and its OSS journey:

2

Some good stuff with Caddy v2.3.0 release:

I’ve been using Caddy for years now on a handful of sites using Lets Encrypt for automatic SSL certs – great stuff. I’ve had nearly zero problems. Caddy sets a new standard for usability, efficiency, ease of deployment, and reliability – gone are the days of cryptic config files – for most sites, a Caddy config is just a few lines. Below is an example from a server where 3 static web sites (generated with tools like Hugo) are served, and a Discourse site is proxied:

        tmpdir.org {
          file_server * {
            root /var/www/tmpdir/website
          }
        }

        yoedistro.org, www.yoedistro.org {
          file_server * {
            root /var/www/yoe/website
          }
        }

        www.simpleiot.org {
          file_server * {
            root /var/www/siot/website
          }
        }

        community.tmpdir.org {
          reverse_proxy localhost:8080
        }

Caddy assumes you want HTTPs by default and automatically gets needed certs – just make sure your DNS is correct before starting Caddy so it can execute the cert handshake.

Deployment is as easy as copying a single binary to your server, or you can use this Ansible role to automate things a bit.

This is the way software should be!

3

Interesting feature in upcoming Caddy v2.4.0:

Self-upgrade command. The new caddy upgrade command will replace the current Caddy binary with an upgraded one from our website, with all the same modules installed, including third-party plugins! (We can use this code to add/remove modules later, too.)

This is how software should work – zero down time and almost zero effort to deploy updates. This reflects a new approach to software – instead of wrapping old technologies with layers of additional tooling (containers, etc.), lets reduce the need for any of that. Statically linked binaries, embedded assets, embedded databases, and now self managing updates – this brings sanity back into system administration – especially for the majority of us who are not Google.

4

Caddy is a wonderful web server – I can’t say enough good things about it. It is so easy to configure and use. Recently I needed to set up a local webserver with TLS to debug some secure websocket issues in SimpleIoT. This is very easy to do with mkcert and Caddy. See notes in SIOT project:

https://github.com/simpleiot/simpleiot/tree/master/testing

Running Caddy on development machine

This can be used to test TLS support for various things like wss:// upstream
URIs, etc.

  • configure one SIOT instance (the upstream) to run on port 8081
  • cd <this directory>
  • install caddy and mkcert (Arch has packages for both)
  • mkcert -install
  • mkcert siottest.com
  • sudo vi /etc/hosts
    • 127.0.0.1 siottest.com
  • sudo caddy run -watch
  • start another SIOT instance (the downstream) and configure upstream with URL
    set to wss://siottest.com – it will not connect to SIOT instance running on
    port 8081.

And the Caddyfile:

{
    debug
}

siottest.com {
    tls ./siottest.com.pem ./siottest.com-key.pem
    reverse_proxy localhost:8081
}

Very slick!
5

Caddy 2.5.0 is released:

Not sure what the following means, but looks interesting:

Automatic HTTPS: Caddy will automatically try to get relevant certificates from the local Tailscale instance (if running with permission to access the Tailscale socket). This makes services running on a Tailscale network automatically available over trusted HTTPS with Caddy.

6

@cbrake you might find this interesting

1 Like
7