Should I Run Plain Docker Compose in Production in 2026?

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?

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).

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 prefer Portainer to manage my docker composes. It is simple and can do it all instead of using cli. Added benefit if you have multiple hosts and want to manage them from one place. And you can extend the whole setup with git for version control.

Compose is great, but a couple things always created friction for me when using it for non-local setups:

* Lack of a user-friendly way of managing a Docker Compose installation on a remote host. SSH-forwarding the docker socket is an option, but needs wrappers and discipline.

* Growing beyond one host (and not switching to something like Kubernetes) would normally mean migrating to Swarm, which is its own can of worms.

* Boilerplate needed to expose your services with TLS

Uncloud [1] fixed all those issues for me and is (mostly) Compose-compatible.

[1] https://github.com/psviderski/uncloud/

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.

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

> This is the shape Distr lands on

> if you close the operational gaps it leaves: cleanup, healing, image pinning, socket security, and updates.

Ie you need a sysadmin. Oops, you fired them all 10 years ago when agile devopsing became the best thing after the pumpkin latte.

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.

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

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

AI article with 27 occurrences of dashes —

Yes. It's perfectly fine.

Yes and no :)