![](/static/66c60d9f/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/ucPeLo62DS.png)
nginx just has a lower barrier to entry (imo) if you’re not looking to sign your own certs. Caddy is great for that.
That said, I didn’t know Caddy had a beta feature for serving Tailscale certs automatically. So I incorrectly thought you were barking up the completely wrong tree, which you apparently are not. I’ll look at your tech details more.
ah, yeah, that’s why. You need to mount the unix socket into Caddy’s container as a volume. Docker uses overlayfs by default to create a layered filesystem, and then launches a distinct user, process, network, etc. namespace for the container’s process, which is why everything is isolated inside the container. You’ll need to make sure the unix socket is available to Caddy’s process inside the container, so you’ll have to mount it using
-v
or thevolume
key in the yaml.sudo
is actually entirely unnecessary with Docker, because most containers will run as the container’s root. Part of containers having their own user and process namespace means their root user is not your root user (technically we can have a debate about semantics for overlayfs and mounted files), and almost all images will ship with the default user as their root. Therefore, almost all processes will be “run as root” from within their container by default, meaningsudo
does nothing except elevate the perms for the user callingdocker
. It would really only get around an issue with your user account not having access todocker
or the docker daemon (also via socket btw). That said, because of the user namespace thing, runningsudo docker run
orsudo docker compose up
doesn’t actually guarantee the process in the container is run as root… just that the container was created as root with perms over the host’s system.The important part is that Caddy inside the container will be run by a user that has permissions over the mounted socket.