Live data from Hacker News

Should I run plain Docker Compose in production in 2026?

distr.sh

91–100 of 312 posts

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

#91
One big thing I think is whether you want some sort of non-trivial network configuration, such as multiple external IPs via ipvlan. That's technically possible off docker, but not in a responsible way as anything in the ipvlan will be accessible to the public internet. Overall the implementations for this are very janky and occasionally enter tilted states that are close to impossible to recover from short of a restart of the docker daemon.

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

#92

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.

What I'd like is systemd-compose. Maintaining several dozens of .service-files is not my idea of fun.

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

#93
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 issues you brought up.

By the way most docker based implementations do not actually need the userland proxy docker runs automatically. Disable it in /etc/docker/daemon.js

{

    "userland-proxy": false

}

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

#94

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.

What I'd like is systemd-compose. Maintaining several dozens of .service-files is not my idea of fun.

It's not quite what you suggested, but you can use podman with systemd.

https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

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

#95
post #40

Earlier quoted context omitted.

Spotify, Visa, NASA, Netflix, and a zillion others do, why not?

There are more secure alternatives. Are you sure those you listed actually use it on the servers? I would guess that at least Spotify and Netflix uses some other container runtime than Docker on their production servers. For a long time Docker was helpful and opened exposed ports on the firewall. So you wanted to access your redis ports locally and exposed it on the container? Now everything in there is accessible on…

[deleted]

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

#96

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.

What I'd like is systemd-compose. Maintaining several dozens of .service-files is not my idea of fun.

Or more simply just wrap some orchestrator in a single service file. Could just be a bash script used for ExecStart.

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

#97
> Every docker compose pull keeps the previous image on disk. Every container with the default json-file log driver writes unbounded JSON to /var/lib/docker/containers//-json.log. On a busy host this is one of the most common reasons for an outage: the disk fills and Docker stops being able to write anything

I ran docker compose in development a lot. Just an easy way to turn on / off 5 different services at once for a project. Over time this was filling up my machine's storage (like 1 TB). Every few months I needed to run docker compose prune and see 600GB free up

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

#98
post #16
post #15

Earlier quoted context omitted.

Every company these days are AI companies. Even the ones you’d least expect. https://www.bbc.com/news/articles/c98mrepzgj7o

Sure, but you wouldn't just say "Oh they are a Postgres" company because they use that specific database somewhere in the stack.

I was being flippant

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

#100

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.

What I'd like is systemd-compose. Maintaining several dozens of .service-files is not my idea of fun.

i don't have dozens of services. My complex SaaS has total 6 services and each one is running on its own server.

Service file lives in the mono repo where all 6 services live.

Makes it trivial to make changes and redeploy.

Post reply on HN