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

261–270 of 312 posts

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

#261

Post by stryan »

stevenhuang wrote: post #253
stryan wrote: post #212

Earlier quoted context omitted.

> Having your whole application with its containers, volumes, and networks all defined together in one easy-to-read YAML file is a way better experience. Deployment is two steps: 1. `git clone foo` 2. `docker compose up -d`. You can see the state of the application containers with `docker compose ps`. You can run multiple compose applications on the same host and manage them separately by putting them in different di…

Parent complaint sounds like they are just unfamiliar in general with managing regular system services using unit files/systemctl.

Yeah, I wouldn't be surprised if a lot of the mindset differences come down to people used to using Docker Compose as a development environment being uncomfortable with managing things on a real/traditional/production/whatever-you-want-to-call-it server. Compose treats things as sort of a hermetically-sealed "Application" versus a collection of services. Quadlets are more the latter, and of course that's all Docker Compose is as well but it's a decently good abstraction over it.

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

#262

Post by zbentley »

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…

https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...

Like, if that works for you, more power to you. But that is a lot of moving parts in exchange for using a tool whose value prop is that it doesn't have many.

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

#263

Post by fud101 »

scottyah wrote: post #224
tcgv wrote: post #160

Earlier quoted context omitted.

Fair points, and yes, failed deploys need to be handled explicitly. In our case, the answer is not "hope and bash". We deploy versioned images, use health checks, monitor the result, and keep rollback simple: redeploy the previous known-good image/config. Host upgrades are also treated as maintenance events, with backups and a recovery path, not as something Compose magically solves. But I think there is an opposite…

Definitely not a one-size-fits-all choice, but Kubernetes can be so easy and there are so many benefits that get you from one small app to a medium sized business that it seems like a no-brainer for someone starting out. Spinning up k3s is pretty minimal overhead, but right away you can handle storage and backups very easily, automatic certs for all your apps with cert-manager is pretty much a one-and-done, traffic m…

>2-3 miniPCs, cloudflare, tailscale, and k3s can save (possibly tens of) thousands on SaaS products, and would probably scale you to a company of dozens AND host your product.

outline a simple real world system to illustrate?

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

#266

Post by c0balt »

mrighele wrote: post #250
c0balt wrote: post #239

Earlier quoted context omitted.

The "easiest" way is to use bind mounts to a local directory (or multiple directories) instead of volumes. Then you can just use normal backup tooling. Docker volumes (and bind mounts) however have the minor problem of being hard to get a consistent copy to without stopping the service. You can work around this by, e. G., having ZFS or btrfs as the underlying FS and making a snapshot there. Otherwise, your software (…

AFAIK volumes are nothing more than a bind mount on a private docker folder, e.g. the files for volume my-volume are stored in /var/lib/docker/volumes/my-volume/_data, so backup strategies (an problems) for bind mounts apply also to volumes

Yep, that is accurate. There is also a command/API route to find the path on disk iirc.

In my setups it just was easier to use fixed paths (or relative to project dir) from a permissions management perspective. Backup tools did not always have to/should run as root which is helpful on machines providing multiple distinct services.

Putting borg or a similar tool in a container that is part of the compose manifest file can also help. I haven't seen this used in practice though yet.

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

#267

Post by monkpit »

daitangio wrote: post #194
tcgv wrote: post #121

Earlier quoted context omitted.

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…

I love it so much I have created a thin statless orchestrator layer upon it: https://github.com/daitangio/misterio It works very well!

You have built a kubernetes…

https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...

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

#268

Post by iamtedd »

api wrote: post #140
tcgv wrote: post #121

Earlier quoted context omitted.

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.

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.

Post reply on HN