![Cover image for Gubernator [the kill k8s]](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fwa82hw9v63e0uvw85zc3.png)
Why I built an alternative to Kubernetes overkill.
Let’s talk about infrastructure efficiency.
Kubernetes is the undisputed industry standard for container orchestration, and for massive, complex enterprises, it’s irreplaceable. But for small-to-medium deployments or distributed multi-host edge environments, it often feels like an operational nightmare.
You install a massive orchestration layer, only to realize it's still missing the basics for actual operations. To get it production-ready, you have to layer on external tools for Ingress routing, plus a heavy stack for observability, health metrics, and SLOs. Suddenly, your infrastructure consumes more resources than your actual applications.
I believe in radical software minimalism. That’s why I’ve been developing Gubernator (gbnt), an open-source, lightweight distributed container orchestrator written entirely in Go.
Unlike traditional platforms, Gubernator bakes essential Site Reliability Engineering (SRE) and traffic management right into its core architecture:
Native Reverse Proxy: No complex third-party Ingress controllers. Gubernator automatically manages routing—like dynamically hooking up web containers to an Ingress layer (e.g., Caddy)—making exposure seamless and native.
Built-in SRE & Observability: Out-of-the-box support for health monitoring, metrics, and SLO tracking natively leveraging OpenTelemetry and Prometheus.
Zero-Bloat State Management: It swaps out heavy external key-value stores for an embedded, rock-solid SQLite architecture, ensuring multi-host consistency with a near-zero footprint.
Gubernator is designed for engineers who want robust, predictable, and resilient orchestration without the overhead and cognitive load of K8s.
If you are passionate about minimalist backend architecture, systems engineering, or streamlined DevOps, I’d love for you to take a look at the blueprint and documentation:
Explore the project: https://mario-ezquerro.github.io/gubernator/
How do you handle container orchestration for smaller setups? Let’s connect and discuss in the comments!
Top comments (1)
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.