3 ms·
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 --de
by oefrha 1y ago
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 1y agoThe 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 1y agoThat’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 1y agoSure, 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.