Hetzner's New -Ltd Tier: What Lower-Cost Hardware Really Trades Away

Hetzner did not just raise prices on June 15, 2026. It rebuilt the catalog, erased custom RAM and storage, and quietly added a cheaper tier built from whatever it could source cheaply. If you run a self-hosted PaaS on Hetzner, the question is not whether that tier saves money. It is whether you should let your node pool default to it.

The cheapest Hetzner server is now the one Hetzner is least specific about​

On May 27, Hetzner announced a portfolio standardization effective June 15, 2026, at 08:00 CEST. The headline was a price increase — the third or fourth pricing action of the year, depending on how you count. The product change underneath mattered more.

Every dedicated server model now carries a fixed suffix: -1, -2, or -3. Custom RAM and storage configurations are gone. You pick a type, not a bill of materials. Alongside those standardized types, Hetzner introduced -1-Ltd — "Limited" servers in limited quantities, built, in Hetzner's own words, from "hardware components that we source at a lower price" with "particularly attractive conditions when we are able to source hardware components at a lower cost."

That sentence is the whole story. The standard tiers are supposed to be predictable hardware behind a known SKU. The Ltd tier is explicitly opportunistic sourcing made into a SKU. It is cheaper because the components were cheaper to buy, not because Hetzner found a more efficient way to build the same machine. For a single server you rent once, that is a deal. For a fleet you provision through Cluster API Provider Hetzner (CAPH) and expect to behave identically for months, it is a different promise entirely.

Before deciding where the Ltd tier belongs in your platform, it helps to see why it exists at all.

Four price actions in ten weeks — how we got to a discount tier​

The segmentation is a direct response to a hardware market that made the old pricing unsustainable. Here is the compressed timeline:

Two things stand out.

First, the June increase was not a uniform bump. It was a re-tiering by architecture. The shared Intel CX line and ARM CAX line — Hetzner's cheapest general-purpose and best price-performance lines — rose about 30-38%. The dedicated-vCPU CCX line and AMD shared-vCPU CPX line, where a PaaS actually sizes production node pools, roughly doubled or tripled. One community price index tracked CCX up 110-175% and CPX up similarly; Hetzner's own docs confirm the same shape. If your fleet ran on CX, you felt a hike. If it ran on CCX/CPX, you felt a repricing.

Second, the policy flipped between April and June. April hit everyone, including running servers. June applies only to new orders and rescales; currently rented servers are not affected, and the one-time setup fee was cut to soften the landing. That matters for an operator: the bill for what you already run is stable, but every future scale-up, replacement, or new region pays the new price — or the Ltd price, if you choose it.

The root cause is procurement costs for DRAM, SSD, and server-grade components. AI infrastructure has redirected fab capacity toward high-bandwidth memory (HBM): one HBM wafer consumes roughly three times the capacity of a standard DDR5 wafer — the "1:3 capacity penalty." Samsung, SK hynix, and Micron have shifted output toward HBM, leaving conventional server DRAM structurally short. Contract DRAM prices rose 43-48% in Q4 2025, with another 58-63% projected in Q2 2026. Hetzner is passing through a bill-of-materials shock, not inventing a margin story.

That is why a cheaper-sourced Ltd tier appeared now. When standard hardware costs 2x what it did a year ago, the only way to hold a lower price point is to build a distinct box from cheaper parts alongside it.

What -1 / -2 / -3 and -1-Ltd actually mean​

Under the old catalog, you could tune a dedicated server's RAM and storage within a family. Under the June catalog, you cannot. Each physical platform now ships in a fixed -1, -2, or -3 configuration — think of it as small/medium/large within a chassis, with CPU, RAM, and disk nailed down per suffix. The upside is comparability: a AX102-1 means the same thing every time. The downside is you lost the knob you used to right-size a database node or a cache node without switching chassis.

