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

221–230 of 312 posts

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

#221

Post by time4tea »

raphinou wrote: post #184

I'm very happy using docker swarm on a single host with traefik as reverse proxy using the setup described here: https://dockerswarm.rocks/ Super easy deployment of additional apps, defined completely in one file (incl setup on host, backups, reverse proxy config, etc). Never found a reason to migrate away. Swarm was already considered dead when I started using it in 2022[1], but the investment was so low and benefit…

Yup, this works so nice.

Using traefik or caddy as proxy.

Docker context for remote access - over Internet or vpn, whatever.

Swarm-cronjob for scheduled things.

Labels for things that need to run in particular places.

So easy.

Personally, k8s is fine, but its an abstraction for building a service architecture, not the thing an end user (developer) should ever use. If you are in a big company and you are using helm or k8s yaml files to roll things out, your infra or platform teams have missed something out.. building the platform!

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

#222

Post by TheCapeGreek »

mystifyingpoi wrote: post #120
TheCapeGreek wrote: post #58

Somewhat adjacent in how I look at using Docker at all in prod, here's what I always wonder: Is using Docker/Compose "just" as the layer for installing & managing runtime environment and services correct? Especially for languages like PHP? I.e. am I holding it wrong if I run my "build" processes (npm, composer, etc) on the server at deploy time same as I would without containers? In that sense Docker Composer becomes…

> if I run my "build" processes (npm, composer, etc) on the server at deploy time It's perfectly fine, as long as you accept the risks and downsides. Your IP can get ratelimited for Docker Hub. The build process can exhaust resources on the host. Your server probably needs access to internal dev dependencies repository, thus, needs credentials it would not need otherwise. Many small things like that. The advantage is…

> IP ratelimited for Docker Hub

How? What I'm describing is using Docker less.

> The build process can exhaust resources on the host

Maybe, but I've yet to have a host where that's the case for usual CRUD fare.

> The advantage is simplicity, and it's often worth the risk.

That's basically what I'm evaluating for here.

For bog standard LAMP or similar stack applications, I've not understood the advantage of going through the build-image-then-pull-on-host rigmarole. There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects.

But I have seen that done fairly often, hence was wondering what the point was.

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

#223

Post by TheCapeGreek »

nijave wrote: post #78
TheCapeGreek wrote: post #58

Somewhat adjacent in how I look at using Docker at all in prod, here's what I always wonder: Is using Docker/Compose "just" as the layer for installing & managing runtime environment and services correct? Especially for languages like PHP? I.e. am I holding it wrong if I run my "build" processes (npm, composer, etc) on the server at deploy time same as I would without containers? In that sense Docker Composer becomes…

I would say it's bad practice because you end up having to copy all the build dependencies (source code) to the host and you're potentially putting a bunch of extra load on the host during the build process. Also adds moving parts to your deploy which increases risk/introduces more failure modes. Couple things that come to mind - disk space exhaustion during build - I/o exhaustion esp with package managers that have…

> you end up having to copy all the build dependencies (source code) to the host

> disk, i/o exhaustion

This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case.

I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deploying by definition also contains my source code because I'm not deploying anything compiled.

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

#224

Post by scottyah »

tcgv wrote: post #160
gear54rus wrote: post #153

Earlier quoted context omitted.

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…

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 management for external and internal tools is easy, and even logins for websites is just an annotation in a yaml file. You can spin up and try out any software you want without spending time configuring it or setting up additional servers- and when you do need more hardware, it's one command on a virtual server, and just about as easy with physical hardware.

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.

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

#225

Post by frje1400 »

throwaway894345 wrote: post #163
bityard wrote: post #152

Earlier quoted context omitted.

I desperately WANT to like podman quadlets and keep trying to find a use case for them. But I always got the impression that the developers who implemented quadlets never actually had to manage multiple containers in a real production environment. 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 st…

