Ha, same here. HAProxy plugin running on my opnSense. I should probably try caddy because HAProxy is complete overkill for my requirements.

Any specific reason you think they should be backwards? I have only limited exposure to the alternatives, but caddy was the easiest for me to set up when I was looking for a reverse proxy.

My main issue with caddy was having to compile in any extensions manually, but you don’t even need to do that anymore.

Absolute psychopath.

This! I’ve setup Traefik and use traefik-redis and traefik-kop to pull in labels from my other Raspberry Pis so I can spin up my containers on any of the Docker hosts without having to change anything in the proxy config.

First time I heard of migrating from Caddy to Traefik and not the other way around. The usual complaint about Traefik is that it’s too complicated to manage all of the moving parts. I have only used Caddy with Dockerized setups though so I don’t know what the others are like.

Yeah, I had lots of service configured like that, and you are correct that it is awesome, however I have other services on other hosts (not on docker swarm either) so I needed to delve into file config quite often, and doing some web dev work, I had services that weren’t dockerized, so I ended up creating dummy services (socat containers) to make them easy. It just got a bit frustrating and taking too much headspace, I was able to setup caddy in about 2 hours one evening, so I am pretty happy so far, and I can see all my hosts in a single file which is great ( I ended up with orphaned routes etc… from containers I forgot about when I was testing things).

As you say, different people come at the same problem and come away with totally different views ( which is pretty great that there are enough option that we can all find something that works for our needs ).

Completely a personal preference, but this is one reason I prefer caddy. I like to keep the configs separate and not clutter up my compose files.

It means I need to update two things when adding a new service (a compose file plus my caddy file), but I like the separation of concerns.

It also makes my proxy config consistent for all services, regardless of whether that run in docket or elsewhere.

Caddy was working fine for me until I scaled my homelab and had around 70 running containers. It constantly gave me 502 upstream errors, I tried all I could to isolate the problem (reducing the number of containers, reducing the number services Caddy handles, reworking Caddyfile), but the timeout still occurs with every service, I searched everywhere and couldn’t find a working solution.

Then I tried out Traefik, set up a dynamic file configuration for all my containers, and haven’t had a single 502 since. The dynamic configuration is such a nice thing to have Im never leaving Traefik. Plus it seems more in line with UNIX philosophy as it is modular with the middlewares and plugins.

I am aware of it, haven’t needed to use it, but seems pretty powerful.

I use docker-compose, and basically just end all my docker-compose.yaml files with

networks:
  default:
    external:
      name: proxynet

This redefines the default network to a pre-existing proxynet network. All services that do not specify a network configuration automatically get added to that network. Because this refers to the same network in each file, it is shared even with services defined in other yaml files (which is not the default).

The proxynet network was created manually using docker network create proxynet.