Professional Kubernetes on a Budget - How to Run Production-Grade Clusters at a Fraction of the Cost

Every platform team eventually has the same conversation with finance: why does Kubernetes cost so much? The honest answer is that it usually doesn't. What costs money is everything wrapped around it. Control plane fees, egress by the gigabyte, storage markups, load balancer surprises, and a managed-service premium that adds 20-30% on top of raw compute.

Run the math on a realistic 8-node cluster, 3 control-plane nodes, 5 workers, and you will realise that AWS, Azure, and GCP all land in roughly the same place: around $2,800–$3,700 a month as of July 2026. Run the same production-grade setup with an HA control plane, GitOps, Cilium, cert-manager, and Prometheus on European bare-metal, and it comes in under $1,000 a month, and as low as ~$480 with Scaleway. That's not a rounding error. That's a 4-8x gap, and it's the gap this post (and the talk we're giving at Open Tech Day 2026 in Nürnberg) is built around.

What's changed since we last ran these numbers is the context. 2026 has been the year cloud hardware got expensive for everyone, and the year "where is my data actually hosted" stopped being a compliance checkbox and became a boardroom question across Europe. Both of those trends make the case for self-managed, EU-hosted Kubernetes stronger, not weaker, but only if you're honest about what changed. This post updates the numbers with July 2026 pricing, adds Hetzner's two main EU competitors, and explains how KubeAid, our open-source GitOps platform, turns "production-grade K8s on bare metal" into a same-day project rather than a quarter-long one.

The invoice nobody budgets for

"Managed Kubernetes" sounds like one line item. In actual practice though, it's six:

None of these line items is dishonest on its own. Egress pricing reflects real network costs. Control-plane fees fund a genuinely managed service. But stack all six together across a realistic cluster, and you get a bill that has almost nothing to do with the actual compute you're using, and almost everything to do with the packaging. Notice that the three EU columns look nearly identical to each other and nothing like the hyperscaler column; that's the more important comparison here, not which of the three is marginally cheaper.

The invoice isn't the real cost. Day 2 is.

One of the people who reviewed an early draft of this pushed back on the whole framing, and fairly: none of the above is really about whether a Kubernetes cluster is expensive. It's about Day 2.

If the framing is new to you: Day 0 is architecture and planning, Day 1 is standing the cluster up, and Day 2 is everything that happens for the three-plus years after that, upgrades, patching, certificate rotation, incident response, capacity planning, security drift, the 2am page when etcd falls over. That's where the real engineering hours go, on any provider, on any hardware. A price-per-hour comparison between AWS and Hetzner says nothing about who's on call when a node dies, or who's tracking the CVE that just dropped against your ingress controller.

The same reviewer made a second point that's just as fair: "expensive" is relative. A team paying $3,700/month for EKS on a cluster that serves a product doing millions a month in revenue isn't going to lose sleep over a $500–$900 bare-metal alternative, that's rounding error against payroll, let alone revenue, especially if that cluster is what's making them 100x what it costs to run.

So when does the savings actually matter?

• Early-stage startups where infrastructure spend is a real fraction of runway
• Agencies running client workloads where margins are tight
• Bootstrapped companies where every dollar saved extends the run
• Any team operating at scale where "save $30K/year per cluster" turns into "save $300K/year" across 10 clusters
• European organisations where sovereignty requirements make hyperscalers non-viable for certain workloads

If your cloud spend is genuinely noise against what that spend is generating, the numbers below are interesting, not decisive. If you're in one of the categories above, they're transformative.

So take the numbers in this post for what they are, real, and worth knowing, but not the whole argument. The more durable one is this: Day 2 burden doesn't disappear because you're spending more on infrastructure, and it doesn't magically appear because you're spending less. A self-managed cluster with no automation behind it isn't cheaper than EKS once you count the engineer-hours spent on manual upgrades and after-hours pages, it's just cheaper on the invoice, and more expensive everywhere else. That's the actual problem KubeAid is built to solve. Not "make the hardware cheaper" (Hetzner, OVHcloud, and Scaleway already did that), but make Day 2 not require a dedicated platform team.

