Live data from Hacker News

Should I run plain Docker Compose in production in 2026?

distr.sh

271–280 of 312 posts

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

#271
post #75

I am using docker-compose everywhere. I really enjoy using it. I have a single thing that is annoying for normal production deployments, and that is that it isn't super easy to have a rolling deployment, I just need two replicas for zero downtime deployment, and I don't really want docker swarm. I think it is the networking which breaks at that point, and you have to have a more involved setup, and at that point I'd…

this is a hack I have used and am proud of:

if you use Caddy as your reverse proxy (instead of nginx for example which does not do this), when requests come in and your service is missing because it's being deployed, Caddy waits for a timeout before giving up. this means that visitors during the brief deploy period don't see errors - they just get a slightly longer wait, which often is not obvious depending on how long your service takes to boot.

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

#272
We use a Docker Compose setup for our team's devcontainer. It's defined right in the repo alongside the Dockerfile used to build our image. Our build scripts are all set up to start/stop/use the container automatically. Integration with Vscode's devcontainer system will come next.

It's been a great way for us to make sure that developers and CI/CD get exactly the same build environment, mount-points, paths, network access, permissions, etc.

It's been a super solid tool overall, and I'm pretty happy with it. The only thing that would make our setup better would be if we could figure out how to go rootless/daemonless with it.

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

#273
Been exploring Docker Compose Bridge for app devs building apps for UDS/Zarf https://github.com/defenseunicorns-labs/compose-bridge-uds/ . Pleasantly surprised at how well we can deterministically produce larger k8s apps configs from the compose spec. As many others have mentioned in the comments, it’s hard to beat compose for a tight dev loop of multiple dependencies in a micro-service architecture.

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

#274

I really want something that is Docker Compose but for Kubernetes. I mean that I can have a simple way to declaring resources in just like Docker Compose, but I run the environment in Kubernetes so that I can get to test the behaviors when there are multiple copies of the softwares running together. I do rely on Kubernetes heavily for distributed and networked software deployment, so it is even better if we can emula…

Have you looked into some of the Docker Compose Bridge transformers? We’re using it to scaffold out k8s apps for UDS from compose files https://github.com/defenseunicorns-labs/compose-bridge-uds/

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

#275
post #139

Earlier quoted context omitted.

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.

Here's a CLI plugin that automates this: https://github.com/wowu/docker-rollout

Another vote for this - we’ve been using it for years without issues.

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

#276
post #254

Earlier quoted context omitted.

Why use a docker volume? Seems like a good way to accidentally lose your files. Just volume-mount from the external filesystem and back it up the same way you would any linux application's files - maybe stop it, maybe not, depends on how it uses files.

Docker volumes still exist on the filesystem. Wouldn't one be able to point the backup solution at that directory?

It's nice to be able to survive someone purging Docker by accident, and it's nice to know `/wherever/you/like` is where your files are instead of in `/var/lib/containers/some long hash/`

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

#277
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…

If the project fits on a single server (which it probably can in 2026) docker compose is great.

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

#278
post #93

Earlier quoted context omitted.

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.

I wish. There's nothing like Kubernetes here nor the features it gives you or any need for them. Just some basic sys admin stuff that works well for me.

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

#279
post #93

Earlier quoted context omitted.

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.

That's neither kubernetes nor a lot of moving parts, just basic sysadmin setup for good hygiene and piece of mind.

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

#280
post #263

Earlier quoted context omitted.

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?

Sure!

Get a few Beelink SER5 or SER9's, install Nextcloud to cover the files, document editing, communications (to save on Microsoft 365). Then you can have Gitea (and gitea actions) for your source code and building (skipping github enterprise), Harbor to host and scan your containers, frappe for HR, etc. Pretty much anything you pay enterprise rates for, you can self-host a version that will get your company from 1 to 100s with minimal extra work. If it's not on https://github.com/awesome-selfhosted/awesome-selfhosted, you can probably vibe code it in a couple hours.

I just started to run a k3s cluster with an almost enterprise grade software factory and a few (light) production workloads on a single cheap minipc.

https://scottyah.com/cluster

Post reply on HN