Hetzner Price Increase 2026: What Changed and How to Move Your Servers

The Hetzner price increase of 2026 came in two rounds. On 1 April 2026 cloud server prices rose 30% to 37%, for running servers and new orders alike. On 15 June 2026 a second round hit new orders and rescales only: in Germany and Finland the shared AMD line (CPX) rose 144% to 175% and the dedicated vCPU line (CCX) 113% to 173%, while the cheaper CX and CAX lines rose 30% to 38%. A server you never resize keeps its pre-June price. New capacity is the harder part: on 12 October 2026 Hetzner's cloud page showed its Cost-Optimized plans as "Currently not available". Below are the official numbers, a worksheet for deciding whether to move, and a migration runbook we tested, in which the final switch froze writes for 24 seconds.

Key facts, checked on 12 October 2026:

• Hetzner's statement of 23 February 2026 says the April prices apply "for both new orders and existing products".
• Hetzner's price adjustment page says the June prices "took effect for new orders and cloud instance rescales" at 8 AM CEST on 15 June. A CPX22 went from €7.99 to €19.49 a month; in the USA a CPX41 went from €38.99 to €120.49 (+209%).
• The press release of 27 May 2026 says "currently rented servers are not affected". IPs, Volumes, Snapshots, Load Balancers and Object Storage were left out of the June round.
• The Hetzner status page has shown "Limited availability of cloud instances" since 26 June 2026, restricting new cloud servers for new customers and for some existing customers chosen at random.
• Hetzner cloud servers in the EU include at least 20 TB of traffic a month, against 1 TB in the USA and 0.5 TB in Singapore (plan page). IPv6 is free and a Primary IPv4 costs €0.50 a month (IP pricing page).

What Hetzner changed in 2026, plan by plan

Hetzner Cloud has three lines. Cost-Optimized (CX on Intel or AMD, CAX on Arm) and Regular Performance (CPX on AMD) use shared vCPUs: the physical cores are shared with other customers. General Purpose (CCX) has dedicated vCPUs, reserved for your server alone. June treated them very differently:

Monthly prices in Germany and Finland, excluding VAT and IPv4. January and April figures come from the February 2026 version of Hetzner's price page (archived copy). The last column applies to a server ordered or rescaled after 15 June; one running since January paid the April step only.

Hetzner blames the hardware market. Its FAQ explains why plans on hardware it already owns went up too: CPUs, RAM and drives that fail in service still have to be replaced, and those parts are caught in the same tight market.

Who pays more, and who doesn't

A cloud server you leave alone paid the April increase and nothing since. What moves it to June prices is listed in Hetzner's billing FAQ: rescaling, "regardless of whether the server is scaled up or down", restoring a deleted server, and moving it to a project billed in another currency. Rebuilding a server (reinstalling it) and moving it to a project in the same currency keep the old price.

A new server costs June prices, and you may not get the plan or location you want. Hetzner's cloud FAQ says that while a location is restricted, affected customers cannot create or rescale servers there; existing servers keep running. With all eight Cost-Optimized models marked "not available" on 12 October 2026, don't delete a CX or CAX server expecting to get the same plan back.

What Hetzner still does well

Billing is hourly with a monthly cap, EU servers include at least 20 TB of traffic, IPv6 is free, the Arm plans suit software built for Arm, and there are locations in Germany, Finland, the USA and Singapore. Most of all, a server you don't touch keeps its current price. If your servers run well and you don't need more, staying is often the cheapest choice.

Stay or move: a 10-minute cost check

Start with what the server really uses, not the plan name:

# as root on the old server
nproc
free -m
df -h /
du -sh /var/www /var/lib/mysql /var/lib/docker
systemctl list-units --type=service --state=running --no-legend --plain
ss -tlnp
ip -s link show eth0

Our lab server showed 2 vCPUs, 354 of 1,024 MB of RAM in use, 540 MB of website files and 283 MB of MariaDB files. The running services and open ports are your to-do list for the new server; ours included exim4, a small mail server, listening on port 25 for local mail. Then fill in:

Moving usually pays off when your next resize or next server would land on June prices, when you can't get capacity, or when you pay for traffic or IPv4 that another provider includes. Otherwise, stay and check again when you need to grow. Before choosing a replacement, run the same tests on both machines with our VPS benchmark commands.

What to compare between providers

Ask every provider the same extra questions: uptime promise (ours is 99% monthly), outbound port 25 for mail (blocked on our new servers, opened on request), support channel (Telegram and email with us), port speed (1 Gb/s on our VPS, 10 Gb/s on VDS) and contract terms. Shared vCPUs suit websites that are idle most of the time; dedicated vCPUs suit databases and long builds. Our VPS, VDS and dedicated server comparison explains the difference.

The migration runbook we tested

Our lab had two Debian 13 containers with 1 GB of RAM each on our Amsterdam test server. The "old" one ran nginx with 20,202 files (522 MB), MariaDB 11.8 with 1.05 million rows (102 MB), PostgreSQL 17 with 500,000 rows and Redis in Docker with 100,000 keys in a volume. The steps work the same from a Hetzner server to any Linux server; replace shop and shop.example with your site and domain.

Step 1: lower the DNS TTL a day before

The TTL (time to live) is how many seconds other DNS servers may remember your record. With 86400, some visitors reach the old IP for a day after you change it. Read it straight from your DNS servers:

# on any Linux machine (Debian: apt install bind9-dnsutils)
dig +short NS shop.example
dig +noall +answer shop.example A @ns1.your-dns-host.example

The number after the name is the TTL; our own domain answered 300. If yours is higher, set A and AAAA to 300 and wait at least the old TTL before the switch.

Step 2: prepare the new server and a migration key

The new server pulls everything, so the old one only needs rsync:

# as root on the new server
apt update
apt install -y rsync nginx mariadb-server docker.io docker-compose acl
ssh-keygen -t ed25519 -N "" -C migration-2026-10-12 -f /root/.ssh/migrate_ed25519
cat /root/.ssh/migrate_ed25519.pub

# as root on the old server
apt install -y rsync
echo 'ssh-ed25519 AAAA...the line you just copied... migration-2026-10-12' >> /root/.ssh/authorized_keys

# as root on the new server
cat >> /root/.ssh/config <<'EOF'
Host old
    HostName OLD_SERVER_IP
    User root
    IdentityFile /root/.ssh/migrate_ed25519
EOF
ssh old hostname

The last command prints the old server's name. From now on, old means the old server.

Step 3: copy the files while the site is live

# as root on the new server
rsync -aHAX --info=stats1,progress2 old:/var/www/ /var/www/
rsync -aHAX --delete --dry-run --itemize-changes old:/var/www/ /var/www/

-a keeps permissions, owners, times and links, -H hard links, -A ACLs (extra permission rules) and -X extended attributes; hard links and ACLs arrived intact in our lab. The second line is a dry run that only lists changes: >f+++++++++ is a new file, *deleting a file removed on the old side. Repeat the copy as often as you like; only changes travel.

Watch the user numbers. On our new server the user app had number 1001 instead of 1000. Run as root, rsync matches owners by name, so the files still belonged to app. With --numeric-ids they went to whichever user had 1000, the wrong one. Leave that option out for website files and use it for Docker volumes.

Step 4: bring over config, not all of /etc

Copying all of /etc would overwrite the new server's network settings, hostname, disk table and SSH keys. Keep a reference copy and pick what you need:

# as root on the new server
rsync -a old:/etc/ /root/old-etc/
ssh -n old "dpkg-query -W -f='\${Package}\n'" | sort > /root/pkgs-old.txt
dpkg-query -W -f='${Package}\n' | sort > /root/pkgs-new.txt
comm -23 /root/pkgs-old.txt /root/pkgs-new.txt
diff -rq /root/old-etc/nginx /etc/nginx
rsync -aR old:/etc/nginx/sites-available/shop :/etc/nginx/sites-enabled/shop :/etc/cron.d/shop-report /
nginx -t && systemctl reload nginx

comm lists packages the new server lacks; in our lab the list was empty, with 325 packages on each side. diff printed "Only in /root/old-etc/nginx/sites-available: shop", the file to bring over. With -R, rsync keeps the full path, so each file lands in the same folder on the new server. The -n stops ssh from swallowing the lines you paste after it. Then test the new server under your real hostname, before DNS changes:

