Hetzner's June 2026 price increase: how to scale around it

June 15 is Hetzner's fourth pricing action since February: setup fees in February, a portfolio-wide monthly increase on April 1, dedicated setup fees again on April 29, and now a standardization with another rate change. This one is different. Unlike April 1, it does not change the price of any existing server.

The short version. Existing servers keep their current rate. Only new orders and rescaled servers get the new price. So protect your stable servers, stop your automation from rebuilding them by accident, and put variable load on new-priced throwaway capacity, where the new rate applies anyway.

The change reprices only two things: new orders and rescales. Hetzner announced it on May 27 without price tables, promising the numbers "during the rollout." So you cannot calculate the exact euro impact yet. But you can plan around the structure, and the structure is where the decisions are.

The useful framing is not "prices went up." Hetzner repriced the act of scaling and rebuilding servers, not the servers themselves. The answer is not to stop scaling, and almost nobody does anyway. The answer is to change how you scale. Keep the stable baseline on today's rates. Put growth and variable load on capacity that is billed at the new rate anyway. And stop your automation from rebuilding a locked-in server at the new price.

What June 15 actually reprices

The mechanics reduce to three rules, and all three follow from one sentence in the announcement: "the changes apply exclusively to new orders and rescales of existing servers."

• A server provisioned before June 15 keeps its current monthly price for as long as you leave its plan alone. "Current" already means the April 1 rate, because that increase did hit existing servers.
• Any server ordered on or after June 15 is billed at the new rate.
• Any rescale, in either direction, moves that server onto the new rate. Hetzner makes no distinction between scaling up and scaling down.

Several resources sit outside this change entirely: Volumes, Snapshots, Load Balancers, Object Storage, IPs, Server Auction inventory, web hosting, and managed servers. They are not getting cheaper, they were already repriced on April 1, but the June 15 standardization leaves them alone.

For dedicated servers there is a genuine sweetener. Hetzner is reducing one-time setup fees "significantly for most dedicated servers," and folding that cost into a higher monthly rate instead. It is also collapsing per-server RAM and storage options into up to three fixed configurations per type, plus a cheaper "Limited" line. That trade between setup fee and monthly rate becomes a timing decision, which is the second half of this post.

The costly move is the rescale, not the server

Here is what the common advice, "protect your locked-in rates," gets wrong. A locked-in rate is only worth keeping if the smaller server you would move to, at the new rate, still costs more than you pay now. For an over-provisioned server it is the opposite: the lock is protecting a bill that is already too high.

Work through a real example. A dedicated-vCPU CCX33 you provisioned before April now sits at its protected rate of €62.49 per month (up from €47.99 before April 1). Say 30 days of metrics show it averaging 12% CPU with no memory pressure: a CPX32-class server would handle that load. A CPX32 costs €13.99 per month. Getting there lands on the new rate either way. You can rescale, and Hetzner charges the new tariff on any rescale. Or you rebuild on the smaller type, which you often have to do anyway, because a rescale cannot shrink the disk.

Keeping the CCX33 to "protect the locked-in price" means paying €62.49 for €13.99 of real work. The locked price is no longer worth keeping. The decision is a single comparison:

Your locked rate (G)	Right-sized server, new rate (N)	Decision
€62.49 (CCX33, oversize)	€13.99 (CPX32)	Switch. The lock was inflating the bill.
€15.99 (CCX13, right-sized)	higher than €15.99	Keep. The lock beats a fresh server.

Utilisation data tells you which N you would land on, and so which row you are in. Per-server CPU, memory, and network over 30 days turn the keep-or-switch choice into a comparison of two numbers instead of a guess.

Your automation can lose a locked rate by accident

The single most expensive thing a DevOps team can do in the next few weeks is destroy and recreate a locked-in server without noticing. A rebuilt server is a new order, billed at the new rate, even if the Terraform looks identical to last month's.

This is easy to trigger by accident. Several everyday actions destroy the old instance and create a new one:

• changing a force-new attribute on an hcloud_server resource (the image, the location, sometimes the server type when the disk would shrink),
• running terraform apply -replace,
• or any "bake a fresh image and roll the fleet" pipeline.

The plan output says forces replacement in small grey text, and the lock-in is gone.

The reliable defense is Hetzner's own protection flag. Every Cloud server can have delete and rebuild protection enabled. Once it is on, the API refuses to destroy the server, so a stray terraform apply -replace fails loudly instead of quietly rebuilding at the new rate. In the Cloud Console, a protected server shows a lock icon with a "Protection active" tooltip. In Terraform it is delete_protection = true and rebuild_protection = true on the hcloud_server resource, or hcloud server enable-protection <name> delete rebuild from the CLI. Turn it on for every server you provisioned before June 15.

Two habits back that up. Prefer in-place updates where Hetzner allows them: a same-or-larger server-type change is a rescale, not a replace, and a rescale at least keeps the server, even at the new rate. And read terraform plan for forces replacement before applying. But only protection physically stops the rebuild, instead of trusting you to spot it.

Scale out, not up, to keep your locked rates

Vertical scaling reprices the server you touch. Horizontal scaling does not touch it at all.