The -1-Ltd type sits beside -1, not above or below it. It is the same class of machine, same nominal position in the lineup, but assembled from components Hetzner could source at a lower cost in that procurement window. Hetzner's pressroom language is careful: "hardware components that we source at a lower price" and "when we are able to source hardware components at a lower cost." That is not "binned but equivalent." That is "the motherboard, DIMM vendor, SSD model, or NIC may differ because the cheaper lot was available." The SKU tells you the price is attractive. It does not tell you which compromise made it attractive, or whether the next -1-Ltd batch makes the same compromise as the last.

Three concrete implications follow:

1. Component consistency across a node pool disappears. A CAPH MachineDeployment that requests type: ax102-1-ltd may receive subtly different hardware as Hetzner rotates Ltd lots. One batch might carry a different NVMe model with different sustained-write behavior; another might use a different memory vendor. None of this violates the contract — Limited means Limited. But a stateful workload that assumes uniform disk latency or uniform memory bandwidth across its pool now needs to either not assume it or not use Ltd for that pool.

2. Supply is capped and non-uniform. Ltd is "in limited quantities" by definition. That means an autoscaler that assumes it can add 10 more -1-Ltd nodes on demand may hit "no capacity" faster than it would with the standard type. Hetzner already showed capacity-constrained provisioning as a distinct failure mode in 2026, with status notices of limited availability on cloud lines due to component shortages. Ltd is the most likely type to be the first to show "sold out."

3. Longevity and replacement behavior is less predictable. When a -1-Ltd machine fails and CAPH replaces it, the replacement may not be the same sub-variant. Your monitoring may see a different device model; your tuning for the previous disk's queue depth may be slightly wrong for the new one. For stateless app replicas, this rarely matters. For databases, search nodes, or anything that benchmarks hardware before declaring itself healthy, it can.

None of this makes Ltd bad hardware. It makes Ltd the wrong place to hide variance. The standard -1/-2/-3 types cost more precisely because Hetzner commits to a known hardware recipe for them. Ltd costs less because Hetzner explicitly reserves the right to vary it.

What the savings actually look like — and what they do not offset​

Hetzner publishes the June prices per type and location. The exact delta between -1 and -1-Ltd moves with the lot, but the order of magnitude is consistent: Ltd sits noticeably below the standard -1 for the same chassis while still above April's pre-hike baseline. For cloud instances, the contrast is starker in percentage terms because the June repricing was so steep on CCX/CPX:

The setup-fee cut deserves its own line because it changes the amortization, not just the sticker. Most dedicated models saw one-time fees drop from triple-digit euros to low double digits or zero. For a server you keep for 12 months, a €100 setup fee amortizes as ~€8/month. Cutting it to €20 saves ~€6.60/month effective. That offsets a meaningful chunk of the monthly increase in year one, but zero of it in year two. Do not let a lower setup fee persuade you that the monthly run rate did not move.

The Ltd discount, similarly, offsets the monthly run rate but not the variance cost. If you run a fleet of 20 app nodes, saving €8-15 per node per month on Ltd is €160-300/month — real money for a small platform team. But if that fleet needs uniform performance for tail-latency SLAs, or you have ever had to explain to a tenant why two replicas of their service bench differently on two supposedly identical nodes, the discount is buying you a debugging story you did not have before.

Why a PaaS cannot just default its node pool to Ltd​

A platform that provisions nodes through CAPH declares a desired state — "this MachineDeployment should have 6 replicas of this type" — and lets the provider reconcile it. That assumes the type means one thing. Ltd, by design, means "one of several cheaper things, depending on when you ordered."

Four consequences follow:

Predictability is the product. Teams choose self-hosting to escape meter variance. Defaulting to Ltd trades meter variance for hardware variance. Two replicas of the same service may bench differently on two "identical" Ltd nodes. The pitch — "own known hardware, know your bill" — weakens when the hardware is whatever was cheapest that week.

Failure domains get blurry. "Your service runs on AX102-1, two NVMe in RAID1, from this generation" needs an asterisk with Ltd. For most tenants that is fine. For sovereignty or compliance-sensitive tenants, the asterisk is paperwork.

