Mist Joins the 2026 Self-Hosted PaaS Wave as a Go-Minimalist Heroku Clone: What a Fresh Show HN Entrant Still Gets Right (and Skips) Versus a Cluster-API Platform

A developer shipped a new self-hosted PaaS on Hacker News in July 2026, and it runs in 20MB of RAM as a single Go binary with an embedded SQLite database — no Postgres to stand up, no Redis to configure, no Kubernetes anywhere in the stack. Mist is git-push Docker deploys, automatic Let's Encrypt TLS, one-click Postgres/MySQL/Redis/MongoDB, and a live-logs dashboard, built by two developers who said existing options "felt too complex or resource-intensive for small servers, homelabs, and side projects." That a fresh 2026 entrant chose the same one-box, single-daemon architecture as Dokploy and Kamal — not Kubernetes — is the actual signal here: it says the bar for "good enough" self-hosted PaaS still sits well below cluster orchestration. Here's exactly what Mist ships, what that architecture gets right, and what it deliberately doesn't attempt that a Cluster-API-managed platform is built around from day one.

What Mist Actually Ships​

Mist is MIT-licensed, built roughly half in Go (the backend/agent, 47%) and half in TypeScript (the dashboard, 49%), with a thin layer of shell for install scripts. The feature list, per its Show HN launch and repo docs:

• Git-push deploys — a webhook triggers a Docker build and rollout on push, the same pattern Dokku popularized a decade ago.
• Automatic HTTPS — custom domains get Let's Encrypt certificates via Traefik, chosen specifically for its Docker-label-based auto-routing (no manual proxy config per app).
• One-click databases — Postgres, MySQL, Redis, and MongoDB, provisioned as managed containers alongside the app.
• Live dashboard — real-time logs and metrics over WebSocket, JWT-authenticated with role-based access control.
• Single binary, embedded SQLite — Mist's own control-plane state lives in SQLite next to the binary, not an external database.

The headline number is the ~20MB RAM footprint for that single Go binary — the vendor's own claim, not independently benchmarked, and it's worth reading as "the agent process idles at 20MB," not "the whole stack including Traefik, your app containers, and your one-click Postgres instance fits in 20MB." Even with that caveat, it's a useful anchor against the two incumbents Mist is explicitly positioning itself between:

Mist isn't competing with Coolify's 280-service marketplace or Dokploy's Swarm integration — it's competing on being small enough to run comfortably on the same $5/month box as the app it's deploying, with nothing to configure beyond docker run.

Why a Brand-New 2026 Project Chose the Old Architecture​

The interesting fact about Mist isn't that it exists — self-hosted Heroku clones have shipped every year since Dokku in 2013 — it's when it shipped and what it copied. In mid-2026, with Kubernetes' Cluster API subproject shipping in-place upgrades and chained multi-version updates, and with Coolify and Dokploy both years into iterating on their own platforms, a brand-new entrant looked at the whole landscape and still chose: one server, one daemon, no control plane, no cluster.

On the Show HN thread, the creator was direct about the target user and the tradeoffs that follow from it. Asked how Mist differs from Coolify, they said it isn't meant as a replacement — the goal is "beginner friendly and lightweight," not feature parity. A long-time Dokku user flagged that Mist checks compiled binaries into the repo, a packaging choice that reads as "we optimized for install-and-go over build-from-source purity."

When a commenter raised the obvious question — what happens when you outgrow one box — the creator's answer was that multi-node support would require real user effort to migrate into, with a promise to ship tooling to soften that later rather than a claim it already exists.

That combination — SQLite over Postgres, Traefik for auto-routing instead of a custom proxy, checked-in binaries for a one-command install — is the same shape of bet Kamal and Dokku made before it: minimize what has to be running and configured before your first app deploys. Every dependency Mist could have added (an external database, a message queue, a scheduler) is a dependency a homelab user now has to keep alive.

Zero of those exist in Mist's design. For the workload it's built for — a handful of side projects on a single VPS someone is running themselves — that's not an MVP shortcut, it's the correct answer to the brief.

What Mist Deliberately Doesn't Attempt​

The same design choices that make Mist small make it structurally single-node. This isn't a bug the creator missed — it's the boundary they described on the launch thread, and it maps directly onto capabilities a Cluster-API-managed platform builds in as defaults rather than future work:

That last row is the real fork in the road. On a Cluster-API-based platform like bex, the fleet-lifecycle machinery isn't a feature bolted on after a single-node MVP — it's what the control plane is, provisioning and self-healing Hetzner-backed clusters via CAPH so that adding a second node is a declarative change, not a data-migration project. Mist embedding its own state in SQLite on the same box it deploys apps to is precisely the choice that forecloses that path without a rewrite — you can't reconcile a fleet from a database that only one machine can see.

None of that is a knock on Mist. It's the same tradeoff Kamal made explicitly: a single point of failure is an acceptable, even correct, design when the thing failing over is a homelab side project a maintainer restarts by hand within the hour, not a service with an SLA.

Where the Line Actually Sits​

The decision isn't "Mist is beginner-grade and a Cluster-API platform is what you graduate to." It's a narrower, answerable question: does the number of machines your workload runs on, and their health, change faster than a human can safely react to it by hand?

• If your app runs on one box, or a small fixed set you provision by hand and rarely touch — Mist (or Kamal, or Dokploy on a single node) is the right tool, not a placeholder. A 20MB daemon with embedded SQLite has no failure mode more complex than "the box is down," and restoring from a backup on a fresh VPS is a solved, well-understood recovery path at that scale.
• If a node dying at 3am needs to self-heal before anyone gets paged, or "add a worker" needs to be a replica-count edit instead of a manual box-provisioning exercise — you need the reconciliation loop Mist doesn't have and isn't currently trying to build. That's a fleet-lifecycle problem, and it's the one Cluster API exists to solve declaratively rather than through scripts a human re-runs.

Mist's launch is itself evidence for where that line sits in 2026: a brand-new project, built from scratch with a full view of the Kubernetes ecosystem available to copy from, still chose the one-box model — because for the audience it's targeting, that's not a compromise, it's the whole point. The bar for "good enough" self-hosted PaaS hasn't moved toward cluster orchestration by default. What has changed is that the two ends of that spectrum — a 20MB single binary and a self-healing multi-node fleet — are now both one git push away, and the honest engineering question is which failure mode you can live with, not which tool looks more sophisticated on a Show HN thread.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Cluster-API control plane handling the node health-checks and fleet reconciliation that a single-binary tool like Mist deliberately leaves for later. Star the repo on GitHub or deploy your first app today.

Sources​

• Show HN: Mist – a lightweight, self-hosted PaaS — Hacker News
• trymist/Mist on GitHub
• corecollectives/Mist on GitHub
• Self-Hosted Deployment Tools Compared (2026) — Haloy
• Coolify vs Dokploy: Complete Comparison Guide 2026 — Contabo
• Cluster API documentation
• cluster-api-provider-hetzner (CAPH) on GitHub