Kubernetes sounds like overkill, but I've been running microk8s for few standalone servers. This feels a pretty good match when working with agents. Codex can manage the cluster also over ssh, schedule new pods, check statuses, logs etc.

Should you have a turkey sandwich for lunch in 2026? I don't know buddy just do whatever. There are ten thousand other sandwiches you could eat surely, but does turkey sound good for you?

Is your point that we shouldn't motivate our technological choices? I wouldn't use Docker Compose in production.

I also would not eat a turkey sandwich for lunch on a Tuesday.

*shudder*

Yes. I clearly believe we should not motivate choices in technology.

I think many of these issues are also solved by Podman and systemd depending on what kind of "production" you're building for. If you're building a linux-y appliance and you need to run a few containers I think Podman is a much better and more ergonomic way of doing so. I think perhaps that's less true for running a web service (where the linux environment is just a means to that end).

What are the benefits of running Podman Compose instead of Docker Compose? I don't see how it helps with orphan containers, logs and mutable tags.

Yes, I recommend this: https://www.redhat.com/en/blog/kubernetes-workloads-podman-s...

Is there a nice guide for podman that includes quadlets (or saying not to use them?) I find lots of guides stray into things that work on redhat, and on my Linuxes of choice, Raspbian and Ubuntu, things aren't straightforward.

Can't comment on Raspbian, but Ubuntu LTS (has/had) a seriously outdated podman version. This is the kind of nuisance the Debian derivatives have been running into for more than 20 years: they are extremely conservative, and if that is all you need, then that is great, but if not, you'll have to either run the latest Ubuntu (not LTS), or you upgrade to something like fedora.

In many cases, Debian unstable is also a good choice.

Is there no upstream package repo like docker has.

My experience with docker-compose is a bit outdated, but my impression some years ago was that it was too sensitive and fragile. I encountered bugs or incompatibilities that broke the docker-compose setup often enough to be forced to pin the specific docker and docker-compose versions.

And the error handling was terrible. Most of these problems resulted in a Python stack trace in some docker-compose internals instead of a readable error message. Googling the stack trace usually lead to a description of the actual problem, but that's really not something that inspires confidence.

Surprised they didn't mention docker compose secrets - https://docs.docker.com/reference/compose-file/secrets/

To be honest I never really understood the benefit of Docker (Compose) Secrets - which a different from Swarm Secrets. Imho there just plain host mounted volumes, which are hidden from inspect commands?

Yes. It's perfectly fine.

Very cool article. Wish it didn't have silly AI-isms:

> This is the shape Distr lands on

It's an AI company, it's kind of expected at this point - who would take an AI company seriously if they don't use AI themselves?

Why do you say it's an AI company? It seems like their business is "Distribute your application to self-managed customers" not especially AI focused.

Every company these days are AI companies. Even the ones you’d least expect. https://www.bbc.com/news/articles/c98mrepzgj7o

Sure, but you wouldn't just say "Oh they are a Postgres" company because they use that specific database somewhere in the stack.

Only in certain bubbles, which certain people have trouble realising they're in

They said they help deployments for "software companies and AI companies" which I thought was an interesting distinction

That's just different customer personas for marketing reasons, just like Vercel has "Build and deploy on the AI Cloud" as their main tag line on the landing page. It doesn't mean they are an "AI company".

TIL about limiting logs. Very useful, I had no idea.

Yes and no :)

hahah came here to say: "It depends."