Skip to main content

Hetzner's Cheap Tier Is Unavailable: What the Missing €5.99 Server Means for Fleet Planning

10 min readDora NodaDora Noda
Share
On this page

On September 7, 2026, developer Vincent Schmalbach opened Hetzner's public cloud catalog and found something no price announcement had warned him about: every single model in the Cost-Optimized tier — four x86 sizes, four Arm sizes — marked unavailable. The advertised 4 GB server still lists at €5.99 a month. But if you need to deploy a new 4 GB server today, the cheapest one you can actually order is the CPX22 at €19.99. That is 3.34 times the budget, with no new price hike to blame — just a shortage doing the price hike's job.

If you run a self-hosted fleet on Hetzner, this is the number that matters this month. Not another repricing table — the catalog price of the cheap tier hasn't moved — but the gap between the price you modeled your fleet on and the price of the capacity you can actually buy. This post pins down that gap, explains the billing mechanics around it, and gives you a concrete planning runbook: pin your machine classes to orderable SKUs, remodel against the post-hike list, and start treating availability as a monitored variable instead of a constant.

The gap, in one table​

Schmalbach's September 9 write-up did the comparison the honest way: hold memory constant at 4 GB and ask what a new deployment costs. His table, for Germany and Finland pricing including IPv4 and excluding VAT:

MemoryCheap plan (unavailable)Orderable planMultiple
4 GBCX23 at €5.99CPX22 at €19.993.34×

A few caveats keep this representative rather than flattering. The CPX22 is not the same machine at a higher price: it carries the same vCPU count but twice the storage and a newer processor generation, and Hetzner says those newer CPUs are faster. Both tiers still share CPU resources, so this is not a shared-to-dedicated jump. And the catalog overview's €11.99 entry point is a half-memory server, so paying double doesn't even buy the same RAM. The fair reading: for the same 4 GB deployment, unavailability — not a price change — tripled the bill.

The shortage also can't be routed around by switching architectures. All four CAX Arm sizes show the same unavailable label as their CX x86 siblings. And there is no cheap-tier equivalent in Hetzner's US regions at all: Ashburn and Hillsboro only sell the CPX/CCX performance lines, so US-based fleets never had a €5.99 option to lose.

Two hikes set the stage; this is the third chapter​

None of this arrived out of nowhere. Hetzner's 2026 pricing story has had two documented chapters, and the current unavailability reads as an unwritten third. (We priced the hikes against a shared workload in last week's ledger; here is the short version with the official numbers.)

Chapter one landed April 1, 2026: a broad adjustment of up to about 37% across products, hitting existing subscriptions and new orders alike. Hetzner pointed at rising DRAM and NAND costs driven by AI infrastructure demand — the same memory-market pressure still projected to keep contract DRAM prices roughly 250–300% above September 2025 levels through the end of the year.

Chapter two took effect June 15, 2026, at 8 AM CEST, and it was the big one — but only for new orders and rescales. Per Hetzner's own price-adjustment docs, dedicated-vCPU CCX instances in Germany and Finland rose 2.1× to 2.73×: the CCX13 went from €15.99 to €42.99 a month, the CCX33 from €62.49 to €138.49. Shared-AMD CPX instances rose 2.4× to 2.75×, up to 3.1× in the US: the CPX22 went from €7.99 to €19.49, the CPX11 from €5.99 to €17.49. The CX and CAX cost-optimized lines rose a gentler 30–40%.

Orders placed before June 15 kept their old prices — a slow-rolling hike that lands hardest on anyone provisioning fresh. The Hacker News thread titled "Hetzner Triples Prices" drew 175 points and 287 comments, which tells you how the new-capacity math landed.

Chapter three — September — has no announcement attached. Schmalbach found no new price communication, just cheap plans marked unavailable after those earlier hikes. His summary line is the one to remember: "If I can't order the cheap plan, the shortage acts like another price increase." For fleet planning, that reframe is exactly right. A SKU you can't order has an effective price of infinity; the price that matters is the cheapest orderable substitute.

What "unavailable" actually means for your bill​

Unavailability interacts with Hetzner's billing rules in ways worth spelling out, because the answer to "what do I pay?" depends on which kind of change you're making:

  • Existing rentals keep their terms. If your CX23 was ordered before June 15, it still bills at the old price. Grandfathered capacity is now your cheapest capacity by a wide margin — treat it accordingly.
  • New orders pay current prices. Any fresh server you create bills at the post–June 15 list, and if the tier you want is unavailable, you either wait or step up to an orderable SKU at its current price.
  • Rescales and plan changes can reprice you. Hetzner's docs warn that certain changes to servers with legacy pricing trigger a switch to current pricing. That makes "resize the box" a billing event, not just an ops event — check which operations preserve legacy terms before you click.
  • Availability flickers. Third-party trackers show CX33/43/53 sold out across Falkenstein, Nuremberg, and Helsinki with the CX23 intermittently restocking — and restocks reportedly sell through within minutes to a few hours. Polling the catalog by hand is not a provisioning strategy.
  • Capacity incidents are visible on the status page. On September 22, Hetzner posted that newly created customer accounts couldn't create cloud servers at all for roughly 17 hours. Even when your SKU shows available, the ability to actually create can blip.

