Hetzner June 2026 price rise: How to keep costs low

15 June is the fourth time Hetzner has changed prices since February: setup-fee rises in February, a monthly price rise on 1 April, dedicated setup fees again on 29 April, and now a new pricing structure. This change is different: it does not affect any server you already have, unlike the 1 April rise.

Hetzner announced this on 27 May, but gave no price list. This article was published before the change and updated on 18 June with the official prices. Hetzner said there would be two types of increase, and that is what occurred: the cheaper shared-vCPU plans went up by about 33%, while the high-performance and dedicated-vCPU plans more than doubled. You could already decide what to do from the pricing rules; the published numbers only give the exact amounts.

What changed price on 15 June

The change follows three rules, all from one sentence in Hetzner's announcement: "the changes apply exclusively to new orders and rescales of existing servers."

• A server created before 15 June keeps its current monthly price as long as you do not change its plan. Note: 'Current price' means the price from 1 April, because the 1 April rise did apply to existing servers.
• Any server ordered on or after 15 June uses the new price.
• Any rescale (a change to a server's size, up or down) moves the server to the new price. Hetzner treats scaling up the same as scaling down.

Some services are not affected: Volumes, Snapshots, Load Balancers, Object Storage, IPs, Server Auction, web hosting, and managed servers. Their prices did not drop on 15 June (they rose on 1 April), and the 15 June change does not touch them.

Cheaper plans rose slightly, expensive plans doubled

The cheaper shared-vCPU plans rose only a little. The high-performance and dedicated-vCPU plans roughly doubled, and a few almost tripled. The table below shows Hetzner's official prices for Germany and Finland, per month, without VAT. The 'Locked price' is what existing servers pay (the 1 April price). The 'New price' is what new orders or size changes pay.

Plan	Locked price (before 15 June)	New price (from 15 June)	Change
CX23 (shared vCPU)	€3.99	€5.49	+38%
CAX11 (shared Arm)	€4.49	€5.99	+33%
CPX32 (high-perf)	€13.99	€35.49	+154%
CPX52 (high-perf)	€36.49	€100.49	+175%
CCX23 (dedicated-vCPU cloud)	€31.49	€85.99	+173%
CCX33 (dedicated-vCPU cloud)	€62.49	€138.49	+122%
CCX63 (dedicated-vCPU cloud)	€374.49	€853.49	+128%

The difference between the locked price and the new price is important. For CX or CAX servers, keeping the locked price saves only €1-2 per month. For CPX or CCX servers it saves more than the old price of the server, so all the advice below depends on whether you keep the locked price.

The table shows Hetzner Cloud servers only. Hetzner also sells bare-metal dedicated servers (the AX series, ordered through Robot), which are a separate product and changed in a different way. A later section covers what happened to them.

Usually keep the locked price, but one case is different

Now that the new prices are known, keeping the locked price is best for almost all CPX and CCX servers because the new price is more than double. However, there is one rare exception worth checking. Keep your locked price only if a smaller server at the new price would still cost more than what you pay now. If your server is much larger than you need (over-provisioned), keeping the locked price means you continue paying too much.

Here is the situation where switching saves money: You have a CCX33 server created before April, locked at €62.49/month (this was increased from €47.99 on 1 April). If your metrics for 30 days show it using only 12% CPU with no memory issues, a CPX32 server would be enough. At the new price, a CPX32 costs €35.49/month. In both cases, you would pay the new price. Moving from CCX to CPX is a change of server type, so it needs rebuilding, not just resizing. Usually you need to rebuild anyway because resizing cannot make the disk smaller. Also, even when resizing is possible, Hetzner uses the new price.

Keeping the CCX33 to 'keep the locked price' means paying €62.49 when €35.49 would be enough. In this case, keeping the locked price is not worth it. However, the savings are much smaller than in May when the same CPX32 cost only €13.99. With the June prices, keeping the locked price is usually the cheaper option. The decision is simple:

Your locked price	Right-sized server at new price	Decision
€62.49 (CCX33, oversize at 12% CPU)	€35.49 (CPX32)	Switch. The locked price kept the bill too high.
€15.99 (CCX13, already right-sized)	€42.99 (same CCX13, new price)	Keep. The new price is 2.7 times the locked price.

Your usage data tells you which right-sized server you need, and therefore which row in the table applies to you. If you check each server's CPU, memory, and network usage over 30 days, you can make the keep-or-switch decision by comparing two numbers instead of guessing.

Automation can accidentally lose the locked price

The most costly mistake a DevOps team can make now is to delete and recreate a server with a locked price without realising it. When you recreate a server, Hetzner treats it as a new order and charges the new price, even if your Terraform file is unchanged.

This can happen by accident. Common actions that delete the old server and create a new one are:

• changing a setting that forces a new server in your hcloud_server resource (such as the image, location, or sometimes the server type if it would shrink the disk),
• running the command terraform apply -replace,
• or any process that creates a new server image and replaces all servers.

Terraform shows forces replacement in red in the plan output; it is easy to miss, and the locked price is lost.

The best protection is Hetzner's own delete-and-rebuild lock. You can turn on delete and rebuild protection for any Cloud server. Once enabled, the API will not delete the server, so a terraform apply -replace fails with an error instead of silently recreating the server at the new price. In the Cloud Console, protected servers show a padlock icon; hovering shows 'Protection active'. In Terraform, use delete_protection = true and rebuild_protection = true on the hcloud_server resource. Or use the command hcloud server enable-protection <name> delete rebuild. Turn this on for every server you created before 15 June.

Two more precautions help here. First, if you must change a server's type, move to the same size or larger. Terraform applies that as an in-place update, which Hetzner carries out as a rescale, so the server keeps its disk and data. A smaller type, or a changed image or location, instead forces a replacement: Terraform destroys the server and creates a new one. The in-place update still moves you to the new price, but it spares you the worse outcome of an accidental replacement that also wipes the server. Second, always check the terraform plan output for forces replacement before you apply. Only the protection flag actually blocks a replacement; the rest depends on you noticing in time.

Adding servers keeps locked prices; resizing does not

Increasing a server's size (vertical scaling) changes its price to the new rate. Adding more servers (horizontal scaling) does not affect existing ones.

If you resize a CCX23 to a CCX33, that server immediately uses the new CCX33 price (€138.49). A CCX23 locked at €31.49 would cost €138.49 after resizing. In May, a CCX33 cost only €62.49. Instead, if you add a second CCX23 server, the first one keeps its locked price, and only the new server uses the new price. For workloads that can scale horizontally (like web servers, API workers, queue workers, or database replicas), adding more servers keeps your existing servers at the locked price. Your average cost then goes up gradually as you grow, instead of jumping to the new price all at once.

The downside is that more servers mean more management. Also, the new servers still use the new price. However, your existing servers keep their locked price, which is valuable after the 15 June change.

Keep main servers locked; use temporary ones for extra capacity

Divide your servers into two groups: stable servers and temporary servers. Treat them differently.

Stable servers: These are servers that run all the time: databases, web servers, message brokers, and monitoring. Adjust their size now based on real usage. Add extra capacity for 3-6 months of growth (more than usual, because making them larger later will move them to the new price). Then do not change them. These are the servers you most want to keep at the locked price.

Temporary servers: These are servers that are created and deleted often: CI/CD runners, preview environments, batch jobs, load tests, and scheduled tasks. These servers always use the new price because they are new each time. You do not need to protect them, but you should run them as cheaply as possible. Use a container system such as Kubernetes or Nomad to pack them efficiently. Use autoscaling to start them when needed and stop them when idle. Run temporary workloads on temporary servers so you never need to resize your stable servers.

Most teams use this approach now that the new prices are active. Community discussions since 15 June give the same advice: keep your production servers at their current size, use the new price only for temporary workloads, and add a second small server instead of resizing a large one.

Heavy CI workloads can cost less with a permanent runner

CI runners look like classic temporary servers, so the split above would put them on new-priced, disposable capacity. For heavy, steady CI that can be the wrong call. Cloud servers are billed by the hour, so the more CI runner-hours you use, the more the price rise costs. If your team uses thousands of CI runner-hours each month, you pay the new price for each hour.

A single permanent runner created before 15 June has a locked price and costs a fixed amount per month, regardless of how much it works. The difference grew much larger on 15 June: temporary CPX and CCX runners now cost more than double, while a locked permanent runner still costs its April price. For heavy, continuous CI workloads, one well-sized permanent runner at the locked price can be cheaper than many temporary instances at the new price. Using only temporary runners is still a good default approach, but it is no longer always the cheapest. Compare the costs based on your actual usage.

Cheaper bare-metal servers are now in the Limited range

This section is about bare-metal dedicated servers (AX series, ordered in Robot), not the CCX cloud servers described above. These did not receive a simple percentage rise. Hetzner now offers each model in up to three fixed configurations (-1, -2, -3). In most cases, these standard configurations have better hardware than the models they replace. For example, the standard AX42-1 now costs €187.30 per month and has more hardware (64 GB DDR5 RAM, two 1.92 TB NVMe drives). The old AX42 was a smaller machine that cost about €57. Looking only at the price, this seems like a tripling, but the standard AX42-1 is actually a more powerful machine.

The cheaper configurations with older hardware moved to a new 'Limited' line, marked as -1-Ltd. These use less expensive hardware that Hetzner buys in limited amounts and are sold only while supplies last. This is where you find the lower entry prices:

Model	Standard price	Limited price (-1-Ltd)
AX41	Limited only	€57.30/mo, €0 setup
AX42	€187.30/mo, €94 setup	€77.30/mo, €39 setup
AX102	€452.30/mo, €224 setup	€157.30/mo, €39 setup
AX162	€612.30/mo, €304 setup	€317.30/mo, €39 setup

Therefore, the cheapest way to order a bare-metal server has changed. If you want an AX42 at the old low price, choose AX42-1-LTD at €77.30 instead of the standard AX42-1 at €187.30. The cheapest AX server overall, the AX41, is only available in the Limited line at €57.30 per month with no setup fee. The limitation is availability: the Limited line is only offered when Hetzner has the cheaper hardware in stock. So check availability when you order, instead of assuming it will always be there.

Server Auction is another low-cost choice that Hetzner recommends

Server Auction prices rose only 3% on 1 April and are not affected by the 15 June change. On its price-adjustment page, Hetzner now points customers to the auction, recommending it 'for some great deals on older server models.' For non-critical or temporary bare-metal workloads that can use older hardware and whatever configuration is available, the auction and the Limited line are the two places where you can still find good value. Auction servers also have no setup fee, which makes them cheaper to start than a new standard order.

Actions that will save you money

You could no longer order at the old prices after 15 June. However, the locked prices you already have are valuable, so focus on protecting them:

1. Lock your pre-15-June servers in your infrastructure code so they cannot be accidentally recreated at the new price. This is the most important action because one accidental recreation changes the price permanently.
2. Adjust the size of your stable servers based on 30 days of usage data. Add a buffer for 3-6 months of growth, then do not change them. Use a larger buffer than usual because increasing their size later will move them to the new price.
3. Check your most over-provisioned locked servers using the keep-or-switch table above. With these high new prices, you should usually keep them. Look for the rare case where switching saves money.
4. Delete unused and forgotten resources. Our resource audit guide lists the hcloud commands. A locked price on an idle server is wasted money.
5. For new bare-metal servers, check prices for the Limited (-1-Ltd) line and Server Auction before the standard configurations (-1, -2, -3). Both still give good value.

Prepare for future price rises; old prices will not return

Four price changes in four and a half months will not be the last. The DRAM shortage that caused the April rise is expected to continue until 2028. Hardware costs also fall much more slowly than they rise. So expect more price increases, and do not expect prices to return to previous levels. The next increase will likely be similar to 15 June: existing servers keep their price, but new orders and size changes use the new price, with the largest increases on high-performance servers. The real question is: can your infrastructure handle the next price increase without urgent changes? This means having stable servers that do not need resizing, and temporary servers that are cheap to replace because they were always designed to be disposable.