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

131–140 of 312 posts

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

#131

Post by dec0dedab0de »

nixpulvis wrote: post #51
2ndorderthought wrote: post #11

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?

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.

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

#132

Post by KetoManx64 »

dizhn wrote: post #93
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…

My containers run in dedicated "docker host" VMs. And I never expose ports on 0.0.0.0, just the private internal IP. Most (all) of my docker hosts do not have a public IP anyway. I use wireguard to access them myself. If they need to be public I reverse proxy with caddy from my web server (or use Authentik's embedded proxy). These servers have access to the same private LAN which could be hardened without having the…

What would the config look like if I have my docker containers split up over multiple VMs?

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

#133

Post by another-dave »

2ndorderthought wrote: post #11

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?

If you already understand it all in-depth, anything becomes "are the benefits worth the trade-offs" but it's useless advice for the people who don't

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

#134

Post by 2ndorderthought »

gchamonlive wrote: post #68
nathanmills wrote: post #62

Earlier quoted context omitted.

Then you either need to try it or research it. Other people can't tell you if you like turkey or not.

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?

It's not a deep insight. Neither is the title of the article. It tells the reader nothing and makes the author sound like they have nothing to say.

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

#135

Post by BigTuna »

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 reverse proxy everything through a Caddy instance running on the same machine so I avoid the firewall dance entirely by just prefixing all my port assignments in the compose file with the loopback IP (eg. 127.0.0.1:3000:3000). Nftables denies all but 80 and 443 and I don't have to worry about restarts/flushes breaking things.

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

#136

Post by nickjj »

kevinfiol wrote: post #129
nickjj wrote: 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.

Thanks a lot, I really appreciate it.

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

#137

Post by jstanley »

> How Do You Handle Deployments?

This section misses the one thing I was interested in: how do you avoid downtime in a deployment?

I like to write web applications with Perl and Mojolicious, and a deployment is just "hypnotoad app", and then hypnotoad gracefully starts up new worker processes to handle new requests and lets the other ones exit once they've finished handling their in-flight requests.

When I switched to Docker I found that there was no good way to handle this.

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

#138

Post by danparsonson »

BigTuna wrote: post #135
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 reverse proxy everything through a Caddy instance running on the same machine so I avoid the firewall dance entirely by just prefixing all my port assignments in the compose file with the loopback IP (eg. 127.0.0.1:3000:3000). Nftables denies all but 80 and 443 and I don't have to worry about restarts/flushes breaking things.

This is surely the easiest and I would guess the safest way, and has the added benefit that your proxy (nginx in my case) can handle SSL for you, making certificate deployment a breeze.

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

#139

Post by fnoef »

jstanley wrote: post #137

> How Do You Handle Deployments? This section misses the one thing I was interested in: how do you avoid downtime in a deployment? I like to write web applications with Perl and Mojolicious, and a deployment is just "hypnotoad app", and then hypnotoad gracefully starts up new worker processes to handle new requests and lets the other ones exit once they've finished handling their in-flight requests. When I switched t…

Record the existing container id, rescale the service to 2 instances (hence bringing a second container up), wait for the second one to be healthy, (optional) stop directing traffic to the old container, wait a few seconds, stop the old container, rescale the service back to 1 instance.

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

#140

Post by api »

tcgv wrote: post #121
nickjj wrote: 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 b…

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

Post reply on HN