12 ms·

Should I run plain Docker Compose in production in 2026?

• ksk23 5mo ago
  Yes and no :)
  • 28304283409234 5mo ago
    hahah came here to say: "It depends."
• TheChaplain 5mo ago
  TIL about limiting logs. Very useful, I had no idea.
• noodlesUK 5mo ago
  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).
  • philipallstar 5mo ago
    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.
    • exceptione 5mo ago
      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.
      • jiggunjer 5mo ago
        Is there no upstream package repo like docker has.
      • mr_mitm 5mo ago
        In many cases, Debian unstable is also a good choice.
      • skydhash 5mo ago
        > they are extremely conservative, and if that is all you need, then that is great You don’t need to live at the edge of new features. Do you upgrade your fridge and your oven every two months? It’s nice when you can have something running and not worry that the next update will break your software and/or your workflow.
        • exceptione 5mo ago
          Sure, but these are development dependencies we are talking about. Running old versions of these dependencies block your projects. But it isn't limited to self-developed software, quite often for of the shelve software you run at the same problem. To each their own, but this is the reason I advice newcomers to stay away from Debian based distro's. I don't intend a distro flamewar, it works perfect for `boring old and feature complete software´ like Dovecot. To add: containers would alleviate a good part of these concerns, but the stupid thing here is that precisely that is broken for up-to-date podman workflows.
          • skydhash 5mo ago
            Your test system should reflect your prod system. Why run Debian if you intend to deploy on the latest ubuntu? Unless you want to use VMs. For other stuff that does not alter the system that much, you can find more recent version in the backports.
            • exceptione 5mo ago
              It has integration with systemd, but moreover, I think the promise of Debian-derivatives is one of "we are boring and old, but also boringly stable". Now, throwing in backports undermines that promise. I think one is better of with a distro that moves faster.
    • notme43 5mo ago
      I find the podman man pages quite readable and thorough if you've had experience configuring systemd services. Good examples as well. https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
      • philipallstar 5mo ago
        Thanks - you're right. I just have never known whether to quadlet or not to quadlet, as the centre of gravity seems to be moving that way, but that might be a redhat-first feature.
        • MrDrMcCoy 5mo ago
          The quadlet feature is just part of podman, which consists of no more than a generator for systemd. Generators are just an executable "hook" that spits out unit files according to systemd-defined paths. Any systemd system with podman will be equivalent to any other for the respective versions of each. There is nothing distro-specific about it, especially since podman can be a single multicall binary like busybox to provide it to a system that has systemd and nothing else.
  • madspindel 5mo ago
    Yes, I recommend this: https://www.redhat.com/en/blog/kubernetes-workloads-podman-systemd https://www.redhat.com/en/blog/kubernetes-workloads-podman-s...
  • pmig 5mo ago
    What are the benefits of running Podman Compose instead of Docker Compose? I don't see how it helps with orphan containers, logs and mutable tags.
    • whilenot-dev 5mo ago
      GP is talking about podman with generated systemd unit files (a.k.a. podman quadlet[0]), not the docker-compose-compatible podman-compose ...and I'd agree, systemd can manage services on a system just fine, and even better than any compose workload ever could. journald will help with logs, and the pull policy[1] helps with mutable tags. What help do you need with "orphan containers"? [0]: https://docs.podman.io/en/latest/markdown/podman-quadlet.1.html https://docs.podman.io/en/latest/markdown/podman-quadlet.1.h... [1]: https://docs.podman.io/en/latest/markdown/podman-image.unit.5.html#policy-always https://docs.podman.io/en/latest/markdown/podman-image.unit....
    • gear54rus 5mo ago
      Then you learn podman can't even list containers for all users properly and it kind of starts smelling like the whole ip4 vs ip6 debacle: bunch of vocal proponents wanting you to subject yourself to endless torture for no discernible reason.
      • figmert 5mo ago
        What do you mean it can't list containers for all users?
      • tovej 5mo ago
        I mean, ipv6 is for not runnig out of IP addresses. There is a clear discernible reason. There are workarounds to make ipv4 work, but they complicate the system and make it more fragile.
    • figmert 5mo ago
      I'm not OP, but the whole podman compose topic gets quite confusing, as initially Podman didn't seem to know what they were trying to do. I've given some more context around it in previous comments. You shouldn't be using podman compose. It's flimsy and doesn't work very well (at least it was last time I used it prior to Podman v3), and I'm pretty sure it doesn't have Red Hat's direct support. Instead, activate Podman's Docker API compatibility socket, and simply set your `DOCKER_HOST` env var to that socket, and from there you can use your general docker client commands such as `docker`, `docker compose` and anything else that uses the Docker API. There are very few things that don't work with this, and the few things that don't are advanced setups. For what it's worth, podman has also a thin wrapper (podman compose) which executes `docker-compose` or the old `podman-compose`. The docs should explain which it picks. Note: - `podman-compose` is an early attempt at remaking `docker-compose` v1 but for Podman. This used parsed the compose config and converts them to podman commands, and executes it. - Later Podman wrote a Docker compatible socket instead, which can work with most docker clis that accept a `DOCKER_HOST` argument, including `docker` and `docker-compose` (both v1 and v2) - `podman compose` is a thin wrapper that automatically selects `docker-compose` or `podman-compose` depending on which is installed. Generally all you need is podman, docker-compose (the v2 binary), and that's it. From there you can use `podman` and/or `podman compose`.
  • bityard 5mo ago
    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 steps: 1. `git clone foo` 2. `docker compose up -d`. You can see the state of the application containers with `docker compose ps`. You can run multiple compose applications on the same host and manage them separately by putting them in different directories. With quadlets, you delegate everything to systemd. You have to break the configuration up into a bunch of tiny unit files and then separately copy them to /etc or a dedicated user's dotfiles. An application with a handful of containers and multiple networks/volumes/etc can spiral into a dozen unit files. Good luck SSH'ing into an unfamiliar system and understanding at a glance what it's doing. It is far more annoying to predictably deploy and tightly couples your application configuration to the host system configuration. (Even moreso if you created dedicated users for each application, which I understand is the recommended solution.) If I'm just holding it wrong and there exists some better tooling to manage podman in prod that I don't know about, I'm happy to hear about it.
    • throwaway894345 5mo ago
      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 dependencies) despite having 90GB free out of a 200GB podman virtual machine * Podman machine will, for reasons I don't understand, create a filesystem in a block device with wildly different sizes, and it seems like it's just random * Pushing podman images to a container image registry via the Podman Desktop UI gives no indication that it's doing anything or even recognized the "push image" click, a success or error notification _might_ appear several or tens of minutes later or possibly not at all * Starting a podman machine might work, but it fails ~75% of the time with not-particularly-exotic options (a bunch of ram and disk) and very cryptic error messages, frequently telling me to file bug tickets (I have) * Podman Desktop won't let me create a podman machine with more than 44GB of disk, but the podman machine CLI won't let me create a machine with fewer than 100GB (IIRC--it's some number larger than 44, in any case) Apart from the container image being absurdly large (Python developers love massive packages, I guess), I'm not doing anything exotic.
  • DeathArrow 5mo ago
    > 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.
