Replacing a $3000/mo Heroku bill with a $55/mo server

Original Article ↗ Hacker News Discussion ↗

Self‑hosted PaaS options and Disco’s niche

  • Commenters list many comparable tools: Coolify, Dokku, CapRover, Kamal, Dokploy, Canine, Kubero, OpenRun, devpu.sh, etc.
  • Disco is described as: Heroku‑like UX, Docker Swarm + Caddy under the hood, GitHub‑driven deploys, CLI + UI, API‑key collaboration instead of SSH.
  • Disco emphasizes a narrow, pragmatic feature set (apps, env vars, deploys) over large app catalogs or compose orchestration; it treats app servers as stateless and recommends external managed databases for prod.
  • Some ask for clearer comparisons, screenshots, and architectural diagrams; docs are seen as sparse.

Heroku / cloud economics vs a single box

  • Many see Heroku’s pricing as 25–50× over raw compute, calling it “a fancy steak dinner” rather than “bread.” Small staging apps can reach $500/month each due to dynos plus managed DBs.
  • Others argue $3k/month is trivial next to developer salaries; you’re paying to offload DevOps, uptime, security and scaling. For high‑salary teams, PaaS can still be cheaper overall.
  • There’s broad agreement that modern single servers (e.g., Hetzner dedicated) are extremely powerful and cheap, and that cloud pricing no longer tracks hardware improvements.

Staging and dev environments

  • Strong support for having staging mirror prod infra to catch infra‑level bugs; some say “it’s not staging” if it runs on a different platform.
  • Others note the article’s use is closer to per‑developer or QA environments, where a shared beefy box is “good enough” and a huge productivity boost, even if prod stays on Heroku.
  • Some question why six staging environments were provisioned at full Heroku prices and why more local or consolidated setups weren’t used.

Operational burden and skills

  • Big split:
    • One side: self‑hosting is fun, simple with automation (Ansible/Salt/Puppet/NixOS), and the cloud has made people irrationally afraid of Linux servers.
    • Other side: even with automation, maintaining OS hardening, backups, monitoring, TLS, scaling, and infra parity is real, recurring work that can outweigh compute savings.
  • Several frame PaaS as buying back engineering time and organizational simplicity; others see it as an unnecessary 10–50× markup once you have in‑house skills.

Databases and stateful services

  • Multiple commenters say the database is what truly scares them: backups, PITR, upgrades, failover.
  • Disco explicitly positions its built‑in Postgres as “good enough” for non‑critical use and recommends managed providers (Neon, Supabase, Crunchy, RDS) for production.
  • Some argue automatic backups and replicas are not “advanced” features but table‑stakes; others say they’d never self‑host prod DBs again.

Swap, zram, and reliability on a single server

  • Large subthread around the htop screenshot: suggestion to enable swap, zram, and earlyoom/systemd‑oomd to avoid total lockups on memory spikes.
  • One camp: swap (especially compressed RAM swap) is valuable for evicting cold pages, improving cache usage, and absorbing leaks; modern SSDs make it acceptable.
  • Opposing camp: swap often leads to severe thrashing and unpredictable latency; many disable it on servers and prefer aggressive OOM killing plus capacity planning.
  • Consensus: defaults matter; Linux’s behavior under memory pressure can be problematic and usually needs tuning if you’re running many services on one box.

Article tone and marketing

  • Some readers feel the blog post is heavily LLM‑polished and doubles as a marketing case study for Disco, reusing copy from the landing page.
  • Others don’t mind: many company tech blogs are implicitly marketing; what matters is whether the technical content and cost analysis are useful and honest.