The server is the cheap part

Bare metal has never cost less per core. The bill that grew instead is the one that never appears on a purchase order.

An essay from LILY Labs

A dedicated server with 48 AMD EPYC cores, at least 128 gigabytes of ECC memory and two NVMe drives currently rents for €199 a month. That is about €4.15 per core-month. The smallest cloud instance from the same provider (two vCPU, four gigabytes, forty gigabytes of disk) is €3.79.

Nobody in this industry is confused about those numbers. Hardware is cheap, it has been getting cheaper per unit for decades, and no engineer choosing a host believes the sticker price is where the money goes. The 2026 memory shortage has pushed some of it back up: one operator on Hacker News this month reported a four-core, eight-gigabyte instance rising from $24.99 to $73.49 over roughly a year, but the direction of travel across any longer window is not in dispute.

The expense arrives one sentence later, when something has to run on that machine and keep running on it. Orchestration is where the bill gets high, and Kubernetes is the usual answer to orchestration. It is a good answer to the problem it was built for: many services, several teams, availability someone is accountable for. It earns its right to complexity there, because distributed systems are genuinely hard and the alternative is a pile of scripts only one person understands. The question is not whether the tooling is good. It is what you are agreeing to when you add it.

The hardware is a purchase. Everything above it is a salary.

The second bill

What you are agreeing to is a second system running alongside your application: a control plane that has to stay available itself, a network layer chosen from several that make different trade-offs, ingress and certificates with renewal dates, storage that survives a rescheduled pod, upgrades that touch all of the above, and the configuration describing the lot. None of it is difficult. Every line has a guide and most have a good one.

What is hard to see at install time is the cost of maintenance. Getting it working is a weekend, and a satisfying one. Keeping it working is open ended: renewals arrive, upgrades arrive, disks fill, and someone has to be the person who notices while their attention is meant to be on the product.

What it has is a running cost, and the running cost is people. The staffing ratio the platform-engineering field converges on is one platform engineer per eight to twelve product engineers. A fifty-engineer organization therefore carries four to six of them. Platform and infrastructure total compensation in Germany runs around €99,800 across levels and about €120,500 at senior level according to TechPays; Glassdoor's German base-salary average is lower, near €74,500, and the difference is mostly base pay against total compensation. Take the conservative end, add employer overhead, and that team costs somewhere between four hundred thousand and seven hundred thousand euros a year.

Set it against the hardware it administers. Ten of those 48-core machines (a serious amount of compute for a company that size) comes to under €25,000 annually.

That is the ratio, and builds the foundation for the whole argument. The infrastructure is not expensive. Operating it is.

Most of what you bought is idle

Then there is what the hardware does while you pay for it.

CAST AI measured more than 23,000 production clusters across the three large providers between January and April 2026, before any optimization was applied. Average CPU utilization was 8 percent. Memory was 20 percent. GPU was 5 percent. The CPU figure has fallen three years running (13 percent, then 10, now 8) while CPU over-provisioning rose from 40 to 69 percent year on year, which amounts to organizations reserving roughly twelve times the compute their workloads consume at peak. CAST AI sells Kubernetes optimization, so weigh the source accordingly; the figures are telemetry rather than a survey, and Komodor's separate finding that over 65 percent of workloads run below half their requested CPU and memory points the same way. Flexera's State of the Cloud, published in March, put wasted cloud spend at 29 percent, reversing five years of improvement.

Efficiency was the promise. Three years of measurement say it is moving the other way.

One defensible commit at a time

Payroll is what this mechanism looks like at the top of the range. It is easier to see at the bottom, where there is no payroll for it to hide in and every decision has a name and a date.

Take one person, one application, one machine. Static files come out of a reverse proxy rather than the application process, because a proxy is better at it and the application stops spending cycles on bytes it did not compute. A cache goes in front of the expensive query, because the query is expensive. The JavaScript frontend gets split from the backend, because the two have different build steps and different release rhythms. Full-text search reaches for a Postgres extension, because the built-in tokenizer cannot segment Japanese and the alternative is shipping wrong results to a third of your users.

Every one of those is good engineering, and every one would survive review. The problem is not the decision. It is the residue. The proxy needs a volume the application also writes to, so file ownership becomes a deployment concern. Proxy headers have to match on both sides or the application sees the wrong client address. The cache needs an eviction policy nobody will revisit. The extension has to exist in the database, which rules out any centrally managed database that does not offer it, so the database becomes a deployment concern too. Two build pipelines produce two artifacts that have to be released together, so releasing becomes a coordination problem where it used to be one process starting.

Then the pattern completes itself. Proxy, cache, Postgres, both halves of the application and a process supervisor to start them in the right order all end up bundled into a single container, because a single container is the one thing that can be handed to somebody else and expected to work. A whole production stack rebuilt inside one artifact, purely to win back the property the setup began with: shipping one thing.

That last step is the one worth sitting with, because it is not a lapse of taste. It is the correct local move. Anyone who has to install this on a machine they do not administer would rather receive one artifact than six, and the person shipping it knows that. The bundle is a rational answer to the complexity produced by five earlier rational answers.

