People are complaining because

  make && make deploy

where the default target is simply `uv run --no-dev sus` and the deploy target is simply `rsync -avz --delete ./dist/ host:/path/to/site/` is hell a lot more neat, clean, effective, and lightweight? (And if you care about atomic deployment it's just another command in the deploy target.)

I have ~60 static websites deployed on a single small machine at zero marginal cost. I use nginx but I can use caddy just the same. With this "lightweight pattern" I'd be running 60 and counting docker containers for no reason.

▲ simonw 4 days ago | parent [-]

The author of this clearly mostly runs non-static sites in containers, but since they have container-based hosting setup already it's more consistent for them to deploy a static site with Caddy in a dedicated container than to spin up a new deployment mechanism that's inconsistent with everything else they are running.

Also their site isn't entirely static: they're using Caddy to proxy specific paths to plausible.io for analytics.

▲

oefrha 4 days ago | parent [-]

That’s what I’m saying. I can use nginx/caddy/whatever to proxy specific paths just the same, with a single server instance. Some of my static sites are even protected by SSO, with a shared auth endpoint proxied by nginx. Proxying wasn’t invented after containers after all, that’s basically an orthogonal concern here.

	▲	simonw 4 days ago \| parent [-]
		Sure, your way of solving this is great. That doesn't mean that a container-based Caddy solution in an existing container-based deployment environment built around Coolify isn't a reasonable way to solve this.