A developer, a consultant, or an article told you that your business should be running Kubernetes. Maybe the word came up in a hiring conversation, or a vendor pitch, or a migration plan. Before anyone builds anything, here is the honest take from a shop that runs infrastructure for a living: Kubernetes is excellent software, and most small and mid-size businesses should not run it.
What Kubernetes actually solves
Kubernetes is a system for running lots of containers across lots of servers. You tell it "I want six copies of this app running at all times," and it finds room for them, restarts them when they crash, replaces them when a server dies, spreads traffic across them, and rolls out new versions gradually so a bad deploy does not take everything down at once.
Those are real problems, at a certain scale. Google built the ideas behind Kubernetes because it runs millions of containers and no human could place them by hand. If you have dozens of services, multiple teams deploying many times a day, and traffic that swings hard enough to need automatic scaling, Kubernetes earns its keep.
Notice what is on that list. Not "we have a website." Not "we have an app and a database." The problems Kubernetes solves are coordination problems that only exist once you have a fleet.
What it costs you
The cost is not mainly the hosting bill, although a managed cluster's control plane and its minimum node count usually start you at a couple hundred dollars a month before you run anything. The real cost is complexity, and complexity is paid in people.
Kubernetes brings its own vocabulary: pods, deployments, services, ingresses, config maps, persistent volume claims, namespaces, and a long tail beyond that. Every application you deploy needs those written out in YAML. Networking inside a cluster works differently than networking everywhere else. Storage is its own puzzle. Upgrades come out multiple times a year, old versions stop being supported on a schedule, and skipping upgrades is how clusters rot into something nobody dares touch.
Then there is the staffing problem, which is the one that actually bites small businesses. When your Kubernetes-savvy developer leaves, who runs the cluster? We have been called into exactly this situation more than once: a cluster someone built two years ago, the builder is gone, nobody remaining can safely change it, and the business is now hostage to its own infrastructure. A plain Linux server in the same situation is something any competent IT person can pick up in a day.
Debugging changes too. When something breaks on one server, you log in and look. When something breaks in a cluster, the problem could be in the app, the pod, the node, the network layer, the ingress, or the interaction between any two of them. The layers that make Kubernetes flexible also give problems more places to hide.
What to run instead
A single VPS. One virtual server from AWS, Hetzner, DigitalOcean, or similar, running your app directly. For roughly five to forty dollars a month, a modern VPS is absurdly capable. It will serve a business website, an internal tool, or a modest web app for thousands of users without breaking a sweat. Boring, cheap, and any IT person can maintain it.
Docker Compose. If your app is already containerized, Compose gives you most of the day-to-day convenience people actually want from Kubernetes: your whole stack described in one file, brought up with one command, on one server. App, database, and reverse proxy defined together, reproducible, easy to move to a bigger server later. For a huge share of real-world workloads, a VPS running Docker Compose is the right amount of infrastructure. It restarts crashed containers, too, which covers the most common "self-healing" need.
A managed platform. Services like Render, Fly.io, Railway, AWS App Runner, or Azure App Service take your code or container and run it for you. Deploys, scaling within reason, certificates, and health checks are their problem. You pay somewhat more per unit of compute and give up some control, and in exchange nobody at your company operates infrastructure at all. For a small team shipping one product, this is very hard to beat.
When Kubernetes is the right call
There are honest reasons to run it. You have many services and multiple teams stepping on each other with anything simpler. You bought software that ships only as a Helm chart and the vendor supports nothing else. You genuinely need automatic scaling across many machines because your load swings by an order of magnitude. Or you are hiring from a pool where Kubernetes is the standard and fighting the default costs more than accepting it.
If one of those is you, use a managed offering, meaning EKS on AWS, AKS on Azure, or GKE on Google Cloud, and never run your own control plane on bare VMs. Even managed, budget for someone to own the cluster as part of their actual job, not as a side task.
How to know you got this right
The test is not whether your infrastructure is impressive. It is whether the person who maintains it could be replaced without a crisis, whether deploys are routine, and whether your monthly spend matches what the business actually needs. If a proposal lands on your desk with Kubernetes in it, ask one question: what problem does this solve that a server with Docker Compose does not? If the answer is about the future ("we might need to scale"), you can migrate when the future arrives, from a position of running something simple and well understood. We size infrastructure to the business in front of us, and most of the time that means talking clients out of Kubernetes, not into it.
Stuck on this, or want it done for you? That's the job.
Email us →