# on your own computer
curl -sI --resolve shop.example:80:NEW_SERVER_IP http://shop.example/

We got HTTP/1.1 200 OK and X-Served-By: wf-hetzner-new, a header we added to tell the servers apart. For HTTPS, copy /etc/letsencrypt too or request certificates after the switch; see our reverse proxy and SSL guide.

Step 5: a trial database copy

# as root on the new server
ssh -n old "mariadb-dump --system=users" > /root/users.sql
grep '`shop`@' /root/users.sql | mariadb
ssh -n old "mariadb-dump --single-transaction --quick --routines --triggers --events --databases shop | gzip -1" | gunzip | mariadb
ssh -n old "mariadb -N -e 'CHECKSUM TABLE shop.orders'"
mariadb -N -e 'CHECKSUM TABLE shop.orders'

The grep line moves only your app's database user with its password hash. --single-transaction reads every InnoDB table as it was at one moment, without locking them, and --quick streams rows instead of holding them in memory. The copy took 16.4 seconds and both checksums matched. PostgreSQL took 4.3 seconds for 500,000 rows. These lines use sudo, so install it on the old server too if it is missing:

# as root on the new server
apt install -y postgresql sudo
ssh -n old "sudo -u postgres pg_dumpall --roles-only" | grep appuser | sudo -u postgres psql
sudo -u postgres createdb -O appuser appdb
ssh -n old "sudo -u postgres pg_dump -Fc appdb" | sudo -u postgres pg_restore -d appdb

The roles dump carries the password hash, so appuser logged in on the new server with its old password. Pipe dumps like this rather than saving them under /root: psql -f on a file there failed for us with "Permission denied", because the postgres user cannot read root's folder.

Step 6: Docker volumes

# as root on the new server
rsync -a old:/opt/cache/ /opt/cache/
cd /opt/cache && docker compose create
docker volume ls

This creates the containers and an empty volume without starting anything; we saw Volume "cache_redisdata" Created. Compose names volumes after the project folder, so check yours with docker volume ls on the old server. The data moves during the freeze with --numeric-ids: without it, a dry run showed the volume's group changing (.d..t..g...), because number 1000 was a different user on each server, and programs inside containers know numbers, not names.

Step 7: freeze, final sync, switch

Prepare two nginx sites on the old server: a 503 "try again later" page for the copy, and a proxy that sends visitors with an outdated DNS answer to the new server afterwards:

