Reclaim the Stack

Original Article ↗ Hacker News Discussion ↗

Reclaim the Stack, an open-source Kubernetes-based platform intended as a self-hosted alternative to Heroku, has drawn interest for claims of 90% cost savings and better performance after one company’s migration from managed PaaS. Commenters weigh those benefits against the operational complexity of running Kubernetes and associated services in-house, questioning whether most startups and SMBs are better served by simpler options like VMs, Docker Compose, or lighter PaaS tools. The exchange surfaces a broader tension between reclaiming control and reducing cloud spend on one side, and the hidden long‑term maintenance costs and reliability risks of DIY infrastructure on the other.

Project scope and goals

  • Reclaim the Stack (RtS) is presented as an open-source, Kubernetes-based Heroku replacement, built after migrating a mature SaaS from Heroku to self‑hosted K8s.
  • Reported results: ~90% infra cost reduction (e.g., ~$7.5k→$520/month, later claimed $400k+/year saved) and ~30% performance improvement, plus more control and GDPR compliance.
  • Stack includes Talos Linux, HA Postgres/Redis/Elastic via operators, monitoring/logging, Cloudflare ingress, GitOps, and a custom CLI.

Kubernetes: power vs. complexity

  • Supportive views:
    • K8s is reasonable if a team already has K8s skills and wants a standardized, extensible platform with HA, observability, and DB operators.
    • With a “minimal” setup (e.g., managed K8s, simple networking, standard operators) some report years of stable operation and modest maintenance.
  • Critical views:
    • Many argue most SMBs and simple SaaS apps don’t need K8s; a few VMs, Docker Compose, or simple PaaS can scale to millions of users.
    • K8s ecosystem (Helm, CNIs, operators, CI/CD, service mesh) is seen as over‑engineered, fragile, and upgrade‑prone; several anecdotes of cluster upgrades breaking prod.
    • Concern that “two willing developers” understates the long‑term operational burden, on‑call load, and skill requirements.

Cost vs. engineering time

  • Pro‑RtS side: infra savings reportedly fund multiple hypothetical devops hires, yet platform work is claimed to be only a few days per month and shared by full‑stack devs.
  • Skeptics:
    • Stress that Heroku‑like platforms price in the hidden “infrastructure debt” (upgrades, DR, tuning); rebuilding this in‑house creates ongoing, not one‑time, work.
    • Question ROI if you spend substantial engineer time and risk outages just to save a few thousand per month, especially for smaller teams.

Security posture

  • RtS explicitly trusts developers and the internal cluster network; multiple commenters label this as outdated “soft perimeter” thinking.
  • Zero‑trust approaches (mTLS, IPsec, strict VPC egress controls) are acknowledged as more complex and costly but considered necessary in many environments.
  • Debate over how far to lock down outbound traffic: some DFIR/infosec voices say proper egress controls regularly stop attackers; others report serious productivity and reliability pain from over‑restrictive policies.

Alternatives and fit

  • Numerous alternatives mentioned: Dokku, Coolify, Docker Swarm, Kamal, ECS/Fargate, Cloud Run, Fly.io, “deploy-to-your-cloud” PaaS, homegrown bash+systemd.
  • Broad consensus: RtS/K8s is attractive for teams with K8s expertise, higher spend, and HA/observability needs; simpler PaaS or VM‑based setups remain better for many smaller or less ops‑heavy products.