Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should I run plain Docker Compose in production in 2026?

distr.sh

Post reply on HN
Print view View original

171–180 of 312 posts

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

#171

Post by declan_roberts »

gomoboo wrote: post #116
merpkz wrote: post #57

How do you guys, who run Docker in production deal with managing nftables firewall on hosts running containers? By design docker daemon creates and manages a set of firewall rules to forward traffic between containers and ingress traffic into containers as well as masquarades the outgoing container traffic. That is all well until admin needs to alter hosts firewall to allow and deny other traffic unrelated to docker…

I put a firewall ahead of the Docker host so that they aren't running on the same system. Docker can do what it wants to on the host without stepping on my firewall rules.

It makes sense but that's more overhead and the spirit of the post seems to be "can we just docker compose and be done with it?"

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

#173

Post by stackskipton »

freedomben wrote: post #102
calmoo wrote: 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!

I did that too, and ended up just skipping helm and using envsubst to interpolate the values I need at runtime from env vars. Nearly everyone preferred that approach. YMMV of course.

BTW, this is what Flux V2 (GitOps) supports as well and we do at our company. It's worked well and covered almost all our use cases.

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

#174

Post by nijave »

calmoo wrote: post #81
nijave wrote: 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!

Yeah, that's fair. I don't think it's as bad if you make your own charts and can more liberally hardcode things. Community charts tend to have an insane amount of "knobs" so you can basically change everything being templated.

I don't know if I'd necessarily call it brittle, though. You can use `helm template` and various linters to validate the generated yaml is correct (and use something like pre-commit to autorun)

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

#175

Post by nijave »

freedomben wrote: post #102
calmoo wrote: 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!

I did that too, and ended up just skipping helm and using envsubst to interpolate the values I need at runtime from env vars. Nearly everyone preferred that approach. YMMV of course.

I think that's a good approach if it works for your use case. Sometimes you might want something slightly more sophisticated like basic logic (loops/conditionals). In those cases, you can still use helm but you have an extremely simple template and avoid many of the "can't read this template" helm pitfalls.

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

#176

Post by fragmede »

dec0dedab0de wrote: post #131
nixpulvis wrote: post #51

Earlier quoted context omitted.

Surely we can give more informed answers to questions like this than to compare a technical decision to the craving for a sandwich. Comments like this are apathetic and reduce the challenges of good software engineering to hopes and random chance.

The analogy you are replying to is pointing out that it works just fine for production, so if you should use it or not is simply a matter of taste. More to the point, there is no objectively right answer of what stack you should use. There are plenty of objectively wrong answers, but compose isn't one of them.

Even the wrong answers, it comes down to who's dealing with the mess? Who's paying for the site's uptime? Who isn't getting paid while the site isn't up?

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

#177

Post by stackskipton »

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

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

#178

Post by nijave »

regexorcist wrote: post #124
calmoo wrote: 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.

I think it's a combination of text templating + yaml (which is whitespace delimited). When templating html with Jinja, it's not a big deal if the indentation isn't right. In helm, best case you get a syntax error, worst case you end up overwriting keys and producing something syntactically but not logically correct.

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

#179

Post by jdw64 »

gear54rus wrote: post #153
api wrote: post #140

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

It's simple to use only for toy use cases, that's why nobody uses it. The article everyone in this thread seems to like only goes as far as 'I pushed to git so it must be ok' which is laughable and I'm not even DevOps. What happens if it errored on deployment or after that? you wanna write custom (bash? :D) hooks for that? What about upgrading your 'very vertically scalable' box? What if it doesn't come up after the…

I think people are using different meanings of “production environment.”

I agree with gear54us and upvoted their comment, but I also understand what the author of the root comment is saying.

I have also delivered systems using Docker Compose that are actually running in production. The point I want to make is that people may define “production” differently depending on the number of active users, operational requirements, and risk level.

To me, this debate feels similar to the broader monolith vs. microservices debate.

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

#180

Post by MrDrMcCoy »

philipallstar wrote: post #158
notme43 wrote: post #35

Earlier quoted context omitted.

I find the podman man pages quite readable and thorough if you've had experience configuring systemd services. Good examples as well. https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

Thanks - you're right. I just have never known whether to quadlet or not to quadlet, as the centre of gravity seems to be moving that way, but that might be a redhat-first feature.

The quadlet feature is just part of podman, which consists of no more than a generator for systemd. Generators are just an executable "hook" that spits out unit files according to systemd-defined paths. Any systemd system with podman will be equivalent to any other for the respective versions of each. There is nothing distro-specific about it, especially since podman can be a single multicall binary like busybox to provide it to a system that has systemd and nothing else.
Post reply on HN