• philipallstar 5mo ago
  Very cool article. Wish it didn't have silly AI-isms: > This is the shape Distr lands on
  • Cthulhu_ 5mo ago
    It's an AI company, it's kind of expected at this point - who would take an AI company seriously if they don't use AI themselves?
    • dewey 5mo ago
      Why do you say it's an AI company? It seems like their business is "Distribute your application to self-managed customers" not especially AI focused.
      • hnlmorg 5mo ago
        Every company these days are AI companies. Even the ones you’d least expect. https://www.bbc.com/news/articles/c98mrepzgj7o https://www.bbc.com/news/articles/c98mrepzgj7o
        • dewey 5mo ago
          Sure, but you wouldn't just say "Oh they are a Postgres" company because they use that specific database somewhere in the stack.
          • hnlmorg 5mo ago
            I was being flippant
        • Eldt 5mo ago
          Only in certain bubbles, which certain people have trouble realising they're in
          • deleted 5mo ago
• meander_water 5mo ago
  Surprised they didn't mention docker compose secrets - https://docs.docker.com/reference/compose-file/secrets/ https://docs.docker.com/reference/compose-file/secrets/
  • pmig 5mo ago
    To be honest I never really understood the benefit of Docker (Compose) Secrets - which is different from Swarm Secrets. Imho there just plain host mounted volumes, which are hidden from inspect commands?
• 2ndorderthought 5mo ago
  Should you have a turkey sandwich for lunch in 2026? I don't know buddy just do whatever. There are ten thousand other sandwiches you could eat surely, but does turkey sound good for you?
  • another-dave 5mo ago
    If you already understand it all in-depth, anything becomes "are the benefits worth the trade-offs" but it's useless advice for the people who don't
  • poly2it 5mo ago
    Is your point that we shouldn't motivate our technological choices? I wouldn't use Docker Compose in production.
    • 2ndorderthought 5mo ago
      Yes. I clearly believe we should not motivate choices in technology.
      • close04 5mo ago
        But then if you're not going to answer a question on technology, and you won't motivate any of the choices, including the one to not give an answer, what's the value in participating to the conversation? Your entire original comment looks like just an opportunity to be snarky. It's a longer version of "whatever", which you can literally throw around as an answer to anything. In case you were curious, the subheading of the article already answers the question posed by the title: > Yes, plain Docker Compose can still run production workloads in 2026—if you close the operational gaps it leaves: cleanup, healing, image pinning, socket security, and updates.
    • jagged-chisel 5mo ago
      I also would not eat a turkey sandwich for lunch on a Tuesday. *shudder*
    • 5mo ago
• _nhh 5mo ago
  Yes. It's perfectly fine.
• fabian2k 5mo ago
  My experience with docker-compose is a bit outdated, but my impression some years ago was that it was too sensitive and fragile. I encountered bugs or incompatibilities that broke the docker-compose setup often enough to be forced to pin the specific docker and docker-compose versions. And the error handling was terrible. Most of these problems resulted in a Python stack trace in some docker-compose internals instead of a readable error message. Googling the stack trace usually lead to a description of the actual problem, but that's really not something that inspires confidence.
  • mkesper 5mo ago
    That was the old docker compose. Things got a lot better since they rewrote it in Golang and update it again.
• jpalomaki 5mo ago
  Kubernetes sounds like overkill, but I've been running microk8s for few standalone servers. This feels a pretty good match when working with agents. Codex can manage the cluster also over ssh, schedule new pods, check statuses, logs etc.
  • gchamonlive 5mo ago
    I think k8s is a great choice today specially when you can plug it into Gitlab and have a control plane for your clusters in the same place where your code lives.
  • nijave 5mo ago
    K3s is also pretty nice for a minimal setup Haven't used it in a while but this thing is also interesting--it supports a bunch of different ways to spin up k8s https://github.com/tilt-dev/ctlptl https://github.com/tilt-dev/ctlptl
• __jonas 5mo ago
  I like running docker compose for my simple needs because it consolidates pretty much all the config in one declarative file, and docker manages 'everything'. By now I know how to handle the handful of caveats listed in this article. Beyond what's listed there, I'd also give a mention to the way port publishing works (the fact that it ignores firewalls), as that's something that still trips people up if they don't know about it. > docker compose pull && docker compose up -d is a fine command if you are SSH’d into the host. At customer scale—dozens of self-managed environments behind firewalls, each with its own change-control process—that manual process doesn’t scale. No idea what this 'customer scale' operation is, but it seems like a pretty clear cut candidate for not using docker compose. I also don't think watchtower should be listed there, it's been archived and was never recommended for production usage anyways.
  • embedding-shape 5mo ago
    > I'd also give a mention to the way port publishing works (the fact that it ignores firewalls), as that's something that still trips people up if they don't know about it. Isn't that a Docker thing rather than Docker Compose though? There is a ton more caveats to add if we don't already assume the reader is familiar with the hard edges of Docker, seems the article only focuses on Docker Compose specifically, probably because it'd be very long otherwise :)
    • __jonas 5mo ago
      It is yeah – I was thinking along the lines of the decision being between docker compose and something like podman quadlets
  • nijave 5mo ago
    Sounds like they're referring to a dedicated tenancy multi-tenant model
  • selfmodruntime 5mo ago
    > docker compose pull && docker compose up -d is a fine command if you are SSH’d into the host. At customer scale—dozens of self-managed environments behind firewalls, each with its own change-control process—that manual process doesn’t scale. We just use ansible for this part.
• Havoc 5mo ago
  I really like developing against compose because it's light but gives you that escape hatch of translating to k8s if later circumstances call for it. Very few separate ecosystem transfers are quite that frictionless.
• mdrzn 5mo ago
  AI article with 27 occurrences of dashes —
• Sarky 5mo ago
  I prefer Portainer to manage my docker composes. It is simple and can do it all instead of using cli. Added benefit if you have multiple hosts and want to manage them from one place. And you can extend the whole setup with git for version control.
• tontony 5mo ago
  Compose is great, but a couple things always created friction for me when using it for non-local setups: * Lack of a user-friendly way of managing a Docker Compose installation on a remote host. SSH-forwarding the docker socket is an option, but needs wrappers and discipline. * Growing beyond one host (and not switching to something like Kubernetes) would normally mean migrating to Swarm, which is its own can of worms. * Boilerplate needed to expose your services with TLS Uncloud [1] fixed all those issues for me and is (mostly) Compose-compatible. [1] https://github.com/psviderski/uncloud/ https://github.com/psviderski/uncloud/
  • esperent 5mo ago
    > Lack of a user-friendly way of managing a Docker Compose installation on a remote host I've been using portainer for years, it's decent.
  • chatmasta 5mo ago
    For remote installation, use the `docker context` command. You create a context with a named SSH host and then it connects via SSH to that host (as configured in your local ssh_config) and uses its docker daemon. Everything works flawlessly apart from local bind mounts (for obvious reasons). If you remember `docker machine`, this is basically the modern version of that.
    • tontony 5mo ago
      That's fair; good solution.
  • deleted 5mo ago
    [deleted]
• aykutseker 5mo ago
  [dead]
• justsomehnguy 5mo ago
  > if you close the operational gaps it leaves: cleanup, healing, image pinning, socket security, and updates. Ie you need a sysadmin. Oops, you fired them all 10 years ago when the agile devopsing became the best thing after the pumpkin latte.
• stevefan1999 5mo ago
  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 emulate things like latency or burstable packet loss so that we can do a controlled chaos test for reliability test. I tried Skaffold, Tilt, Devspaces and Devpod/Coder v2, none of them are really simple like Compose.
  • nijave 5mo ago
    Helm mostly does that. Not a huge fan of a text templating engine generating yaml but once you get your chart setup with a few variable inputs, you can continue using it for a bunch of other stuff with minimal new config. The inputs (values) are yaml so you can make it look exactly like a Docker Compose file if you want (wouldn't be surprised if there's some charts floating around that do that)
    • calmoo 5mo ago
      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!
      • freedomben 5mo ago
        I did that too, and ended up just skipping helm and using envsubst to interpolate the values I need at runtime from env vars. Nearly everyone preferred that approach. YMMV of course.
        • stackskipton 5mo ago
          BTW, this is what Flux V2 (GitOps) supports as well and we do at our company. It's worked well and covered almost all our use cases.
• hmontazeri 5mo ago
  Couple of months ago I published the way I use docker compose in production with mushak.sh and it’s really convenient to deploy this way
• merpkz 5mo ago
  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 - and restarting nftables or even applying new nftables rules usually ( flush ruleset in /etc/nftables.conf ) purges all the docker created rules and effectively breaks everything until docker daemon is restarted and rules re-created. I have partially solved this by using nftables filter chains with different names - admin_input/admin_output and using input hook with negative priority - so that traffic I choose to block is evaluated before docker rules are applied - that feels a bit like hack, but so far is the only way I have found. It is good practice in this day and age to run local firewalls on all hosts with policy deny, so that only traffic explicitly allowed can pass, that can severely limit blast radius during compromise.
  • nijave 5mo ago
    I don't. I'd run other workloads on separate hosts
  • sneak 5mo ago
    On my docker hosts there is no other traffic unrelated to docker. Everything goes in containers.
    • nijave 5mo ago
      To expand, you can use privileged containers, host network, capabilities, etc if the software really needs it. In that case, Docker basically becomes an init system/service manager but you get a singular daemon managing everything
    • merpkz 5mo ago
      Well, as an example we usually set incoming rules to filter SSH only from administrator IP addresses, TCP 10050 only from zabbix monitoring server and leave few icmp types required and rest is dropped and logged. For forward chain we set docker network ranges to route between themselves and only services actually used in containers. Allow container outgoing connections to our DNS servers, centralized HTTP proxy server and monitoring - nothing else containers are allowed to route to. And for output is similar, only allow our DNS servers, NTP, HTTP proxy, centralized rsyslog where everything goes and zabbix monitoring server and a few icmp types - nothing else gets out and is logged. With the advent of these supply chain attacks we read about often here it's just a matter of time some container is compromised and this seems like only viable way to at least somehow limit impact when such an event occurs.
