Kubernetes is overkill: when you don't need the colossus

The right question in 2026 isn't "is Kubernetes good?". That debate is over — yes, it is. The right question is another one, and almost no startup CTO asks it out loud: "do I need this for what I'm building?".

For most teams deciding architecture now, the honest answer is no. But the industry incentive system pushes in the opposite direction. Recruiters filter résumés by keyword. Conferences reward those who show YAML on a projector. Series A investors ask "are you on K8s?" as if it were a seriousness seal. The collective result is a giant complexity layer adopted by teams that didn't have the problem this complexity solves.

This post is the explicit defense of "you don't need it", with the math in hand. It's not about Kubernetes being bad — it's about choosing the right tool for the actual size of the problem you have today, not for the picture you want to project.

The seduction is real (and has a name)

The first thing to admit is that excessive Kubernetes adoption isn't irrational. It makes total sense — for the individual. The name of the force operating here is resume-driven development.

A platform engineer who learns Kubernetes earns, on average, 30% more at the next job. It's the technical skill with the highest salary premium in 2026 job listings among everything operations-related. Whoever puts "operated multi-region cluster in production" on LinkedIn has thirty recruiters in a week. Whoever puts "operated self-hosted panel on three servers" has two.

For the engineer, it's rational to learn Kubernetes even when the work doesn't require it. For the CTO, it's rational to adopt Kubernetes even when the product doesn't require it — it signals to the market that the company "is ready to scale", which is the vocabulary investors understand. For the platform team, it's rational to suggest Kubernetes on every new project — guarantees relevance for the next five years.

Each of these individual calculations is defensible. The aggregate is disastrous. The company pays the bill for a decision nobody made thinking about the company.

The starting point of this post is to assume that tension. You, reading, may be being pressured by one of the three forces above. Recognizing the pressure is the first step to deciding based on the real problem, not on the incentive of who's advising you.

The honest financial math

Let's put numbers down. Real, Brazilian, 2026. For the version of this math with the full Brazilian lens — exchange rate, LGPD, national hosting — there's a specific post at Kubernetes alternative in 2026: self-hosted PaaS for Brazilian teams.

A senior platform engineer in São Paulo or Florianópolis, capable of operating Kubernetes in production without supervision, costs today between R$25k and R$40k per month CLT, or between US$8k and US$12k per month PJ. Let's use R$30k as a conservative average — it's the salary you can close with someone competent who hasn't yet hit the market ceiling.

But R$30k is just one person. A production cluster needs 24×7 on-call. Brazilian labor law doesn't allow a single person to carry indefinite on-call — and even if it did, the mental health of the sole operator collapses in six months. You need at least two people rotating, with real time off between shifts.

R$30k × 2 people × 12 months = R$720k per year just in payroll.

On top of that payroll, add charges (CLT runs around 70-100% above the base salary; PJ varies but generally 30-40% if you want to treat the person decently). And on top of that, real costs of a platform team: auxiliary tool licenses, training, certifications the market asks for, conferences, eventual punctual consulting hire when something breaks in a way nobody in-house has seen before.

On infrastructure proper, the math also isn't cheap. The managed version of the colossus (EKS, GKE, AKS) charges about US$73 per month per cluster just for the control plane — that's about R$370 per month. On top of that comes NAT Gateway (US$40 per month minimum), Application Load Balancer (US$25 per month minimum), outbound traffic billed per gigabyte, disk snapshots, observability costs that grow with the number of pods and exported metrics.

Serious companies run at least two environments (staging and production), and many have a third dedicated dev or homologation environment. Multiply.

Total estimate year 1, with two platform engineers and two managed environments: between R$770k and R$800k. That's before the first serious customer, before the first real of recurring revenue, before the second product hire.

Make the inverse comparison. A team of three full-stack developers at R$15k each: R$540k per year. With charges, let's say R$720k. It's exactly the same range.

The concrete question is this: do you prefer to have three more people shipping code the customer will use, or do you prefer to have two people maintaining a platform the customer will never see?

