I don't really have an opinion on using caddy in a container to serve a static site. That's fine, really.. However, the way the container is built is done in the worst possible way:

  # copy all files
  COPY . .

  # install Python with uv
  RUN uv python install 3.13

  # run build process
  RUN uv run --no-dev sus

This adds the entire repository to the first layer, then installs python, then runs the build which I assume will only then install the dependencies. This means that changing any file in the repository invalidates the first layer, triggering uv reinstalling python and all the dependencies again. The correct Dockerfile would be something like

  # install Python with uv
  RUN uv python install 3.13

  # copy info for dependencies
  COPY pyproject.toml uv.lock .

  # Install dependencies
  RUN uv whatever

  # Copy over everything else
  COPY . .

  # run build process
  RUN uv run --no-dev sus

▲ nkantar 5 days ago | parent | next [-]

Author (not OP) here. It hadn’t really occurred to me to optimize the Dockerfile in this way because of how rarely the build is run in the first place, but I’m absolutely going to do this, since the ratio of code changes to content changes will definitely skew heavily toward the latter, and it just seems like a good habit anyway. Thanks for reminding me, and even explaining how to do it!

▲ codespin 5 days ago | parent | prev | next [-]

Getting the dockerfile order right is critical due to how docker caching works.

Even if you aren't an expert it is trivial these days to copy/paste it into chatGPT and ask it to optimize or suggest improvements to the dockerfile, it will then explain it to you.

▲ globular-toast 5 days ago | parent | prev | next [-]

My heuristic to go from least likely to change to most likely, bearing in mind dependencies, of course.

▲ krick 5 days ago | parent | prev | next [-]

Exactly. I wanted to also point this out in the relation of the author's desire to put all build commands in `just` configuration file. It sounds to me like a desire to use some another "slick and shiny tool" (which `just` is when compared to `make`), but what's the point exactly? The build-process will still be container-dependent and may or may not work outside of the container, and you don't get the benefit of Docker caching anymore.

▲

simonw 5 days ago | parent [-]

Being able to run "just build" in a container-free local development environment and have the same build process run as the one in your production setup is a productivity boost worth having.

Same as how it's good to be able to easily run the exact same test suite in both dev and CI.

▲

krick 4 days ago | parent [-]

But wouldn't you run whatever you are writing in Docker container on dev anyway? I always did just that, as long as I use Docker as a deployment tool for a project at all. And, in fact, even sometimes when I didn't, since it's much easier and cleaner to keep, say, multiple php or redis versions in containers, than on your PC. And it's only maybe a year since it became actually effortless to maintain all this version-zoo locally for Python, thanks to uv. In fact, even when it's something like Go, so the deployable is a compiled binary, I'd usually wrap the build process into a Docker container for dev anyway.

	▲	simonw 4 days ago \| parent [-]
		Depends on how complex your stuff is. Most of my own projects run outside of Docker on my machine and run inside Docker when deployed. I have over 200 projects on my laptop and I don't want the overhead of 200 separate containers for them.

▲ pvtmert 5 days ago | parent | prev [-]

delayed