Minimal Viable Kubernetes: Finally, a Self-Hosted Cluster You Can Actually Run

How on earth can I get a self-hosted Kubernetes up and running without a degree in computing science ? You’ve been pulling your hair out trying to get into Kubernetes and a fire hose of tutorials and technical manual pages look like it could take 6 months and a steep learning curve to implement a simple use case where you can just:

• host an application
• serve an endpoint to the internet
• save data to a persistent, available volume

Seemingly, this is not a lot to ask is it ? But Kubernetes out of the box cannot do a lot of these ‘basics’ without being hosted atop of a managed service, typically on one of the big 3 cloud providers.

You may have privacy and security issues that prohibit the use of cloud based, managed Kubernetes. It may be that the cost of managed Kubernetes is too much for a small business or start up to commit to when only minimal essential infrastructure needs to be running to start out with.

Minimal Viable Kubernetes (MVK) cuts through the noise and reduces the complexity that would lead to decision paralysis. It presents a keep it stupid simple template approach to setting up a self-hosted, hyper converged Kubernetes cluster.

MVK is a self-contained Kubernetes implementation designed for maximum portability and ease of management. It’s engineered to run on self hosted virtual machines. It can be on just a single host but is is intended to run on 3 to be resilient to single node failure. It is intended to be simple enough to maintain without the need for a dedicated platform team, while still mirroring the structural patterns of traditional managed cloud environments.

MVK isn’t just for small-scale use; it’s built to scale beyond its initial three hosts, transforming into a robust reference architecture for deploying business-critical workloads in real production settings.

A key focus of MVK is its implementation into self-hosted environments. It aims to fulfill dependencies typically provided by cloud services directly within MVK itself, significantly boosting its portability across various infrastructure landscapes. This hyper-converged approach means that compute, storage, and networking resources are integrated, reducing dependencies on these being cloud provided.

Your Path to MVK

The MVK documentation is designed to be your comprehensive guide to Minimal Viable Kubernetes. It’s an instruction-led resource that covers everything from introduction and installation to getting started and configuring infctl.

This brand-new documentation emphasizes microlearning, beginning with practical steps for local development environments. You’ll start by learning how to create a local k3s environment using k3d and execute initial infctl pipeline runs. Before long, you will have implemented resilient production like multi node k8s with trusted host workstation and then ephemeral cloud based proof of concept or pre-production workflows.

The goal is to take you on a complete journey from zero to hero with MVK. The documentation will guide you through deploying real workloads using self-hosted ingress, storage, and load balancing. Importantly, we focus on solutions that don’t abstract these critical components to third-party cloud providers, allowing you to build a hyper-converged Kubernetes cluster that you both control and understand.

infctl: The Gateway to Minimal Viable Kubernetes

infctl is the command-line utility at the heart of Minimal Viable Kubernetes (MVK), designed for rapid and reliable deployment of an MVK stack. We built infctl with a few core principles in mind:

• Simplicity and Transparency: infctl is intentionally small and straightforward. Its source code is concise enough to be reviewed and understood in a single session. It does its best to not hide underlying Kubernetes manifests, scripts, or kubectl commands. This transparency allows curious minds to easily learn from and extend MVK, providing a clear path into its operations.
• Empowering User Understanding: Ultimately, infctl aims to get out of your way. Once you’ve gained an understanding of MVK, you could conceivably replace infctl with your own preferred tools or methods. It’s intended to be a stepping stone, not a permanent dependency but if you find it works for you, that’s fine also, carry on regardless.
• Flexible Workflow Orchestration: Beyond initial deployment, infctl is designed for extension. It can serve as a lightweight pipeline for orchestrating workflows in various environments—whether that’s your local development setup, a cloud-based CI/CD pipeline, or a remote host. Its flexibility and minimal footprint make it a valuable tool in any of these scenarios.

Our path to MVK

In an effort to rationalize and simplify your infrastructure, it can be tempting to start with a single virtual machine. This pattern is adopted by many and scaling can be achieved with some providers by simply upgrading CPU, disk and network as time goes on. This simple vertical scaling is good for smaller, non enterprise applications and where the physical limits this incurs are acceptable to your use case and budget.

A single virtual machine however inevitably becomes a single point of failure. Having a cluster of 3 or more VMs running Kubernetes gives us a degree of resilience and allows for horizontal scaling.

In February of 2025 I stared to build a minimal, viable Kubernetes cluster to host services for ourselves and our customers.

The primary goal was to reduce the cost of managed Kubernetes by self hosting on Virtual Machines.

Discussing this activity led to being asked to provide a starting guide to fellow tech minded folk that wanted to get into Kubernetes but have limited time and immediate practical use cases.

Having worked with Kubernetes from around 2018 and starting out with self-managed k8s, these activities seemed to align and in July infctl received an initial commit. MvK became the guide and documentation for the project, with an initial commit in July 2025. This continues and now has two main sections:

• Microlearnings, which:
  • is for technically minded time poor folk that need to get up and running with k8s
  • uses infctl command line to automate the steps needed to achieve this

Templates, which

• are new and under development
• will contain functionally complete Kubernetes implementations in each of the 3 main cloud providers and possibly more to follow

MVK Design Decisions

MVK has to take an opinionated approach in order to provide a clear path to achieving its goals of being minimal and viable.

K3s and K3d are chosen as tools to deploy MVK as they are well established, known in the industry and provide efficiencies over traditional kubeadm based k8s binary distribution.

Ultimately we would like to think that our users are empowered to extend and enhance their own MVK, even to use any K8s distribution, based on the principles of MVK.

To get our head around some of the design decisions that have gone into MVK, it is interesting to compare K3s, the distribution it currently uses, with Talos, another super lightweight (Linux & Kubernetes distribution), Docker swarm - an alternative container orchestration platform and more traditional, ‘full fat’ Kubernetes - from the source maintainers.

Picking through this decision matrix is a maze. Having done so over several years led us through comparison, experimentation and practice to end up where we are right now with MVK being based upon K3s. But this journey will continue and MVK is bound to evolve.

Whats the point of MVK ?

So what does MVK give us and whats in it for you and your organisation ?

Colloquially we had heard that an average cost of around $100 a month for managed Kubernetes could cost 30% less with a self managed approach. We have found this to be closer to 50% for an initial hyper converged 3 node cluster.

We use this to build our own production infrastructure upon using MVK as an initial template onto which we apply our own security policies and operational process.

You also can do the same and MVK templates will make this a 3 step process comprising of:

1. prerequisite tooling checks
2. nitial configuration
3. pipeline run

Once 1 and 2 are done, 3 should be idempotent and can be run multiple times without issue and in order to maintain consistency and state.

For development through to pre-production and even production, infrastructure can be built, destroyed and re-deployed as required. Infrastructure as code, assures that our infrastructure is reproducible and version controlled.

Disaster recovery rehearsals as part of a business continuity strategy is available to even small teams and companies, not just the preserve of larger enterprises.

In the event of real life disasters, we can quickly and nimbly move from one infrastructure to an entirely new one, even to use other cloud providers. This makes us cloud agnostic, another goal in the enterprise but now made available to the none enterprise, the startup and smaller operators. All at a fraction of the cost of managed Kubernetes.

Build and deploy your own self-hosted MVK or contact me to discuss how I can help you get on stream with MVK in your organisation or next venture. We look forward to sharing MVK with you..