• TheCapeGreek 5mo ago
  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 more like Ansible for me - the tool I use to build the environment, not the entire app. For the purpose of my question, let's assume I'm building normal CRUD services that can go a little tall or a little wide on servers without caring about hyper scale.
  • nijave 5mo ago
    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 lots of small files (npm) However, on the small/hobby end I don't think it's a huge concern.
    • TheCapeGreek 5mo ago
      > 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.
      • nijave 5mo ago
        >I'm specifically asking for that use case. That's what I answered for. >I'm not building binaries If you were, I would have added CPU to the list. >my "build" steps are actually deployment steps (npm build, composer install, etc) No, those are build steps. If you weren't using Docker, you would either run all those and shove in a zip/tarball or package into a deb/rpm, etc >The image I'm deploying by definition also contains my source code It doesn't contain .git or need credentials to your git/SCM >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 You don't need a registry--you can Docker save/load to push images directly to the server. Images buy you a versioned artifact with all the code-level dependencies baked in. Some maintainer yanks their package from npm? Who cares--you have a copy in your Docker image. Your new app version doesn't work? Edit 1 line to point back to the old image tag and rollback. >> 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. When the build process completes, it tears down the overlayfs which causes everything to sync which leads to a big I/O spike. Depending on the server and amount of files, it might have no impact. However, I've seen build servers become completely unresponsive for 5+ minutes due to the I/O load when this happens. One place I worked, we had to switch our build servers to NVMe--the Docker container teardown caused spikes over 100k IOPs. Can't remember the exact details--it was React either React web front end or React Native mobile app. >There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects. `docker save myimage:tag | gzip | ssh user@server 'gunzip | docker load'` Not saying creating distributable artifacts is the de-facto answer, but I'd strongly consider whether it's really that much more complicated.
• nickjj 5mo ago
  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-compose-in-production https://nickjanetakis.com/blog/why-i-like-using-docker-compo.... Not just for my own projects but for $500 million dollar companies and more.
  • Pxtl 5mo ago
    Thank you. I had been procrastinating on learning how to work with containers and finally got a handle on Docker Compose to play with self-hosting a coding agent and was worried that I'd once again procrastinated so long that I'd picked something up long after it was already dead.
    • duskdozer 5mo ago
      It makes things amazingly simple and portable, dealing with things otherwise seems so horrible now.
  • tcgv 5mo ago
    I love Docker Compose. It is simple to use, easy to organize and manage, and very robust. Also, our company does not need to "scale" production aggressively. Our production load is very predictable, so Docker Compose fits like a glove. We have been using it for more than five years now. Before that, we had a legacy deployment model, and I do not remember a single major issue related to Docker Compose. We use it for both staging and production environments. The same Docker image validated in staging is deployed to production. Never fails!
    • api 5mo ago
      "It is simple to use, easy to organize and manage, and very robust." This is why nobody uses it. Cloud stuff has to be as baroque as possible.
• wewewedxfgdf 5mo ago
  Use Nspawn. It's on every machine.
• dzonga 5mo ago
  well written guide. even their follow up - Docker Compose vs Kubernetes. Docker compose for me has been great - no complexity.