Rescaling a CCX23 up to a CCX33 moves that one server onto the new rate. Adding a second CCX23 next to it leaves the original locked in and prices only the new node at the new rate. For any tier that scales horizontally (stateless web and API workers, queue consumers, read replicas), adding nodes keeps the locked-in rate on everything you already run. Your blended rate then rises slowly as you grow, instead of resetting in one jump.

The trade-off is real and worth stating: more nodes mean more orchestration, and the new nodes are still new-priced. But the existing fleet stays locked, which is exactly the asset the June 15 change makes valuable.

Lock the baseline, make the variable part disposable

Split your fleet into two groups: stable servers and temporary servers. Manage them differently.

Stable servers. The stable baseline is everything that runs continuously: databases, the standing web tier, brokers, monitoring. Right-size it now against real utilisation, add a deliberate growth buffer of three to six months (larger than usual, because scaling it up later moves it to the new rate), then leave it alone. That fleet is your protected asset.

Temporary servers. The variable part is everything that comes and goes: CI/CD runners, preview environments, batch jobs, load tests, cron-driven bursts. This capacity is new-priced no matter what, because it is created fresh every time, so there is nothing to protect and every reason to optimize it. Pack it densely with a container orchestrator (Kubernetes or Nomad), autoscale aggressively, and shut it down as soon as it is idle. Temporary spikes should use temporary capacity, not force you to resize long-running servers.

Two timing plays before the prices publish

The setup-fee change and an overlooked exemption both reward acting before June 15.

Order long-lived dedicated servers before June 15

Dedicated monthly rates rise on June 15 while setup fees fall. For a server you will run for years, ordering now locks the lower monthly rate; you pay the higher setup fee once and save the monthly difference every month after. For a server you will keep only briefly, a migration staging box or a one-off batch cruncher, the post-June-15 low setup fee can win despite the higher monthly.

The breakeven is just setup-fee saving divided by monthly increase. If waiting saves €60 in setup but adds €10 per month, the breakeven is six months: keep it shorter and wait, keep it longer and order now. Cloud servers have no setup fee, so for cloud the rule is simply "order anything long-lived before June 15." You cannot fill in the exact figures until Hetzner publishes them, but you can decide the rule now and act the day the numbers land.

The setup-fee cut is a correction, not a gift. The late-April increase pushed one-time fees on newer dedicated hardware to roughly four times the monthly rate. The AX-line matrix shows it plainly: the AX102-U, a current 16-core Ryzen 9 7950X3D with 128 GB of RAM, has a €500 setup fee against €119 per month (excluding VAT). The AX42-U and AX162-R sit at similar multiples; only the older AX41-NVMe stays near one month. At that level you prepay several months of rent before the server does any work. That makes short-term and experimental dedicated servers uneconomic, and sends that business to providers without the high upfront fee. June 15 reverses it, which is why waiting is usually better for short-lived servers.

Server Auction quietly became the cheaper pool

Server Auction inventory took only a 3% increase on April 1 and is on the excluded list for June 15. As the standardized dedicated line gets more expensive, the auction pool stays cheap by comparison. For non-critical or variable dedicated workloads that tolerate older hardware and whatever configuration is in stock, it is now the cheaper option, and the gap keeps growing. Auction servers also have no setup fee at all, exactly the cost that has just made new dedicated orders so expensive to start.

Heavy CI rewards the opposite of ephemeral

Cloud servers bill by the hour, so the new rate scales with runner-hours, not server count. A team burning thousands of CI runner-hours a month pays the increase on every one of them.

A single persistent runner provisioned before June 15 is on a protected rate and bills a flat monthly rate no matter how hard it works. For heavy, steady CI pipelines, one well-sized standing runner locked in at today's rate can cost less than fleets of fresh, new-priced ephemeral instances. The "always ephemeral" default is a sensible one, but it is no longer automatically the cheapest, and this is worth measuring against your actual runner-hour volume.

What to lock in before June 15

The window rewards a few deliberate actions rather than a panic:

1. Right-size the stable baseline against 30 days of utilisation, with a three-to-six-month buffer, then freeze it.
2. Pin or guard pre-June-15 servers in your IaC so a stray forces replacement cannot rebuild them at the new rate.
3. Order any long-lived dedicated or cloud capacity you already know you need, to lock the current monthly rate.
4. Delete idle and orphaned resources now. The resource audit guide lists the hcloud commands; a locked-in rate on an idle server is just locked-in waste.
5. Decide the dedicated setup-fee breakeven rule so you can act the day prices publish.

Plan for the next increase, not a rollback

Four pricing actions in four and a half months is not a one-off. The DRAM shortage behind the April increase is expected to last into 2028, and hardware costs fall much more slowly than they rise. So the realistic assumption is more increases ahead, not a return to old prices. Each one is likely to look like this June: existing servers left alone, new orders and rescales repriced. The real question is not how to react to June 15. It is whether your infrastructure can handle the next increase without urgent changes. That means a baseline that can sit still, and a variable tier that is cheap to rebuild, because it was always meant to be thrown away.