Dora NodaThe most honest sentence in the whole "What would a Kubernetes 2.0 look like" debate fits in a Hacker News comment: Kubernetes is not something that "Just Works," and running anything yourself has come to feel like a time sink that is incredibly error-prone and very likely to fail in production. That comment, from Rivet's founder on a thread with 259 points and 432 replies, is also a mission statement. Rivet is his attempt to build the thing the thread was asking for: an orchestrator and deployment platform engineers can self-host and scale trivially while keeping a small core with strong primitives.
It is a genuinely appealing pitch, and Rivet has real engineering behind it. But "trivially self-hostable" describes one machine much better than it describes two.
The thread itself was a response to Mat Duggan's essay arguing that Kubernetes' landmines come from not being opinionated enough — a decade of ecosystem churn around an under-opinionated core. Rivet takes that critique seriously: fix the core by shrinking it. This post inventories exactly what Rivet drops from Kubernetes' surface to hit its simplicity bar, what a Cluster-API-managed fleet already solves on the other side of that trade, and where the break-point lands for a self-hosted PaaS on owned hardware.
The inventory: what Rivet drops to stay small
Here is the core of the comparison. Each row is one responsibility a PaaS on owned machines must cover somewhere, and who covers it in each world:
| Responsibility | Rivet-only | Kubernetes + Cluster API fleet |
|---|---|---|
| Schedule work onto capacity | ✅ Actors → workers, built in | ✅ Pods → nodes, built in |
| Route requests to the right unit | ✅ Gateway routes per Actor | ✅ Services / Ingress / Gateway API |
| Per-workload durable state | ✅ SQLite or filesystem per Actor, tiered to S3 | ✅ PVCs via CSI, operator-managed DBs |
| Tenancy boundary | ✅ Namespaces (per customer, per env) | ✅ Namespaces + RBAC + NetworkPolicy |
| Container image lifecycle | ❌ Dropped — workers are your processes, you ship them | ✅ Image pull, caching, rollout strategies |
| Pod network fabric | ❌ Dropped — no CNI, no cross-host overlay | ✅ CNI, DNS, service discovery |
| Provision / replace machines | ❌ Dropped — nothing provisions a box | ✅ CAPI MachineDeployments (CAPH on Hetzner) |
| Upgrade and drain machines | ❌ Dropped — no cordon, drain, or rolling node upgrade | ✅ Rolling machine rollout, drain/evict |
| Heterogeneous bin-packing | ❌ Dropped — one Actor model, uniform workers | ✅ Requests/limits, affinities, DRA device claims |
The top four rows are why Rivet feels like Kubernetes 2.0. The bottom five are why it isn't a Kubernetes replacement. Every ❌ is a deliberate cut in service of the small core — and every one of them is a job your platform still has to do, on machines you own, with no cloud API to absorb it.
What Rivet keeps, and why it's good at it
To be fair to the pitch, the part Rivet keeps is the part Kubernetes is worst at: dense, fast, stateful units of work that don't look like containers. Rivet schedules Actors, not pods. An Actor is a long-lived process with durable state, a queue, realtime connections, and its own address — one per agent, session, user, or tenant.
The numbers are the argument. Rivet claims 12 ms cold starts, 72 KB per Actor, and billions of Actors on one control plane. An Actor lives inside a worker process you already run, not in its own container or VM, so a server that held hundreds of pods holds hundreds of thousands of Actors. Idle Actors hibernate — state persisted, memory freed — and wake on the next request with nothing lost. Every Actor gets a SQLite database or a POSIX filesystem tiered to S3, so millions can sit parked at near-zero cost.
The architecture is a clean split: the control plane is a single Rust binary that schedules, routes, and persists but never runs your code, while workers are your processes running your code. Rivet's founder puts the payoff this way: you can build roughly the equivalent of a Kubernetes controller trivially, which unlocks per-tenant deploys, metered billing, and workload orchestration (game servers, sandboxes, LLM interpreters) that would each be a bespoke operator on Kubernetes.
For agentic workloads — a sandbox and durable memory per coding-agent session, a backend per generated app — this is a better-shaped primitive than a pod. Nothing in the inventory above disputes that. The dispute is only about what happens outside the Actor.
Machine one vs machine two
On one machine, Rivet's self-hosting story is genuinely trivial:
docker run -p 6420:6420 rivetdev/engineOne container, filesystem-backed state, your app connects as a runner over RIVET_ENDPOINT. Compare that to standing up even a minimal Kubernetes control plane with etcd, a CNI, and a CSI driver on the same box, and the "Just Works" gap is real. This is the demo that wins the argument — and it should, because on one machine the dropped rows of the inventory don't exist yet. There is no overlay network to run, no second box to provision, no drain to orchestrate.
Machine two is where the ❌ rows send their invoice. Multi-node Rivet needs an external Postgres for control-plane state, a runner process on every box registered with the engine, and reachable networking between them. All of that is documented and reasonable — Rivet even versions workers and pools so Actor code can roll forward.
But notice what still has no owner: provisioning the box, installing its OS, joining it to the fleet, patching the kernel without dropping Actors, draining it for maintenance, and replacing it when the disk dies. Rivet schedules Actors onto workers; it has no opinion about where workers come from, because workers are processes somebody else placed on machines somebody else racked. Worker versioning covers the code; nothing in Rivet covers the computer.
A Cluster-API-managed fleet is the mirror image. CAPI's entire job is the machine rows Rivet drops: declarative MachineDeployment reconciliation that provisions Hetzner servers via CAPH, rolls them for upgrades, drains and replaces the unhealthy ones. Kubernetes then handles the container rows: images, networking, storage, bin-packing. The CAPI fleet never had Rivet's Actor primitive — but it never had an unowned machine either.
The tell: Rivet self-hosts on Kubernetes
The layering question settles itself in Rivet's own deployment docs: the self-hosted control plane runs on Kubernetes, Docker Compose, or a VM, with your own database. A system that were truly a Kubernetes replacement would not list Kubernetes as one of its three supported substrates. Rivet is a workload layer that floats above machine orchestration; something underneath still owns the machines, and for production that something is very often the system it proposes to obsolete.
This layering is also visible in Rivet's history. The project started as open-source game-server management built on Nomad and Rust (its 2023 Show HN), then grew past game servers into a general Actor engine, then added a managed Rivet Cloud in October 2025. Each step moved the "just works" boundary upward: first the game server, then the Actor, then the control plane itself. What never moved into Rivet is the machine. That boundary is the product decision, not an oversight — but it means "self-host Rivet" was never "self-host your infrastructure."
Verdict: compose, don't substitute
So here is the decision rule for a self-hosted PaaS on owned hardware:
- Pick Rivet's primitive when your workload is thousands of small, stateful, bursty units — agent sandboxes, per-tenant backends, realtime sessions. Pods are the wrong granularity there, and Rivet's hibernate/wake plus per-Actor SQLite is purpose-built for exactly that shape.
- Keep Kubernetes + Cluster API for everything a git-push PaaS does around those units: building and rolling container images, provisioning and upgrading the Hetzner boxes underneath, networking tenants apart, bin-packing heterogeneous web/worker/GPU workloads onto shared nodes.
- Compose them when you need both: Rivet workers are just processes, and there is no better place to run versioned, health-checked, rolling-updated processes across a fleet of owned machines than the orchestrator whose whole job is owning machines.
The HN thread asked what Kubernetes 2.0 would look like. Rivet's answer — a boring Actor scheduler with strong primitives — is a good answer to half the question. The other half is the fleet: declarative machines, drains, upgrades, and the long tail of owning hardware. Until a lightweight orchestrator covers those rows too, the self-hosted PaaS still bets on Kubernetes once the second machine arrives. It just might run its agents as Actors on top.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
