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

301–310 of 312 posts

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

#301

Post by MrDrMcCoy »

exceptione wrote: post #198
MrDrMcCoy wrote: post #181

Earlier quoted context omitted.

So use a static build of podman. They're readily available.

Podman's quadlets have a deep integration with systemd. I guess that if you have that kind of risk appetite you would be better of with running Arch on auto-update.

If by "deep integration" you mean "unit generator", then sure. There isn't much I've seen beyond that, nor are there many systemd features being used that version drift would cause an issue for. Static podman introduces no real risk that I can identify.

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

#302

Post by exceptione »

linsomniac wrote: post #299
exceptione wrote: post #227

Earlier quoted context omitted.

Ubuntu 24.04. The new LTS had dropped only two weeks ago. LTS users had a very outdated podman (4.9, two years old) and couldn't use quadlet types like build units (v5.2.0, aug 2024).

We are switching our Docker systems over to using Podman, primarily to get rid of the machinations we have to do to keep "apt update" from taking down services if there's a new Docker version. We're rolling them up from 24.04 to 26.04 and just using the podman packages on 26.04.

I see, at least the good thing with 26.04 is that you are set for a while.

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

#303

Post by a96 »

sunaookami wrote: post #150
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…

Have you read the article?

https://news.ycombinator.com/newsguidelines.html

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

#304

Post by 7bit »

sunaookami wrote: post #151
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?

What does this have to do with the article?

Some people like to hear themselves talk

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

#306

Post by gitaarik »

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?

I don't think you should only let "if it sounds good" determine what you eat

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

#307

Post by tartieret »

why not swarm? it's basically the same yml file except that you can do zero downtime deployment, simply with docker stack deploy -c stack.yml (swarm will outline the image, warm up the container and switch traffic automatically). roll backs are also included for free. it's part of docker so no additional dependency

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

#308

Post by selfmodruntime »

giobox wrote: post #169
selfmodruntime wrote: post #155

Earlier quoted context omitted.

A really nifty thing is that you can also of course bind this to the device's tailscale ip! Also you don't even need the loopback address if the traffic is between one container and another, just a bridge network is fine.

This is how I self host all my home services (Home Assistant, PFSense, Frigate etc), I do not for the life of me understand why so many folks doing self-hosted services for themselves put them on the public internet. Caddy will even do fully automated valid TLS certificates for private IP ranges via DNS ACME challenge for free etc with renewals handled, so all my internal self-hosted sites have properly terminated TL…

A lot of people using docker or even k8s don‘t know that by default, a service is available to all other services via the service name defined in the compose file or your yaml specs. Docker compose builds an implicit bridge network. Most internet tutorials are wrong here and bing ports publicly to your ipv4 interface. So if you follow them you‘ll accidentally expose your database or similar to the public web

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

#309

Post by __MatrixMan__ »

arikrahman wrote: post #270

Just use nix flakes

Well yes, but if you think you need docker-compose then you're looking for runtime control and not build time control, so you should use this nix flake: https://github.com/juspay/services-flake (which uses process-compose instead of docker-compose).

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

#310

Post by codessta »

nathanmills wrote: post #62
gchamonlive wrote: post #30

Earlier quoted context omitted.

> does turkey sound good for you? What if you can't by yourself objectively evaluate if turkey sandwich sounds good? It's not a matter of giving a universal answer to whether docker compose in production is fine, but how to evaluate it. Which features or safeguards necessary for a healthy production environment you forfeit when choosing plain docker compose? What's the tradeoff?

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

Lol, you should just try to use something you're not familiar with in production. Let's just stop all discussion around things and just let people try everything for themselves. That't the best way for humans to learn. Writing, reading and discussion are so blase'
Post reply on HN