This just seems like several unnecessary layers of complexity to me.

For making a static site that you're personally deploying, exactly why is Docker required? And if the Docker process will have to bring in an entire Linux image anyway, why is obtaining Python separately better than using a Python provided by the image? And given that we've created an entire isolated container with an explicitly installed Python, why is running a Python script via `uv` better than running it via `python`? Why are we also setting up a virtual environment if we have this container already?

Since we're already making a `pyproject.toml` so that uv knows what the dependencies are, we could just as well make a wheel, use e.g. pipx to install it locally (no container required) and run the program's own entry point. (Or use someone else's SSG, permanently installed the same way. Which is what I'm doing.)

Author—though not OP—here. I’ll try to broadly address the questions, which are all fair.

Broadly speaking, I explicitly wanted to stay in the Coolify world. Coolify is a self-hostable PaaS platform—though I use the Cloud service, as I mentioned—and I really like the abstraction it provides. I haven’t had to SSH into my server for anything since I set it up—I just add repos through the web UI and things deploy and show up in my browser.

Yes, static sites certainly could—and arguably even should—be done way simpler than this. But I have other things I want to deploy on the same infrastructure, things that aren’t static sites, and for which containers make a whole lot more sense. Simplicity can be “each thing is simple in isolation”, but it can also be “all things are consistent with each other”, and in this case I chose the latter.

If this standardization on this kind of abstraction weren’t a priority, this would indeed be a pretty inefficient way of doing this. In fact, I arrived at my current setup by doing what you suggested—setting up a server without containers, building sites directly on it, and serving them from a single reverse proxy instance—and the amount of automation I found myself writing was a bit tedious. The final nail in the coffin for that approach was realizing I’d have to solve web apps with multiple processes in some other way regardless.

I created a static site generator for my wife's business using go + js + git. She has no tech skills whatsoever, but had very specific ideas about how the website should work.

Once the basic functionality was worked out in js (with a simple JSON schema and Lourm Ipsum text), I created a Samba share on the network, mapped it to her computer.

Her first post was an edit of the Lorum Ipsum markdown and some new images, and from then on she had a pattern to follow: add a directory with a markdown file and assets.

The NAS runs a Go program that generates a JSON file for the static site js, starts a http server for testing. She can access the http server over the network to preview the static site. If it's ok, she can trigger a git commit and push (with a click). She didn't have to learn anything (like Hugo or jinja), because markdown is kinda obvious. She has exactly the website she wants.

Of course, I had more work to do initially, coming up with the static site, the JSON schema and the go generator, but it was over a week of evenings. She's been happily adding to it regularly without my interaction.

And this, my friends, is why I (a mere DevOps / Cloud guy) "vibe code" with Claude.

> why is obtaining Python separately better than using a Python provided by the image?

I mostly work in a different domain than webdev, but feel strongly about trying to decouple base technologies of your OS and your application as much as possible.

It's one thing if you are using a Linux image and choose to grab their Python package and other if their boot system is built around the specific version of Python that ships with the OS. The goal being if you later need to update Python or the OS they're not tethered together.

My guess is that when you are self taught and don't know what the hierarchy of technologies looks like, you can learn several advanced technologies without knowing the basic technologies that they are built upon and the challenges the basic tech can't solve.

So you just solve all problems with advanced tools, no matter how simple. You get into tech by learning how to use a chainsaw because it's so powerful and you wanted to cut a tree, now you need to cut some butter for a toast? Chainsaw!

Looking forward to the follow up:

Static sites with HTML, CSS, Apache and Linux.

At my work we use docker for everything now. Makes no sense. Literally we have a dedicated server for each application. Instead of copying python files to the server in 5 seconds we take 30 minutes to build a docker container, copy to repo, scan it, deploy.

Simple answer is to package it up with all its system dependencies ans not worry about anything.