There's no universal answer. But almost always, at the stage when this decision is made — pre-Series A company, team of five to fifteen people, product searching for product-market fit — the correct answer is to ship product.

The time math (more important than the financial)

Money you capture or save. Time you don't recover. The time math weighs more than the R$ math.

Setting up managed Kubernetes for minimally decent production takes 2 to 4 weeks. It's not installing the cluster — that's minutes. It's configuring the ingress controller, the certificate issuer, the monitoring stack (generally three coordinated products), the centralized log system, automatic backup of persistent volumes, alerts, network policy between pods, namespace segregation. Each component has five legitimate choices and three known pitfalls.

First real application deploy after that: another week. Manifests for the application, manifests for auxiliary components, health probe definitions (liveness, readiness, startup), resource request vs limit tuning, load tests to calibrate autoscaling, failure tests to calibrate restart policy.

Each new platform feature after that becomes a project. Automatically rotated secrets: one to two weeks. Custom metrics integrated into the dashboard: one week. Service mesh with end-to-end observability: two to three weeks, and that's if you choose one of the stable options upfront. Granular network policy per namespace with auditing: one week.

You spend the first six months assembling a platform. That's the optimistic scenario, with competent people and no major incidents.

Meanwhile, the smaller competitor that chose a simpler stack is shipping features. When you finish the "minimally decent platform", they already have three features you don't, eight customers who made buying decisions based on those features, and a feedback cycle running that will compose their next features with more precision.

In markets where the winner is decided in the first twelve months — almost every B2B SaaS market — that delay is fatal. You can have the most robust infrastructure in the segment and lose the entire segment because you arrived three months late with the feature that matters.

The profile that DOES NOT need Kubernetes

Here lives the majority of teams deciding this in 2026. If you fit all the criteria below, Kubernetes is overkill — almost certainly:

• Team of 1 to 15 engineers. You can't dedicate two people just to platform without compromising 15-30% of delivery capacity.
• 1 to 50 total production servers. At this size, simple abstractions still work. You can list all servers on one page.
• 1 to 100 distinct services or applications. The colossus ecosystem shines when you have thousands of microservices with cross-dependencies. Below 100, the orchestrator complexity is greater than the complexity of the system it orchestrates.
• Predictable traffic. No 100× spike in 30 seconds. If your load oscillates two or three times between valley and peak throughout the day, you don't need millimetric autoscaling.
• Typical HTTP/web workloads. Web application, REST API, queue worker, managed database. Without exotic needs like GPU sharding, large-scale ML inference, petabyte-per-night batch processing.
• Operation in 1 to 3 cloud regions. You serve one country, or at most two close continents. You're not orchestrating workloads that migrate between five datacenters in real time.

This is the overwhelming majority of teams adopting Kubernetes today. They fit all six criteria and still chose the tool designed to solve the opposite of each criterion.

If you recognize yourself here, the next section may be uncomfortable — but read until the end before dismissing.

The profile that NEEDS Kubernetes

To not fall into "Kubernetes never works", here's the honest side. These are the profiles where adopting the colossus is the right choice, not overkill:

• Multi-tenant SaaS with namespace isolation, with resource quota requirements, granular network policy, and audit per tenant. Banks, regulated fintechs, platforms that sell hosting to other developers. The colossus namespace model is the best primitive available for that problem.
• Real multi-region operation with workloads moving between datacenters in response to failure or demand. It's not "I have replicas in two regions for DR". It's "I move active workloads between four regions with automatic state and latency management". Very large company, with lots of money.
• Dependency on mature specialized operators that are worth the overhead. Postgres with automatic replication, Kafka with continuous balancing, Cassandra with orchestrated bootstrap, Spark in batch. If your architecture has three or more of these components operated by specialized automation, the colossus ecosystem is the place where this automation matured.
• Platform team of five or more dedicated people. You have real human capacity to maintain the system without compromising product delivery. It's not one person doing platform "also"; it's a department.
• Compliance that requires pre-approved tool names. FedRAMP, ITAR, some government contracts, some health frameworks in the US. If your auditor needs to point to an existing certificate on a list, the colossus is on that list. Other alternatives, generally, are not yet.
• Scale of hundreds to thousands of nodes. Above 500 servers you exit the range where simpler alternatives shine and enter the range where the colossus was designed to work. There's no serious substitute here.

