Hoping the brain trust can help.

Single reverse proxy? No issues at all.
If I add multiple per some instructions on the caddy forums, nothing works - the docker container just continually reboots with no errors in the log.

Caddyfile:

fmd.domain.ca {
    reverse_proxy 10.179.200.199:8080
}

llama.domain.ca {
    reverse_proxy 192.168.3.199:3000
)

With only the fmd entry, works fine.

Idiot. Didn't close the last bracket and instead used a parentheses. D'oh!

Working as it should with the correction.

For once it wasn't DNS! 🔥🔥

Its never DNS! Unless it is, which is almost always.

It's a good idea to validate your config before reloading it (whether it's by running caddy reload or restarting/reprovisioning the container):

[docker exec -it caddy-container] caddy validate --config /etc/caddy/Caddyfile

Note that you are likely leaking a list of all your subdomains in certificate transparency logs. Some users might not want that to happen, in that case using a wildcard certificate can help, but it's either more tedious to set up (generating the cert outside of caddy) or less readable (using a Caddyfile with a single domain block for the wildcard containing a handle block per subdomains).

Its actually simpler than I expected to do the wildcard cert setup in Caddy. Its not necessary to nest everything. You can just add the wildcard block at the top, and leave the rest of the config as-is, and they will default to using the wildcard instead of individual certs.

That would be great. Though I've had that not work as expected at the beginning of 2026, but maybe you are right.

Thanks for this. Next project to look in to.

I user caddy-cloudflare with *.caddy files which allows me to get a signed wildcard cert for my internal subdomains. I did it for this exact reason, I didn't want to leak my internal subdomains.

This is a home lab, I have no change control or testing. It either comes up or it doesn't. We test in prod around here.

One day it's gonna bite me in the ass hard.