2026's plot twist: hardware got expensive too

If you're comparing prices to a deck from six months ago, throw the numbers out and re-check. Since Q1 2026, AI-driven demand for HBM (High Bandwidth Memory, the 3D-stacked memory that feeds AI accelerators like NVIDIA's H-series GPUs) has pulled DRAM and NAND production capacity away from conventional server memory, and contract prices have moved accordingly.

TrendForce tracked DRAM contract prices rising more than 50% quarter-on-quarter at the start of 2026. Their Q3 2026 projections show DRAM contract prices rising an additional 13–18% quarter-over-quarter, with NAND up another 10–15%. As one industry observer noted, "Unless the AI bubble bursts, prices aren't coming down."

Every infrastructure provider has passed some of that through, and none of the three EU alternatives were spared:

None of this closes the gap. It's a hardware-cost story that hits every provider's underlying bill of materials roughly proportionally, hyperscaler compute, EU bare metal, all of it. What it doesn't touch is the packaging: control-plane fees, egress pricing, and load-balancer markups aren't raw-material costs, they're commercial decisions, and they haven't moved the way memory prices have. So even after two rounds of Hetzner price increases, a self-managed 8-node cluster on EU bare metal is still roughly 4-8x cheaper than the equivalent managed offering on AWS.

Europe is done asking for permission

The cost argument used to be the whole pitch. In 2026, it's joined by a second, faster-moving one: European organizations are re-examining where their infrastructure actually lives and who can legally and silently compel their hardware provider to hand over the data on it, without the customer ever being notified.

A few data points worth knowing if you're making this case internally:

• Gartner projects worldwide sovereign cloud spending will hit roughly $80 billion in 2026, with European spend growing about 83% year-over-year off a $6.9 billion 2025 base.
• The EU Data Act, fully applicable since September 2025, gives customers a statutory right to data portability and requires cloud providers to actively support switching. As of January 2027, providers will no longer be permitted to charge switching fees.
• The European Commission is expected to publish its Cloud and AI Development Act (CADA) in the first half of 2026, which would formally define "sovereign cloud" in EU law for the first time and could tie public-sector procurement to EU ownership.
• In December 2025, the EU Council signed a Declaration for European Digital Sovereignty, following a France-Germany digital sovereignty summit the previous month.
• A recent executive survey found 78% of European leadership teams report being more concerned about digital sovereignty than they were a year earlier, 81% in Germany specifically.

The underlying legal issue is the US CLOUD Act, which gives US authorities a route to compel disclosure of data held by US-headquartered providers, including data sitting in an EU data center. That collides directly with GDPR's restrictions on transferring personal data to non-EU authorities without a valid legal basis. It's why even the hyperscalers are responding: AWS launched a physically and logically isolated "European Sovereign Cloud" in Brandenburg in January 2026 (a €7.8 billion investment structured as a standalone German entity), and Microsoft and Google have leaned on partnerships with T-Systems and similar EU operators to offer comparable isolation.

None of this means "leave AWS tomorrow." Analysts are consistent on that point. Forrester, among others, doesn't expect any European enterprise to fully exit the hyperscalers in 2026, and the switching costs for deeply integrated PaaS workloads are real. But for the workloads that are portable, and Kubernetes, by design, is one of the more portable workload shapes in existence, the interest has shifted from "why would we bother" to "why haven't we started."

Three EU alternatives, one spec sheet

Hetzner isn't the only option, and for a sovereignty-driven decision, it shouldn't be the only one you evaluate. Here's how the same class of dedicated server compares across the three EU-owned providers most commonly considered as AWS alternatives, using each provider's closest match to an 8-core/64GB machine:

