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

291–300 of 312 posts

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

#291

Post by nonameiguess »

jdw64 wrote: post #179
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…

I think people are using different meanings of “production environment.” I agree with gear54us and upvoted their comment, but I also understand what the author of the root comment is saying. I have also delivered systems using Docker Compose that are actually running in production. The point I want to make is that people may define “production” differently depending on the number of active users, operational requirem…

That as well as different definitions of scale. I've done small bits of consulting work for a research company for the past four years, deploying and managing Kubernetes clusters for them as well as helping get some of the main applications up on it. This is all internal tooling, though. Their customer-facing sites are just Drupal instances running on bare EC2.

Internally, though, they wanted to self-host a chat server, Apache airflow, Overleaf for collaborative editing of research proposals, three separate Git servers, a container registry, many other things, all with extremely strict multi-tenancy isolation requirements for storage and networking because they're handling customer data and their own customers audit them for it. That was a hell of a lot easier to do with Kubernetes than trying to figure out some giant universe of barely related technologies with vastly different APIs, having to buy specialized appliances for network and storage that probably also need their own control plane software hosted somewhere else.

But if you just look at "scale" as number of http requests a particular URL gets per some unit of time, the customer-facing sites have far greater scale. If you're trying to attribute revenue, beats me. They wouldn't sell anything without the customer-facing sites, but they wouldn't have anything to sell without the internal tooling. Solo web devs get into this tunnel vision view of ops because, to them, often the web site is the product. That's not the case for most businesses.

And, of course, they'd probably just use someone else's SaaS for tooling. But if you're in a heavily regulated space where that isn't possible and you have to self-host most of your business systems, then what?

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

#292

Post by suralind »

stevefan1999 wrote: post #52

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…

This is a great idea for some vibe coding tbh and you can customize it to match exactly the resources that you need as everyone has slightly different requirements for their k8s stack.

The simplest way to start probably would just be to create a custom Helm chart and define what you want in `values.yaml`.

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

#293

Post by pydry »

stryan wrote: post #260
pydry wrote: post #255

Earlier quoted context omitted.

>Systemd is a tool for managing services It's a tool for user age verification that happens to be something you can use to manage services. Did you miss my point about it being a filthy kitchen sink? >This is the same system state as using docker compose with docker One of the major selling points of podman is that you dont need a daemon. except maybe yes you do because podman compose sucks so toss that selling point…

> It's a tool for user age verification that happens to be something you can use to manage services. Good talk buddy. > Did you miss my point about it being a filthy kitchen sink? I suspect there's not really a point in responding to this since you've already made up your mind. Nevertheless, yes I am aware the systemd project contains many modular components. Some of which are good (systemd-the-service-manager that i…

>I suspect there's not really a point in responding to this since you've already made up your mind.

I suspect you ignored the point because you didnt want to address the point.

My repeating it seems to only have highlighted your wish to continue avoiding it here.

>Nevertheless, yes I am aware the systemd project contains many modular components.

Another red herring. "Modular" really isnt the point here.

It's certainly one way to justify throwing even more shit in an already overloaded kitchen sink though.

>You skipped the second part of my sentence where I reminded you that Podman is daemonless.

No, you skipped the part where I acknowledged that it was daemonless-by-default but you actually DO need to run a podman daemon if you're using docker compose with podman.

>Take this up with docker?

They're not responsible for podman trying to piggyback on their tools.

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

#294

Post by gear54rus »

scottyah wrote: post #280
fud101 wrote: post #263

Earlier quoted context omitted.

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

I checked your page. Wanted to ask, are you using longhorn with k3s for replicated volumes? How beefy a box do you need for that (CPU/MEM/Disk speed)?

I have several VMs in clouds with similar k3s architecture as yours and am wondering if there are any benefits to installing longhorn vs sticking to logical (postgres, mimir, whateveritis) replication instead.

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

#295

Post by xyzzy123 »

scottyah wrote: post #280
fud101 wrote: post #263

