Docker swarm might fit better if you want seamless rollout deploys and quick rollbacks. Also scaling and load balancing
Should I run plain Docker Compose in production in 2026?
281–290 of 312 posts
Re: Should I run plain Docker Compose in production in 2026?
#282Earlier quoted context omitted.
"It is simple to use, easy to organize and manage, and very robust." This is why nobody uses it. Cloud stuff has to be as baroque as possible.
To misquote Douglas Adams: There is a theory which states that if ever anyone discovers exactly what Kubernetes is for and how it works, it will instantly disappear and be replaced by something even more bizarre and inexplicable.
>if ever anyone discovers exactly what Kubernetes is for
This part is easy, Kubernetes is for your CV. /s
Re: Should I run plain Docker Compose in production in 2026?
#283Docker swarm might fit better if you want seamless rollout deploys and quick rollbacks. Also scaling and load balancing
I was looking for this comment. Seems to fit right in between “just” docker compose and a “fully-fledged” K8s. This book is running Erlang clusters on Swarm on EC2: https://www.goodreads.com/book/show/216601296.
Re: Should I run plain Docker Compose in production in 2026?
#284SRE here, my thought is "Sure, Docker Compose is great for production assuming your needs are light and Docker Compose works well for you." K8s as small time is overkill for sure but make sure you don't fall into this trap. https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
I spun k3s up with a config that I used an LLM to write. It's been almost 2 years. Thing just works for the most part. Even useful on a single node.
Yep, I've got a couple of single node k3s clusters and it just works. It can be a useful way to transition from applications running on their own dedicated servers to running on a true k8s cluster.
What it gets you is a more powerful Docker Compose running on server that you can interact with via kubectl. No SSH, no custom scripts etc. Just kubectl and YAML.
Re: Should I run plain Docker Compose in production in 2026?
#285SRE here, my thought is "Sure, Docker Compose is great for production assuming your needs are light and Docker Compose works well for you." K8s as small time is overkill for sure but make sure you don't fall into this trap. https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
That's mostly my take as well. I'm a big proponent of having separate teams for ops/deployment/sre from app development when you make the jump to k8s though. There's also a few bridge or in-between options for most cloud services as well. To me, if there's generally fewer than 10 actual active users at any given time and/or you can easily tolerate 30-60m of down time now and then... I'd lean into the simpler option o…
If you go cloud managed (EKS etc), there isn't really much to take care of. I do dev work and even keep a bare metal cluster going as well as a cloud managed one.
Probably needs a real generalist though which maybe doesn't include your average dev.
Re: Should I run plain Docker Compose in production in 2026?
#286Guess this is an unpopular opinion:
If you run more than one service/codebase, you might be better suited to using a proper container orchestration platform. Doesn't have to be Kubernetes. AWS ECS, GCP Cloud Run, Kamal are all modern options here.
If you run a single codebase in production, why are you even containerizing? Language ecosystems have done a phenomenal job of improving their dependency management since Docker was released. Python has uv. Go has modules. NodeJS has pnpm. Do you actually get benefit from containerizing if you're deploying to a single production host somewhere?
Re: Should I run plain Docker Compose in production in 2026?
#287Earlier quoted context omitted.
> you end up having to copy all the build dependencies (source code) to the host > disk, i/o exhaustion This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case. I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deployin…
>I'm specifically asking for that use case. That's what I answered for. >I'm not building binaries If you were, I would have added CPU to the list. >my "build" steps are actually deployment steps (npm build, composer install, etc) No, those are build steps. If you weren't using Docker, you would either run all those and shove in a zip/tarball or package into a deb/rpm, etc >The image I'm deploying by definition also…
> Images buy you a versioned artifact with all the code-level dependencies baked in.
Fair enough, that buys a little bit of time to not break deployments I supose.
> When the build process completes, it tears down the overlayfs
Ah okay, I misunderstood you then - I was referring to Docker-less servers and my build steps running there, not building the images on the machine.
Thanks for the info!
Re: Should I run plain Docker Compose in production in 2026?
#288Since all the tools around that orchestrate Docker Compose don't do these best practices, I made my own: https://yoink.is/
Things like a good security posture by default, health checks, drift detection, and port forwarding.
Re: Should I run plain Docker Compose in production in 2026?
#289I run it for my apps with traefik in front and is awesome. you can easily add services, DBs, backups and more and using the bin mounts you can migrate in painless way.
Re: Should I run plain Docker Compose in production in 2026?
#290I also configured some productions with docker compose. The biggest problem is to handle the case of machine reboot. Docker restart policy needs to be set to "no". That's also the problem if there would be dependencies between services. Solving that always lead to some type of hacks. I created a bash script that's run with SystemD on machine boot, to start all docker compose services one by one, to avoid them startin…
I use unless-stopped and containers come back up fine after reboot
That's the problem. If there are many heavy apps, you don't want to start all of them at once. There's no control about that, that I'm aware of. Also, if you have dependson, this is a compose feature and it's ignored when docker daemon is restarted.