Fallback is mandatory anyway. Ltd is sold in limited quantities. Your CAPH config needs a fallback to standard -1 or another location/type, because Ltd can be out of stock. With a fallback, you have a mixed fleet with mixed performance — the operational cost that uniform pricing was supposed to avoid.

Grandfathering hides the variance. Existing servers keep old prices and hardware. A team that defaults to Ltd will not notice the variance until a node fails months later and the replacement Ltd node is subtly different from the five it joined.

Ltd is not unusable. It should be an opt-in, not a default.

A responsible way to use Ltd in a Cluster API fleet​

If you want the savings without inheriting the variance as your platform's default promise, treat Ltd as a distinct capacity class with explicit policy:

Pin defaults to standard, allow Ltd per workload. Keep the platform's default MachineDeployment on the standard -1/-2/-3 types. Expose Ltd as a workload-level opt-in — a label or scheduling hint such as hardware-class: limited that a tenant or deploy config chooses when cost matters more than uniformity. Stateless preview environments, batch workers, CI runners, and internal tooling are ideal Ltd candidates. Production databases and latency-sensitive primaries are not.

Declare heterogeneity instead of assuming uniformity. If you do run a mixed pool, stop bin-packing as if every node is identical. Use node.kubernetes.io/instance-type and custom labels to schedule stateful sets only onto standard nodes, and spread stateless replicas across both classes. A simple nodeSelector or affinity rule is cheaper than a post-incident explanation about why the new pod landed on the cheaper disk.

Hold headroom and test fallback. Because Ltd is sold in limited quantities, size your autoscaler headroom against the standard type, not the Ltd type. Run a periodic "what if Ltd is sold out" drill: cordon the Ltd nodes, let the standard type take the load, and verify your SLO holds. Hetzner's own H1 2026 capacity notices — "limited availability" on specific cloud lines due to hardware shortages — are a preview of how this fails. Not with an error, but with a scale-up that simply waits longer than your HPA timeout.

Document what you do not guarantee. If you offer Ltd, say what varies. "Limited nodes use hardware sourced at lower procurement cost; disk model and memory vendor may differ between batches and are not part of the type's compatibility guarantee" is a more honest line in your platform docs than pretending -1-Ltd is just -1 but cheaper. Tenants who care will self-select correctly; tenants who do not care get the savings they wanted.

Measure the real delta before promising it. Track p95/p99 tail latency, sustained disk throughput, and memory bandwidth per hardware class, not just per "type family." The moment Ltd shows a measurable tail difference for your workload, you have the number you need to justify keeping production on standard. If it shows no difference, you have the evidence to expand Ltd usage with confidence. Either way, you are deciding from data, not from the price tag.

Owned hardware is still cheaper — if you stay honest about which hardware​

Self-hosting on owned Hetzner hardware is still structurally cheaper than metered hosted PaaS for always-on workloads — even after CCX and CPX roughly doubled. Hosted alternatives meter every GB of RAM, every vCPU-hour, and increasingly every snapshot, NAT gateway, and inter-region byte. The Hetzner bill, even post-hike, is flat monthly with 20 TB included. That shape still wins for steady-state services.

What changed is that "Hetzner is cheap" stopped being a single number. After June 15, it is four numbers: CX/CAX on one curve, CCX/CPX on a steeper one, dedicated -1/-2/-3 on a third, and -1-Ltd as the deliberately cheaper, less specified fourth. Treating Ltd as a drop-in for standard spends the savings on complexity. Treating it as a distinct capacity class — cheaper, limited, less consistent between batches — lets you offer both a predictable default and a cheaper option where it fits.

The hardware market behind this is not easing soon. DRAM makers keep allocating more wafer capacity to HBM, which consumes about 3x the capacity of standard DDR5 per unit of output. Contract DRAM prices that jumped ~45% in a single quarter are expected to keep climbing into 2027. In that world, a platform that says "we own the machines" must be specific about which machines — because the cheapest machine on the price list is now also the least specific.

That specificity is not overhead. It is the product.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Standard or Ltd, the fleet is yours to declare; Cluster API provisions it, you choose the promise. Star the repo on GitHub or deploy your first app today.