If you have three or more of these, Kubernetes is the right choice, not overkill. Adopt without guilt, hire the team, spend the money — it's aligned.

If you have one or two, watch out: it can probably be solved with something simpler and migrated later, if you actually scale until you need more. Evaluate calmly.

If you have zero, any Kubernetes adoption is a résumé decision, not a product decision. Be honest with the team and with yourself.

The gray zone — where the most common error lives

There's an intermediate range where the decision is harder, and it's where the most common error happens. Let's describe it precisely:

• Team of 5 to 15 engineers
• 5 to 20 servers
• 10 to 50 services or applications
• 1 or 2 cloud regions
• Expected but not explosive growth (let's say, doubling in size in 18 months)

Here lives 70% of pre-Series B SaaS teams in Brazil in 2026. And here lives the fatal phrase: "we'll grow fast so it's better to start with Kubernetes already".

The fallacy is double. First: you won't grow 100× in six months. Real growth of successful SaaS sits between 2× and 5× per year in the first three years. You have time to migrate if you really need to.

Second, and more important: the stack you choose for a five-person team is rarely the stack you'll run with fifty. Priorities change, requirements change, trade-offs change. Companies that scaled from five to fifty people and kept the same stack are the exception, not the rule. You'll migrate anyway — the only question is when, and what you'll have shipped by then.

The right heuristic is: optimize for today + 18 months, not for a 5-year hypothesis. If in the next 18 months your infra won't require Kubernetes, don't adopt now. When the problem appears, you'll have revenue to hire the team that operates, and clarity about real requirements (which will be different from what you imagine today).

Engineering that ages well is the kind that solves the current problem with room to spare, not the kind that tries to anticipate every hypothetical problem.

What you gain on each path

To organize the decision, three paths side by side on ten criteria. The grades are honest — every path has caveats.

The middle column solves the case "one server, no SLA pressure" — and solves it well. The left column solves "hundreds of nodes, dedicated team, complex requirements" — and solves it well. The right column solves the range between the two extremes, which is where most SaaS teams in Brazil today live.

HeroCtl as the honest middle ground

To be direct with you: this blog is HeroCtl's, and the pitch exists. But it only makes sense for those who fit.

HeroCtl preserves the operational model of simple self-hosted panels — an executable file, install on Linux servers, manage everything from an embedded panel. The learning curve is hours, not weeks. You don't need to learn new vocabulary, abstract concepts, mandatory adjacent tools. Spin up the application, open the panel, see what's running.

But, unlike simple panels, HeroCtl runs as a real replicated cluster from day one. Three or more servers and the control plane survives the crash of any of them, without manual intervention. The coordinator election happens in about 7 seconds after a hard crash — tested in lab with repeated kill -9. You answer "what's the SLA?" to the first serious customer with a clean face.

And without the colossus complexity. No 300-line manifests — the equivalent in HeroCtl runs in about 50 lines. No specialized operators for each subsystem — router, certificates, metrics and logs come embedded. No assembling three observability products — the public stack lives inside the cluster itself.

Practical application range: 1 to 500 servers. Above that, the colossus ecosystem gives you tools we don't yet have, and we're honest about that. Below that, the operational economy is large — generally swaps two on-call platform engineers for one part-time developer managing the entire stack.

The numbers from the public cluster to calibrate expectations: 4 servers totaling 5 vCPUs and 10 GB of RAM, running 16 containers that serve 5 distinct sites with automatic TLS. The control plane occupies between 200 and 400 MB per server. By comparison, the control plane of a managed version of the colossus starts at about 700 MB per master node before any application comes up.

Practical decision (decision tree)

For those who need an answer today, without reading the entire post again:

1. Do you have a dedicated platform team of 3 or more people, today, hired? If yes → Kubernetes is viable. If no → continue.
2. Do you have a formal compliance requirement that lists Kubernetes nominally? If yes → Kubernetes is mandatory. If no → continue.
3. Do you operate 100 or more servers in production, today? If yes → Kubernetes or an equivalent orchestrator is the right choice. If no → continue.
4. Do you have a single server and zero SLA pressure? If yes → simple self-hosted panel solves it. If no → continue.
5. Are you between 2 and 500 servers, with real SLA requirement, and want to avoid the colossus platform bill? → HeroCtl is the honest middle ground.

Almost every pre-Series B SaaS team in Brazil in 2026 falls into case 5. Whoever falls into case 1 or 3 already knows it and probably isn't reading this post. Whoever falls into case 2 has regulation dictating.

Questions we receive

But what if I grow and need the colossus later? Grow first. Migrate later. Migrating 50 servers running HeroCtl to Kubernetes is a quarter project with a small team — much cheaper than carrying the colossus platform for two years without needing it. And when you actually need it, you'll have revenue to hire whoever operates it.

Can I use Kubernetes for only part of the stack? You can, and sometimes it makes sense. A specific workload that benefits from a mature specialized operator (Spark batch, large-scale ML inference) can run in a dedicated colossus cluster, while the rest of the product runs on something simpler. The cost is maintaining two operational models — worth it if the isolated subset really pays off.

What if my customer requires Kubernetes contractually? Then Kubernetes becomes a sales requirement, not an architecture decision. If the revenue justifies, adopt for the contract in question. But require the item in writing — many times the customer "requires Kubernetes" because their technical team assumed, without anyone writing it in a clause. Worth checking.

What if I already invested 2 years learning Kubernetes? The knowledge isn't lost. Kubernetes will continue to be relevant for decades — it's the standard infrastructure of large companies, and large companies don't disappear. You have applicable intellectual capital when the company grows, or when changing jobs to one that actually needs it. The choice not to use now doesn't invalidate the learning; it only postpones the use.

Are there cases of migrating from Kubernetes to something simpler? Yes, more common than publicly discussed. Companies that adopted early, realized requirements didn't justify it, and migrated to reduce operational cost and regain delivery speed. Generally stays out of blog post because admitting "we backtracked" is uncomfortable. But it happens, and almost always the team reports greater productivity afterward.

How long does it take a team to learn HeroCtl versus Kubernetes? HeroCtl: a competent developer runs the entire stack in production in one day. Documentation fits in a long post, concepts add up to about five. Kubernetes: the official tutorial takes a week, and the time to "operate confidently in production" varies from three to twelve months, depending on the complexity of the adjacent stack. It's not the same scale.

And for those who can't pay anything for platform? HeroCtl Community plan is permanently free. No artificial server limit, no feature gate on high availability, no expiration. You run the entire stack described here — coordination, router, certificates, metrics and logs — without paying anything. Paid plans (Business and Enterprise) add things that only matter when the company grows: corporate SSO, detailed auditing, source code escrow, SLA support. The current price contract is frozen for those who sign today — no clause that allows retroactive change.

Closing

The question we opened with isn't rhetorical. "Do I need this for what I'm building?" deserves an honest answer, the size of your real problem, without the filter of résumé pressure, the meeting with investors, or last week's conference talk.

For most pre-Series B SaaS teams in Brazil in 2026, the honest answer is no. Not because Kubernetes is bad — it's excellent for what it was designed for. But because what it was designed to solve isn't your current problem. You're planting a seedling; it's an excavator.

There's a middle path. If you want to try:

curl -sSL get.heroctl.com/install.sh | sh

Runs on any Linux server with Docker. No signup, no card, no phone-home. If you like it, scale to three servers and gain real high availability. If you don't like it, uninstall and go back to what you were using — without locked-in data, without embedded dependency.

The long history of why we chose to build this, instead of pointing to one of the existing alternatives, is at /en/blog/why-we-built-heroctl. It's the complementary reading for those who want to understand the reasoning before the tool.

The intent is simple: container orchestration, without ceremony. And without the cost of the colossus when you don't need it.