I really like developing against compose because it's light but gives you that escape hatch of translating to k8s if later circumstances call for it.
Very few separate ecosystem transfers are quite that frictionless.
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.
I like running docker compose for my simple needs because it consolidates pretty much all the config in one declarative file, and docker manages 'everything'. By now I know how to handle the handful of caveats listed in this article. Beyond what's listed there, I'd also give a mention to the way port publishing works (the fact that it ignores firewalls), as that's something that still trips people up if they don't know about it.
> docker compose pull && docker compose up -d is a fine command if you are SSH’d into the host. At customer scale—dozens of self-managed environments behind firewalls, each with its own change-control process—that manual process doesn’t scale.
No idea what this 'customer scale' operation is, but it seems like a pretty clear cut candidate for not using docker compose. I also don't think watchtower should be listed there, it's been archived and was never recommended for production usage anyways.
> I'd also give a mention to the way port publishing works (the fact that it ignores firewalls), as that's something that still trips people up if they don't know about it.
Isn't that a Docker thing rather than Docker Compose though? There is a ton more caveats to add if we don't already assume the reader is familiar with the hard edges of Docker, seems the article only focuses on Docker Compose specifically, probably because it'd be very long otherwise :)
TIL about limiting logs. Very useful, I had no idea.
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?
> does turkey sound good for you?
What if you can't by yourself objectively evaluate if turkey sandwich sounds good?
It's not a matter of giving a universal answer to whether docker compose in production is fine, but how to evaluate it. Which features or safeguards necessary for a healthy production environment you forfeit when choosing plain docker compose?
Is your point that we shouldn't motivate our technological choices? I wouldn't use Docker Compose in production.
I wouldn't use Docker in production.
Yes. I clearly believe we should not motivate choices in technology.
I also would not eat a turkey sandwich for lunch on a Tuesday.
*shudder*
Yes. It's perfectly fine.
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 and no :)
hahah came here to say: "It depends."
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.
I think k8s is a great choice today specially when you can plug it into Gitlab and have a control plane for your clusters in the same place where your code lives.
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
Only in certain bubbles, which certain people have trouble realising they're in
Sure, but you wouldn't just say "Oh they are a Postgres" company because they use that specific database somewhere in the stack.
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".
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.
I find the podman man pages quite readable and thorough if you've had experience configuring systemd systemd services. Good examples as well.
https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
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.
Is there no upstream package repo like docker has.
In many cases, Debian unstable is also a good choice.