4 ms·

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

• 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.
    • gear54rus 5mo ago
      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 upgrade? your downtime is suddenly hours, oops. The k8s denial is strong and now rivals frontend frameworks denial. Never fails to amuse.
      • tcgv 5mo ago
        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 mistake too: assuming every production system should be operated like a high-scale tech company. Many production workloads are boring, predictable, and business-critical. They do not need aggressive autoscaling, multi-node orchestration, or constant traffic-spike handling. They need reliable deploys, backups, monitoring, health checks, and a clear rollback path. That is where Compose can be a good fit: simple operational model, understood failure modes, low moving parts. Kubernetes becomes much more compelling when you actually need automated failover, rolling deploys, autoscaling, multi-node scheduling, and stronger deployment primitives. Not needing Kubernetes is not necessarily denial, it is just choosing the complexity budget that matches the problem.
        • scottyah 5mo ago
          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.
  • daitangio 5mo ago
    I love it so much I have created a thin statless orchestrator layer upon it: https://github.com/daitangio/misterio https://github.com/daitangio/misterio It works very well!
    • monkpit 5mo ago
      You have built a kubernetes… https://www.macchaffee.com/blog/2024/you-have-built-a-kubernetes/ https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...
• kevinfiol 5mo ago
  Hey, just want to say thank you for your blog. I've learned so much about Docker, dev tooling, and engineering from reading it over the past 7 years.
  • nickjj 5mo ago
    Thanks a lot, I really appreciate it.
• sunaookami 5mo ago
  Have you read the article?
  • a96 5mo ago
    https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• codegeek 5mo ago
  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 ?
  • pvillano 5mo ago
    What effect does docker compose have on database resilience?
    • codegeek 5mo ago
      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)
  • giobox 5mo ago
    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 can't remember the last time I ever "natively" installed a DB personally!
    • codegeek 5mo ago
      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.
      • giobox 5mo ago
        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.
• seniorThrowaway 5mo ago
  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 realistically kubernetes is a superior orchestrator in just about every way, and installing k3s is simple and k3s is actually production ready. I don't like kubernetes all that much as cluster tech, but as a container orchestrator it has a lot of nice features.
  • theK 5mo ago
    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 maintenance heavy pipelines with just docker compose up --build --wait in the past years. How come you say health checks are still broken?
    • seniorThrowaway 5mo ago
      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 https://github.com/willfarrell/docker-autoheal exist. It’s something that was never fully carried through in Docker itself.
• merb 5mo ago
  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/ 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
  • mikestorrent 5mo ago
    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.
    • limaho 5mo ago
      Docker volumes still exist on the filesystem. Wouldn't one be able to point the backup solution at that directory?
      • mikestorrent 5mo ago
        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/`
  • c0balt 5mo ago
    The "easiest" way is to use bind mounts to a local directory (or multiple directories) instead of volumes. Then you can just use normal backup tooling. Docker volumes (and bind mounts) however have the minor problem of being hard to get a consistent copy to without stopping the service. You can work around this by, e. G., having ZFS or btrfs as the underlying FS and making a snapshot there. Otherwise, your software (like PostgreSQL) might also have other online backup tooling.
• lumost 5mo ago
  If the project fits on a single server (which it probably can in 2026) docker compose is great.