• kjuulh 5mo ago
  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 just use kubernetes, as I know how that works. Could i survive with 10 seconds of downtime, probably, but I'd really like if I could avoid it.
  • jimmydoe 5mo ago
    I’m happily taking that 10sec whenever thinking about the lifting I have to do for kube and extra cost.
  • derfurth 5mo ago
    That's why I now use uncloud, simple as docker compose and got rolling deployments https://uncloud.run/docs/guides/deployments/rolling-deployments https://uncloud.run/docs/guides/deployments/rolling-deployme...
  • Pxtl 5mo ago
    Reading the article over, it really feels like Docker should be targeting Swarm as (instead of being its own platform) a set of incremental enhancements to Docker Compose. "I need healthcheck-restarts" "I need off-host logging", etc. They've basically lost the war against Kubernetes but they could easily claim a lot of ground when it's just one more tweak you're adding to your docker-compose file as it scales.
  • n_e 5mo ago
    Why not use swarm? On a single node it isn't really more complicated than compose, and you get scaling and rolling deployments.
  • crummy 5mo ago
    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.
• rho4 5mo ago
  I really liked the specific actionable steps in the TLDR.
• kurtis_reed 5mo ago
  No
• rob 5mo ago
  I do this via Dokploy on a hosted Linode VPS and absolutely love it. Super easy to set up and maintain for tons of little side projects that don't require tons of resources. Seems like an ad for whatever "Distr" is though; I haven't run into any of these issues with Dokploy and everything's been running fine for months.
• faangguyindia 5mo ago
  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.
  • marginalia_nu 5mo ago
    What I'd like is systemd-compose. Maintaining several dozens of .service-files is not my idea of fun.
    • ctippett 5mo ago
      It's not quite what you suggested, but you can use podman with systemd. https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    • trey-jones 5mo ago
      Or more simply just wrap some orchestrator in a single service file. Could just be a bash script used for ExecStart.
    • faangguyindia 5mo ago
      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.
      • eb0la 5mo ago
        Keeping your sanity in tech is underrated.
  • vincentkriek 5mo ago
    How does this work? Can you show it?
    • throw5 5mo ago
• pm90 5mo ago
  No
• marginalia_nu 5mo ago
  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.
• jackconsidine 5mo ago
  > 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/<id>/<id>-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
  • yabones 5mo ago
    A very simple fix for that is to use the systemd log driver to send all the container logs to journald. Then you can set a size or time limit on journald. https://docs.docker.com/engine/logging/drivers/journald/ https://docs.docker.com/engine/logging/drivers/journald/ I believe Podman can do something similar.
• INTPenis 5mo ago
  Sure why not, it just never fits into my model of how I design infrastructure. Docker compose assumes all your services can reach each other over docker, which I find horribly insecure. I separate all my services by user account at least, maybe even by VM, and I run them all in rootless podman containers. So it just doesn't fit my style, but I'm sure it works fine.
• tacker2000 5mo ago
  Yes of course, im running a few production projects with it. Granted, its B2B Saas with not many users, maybe 100 concurrent. 80% of workloads dont need the complexity of Kubernetes and run fine with compose.
• deleted 5mo ago
  [deleted]
• ViewTrick1002 5mo ago
  Personally I have moved to k3s, although after learning a bit too deep how k8s operates when writing custom controllers at the day job. Docker/containers are great, especially for local development. But I feel the docker compose model quickly becomes a lot of messy brittle squeeze for little gain when multiple containers need to integrate. Better then to just take the plunge for the "real deal" and set up a non-HA k8s/k3s cluster with the interactions between the workloads clearly specified. In other words. I care care more about the interactions declaratively spelled out than the "scale to the moon" HA, auto-scaling, replicas or whatever people get sold on. And LLMs make this even easier. If you love reviewing yaml manifests....
• chuckadams 5mo ago
  Sure, it's stable enough, just keep in mind you won't get any autoscaling (or manual for that matter). Swarm is still supported by a third party, but that party has been loudly signaling that they intend to kill it off this year or next. Kubernetes isn't too big a leap, but damn are all those yaml manifests annoying to maintain. I usually just copy and tweak them from another project.