Nothing in that sequence prices the sum. Each commit optimizes the thing directly in front of it against a real constraint, and no commit is charged for what it does to the whole. No review comment reads "and this makes the deployable unit one degree harder to hand over". The stack is not really chosen. It accumulates. And because every individual step is defensible, there is no obvious moment at which to object, which is exactly why the accumulation runs unchecked. Complexity that arrives through bad decisions gets caught. Complexity that arrives through good ones does not.

What it costs depends only on which end of the range you are standing at, and the currency is the only thing that changes. For one person it is charged in evenings: the hours meant for the product go into the layer underneath it, and that layer produces nothing a user will ever see. At the other end it is charged in the payroll above, four to seven hundred thousand euros a year for a team whose entire output is that the other engineers can deploy. Same mechanism, same shape, different denomination. In neither case is the result anything anybody would have designed on purpose in one sitting.

The complaint is coming from inside

The CNCF's 2025 annual survey, published in January, puts Kubernetes in production with 82 percent of container users, and still lists tool complexity at 37 percent and the skills gap at 33 percent among the leading barriers, a decade in. Komodor's 2025 enterprise report has operations teams spending more than 60 percent of their time troubleshooting, only one incident in five resolving without escalation, and more than 64 working days a year lost to detection and resolution. Spectro Cloud's survey of 455 practitioners, fielded by an independent research firm, found cost had overtaken skills and security as the number one challenge, with 88 percent reporting total cost of ownership rising year on year.

The most interesting figure belongs to Google's DORA programme, because it measures the cure rather than the disease. Internal developer platforms (the industry's designated answer to exactly this problem) raised individual productivity by around 8 percent, and were associated with an 8 percent decrease in throughput and a 14 percent decrease in change stability. The layer built to absorb the complexity has an operating cost of its own.

The discourse has moved with it. A Hacker News thread last month on running Kubernetes cheaply on rented hardware drew 70 points and 36 comments, and the top response did not come from someone avoiding the tools. It recalculated the author's costs and concluded that ten or fifteen euros extra a month was a negligible price for not having to manage and upgrade the cluster yourself. A thread on 9 August, on an essay arguing the deployment model has broken down at hobby scale, described the assembly as a Rube Goldberg machine of cache headers, TLS termination and database extensions.

Complexity is not gratuitous

The CNCF's own position is that orchestration is hard because distributed systems are hard, and that the difficulty is earned. Joe Beda, one of Kubernetes' creators, has made the sharpest version of the point: the hand-rolled alternative carries its own complexity, one you happen to be comfortable with, which grew organically and therefore does not feel like complexity at all. He is right. "Just a VM and a script" does fail: at multi-team scale, at real availability requirements, and on the day the person who built it leaves. Managed control planes exist precisely to absorb the burden described above, and they absorb a real part of it.

The honest framing is not that the layers are wrong. It is that they have a threshold. Encore's engineering write-up puts it at roughly a platform team of two or more and enough interdependent services that consistent orchestration saves more time than it costs — somewhere in the region of fifteen to twenty. Below that line you are running a distributed-systems answer to a problem you do not have, and paying for it monthly in attention. Above it, the layers earn their keep.

The awkward part is how many organizations sit below the line and have provisioned as though they were above it.

Four questions worth asking instead

1. What share of engineering payroll maintains something no customer will ever see? Not the cloud bill. The salaries. That is the real infrastructure line item.
2. What is your measured utilization, as opposed to your requested? Requests are a guess someone made once and nobody revisited. The gap between the two is the bill.
3. How many genuinely interdependent services do you run? Under fifteen, the orchestration layer is unlikely to be paying for itself.
4. What happens at the next upgrade if the person who built it has left? Institutional knowledge is a load-bearing component that appears in no architecture diagram.

Where we sit

Every approach above starts from the same premise: the layers exist, so the work is to manage them better. Ours starts somewhere else.

That product argument also runs through European infrastructure is having a moment: European infrastructure will not win by asking developers to accept a weaker product for jurisdictional reasons. It has to be simpler and cheaper to operate.

LILY is built around a smaller deployment unit and a simpler operating surface. Instead of asking a team to assemble and maintain the usual stack around every application, the platform is designed to take source code in and return a running service with far less infrastructure work exposed to the user.

That is the product claim we are comfortable making publicly: less operational surface, fewer moving parts to own, and a deployment model aimed at putting engineering attention back on the application rather than the machinery underneath it.

Note what this does not fix. It does not make distributed systems easy, and it does not remove the need to think about failure. It removes a category of routine infrastructure ownership that many teams should not have to carry themselves.

LILY is in its Beta now! Try one workload and compare the experience against what you are running now.

Good strategists talk tactics. Great strategists talk logistics. The greatest eliminate logistics from the conversation entirely.

So the better question is not how to make that layer cheaper, or how to automate more of it away. It is what it is worth to put that attention back on the product: the evenings at one end of the range, the team at the other.

The server was always the cheap part. It is worth knowing what else has been on the invoice.

You build. We carry.

Start for free.      Read the docs.      Talk to us about migrating a workload.