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

181–190 of 312 posts

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

#181

Post by MrDrMcCoy »

exceptione wrote: post #12
philipallstar wrote: post #8

Earlier quoted context omitted.

Is there a nice guide for podman that includes quadlets (or saying not to use them?) I find lots of guides stray into things that work on redhat, and on my Linuxes of choice, Raspbian and Ubuntu, things aren't straightforward.

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.

So use a static build of podman. They're readily available.

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

#182

Post by jdwithit »

stackskipton wrote: post #177

SRE here, my thought is "Sure, Docker Compose is great for production assuming your needs are light and Docker Compose works well for you." K8s as small time is overkill for sure but make sure you don't fall into this trap. https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...

Just the other day, someone was asking me if I knew of any options for replicating externaldns for Docker Compose. They didn't want "all the complexity" of running k8s, but wanted the features. This person was absolutely on the way to "building a Kubernetes".

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

#183

Post by calmoo »

regexorcist wrote: post #124
calmoo wrote: post #81

Earlier quoted context omitted.

I've recently been dipping my toes into k8s / kustomize / helm, and I recently had a situation where having a base deployment yml template that I wanted to reuse across various deployments. I had a look at Helm and I was frankly shocked how bad the templating was with Go templates, it was close to unreadable and felt very brittle!

How so? I find it much the same to other templating engines like Jinja, though I'm definitely not a fan of the syntax. But that hardly matters anymore with LLMs.

Specifically with YAML, Go templating requires some special operators to get anything useful done and it ends up being an unreadable mess.

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

#184

Post by raphinou »

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 benefits so big, that it was the right choice for me. I think a lot of people are replicating swarm features with compose, losing a lot of time. But hey, to each their own choice!

1: https://www.yvesdennels.com/posts/docker-swarm-in-2022/

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

#185

Post by QGQBGdeZREunxLe »

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…

Swarm or Nomad is the way to go for simple single/multi-node setups.

https://developer.hashicorp.com/nomad

Disclaimer: I used to work for HashiCorp

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

#187

Post by codegeek »

giobox wrote: post #165
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 ?

At this stage the volume/persistence configuration for all of the major DBs is arguably extremely well understood and has been for years. The only real risk in running the DB as a container for most people is not configuring volumes for persistence correctly. For most DBs it's one or two paths in the container, and virtually all DBs vendors have a reference Docker Compose example somewhere showing volume config. I ca…

Do you prefer self hosting DB with container OR using a managed service liek RDS ? I guess both can work depending on your level of comfort and even though I am a big self host guy, db hosting is something that makes me nervous and I end up just leaving it to RDS etc.

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

#188

Post by codegeek »

pvillano wrote: post #164
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 ?

What effect does docker compose have on database resilience?

I probably used the wrong word. I meant more about managing volume property so we dont have data loss, backups, replication etc etc. I assume going managed is easier if you can pay for it (e.g. RDS)

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

#189

Post by giobox »

codegeek wrote: post #187
giobox wrote: post #165

Earlier quoted context omitted.

At this stage the volume/persistence configuration for all of the major DBs is arguably extremely well understood and has been for years. The only real risk in running the DB as a container for most people is not configuring volumes for persistence correctly. For most DBs it's one or two paths in the container, and virtually all DBs vendors have a reference Docker Compose example somewhere showing volume config. I ca…

Do you prefer self hosting DB with container OR using a managed service liek RDS ? I guess both can work depending on your level of comfort and even though I am a big self host guy, db hosting is something that makes me nervous and I end up just leaving it to RDS etc.

The answer to this for me anyway depends entirely on the size of the solution, what the rest of the stack looks like, how many users, what is my support contract like etc etc, do I have to collaborate with other engineers or is it just me? Similarly, if you already have a bunch of ops guys managing some RDS stuff, it might make sense to just take advantage. RDS also comes with a ton of features a simple compose stack won't, especially around redundancy and disaster recovery.

I don't think there's a good one size fits all answer to whether hosting in Compose or RDS is right for you or a given project.

Post reply on HN