# as root on the old server
cat > /etc/nginx/sites-available/shop-maintenance <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name shop.example;
    add_header Retry-After 600 always;
    return 503;
}
EOF
cat > /etc/nginx/sites-available/shop-proxy <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name shop.example;
    location / {
        proxy_pass http://NEW_SERVER_IP;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
EOF

Checked with curl, the maintenance site answers HTTP/1.1 503 Service Temporarily Unavailable with Retry-After: 600, which tells browsers and search engines that the outage is short. Then run the switch from the new server. The freeze starts with the first line:

# as root on the new server
ssh -n old 'ln -sf /etc/nginx/sites-available/shop-maintenance /etc/nginx/sites-enabled/shop && systemctl reload nginx'
ssh -n old 'mariadb -e "SET GLOBAL read_only = ON"'
ssh -n old 'cd /opt/cache && docker compose stop'
ssh -n old 'systemctl disable --now cron'
rsync -aHAX --delete old:/var/www/ /var/www/
ssh -n old "mariadb-dump --single-transaction --quick --routines --triggers --events --databases shop | gzip -1" | gunzip | mariadb
rsync -aHAX --numeric-ids --delete old:/var/lib/docker/volumes/cache_redisdata/_data/ /var/lib/docker/volumes/cache_redisdata/_data/
cd /opt/cache && docker compose up -d
ssh -n old 'ln -sf /etc/nginx/sites-available/shop-proxy /etc/nginx/sites-enabled/shop && nginx -t -q && systemctl reload nginx'

Timed in our lab, with the cron line run separately: old server frozen at 2.0 seconds, files in sync at 3.0, database at 22.4, Docker volume at 22.8, containers up at 23.5, old server forwarding at 23.8. The database sets the length of the freeze; the files hardly matter after the trial runs. Stopping cron keeps scheduled jobs from running twice. Our timed switch moved MariaDB only. If you also run PostgreSQL, stop the app that writes to it and repeat the Step 5 dump inside the freeze, into a freshly created empty database on the new server.

The new server had all 1,000,250 orders with matching checksums and all 100,500 Redis keys. A write on the old database failed with ERROR 1290 (HY000) ... --read-only option, as intended, and a request to the old IP came back with X-Served-By: wf-hetzner-new. Now point the A and AAAA records at the new server. Late visitors still arrive through the proxy, and the old server's access log shows when they stop. If your app sends mail on port 25 and the new server is ours, ask us on Telegram to open the port first.

Step 8: rollback, then clean up

Keep the old server read-only for a few days. If the new one misbehaves, send the newer data back and point DNS at the old IP again:

# as root on the new server
mariadb -e "SET GLOBAL read_only = ON"
mariadb-dump --single-transaction --quick --routines --triggers --events --databases shop | gzip -1 | ssh old "gunzip | mariadb"
rsync -aHAX --delete /var/www/ old:/var/www/
ssh -n old 'mariadb -e "SET GLOBAL read_only = OFF"'
ssh -n old 'ln -sf /etc/nginx/sites-available/shop /etc/nginx/sites-enabled/shop && systemctl reload nginx'
ssh -n old 'systemctl enable --now cron'

Our database rollback took 11 seconds and brought back an order placed on the new server after the switch, and the reverse rsync carried a file uploaded after the switch back to the old server. If the app also wrote to Redis or PostgreSQL on the new server, copy those back the same way before you start the old containers again. Once you decide to stay on the new server, remove the key and delete the old one; Hetzner's billing FAQ says cloud servers are billed until deleted, even when switched off.

# as root on the old server
sed -i '/migration-2026-10-12/d' /root/.ssh/authorized_keys

Set up backups on day one, for example with our restic and MinIO guide, and for WordPress add the checks in our WordPress migration guide. If a server is too hand-made to rebuild, you can move its whole disk instead: Hetzner's rescue system boots the server into a separate Linux system, so its disk is not in use. Our VMware to KVM guide shows how to convert and check an image with qemu-img. We import a converted .qcow2 or .raw disk on request; like other setup work, it is quoted per job.

Frequently asked questions

Did Hetzner raise prices for existing servers in 2026?

Yes, once. The 1 April 2026 increase of 30% to 37% on cloud servers applied to existing products and new orders. The 15 June 2026 round applies only to new orders and rescales, so a running server that is never resized keeps its pre-June price.

How much did Hetzner cloud prices rise in June 2026?

In Germany and Finland, the shared AMD CPX plans rose 144% to 175%, the dedicated CCX plans 113% to 173%, and the CX and CAX plans 30% to 38%. A CPX22 went from €7.99 to €19.49 a month. In the USA some CPX plans rose more than 200%.

Why are Hetzner's cheapest cloud servers not available?

Since 26 June 2026 Hetzner's status page has reported limited availability of cloud instances because of high demand and limited hardware supply. On 12 October 2026 all eight Cost-Optimized models (CX and CAX) were marked "not available" on Hetzner's website.

Does rescaling a Hetzner server change its price?

Yes. Hetzner's billing FAQ says rescaling moves a server with older pricing to the current price, whether you scale up or down. Rebuilding the server keeps the old price.

How long does it take to move a server to another provider?

Mostly preparation, not downtime. In our lab, 522 MB of files took 42 seconds at about 100 Mbit/s, a database with 1.05 million rows took 16 seconds, and the final switch froze writes for 24 seconds.

Do I have to take my website offline to migrate?

Only briefly. Copy everything while the site runs, then freeze writes for the final sync. A proxy on the old server forwards late visitors until DNS has caught up.

Before you click Rescale

Running Hetzner servers keep their prices; new and resized ones pay June rates, and the cheapest line is hard to get. Do the cost check, and if moving wins, copy early, test under your real hostname, freeze briefly and keep a way back. RS Computers runs KVM VPS and VDS servers in Amsterdam, Dublin and Prishtina with unmetered traffic and IPv4 and IPv6 included; availability by city is on the plans page. Planning a move or a disk import? Message us on Telegram.

← All articles