Earlier quoted context omitted.

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

The concept totally works but I would worry about using a beelink in a business context where I had to support it.

For up to low hundreds of users I think you're better off just with 1 vertically scalable box for all the officey / web server workloads.

You mitigate the hardware failure stuff with a vendor contract where you can get someone on-site and overnight you parts, and by keeping things super boring. Volume replication is not boring, avoid at all costs. NAS or SAN if you have to but all disks in the main box for as long as you can.

For 20 person SME maybe a 2-bay Synology or similar, for a heavier company a low end 2U with hardware support. Proxmox under the OS for reduced worry snapshots, rollback, backup etc. Proxmox is there for operational flexibility, resist the temptation to create a network of VMs, you just need 1 CT or VM with all the workload inside it.

For container workloads on 1 host Portainer works as well as k8s IMHO, it gives you the key property you want - you can IaC everything declaratively with terraform + compose over an API.

Caveat that if CI gets heavy you might need to scale that out but you can keep it stateless.

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

#296

Post by DeathArrow »

noodlesUK wrote: post #5

I think many of these issues are also solved by Podman and systemd depending on what kind of "production" you're building for. If you're building a linux-y appliance and you need to run a few containers I think Podman is a much better and more ergonomic way of doing so. I think perhaps that's less true for running a web service (where the linux environment is just a means to that end).

> I think perhaps that's less true for running a web service (where the linux environment is just a means to that end).

If some BSD would support OCI containers, I would run my apps on BSD.

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

#297

Post by dfreire »

oddurmagnusson wrote: post #288

Since all the tools around that orchestrate Docker Compose don't do these best practices, I made my own: https://yoink.is/ Things like a good security posture by default, health checks, drift detection, and port forwarding.

Looks great!

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

#298

Post by curt15 »

nickjj wrote: post #168
codegeek wrote: post #154

Earlier quoted context omitted.

Really liked reading your blog. Bookmarked for future. One question: for databases, do you recommend using containers as well because in development, I love the ease of using databases in docker compose as well but I always worry about production in terms of resilience. Thoughts ?

For databases, I usually host them on a separate server. This could either be through Docker Compose or a managed DB server. If a managed DB is affordable enough I'd reach for it. It's because I like keeping my servers stateless when possible. It makes it easier to upgrade them in a zero downtime way later. If your web server has your DB too, then you can't do zero downtime system upgrades. For example I would never…

> This pattern works because both the old and new server can be writing to a database on a different server.

How would you upgrade the server running the database?

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

#299

Post by linsomniac »

exceptione wrote: post #227
linsomniac wrote: post #214

Earlier quoted context omitted.

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

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.

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

#300

Post by nickjj »

curt15 wrote: post #298
nickjj wrote: post #168

Earlier quoted context omitted.

For databases, I usually host them on a separate server. This could either be through Docker Compose or a managed DB server. If a managed DB is affordable enough I'd reach for it. It's because I like keeping my servers stateless when possible. It makes it easier to upgrade them in a zero downtime way later. If your web server has your DB too, then you can't do zero downtime system upgrades. For example I would never…

> This pattern works because both the old and new server can be writing to a database on a different server. How would you upgrade the server running the database?

It depends on the business use case and requirements.

Using a managed database solves this problem, so there's that an option.

If you self host your DB, if the data is on block storage you can at least spin up a new instance and connect that storage device onto the new instance with a short period of downtime. This is usually a satisfactory level of downtime for an event that doesn't happen too frequently.

What I like about the above is it'll work with any database and avoids needing to even think about performing real-time or near real-time replication with multiple writers.

There's also the scary truth that there's a ton of stuff out there where compliance requirements aren't enforced. I'm not saying it's a good idea but you can choose not to upgrade too. This is a risk assessment you'd need to do. At the very least if you go down this route, please make sure your server doesn't even have a public IP address. If it's super locked down, that doesn't mean it's safe but you'll want to limit the number of attack vectors as much as you can.

Post reply on HN