There is a weird dynamic going on where defaults have become "good enough": ssh with public key configured and password auth disabled, services defaulting to only listening on localhost, etc., but those improvements have also cause people to pay much less attention to server hardening or to checking if any of their services might have unsafe defaults.

The world is made much better by safer defaults, but they also lead to a degree of complacency.

I had a quick look, that "deploy" user can run any sudo command without password? It's basically root at that point. I think that forcing a password (maybe using some lax timeout if you don't want to insert it so often) is a much better option. Correct me if I am wrong, but I also see that there are secrets in the file (e.g., gmail SMTP creds). Make sure the file is protected in read at a minimum. If those are your gmail app credentials, they are pretty serious and obtainable by just reading the file (same goes for postfix config).

Thank you for sharing, because I didn't know what cloud-init was until your post. I've done something similar, but packaged as a library of bash functions, designed to be called in arbitrary order. I cannot comment on the specific decisions you made in your file, but the fact that a declarative, compact, and standard solution exists for this problem is music to my ears. Out of curiosity, where did YOU learn of the existence of this feature?

server hardening is definitely an often overlooked aspect... that gist looks comprehensive. i'm curious, have you benchmarked the performance impact of all those security measures? it's a trade-off, right? some community members mentioned using CIS benchmarks as a starting point, then tailoring from there.

No need to even copy a folder, simply link it.

Docker compose + Cloudflare Tunnels is my current setup, no need to deal with SSL, have a public IP address, and if you make use of Tailscale, you do need any open ports, witch is extremely secure and robust.

Does it even configure caddy? I can’t see how the caddy config could be generated from the env.yaml (unless it relies on the directory name etc for the path).

Seems like something that could have been solved with just docker compose (by setting a remote DOCKER_HOST). If you need “automatic” proxying, then traefik can do it off container labels.

This sounds like a misconfiguration on your part. I've never had this problem with docker before. Are you sure it's not your makefile skipping something because you haven't made the docker bits phony targets (if you're using make as a "script runner", everything should be a phony target. A sign that you're using the wet tool, but I digress).