Docker Compose Isn't Enough

Original Article ↗ Hacker News Discussion ↗

Docker Compose’s role beyond development environments is contested, with some engineers successfully running sizable production and self‑hosting setups on it, while others argue it’s the wrong abstraction for reliable, large‑scale or user‑friendly deployment. Commenters contrast Compose with Docker Swarm, Kubernetes, and tools like Traefik, Caddy, Kamal, and various homegrown scripts, debating when the extra complexity of full orchestration is justified. The thread also critiques a new product (Tealok) that aims to simplify self‑hosting via higher‑level configuration, questioning whether another abstraction layer or even a GUI is really what less technical operators need.

Scope and role of Docker Compose

  • Many see Compose as a dev / personal or “single-box” tool; others report running serious production workloads with it on many servers.
  • Some argue Docker’s intended production story is Swarm (or K8s), making “Compose in prod” a misuse; others counter that if it’s simple and works, that’s sufficient.
  • Several note that for home/self‑hosting, a single server and occasional downtime are acceptable, making Compose a good fit.

Reception of the article and Tealok

  • Thread recognizes the piece as content marketing for a new runtime (Tealok) aiming to simplify self‑hosting for less‑technical users.
  • Some readers found it informative or relatable, especially around self‑hosting pain; others call it FUD, say it misunderstands Compose, or attacks it for not being a full PaaS.
  • The Tealok approach (TOML DSL, shared infra, automatic TLS/backups, app‑store‑like UX) is seen as promising by some but also questioned for lock‑in and narrow applicability.

Pain points and “wrong abstraction” claims

  • Article’s main complaints: port conflicts, lack of higher‑level concepts (domains, TLS, shared DB/cache), and backups.
  • Many commenters respond that these are routinely solved today with:
    • Reverse proxies/ingress (Traefik, Caddy, Nginx, HTTPS‑portal).
    • Multiple compose files / overrides and conventions for data directories.
    • External backup tools (borgmatic, kopia, scripts) and Git for config.
  • Some agree the abstraction is low‑level for non‑experts; others insist Compose should remain a thin orchestrator, not absorb TLS/backup logic.

Alternatives and tooling landscape

  • Suggested options: Docker Swarm (+Traefik), k3s/microk8s/minikube, managed K8s, Kamal, Podman + systemd, LXD/Incus, nspawn, small custom orchestrators and scripts.
  • Opinion is split: K8s praised for ingress, Helm charts, and hosting third‑party stacks; also criticized as overkill, complex, and costly to run.
  • Several argue that for a single node, Swarm or simple scripts over Compose often beat K8s on simplicity.

Self‑hosting patterns

  • Many describe successful self‑hosting setups: central reverse proxy, one or more shared DBs, Git‑tracked compose files, regular backups, and occasional manual deploys.
  • A recurring theme: most real‑world needs can be met by Compose plus a few well‑chosen tools, provided the operator is comfortable with some scripting and configuration.