Note: Scaleway's 8-core options are in higher tiers with different pricing. The table uses the closest match available at the time of writing.

Hetzner remains the cheapest 8-core bare-metal euro-for-core, but the gap has narrowed. OVHcloud is the only one of the three with a formal French SecNumCloud pedigree already partially achieved and datacenters spanning France, Germany, Poland, and the UK. Scaleway, owned by the Iliad Group, is 100% self-built software stack with no dependency on any US vendor anywhere in it, and reached ANSSI's first SecNumCloud milestone in early 2025. All three publish unlimited traffic and unmetered bandwidth as standard, the single biggest structural difference from hyperscaler pricing, where egress is often the line item finance notices first.

If your driver is pure cost, start with Hetzner or Scaleway depending on your core count needs. If your driver is a specific compliance regime, French public-sector work, healthcare data hosting, a SecNumCloud requirement in a tender, OVHcloud or Scaleway may be better starting points, even at a modest premium.

Real numbers: an 8-node cluster, three ways

Scale the single-server comparison up to the same realistic 8-node cluster (3 control-plane + 5 workers) used earlier. Here's the full cost breakdown per provider using July 2026 pricing:

All prices exclude VAT. Hyperscaler estimates use the closest 8 vCPU / 64 GB instance match (AWS r5.2xlarge at $0.50/hr). Even at this matched spec, the hyperscaler compute alone is 2-4x more expensive before adding egress, storage, and control-plane fees. The gap is structural, not a specification mismatch.

The headline isn't "Hetzner is the cheapest", it's that all three EU options save roughly $33,000–$39,000 a year versus AWS on this workload with the right automation. All three come with no control-plane fee, no egress tax, and no load-balancer markup baked in. The choice between them should be driven by data-residency requirements, certification needs, or which region you need presence in, not by a marginal cost gap.

What "production-grade" actually requires

The reason people default to managed Kubernetes isn't that self-hosting is impossible; it's that "just install Kubernetes" was never really the job. Production-grade means:

• A highly-available control plane (3 nodes, not 1)
• GitOps for every cluster change (ArgoCD, so nothing drifts from what's in Git)
• Sealed Secrets for credentials that never touch Git in plaintext
• Cluster Autoscaler / node auto-provisioning
• A real observability stack (Prometheus + Grafana, not "we'll add monitoring later")
• cert-manager and automatic TLS
• Cilium (or equivalent) with enforced network policies
• An ingress controller
• Cluster API for lifecycle management, upgrades, node replacement, scaling
• Multi-cloud or bare-metal parity, so you're not rebuilding this from scratch if you ever change providers

None of this is exotic. All of it is well-understood, open-source, and boring in the best sense of the word. What makes it expensive in practice isn't the software; it's the engineering time to wire it together correctly, keep it patched, and avoid being paged in the middle of the night because someone's certificate expired.

To be fair: this list is not what EKS, AKS, or GKE sell you as "managed Kubernetes." What those services manage is the control plane (API server, etcd, scheduler), not the application-layer tooling above. ArgoCD, cert-manager, Prometheus, Cilium, Sealed Secrets, you assemble and operate all of that yourself regardless of which cloud you're on. The comparison here is specifically about the cost of the infrastructure underneath, not a claim that one-click cloud K8s and self-managed bare metal are operationally equivalent out of the box. That's precisely why tools like KubeAid exist: to close the operational gap on the self-managed side so the cost advantage becomes realistic, not just theoretical.

How KubeAid gets you there in two commands

KubeAid is Obmondo's answer to that automation problem: an open-source GitOps platform that gives you one consistent way to install and operate Kubernetes on Hetzner (Cloud or Bare Metal), AWS, Azure, or your own on-prem hardware, using Cluster API under the hood for lifecycle management, and ArgoCD for everything after bootstrap.

The practical workflow, via KubeAid CLI (a single self-contained Go binary with the engine compiled in):

kubeaid-cli config generate --configs-directory ./outputs/configs/my-cluster/
# interactive prompt walks you through provider, credentials, node groups, SSH keys, Git repo URL
kubeaid-cli cluster bootstrap --configs-directory ./outputs/configs/my-cluster/

Two commands. The first runs an interactive prompt that collects everything — provider choice, cluster name, credentials, node groups, Git URLs — and writes general.yaml and secrets.yaml. The second provisions machines via the provider API, installs Kubernetes, and pushes the cluster's full configuration, including CNI, ingress, cert-manager, monitoring, and autoscaling, into your Git repository, where ArgoCD takes over and keeps the live cluster in sync with what's committed. Roughly 100 pre-configured, tested Helm charts ship with the project and get weekly automated updates, so you're not hand-rolling values files for Prometheus or Cilium from scratch.

What about OVHcloud and Scaleway?

KubeAid's native cloud integrations today cover Hetzner (Cloud and Bare Metal), AWS, and Azure. GCP, OVHcloud, and Scaleway are not yet native integrations, but that doesn't mean you can't use them.

Both providers offer excellent bare metal options. KubeAid's bare metal provisioner can treat these servers as "on-premise" hardware, giving you the same GitOps workflow and Day-2 automation without waiting for a dedicated cloud API integration. The workflow looks like:

kubeaid-cli config generate onprem(or_some_cloud_provider)
# edit configuration with your OVHcloud or Scaleway server details
kubeaid-cli cluster bootstrap --configs-directory ./outputs/configs/onprem/

This is the recommended path for using KubeAid with these providers today. The underlying Cluster API architecture means that as native Cluster API providers for OVHcloud (cluster-api-provider-ovhcloud) and Scaleway (cluster-api-provider-scaleway) mature, they can be integrated into KubeAid with minimal friction.

What matters once it's running in production

A few things that matter once this is running in production rather than a demo, and that double as a direct answer to the Day 2 point made earlier:

• GitOps drift detection, if someone changes something in-cluster instead of through Git, KubeAid flags it. That's an incident-prevention feature, not a cost-saving one.
• Shadow-cluster upgrades, major version bumps run through a parallel cluster you can validate before cutting over, rather than upgrading in place and hoping. That's the Day 2 task people put off until it becomes a Day 2 emergency.
• Compliance mapping, security and operational defaults are mapped to ISO 27001:2022, covering GDPR and NIS2 requirements out of the box, which matters a great deal if sovereignty is part of why you're doing this in the first place.
• Zero lock-in by design, you mirror the KubeAid repo into your own Git platform, so if Obmondo disappeared tomorrow, your infrastructure still runs, and you still own the update path.

Obmondo also offers a managed support layer on top. Monitoring, alerting, and patching SLAs for teams that want the operational safety net of a managed service without paying the managed-service markup on the underlying infrastructure. That layer exists specifically because Day 2 doesn't go away just because the automation is good, it just gets smaller and more predictable. But the open-source core works standalone; the business model is just the support, not the software itself.

Getting started

If you're evaluating this for your own infrastructure, the honest advice is: don't start by moving your riskiest, most stateful workload. Start with something Kubernetes-shaped that's already fairly portable, a staging environment, an internal tool, a stateless service. Stand it up on Hetzner (or OVHcloud, or Scaleway) with KubeAid, and let the GitOps workflow prove itself before you trust it with anything that pages people at night. Then judge it on the thing that actually matters: not the invoice, but how many Day 2 hours it did or didn't take from your team in the first month.

• KubeAid: github.com/Obmondo/kubeaid
• KubeAid CLI: github.com/Obmondo/kubeaid-cli
• Obmondo: obmondo.com

And if you're at Open Tech Day in Nürnberg on October 1st, visit us to see the full breakdown live, TCO across every major cloud, the architecture, and a cluster bootstrapped end-to-end on stage in a few minutes.