• jstanley 5mo ago
  > How Do You Handle Deployments? This section misses the one thing I was interested in: how do you avoid downtime in a deployment? I like to write web applications with Perl and Mojolicious, and a deployment is just "hypnotoad app", and then hypnotoad gracefully starts up new worker processes to handle new requests and lets the other ones exit once they've finished handling their in-flight requests. When I switched to Docker I found that there was no good way to handle this.
  • fnoef 5mo ago
    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.
    • hamdingers 5mo ago
      Here's a CLI plugin that automates this: https://github.com/wowu/docker-rollout https://github.com/wowu/docker-rollout
      • nojs 5mo ago
        Another vote for this - we’ve been using it for years without issues.
    • Oras 5mo ago
      Blue Green Deployment. There must be a docker container to handle this or at least a bash script. edit: thanks to next comment for referencing one
  • nsxwolf 5mo ago
    [dead]
• DeathArrow 5mo ago
  I am doing just this. Running docker compose on a server. When there will be to many microservices, we will move them in managed Kubernetes on a cloud platform or Nomad if any cloud platform offers it.
• eddyaipt 5mo ago
  [flagged]
• xenophonf 5mo ago
  Yes. It's nice to get an easy question every once in a while.
• perarneng 5mo ago
  If you love docker compose then you would love k3s. A single server with k3s is basically docker compose + the possibility to use helm to install all kinds of open source project such as monitoring and it just works.
• stackskipton 5mo ago
  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-kubernetes/ https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
  • jdwithit 5mo ago
    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".
  • tracker1 5mo ago
    That's mostly my take as well. I'm a big proponent of having separate teams for ops/deployment/sre from app development when you make the jump to k8s though. There's also a few bridge or in-between options for most cloud services as well. To me, if there's generally fewer than 10 actual active users at any given time and/or you can easily tolerate 30-60m of down time now and then... I'd lean into the simpler option of docker-compose. While I generally think of compose as a dev tool first, it's definitely useful sometimes.
    • globular-toast 5mo ago
      If you go cloud managed (EKS etc), there isn't really much to take care of. I do dev work and even keep a bare metal cluster going as well as a cloud managed one. Probably needs a real generalist though which maybe doesn't include your average dev.
  • arjie 5mo ago
    I spun k3s up with a config that I used an LLM to write. It's been almost 2 years. Thing just works for the most part. Even useful on a single node.
    • 5mo ago
• raphinou 5mo ago
  I'm very happy using docker swarm on a single host with traefik as reverse proxy using the setup described here: https://dockerswarm.rocks/ 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/ https://www.yvesdennels.com/posts/docker-swarm-in-2022/
  • QGQBGdeZREunxLe 5mo ago
    Swarm or Nomad is the way to go for simple single/multi-node setups. https://developer.hashicorp.com/nomad https://developer.hashicorp.com/nomad Disclaimer: I used to work for HashiCorp
  • time4tea 5mo ago
    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!
• jesse_dot_id 5mo ago
  We are a swarm shop and I don't foresee changing that anytime soon.
• fulafel 5mo ago
  There was also a way to deploy on AWS: https://aws.amazon.com/blogs/containers/deploy-applications-on-amazon-ecs-using-docker-compose/ https://aws.amazon.com/blogs/containers/deploy-applications-... - but AWS retired it pretty soon. I wonder how many people were using it when it was pulled, and if there were problems with it.
• saejox 5mo ago
  sign... another ai written article. are we already living in the dead internet? hackernews is filled with ai written blog posts.
• bouh 5mo ago
  I use docker compose a lot for small projects on a single box like Ovh vps. With a reverse proxy on the host. Nice ans easy to setup and update. If you want to test something that is between compose and k8s, check ring: https://github.com/kemeter/ring https://github.com/kemeter/ring
