Hi! Thanks for the kind words! I’m not taking the comments to heart, though I might write a follow-up post explaining why I chose this stack to pre-empt the surprising number of assumptions, and I might keep this in my for other, future posts.
I’m glad this lead to some learning for you! Some of the comments did that for me, which is great.
Author (not OP) here. In hindsight, I wish I’d explained “the why” mostly to save so many folks in this thread from making lots of assumptions. The third paragraph in this comment touches on that: https://news.ycombinator.com/item?id=44993875
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!
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 explicitly wanted to stay in the Coolify world.
I too was skeptical of the motivation until reading this. Given that Coolify requirement, your solution (build static files in one container, deploy with Caddy in another) seems quite sensible.
So what you're saying is that "Static sites with Python, uv, Caddy, and Docker" wasn't the overall goal. You want to stay in Coolify world, where most things are a container image.
It just so happens that a container can be just a statically-served site, and this is a pattern to do it.
By treating everything as a container, you get a lot of simplicity and flexibility.
Docker etc is overkill for the static case, but useful for the general case.
Location: Los Angeles, CA, USA
Remote: Yes, exclusively
Willing to relocate: No
Technologies: Python, AWS, TypeScript, open to others
Résumé/CV: https://nkantar.com/resume
Email: hn@nkantar.com
More: https://nkantar.com/blog/2023/08/hire-me-v202308/
Location: Los Angeles, CA, USA
Remote: Yes, exclusively
Willing to relocate: No
Technologies: Python, AWS, TypeScript, open to others
Résumé/CV: https://nkantar.com/resume
Email: hn@nkantar.com
More: https://nkantar.com/blog/2023/08/hire-me-v202308/
Location: Los Angeles, CA, USA
Remote: Yes, exclusively
Willing to relocate: No
Technologies: Python, AWS, TypeScript, open to others
Résumé/CV: https://nkantar.com/resume
Email: hn@nkantar.com
More: https://nkantar.com/blog/2023/08/hire-me-v202308/
Location: Los Angeles, CA, USA
Remote: Yes, exclusively
Willing to relocate: No
Technologies: Python, AWS, TypeScript, open to others
Résumé/CV: https://nkantar.com/resume
Email: hn@nkantar.com
More: https://nkantar.com/blog/2023/08/hire-me-v202308/
