Live data from Hacker News

Should I run plain Docker Compose in production in 2026?

distr.sh

121–130 of 312 posts

Re: Should I run plain Docker Compose in production in 2026?

#121
post #63

Docker Compose was production ready in 2015 and it still is today. I've lost track of how many projects I've deployed with it and never really ran into a single issue where Docker Compose was at fault. It's super solid. Some time ago I've written about my experiences using it in production https://nickjanetakis.com/blog/why-i-like-using-docker-compo... . Not just for my own projects but for $500 million dollar compan…

I love Docker Compose. It is simple to use, easy to organize and manage, and very robust. Also, our company does not need to "scale" production aggressively. Our production load is very predictable, so Docker Compose fits like a glove.

We have been using it for more than five years now. Before that, we had a legacy deployment model, and I do not remember a single major issue related to Docker Compose.

We use it for both staging and production environments. The same Docker image validated in staging is deployed to production. Never fails!

Re: Should I run plain Docker Compose in production in 2026?

#123
Personally I have moved to k3s, although after learning a bit too deep how k8s operates when writing custom controllers at the day job.

Docker/containers are great, especially for local development. But I feel the docker compose model quickly becomes a lot of messy brittle squeeze for little gain when multiple containers need to integrate.

Better then to just take the plunge for the "real deal" and set up a non-HA k8s/k3s cluster with the interactions between the workloads clearly specified.

In other words. I care care more about the interactions declaratively spelled out than the "scale to the moon" HA, auto-scaling, replicas or whatever people get sold on.

And LLMs make this even easier. If you love reviewing yaml manifests....

Re: Should I run plain Docker Compose in production in 2026?

#124
post #81
post #64

Earlier quoted context omitted.

Helm mostly does that. Not a huge fan of a text templating engine generating yaml but once you get your chart setup with a few variable inputs, you can continue using it for a bunch of other stuff with minimal new config. The inputs (values) are yaml so you can make it look exactly like a Docker Compose file if you want (wouldn't be surprised if there's some charts floating around that do that)

I've recently been dipping my toes into k8s / kustomize / helm, and I recently had a situation where having a base deployment yml template that I wanted to reuse across various deployments. I had a look at Helm and I was frankly shocked how bad the templating was with Go templates, it was close to unreadable and felt very brittle!

How so? I find it much the same to other templating engines like Jinja, though I'm definitely not a fan of the syntax. But that hardly matters anymore with LLMs.

Re: Should I run plain Docker Compose in production in 2026?

#125
Sure, it's stable enough, just keep in mind you won't get any autoscaling (or manual for that matter). Swarm is still supported by a third party, but that party has been loudly signaling that they intend to kill it off this year or next. Kubernetes isn't too big a leap, but damn are all those yaml manifests annoying to maintain. I usually just copy and tweak them from another project.

Re: Should I run plain Docker Compose in production in 2026?

#126

Earlier quoted context omitted.

So we agree people shouldn't write off these posts with "does turkey sandwich sounds good to you" like it's some deep insight to default to the trivial answer?

Does a turkey sandwich sound good to you? Yes: okay try it No: okay you don't have to try it Unsure: okay you can read about it some more and decide if it sounds good to you

Are we still talking about infrastructure?

Re: Should I run plain Docker Compose in production in 2026?

#127
post #19
post #13

Earlier quoted context omitted.

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.

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

I think it's just to get the AI keyword in there.

Re: Should I run plain Docker Compose in production in 2026?

#128
post #81

Earlier quoted context omitted.

I've recently been dipping my toes into k8s / kustomize / helm, and I recently had a situation where having a base deployment yml template that I wanted to reuse across various deployments. I had a look at Helm and I was frankly shocked how bad the templating was with Go templates, it was close to unreadable and felt very brittle!

How so? I find it much the same to other templating engines like Jinja, though I'm definitely not a fan of the syntax. But that hardly matters anymore with LLMs.

[deleted]

Re: Should I run plain Docker Compose in production in 2026?

#129
post #63

Docker Compose was production ready in 2015 and it still is today. I've lost track of how many projects I've deployed with it and never really ran into a single issue where Docker Compose was at fault. It's super solid. Some time ago I've written about my experiences using it in production https://nickjanetakis.com/blog/why-i-like-using-docker-compo... . Not just for my own projects but for $500 million dollar compan…

Hey, just want to say thank you for your blog. I've learned so much about Docker, dev tooling, and engineering from reading it over the past 7 years.

Re: Should I run plain Docker Compose in production in 2026?

#130

I am using systemd + go binary deploy. Running 10 years+ in production. Meanwhile docker based setup fail every now and then. And kubernetes? well forget about it.

That's like comparing you being able to make a salad from tomatoes and an industrial tomato sauce making facility. Both take tomatoes and end up with food, but the scale is completely different.

Yes, you can deploy a Go binary easily with systemd. Could you reliably do this across a fleet of machines? Including managing its configuration, persistent storage, database, network setup, etc.? Maybe, just need Ansible or equivalent config management. What if it were multiple Go binaries? And what if some of them needed to scale up some days because they hit more traffic than the others?

And on and on. Yes, not everyone needs Kubernetes, Nomad or other advanced orchestrators. But comparing them to running a Go binary with systemd is an unfair comparison.

Post reply on HN