• Helmut10001 5mo ago
  What I found pretty great with docker is isolating individual docker systemd instances in rootless linux namespaces (i.e. users). I wrote about this here [1]. This lets you easily create multiple services on one VM that are quite isolated from each other. This system of doing things has worked reliably for me for quite some time, even for the 'bigger' services (gitlab, nextcloud, mailcow-dockerized etc.). [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless/ https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...
  • larsnystrom 5mo ago
    What a great blog post! I have wanted to do rootless docker with subuids, but putting it all together like you have is not easy. Thank you for writing it down!
• a_t48 5mo ago
  If nothing else, it's nice for at least making a declarable developer setup.
• Eduard 5mo ago
  when did docker get production-ready?
• dlt713705 5mo ago
  Docker Swarm sits between Compose and k8s and can be used on a single node if your needs are modest. I find Docker Swarm more reliable and easier to automate with a CI/CD pipeline than Compose, and it also provides health checks and other useful directives allowing you to minimize downtime, rollback when a deploy fails, and so on.
• appz3 5mo ago
  [flagged]
• sleepytree 5mo ago
  It seems nomad and consul would be another good choice before reaching for Kubernetes, no?
• predkambrij 5mo ago
  I also configured some productions with docker compose. The biggest problem is to handle the case of machine reboot. Docker restart policy needs to be set to "no". That's also the problem if there would be dependencies between services. Solving that always lead to some type of hacks. I created a bash script that's run with SystemD on machine boot, to start all docker compose services one by one, to avoid them starting all at once (if restart policy would be set to anything except "no"). Other than that, it's awesome. Complexity reduced if high availability is not a critical requirement.
  • sgt 5mo ago
    I use unless-stopped and containers come back up fine after reboot
    • predkambrij 5mo ago
      That's the problem. If there are many heavy apps, you don't want to start all of them at once. There's no control about that, that I'm aware of. Also, if you have dependson, this is a compose feature and it's ignored when docker daemon is restarted.
• dubovskiyIM 5mo ago
  [dead]
• whatever1 5mo ago
  Who are we to judge? It's whatever Claude decides.
• calini 5mo ago
  Still looking for a nicer solution to just deploy some personal projects that are usually 1 container big but might end up being 2-4, and being able to do logging, tracing, rolling updates, networking, etc; For now using Docker Compose for most of that.
• mococa 5mo ago
  I used to use DOCKER_HOST=ssh… with compose for years, very solid. The only issue is the little downtime during deployments.
• silverwind 5mo ago
  I'm going even simpler, just bare docker with a idempotent bash wrapper.
• arikrahman 5mo ago
  Just use nix flakes
  • __MatrixMan__ 5mo ago
    Well yes, but if you think you need docker-compose then you're looking for runtime control and not build time control, so you should use this nix flake: https://github.com/juspay/services-flake https://github.com/juspay/services-flake (which uses process-compose instead of docker-compose).
    • arikrahman 5mo ago
      I appreciate you sharing this with me!
• nrclark 5mo ago
  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.
• willswire 5mo ago
  Been exploring Docker Compose Bridge for app devs building apps for UDS/Zarf https://github.com/defenseunicorns-labs/compose-bridge-uds/ 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.
• arrty88 5mo ago
  Docker swarm might fit better if you want seamless rollout deploys and quick rollbacks. Also scaling and load balancing
  • bkircher 5mo ago
    I was looking for this comment. Seems to fit right in between “just” docker compose and a “fully-fledged” K8s. This book is running Erlang clusters on Swarm on EC2: https://www.goodreads.com/book/show/216601296 https://www.goodreads.com/book/show/216601296.
• solatic 5mo ago
  Guess this is an unpopular opinion: If you run more than one service/codebase, you might be better suited to using a proper container orchestration platform. Doesn't have to be Kubernetes. AWS ECS, GCP Cloud Run, Kamal are all modern options here. If you run a single codebase in production, why are you even containerizing? Language ecosystems have done a phenomenal job of improving their dependency management since Docker was released. Python has uv. Go has modules. NodeJS has pnpm. Do you actually get benefit from containerizing if you're deploying to a single production host somewhere?
• oddurmagnusson 5mo ago
  Since all the tools around that orchestrate Docker Compose don't do these best practices, I made my own: https://yoink.is/ https://yoink.is/ Things like a good security posture by default, health checks, drift detection, and port forwarding.
  • dfreire 5mo ago
    Looks great!
• danielpetrica 5mo ago
  I run it for my apps with traefik in front and is awesome. you can easily add services, DBs, backups and more and using the bin mounts you can migrate in painless way.
• fithisux 5mo ago
  Why not? There are numerous security hardened images on Bitnami. We used it thar way in a project 4 years ago. What I like for my prototype projects is how easy is to use it with podman too.
• tartieret 5mo ago
  why not swarm? it's basically the same yml file except that you can do zero downtime deployment, simply with docker stack deploy -c stack.yml (swarm will outline the image, warm up the container and switch traffic automatically). roll backs are also included for free. it's part of docker so no additional dependency