Gubernator [the kill k8s]

DEV Community

Top comments (1)

Building Shelf, an open-source desktop workspace manager for Claude Code and Codex sessions.

Joined

Jun 1, 2026

The "k8s is overkill for most teams" argument is correct, but the harder problem underneath it is "what to replace it with that doesn't grow into k8s by accident." Three things I'd push on:

1) The "lightweight orchestrator" market is essentially a graveyard because every lightweight orchestrator eventually adds the features that k8s already has (ingress, secrets, RBAC, service mesh). The way to win is to be opinionated: pick a fixed topology and refuse to grow new features. If Gubernator says "one host = one process group" and stays there, it has a chance. If it has a plugin system, it's already becoming k8s.

2) The "radical minimalism" pitch is great marketing but the real product is the operator's day. The reason k8s wins isn't the API — it's the ecosystem of dashboards, alerts, and runbooks that exist for it. The k8s-killer isn't smaller YAML, it's "I have a single page that tells me what's wrong." Gubernator's gde page is the right move; the SRE dashboard is what you actually have to nail.

3) For edge / multi-host small deployments, the hidden cost is cert rotation and service identity, not the orchestrator. If Gubernator ships with a baked-in cert lifecycle (one command, no CFSSL, no Vault), that's the unlock. If it doesn't, the operator ends up gluing cert-manager on top and we're back to k8s.

Curious how Gubernator handles stateful workloads — most "lightweight" orchestrators punt on this and the user ends up running postgres on a single VM anyway.