The combined picture: the price/perf champion's catalog is now a menu with items crossed out, and the crossed-out items are exactly the ones fleet cost models were built on.

The fleet-planning runbook​

Here is the concrete response, in checklist form. If you run Cluster API with the Hetzner provider (CAPH), an autoscaler, or even shell scripts around hcloud, every item applies.

1. Pin machine classes to SKUs you can actually order. Audit every machine deployment, node pool, and server template for CX/CAX references and verify each one is orderable in your target locations right now — not "listed," orderable. Where a cheap-tier SKU is gone, pin the fallback explicitly (e.g., CPX22 where you had CX23) so your automation degrades to a known-good type instead of failing at 3 AM.

2. Remodel the fleet against the post-hike list. Recompute per-node and per-tenant cost on current prices for every SKU you might actually provision. The number that matters for capacity planning is the cheapest orderable node, not the cheapest listed one. If your unit economics were built on €5.99 4 GB nodes, rebuild them on €19.99 and see what survives — that 3.34× is your planning reality until availability returns.

3. Treat availability as a monitored variable. Add a probe: query the hcloud API (or your CAPH controller's view of it) for server-type availability per location on a schedule, alert when a pinned SKU goes unavailable, and feed that signal into provisioning decisions. Community trackers exist, but your automation should consult the API, not a screenshot. Availability is now an input to your cost model with the same standing as price.

4. Make provisioning capacity-aware. Build retry-with-fallback into whatever creates servers: if the preferred type/location errors as unavailable, fall back to the next pinned SKU or location instead of looping. This pattern already exists in the wild — the Karpenter provider for Hetzner skips type/location combinations Hetzner reports as unavailable so scheduling falls back instead of retrying a sold-out pairing, and self-hosted GitHub-runner automation on Hetzner Cloud documents hour-long create-retry windows against exactly this failure mode. Copy the pattern; don't rediscover it during an outage.

5. Protect grandfathered capacity. Since existing rentals keep old terms, deletions and recreations now have a price tag: every rebuilt CX node comes back (if at all) at current prices. Gate destructive operations on cheap-tier nodes behind a check, prefer in-place upgrades where they preserve legacy billing, and confirm which operations trigger a reprice before rolling a pool.

6. Decide the re-shop threshold in advance. Pick the multiple at which you stop waiting for restock and evaluate alternatives — for new capacity, not for the grandfathered nodes you already hold. Having the threshold written down before you're paged is the difference between a plan and a panic.

Stay or re-shop? A decision rule​

The honest answer is split by vintage. For capacity you already hold on legacy pricing, staying is obviously right: nothing in the market touches a grandfathered €5.99-class node, and churning it destroys value you can't recreate. Baby those servers.

For new capacity, the comparison set has to be rebuilt at CPX prices, because that's the orderable floor. Independent comparisons published since June make the point sharply: Contabo's entry dedicated-core VDS at around €34 for 3 physical cores and 24 GB of RAM now sits below Hetzner's CCX13 at €42.99 for 2 cores and 8 GB, and Netcup's dedicated-core RS 1000 line at roughly €10.74 is cited against the same CCX13 at four times the price. Those are dedicated-core comparisons against Hetzner's repriced top tier — read them as evidence that the value crown is contestable now, not as buy recommendations. Your re-shop inputs are your actual workload shape, your region needs (EU-only cheap tiers vs. US presence), and whether an alternative's availability is any better than what you're fleeing.

One more consideration for the stay column: Hetzner is still Hetzner on traffic (generous included transfer), API quality, and the CAPH ecosystem around it. If your fleet is automated against hcloud and your per-tenant margins absorb CPX-level node costs, continuity has real value. Re-shop when the orderable-floor math breaks your margins, not when the headline annoys you.

The shortage is the price increase​

Step back and the pattern is simple. April repriced everything. June repriced new capacity. September made the cheapest capacity unorderable — which, as Schmalbach put it, acts like another price increase without anyone announcing one. The through-line for operators is that the variable you must track on the price/perf champ is no longer just price. It's the pair of price and orderability, and your machine classes, cost models, and provisioning retries should all take both as inputs.

If you do one thing this week, do item one of the runbook: check that every SKU your automation can request is a SKU Hetzner will actually sell you today. The €5.99 server is still in the catalog. It just isn't for sale.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex