Remix.run Logo
simonw 5 days ago

Almost every other comment in this thread is people complaining this is too complex and over-engineered.

I had the opposite reaction when I read this post: I thought it was a very neat, clean and effective way to solve this particular problem - one that took advantage of an excellent stack of software - Caddy, Docker, uv, Plausible, Coolify - and used them all to their advantage.

Ignoring caching (which it sounds like the author is going to fix anyway, see their other comments) this is an excellent Dockerfile!

  FROM ghcr.io/astral-sh/uv:debian AS build
  WORKDIR /src
  COPY . .
  RUN uv python install 3.13
  RUN uv run --no-dev sus
  
  FROM caddy:alpine
  COPY Caddyfile /etc/caddy/Caddyfile
  COPY --from=build /src/output /srv/
8 lines is all it takes. Nice. And the author then did us the favor of writing up a detailed explanation of every one of them. I learned a few useful new trick from this, particularly around using Caddy with Plausible.

This one didn't strike me as over-engineering: I saw it as someone who has thought extremely carefully about their stack, figured out a lightweight pattern that uses each of the tools in that stack as effectively as possible and then documented their setup in the perfect amount of detail.

oefrha 4 days ago | parent | next [-]

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.

hamdingers 4 days ago | parent | prev | next [-]

Meanwhile, my dockerfile for "purely static—hand-crafted artisanal HTML and CSS" is this:

  FROM nginx:alpine
  COPY . /usr/share/nginx/html
simonw 4 days ago | parent [-]

Sure, but that doesn't handle Plausible proxying or run the static site generator script.

indigodaddy 4 days ago | parent | prev [-]

Here's my dockerfile (hosted on fly). It was done before I knew about uv, but poetry works fine. Anything look wrong or any suggested optimizations?

https://raw.githubusercontent.com/jgbrwn/my-upc/refs/heads/m...