Honestly with the hell I'm going through just trying to get Podman to run properly on macos, I can't imagine trusting the Podman people with a production deployment. I was not particularly impressed with the Docker tooling, but Podman has been even worse. This is a not-remotely exhaustive list of things I've run into in the last 24 hours: * Podman fails to build a 16GB container image (after 30 minutes of downloading…

There's a reason why Orbstack can charge money: it just works, and podman doesn't (on macos).

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

#226

Post by TheCapeGreek »

mkesper wrote: post #85
TheCapeGreek wrote: post #58

Somewhat adjacent in how I look at using Docker at all in prod, here's what I always wonder: Is using Docker/Compose "just" as the layer for installing & managing runtime environment and services correct? Especially for languages like PHP? I.e. am I holding it wrong if I run my "build" processes (npm, composer, etc) on the server at deploy time same as I would without containers? In that sense Docker Composer becomes…

Have a look at multi stage container builds. Your images should not need a build step at start, the result should be in the baked image. Else you become reliant on fetching packages during build etc.

I guess what I'm asking for is what the point is of a "baked" image for interpreted language ecosystems. Already using multi stage builds.

"Builds" are the same as deploys, so when working with server(s) instead of larger scale deployments, I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios.

But I have seen this in action, which is why I'm wondering if I'm missing something.

The clearer benefit to me seems to be in this scenario to use it as a fast environment provisioning tool.

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

#227

Post by exceptione »

linsomniac wrote: post #214
exceptione wrote: post #12

Earlier quoted context omitted.

Can't comment on Raspbian, but Ubuntu LTS (has/had) a seriously outdated podman version. This is the kind of nuisance the Debian derivatives have been running into for more than 20 years: they are extremely conservative, and if that is all you need, then that is great, but if not, you'll have to either run the latest Ubuntu (not LTS), or you upgrade to something like fedora.

Not sure if you consider 5.7.0 (6 months old) "seriously outdated", or are talking about Ubuntu 24.04 (the previous LTS). I recently looked and decided 5.8.2 (3 weeks old), didn't have anything compelling to make me want to try to shoehorn it in.

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

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

#229

Post by merb »

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…

How do I backup docker volumes? I never found a native flow for backing up docker compose projects.

While not built in k8s has at least velero and kasten. However they are only possible because of snapshots https://kubernetes.io/docs/concepts/storage/volume-snapshots... and kasten has a plugin like architecture (because of k8s ) that supports application specific backups. However I never found something like that for compose. And that is troublesome in bigger projects like sentry

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

#230

Post by seniorThrowaway »

theK wrote: post #211
seniorThrowaway wrote: post #192

Earlier quoted context omitted.

Extremely debatable. They still have never fully implemented health checks and auto healing. I have had compose itself behave in unexpected ways, weird things like not realizing the tag of an image it is running is actually in use, and letting prune commands yank it out from under the system. Other things I can't remember. I'd rather use something like Nomad or for simpler systems maybe plain systemd. But realistical…

I'm totally onboard with k3s/k8s being better in a lot of cases. But docker compose can actually be very sufficient for what many projects actually need. Granted I am a guy pushing for compose based localdevs and such but going further you often just cannot beat the simplicity of doing update QA or other CI/CD workloads in compose based projects. I have had dozens of projects where we replaced flaky slow and maintena…

I do use compose for some things, smaller one off type setups, and I’ve done the compose up --build CI/CD approach before. I’m generally not a fan of building on the production node outside of very small deployments. It can work, I just think it tends to blur the line between build and runtime more than I’m comfortable with.

Some of my concerns with compose aren’t purely technical. It makes it easier to lean on local state like volumes, bind mounts, and large .env files. Similar mechanisms exist in kubernetes, but the additional setup tends to force a bit more thought about whether they’re actually needed or just a shortcut.

On the health check side, they exist, but compose doesn’t fully act on them, that's the part that is missing. There’s no built in remediation or orchestration behavior tied to health status, which is why things like https://github.com/willfarrell/docker-autoheal exist. It’s something that was never fully carried through in Docker itself.

Post reply on HN