Pricing and Instance Tiers in 2025

Hetzner restructured their lineup in late 2024, retiring the older CX line suffixes and replacing them with cleaner tier names. The shared ARM instances (CAX) are the cheapest entry point: CAX11 gives you 2 ARM vCPUs and 4 GB RAM for €3.79/month. The AMD shared instances start at CX22 for €3.29/month. Dedicated CPU instances (CCX) start at CCX13 with 2 dedicated AMD vCPUs and 8 GB RAM for €12.49/month.

For comparison, DigitalOcean's closest equivalent to the CX22 is their Basic Droplet at $18/month for the same specs. Vultr's 4 GB KVM instance runs $24/month. Even accounting for currency differences, Hetzner is 4-5x cheaper at the low end. The gap narrows slightly on dedicated CPU tiers but Hetzner still wins.

Network egress is where Hetzner really separates itself. Every instance includes a traffic allocation: 20 TB/month on CX22, scaling up with tier. DigitalOcean gives you 2 TB on a comparable plan. Overage on Hetzner is €1/TB. Overage on DigitalOcean is $0.01/GB, which is $10/TB - ten times more expensive.

# Current pricing snapshot (August 2025)
# hcloud CLI - list server types with price
hcloud server-type list --output columns=name,cores,memory,disk,storage_type,price_monthly_gross

# Output excerpt:
# NAME      CORES  MEMORY  DISK  STORAGE  PRICE/MO
# cx22      2      4.0 GB  40    local    €3.29
# cx32      4      8.0 GB  80    local    €6.49
# ccx13     2      8.0 GB  80    local    €12.49
# cax11     2      4.0 GB  40    local    €3.79

Provisioning Speed and API Quality

Server provisioning on Hetzner took an average of 18 seconds from API call to SSH-accessible in our testing across 50 deployments. That is not a typo. DigitalOcean averaged 52 seconds. Vultr averaged 41 seconds. This matters for autoscaling workloads and CI/CD ephemeral runners.

The hcloud CLI is first-class. It is a compiled Go binary with a clean subcommand structure, proper exit codes, and JSON output via --output json. Terraform support via the official hetznercloud/hcloud provider is mature and has been stable since provider version 1.44. The API itself is REST with predictable resource URLs and returns sensible HTTP status codes.

One gap we found: the API does not support instance resize without downtime. You stop the server, resize, restart. AWS and GCP allow in-place vertical scaling on some instance types. Hetzner does not. For stateless workloads this is fine. For persistent services, plan your initial sizing carefully or architect around horizontal scaling from day one.

# Provision a server and time it
time hcloud server create \
  --name prod-web-01 \
  --type cx22 \
  --image ubuntu-24.04 \
  --location hel1 \
  --ssh-key ~/.ssh/id_ed25519.pub \
  --output json | jq '.server.status'

# Resize example (requires server stop)
hcloud server poweroff prod-web-01
hcloud server change-type prod-web-01 --server-type cx32
hcloud server poweron prod-web-01

Raw Performance: Disk, CPU, and Network Benchmarks

We ran fio on CX22 with a 4K random read/write workload against the local NVMe. Read IOPS averaged 89,400. Write IOPS averaged 42,100. Sequential read throughput hit 1.1 GB/s. These numbers are competitive with DigitalOcean's Premium NVMe droplets which cost 2x more.

The ARM-based CAX11 is worth separate attention. We ran the same fio workload and got 94,200 read IOPS - slightly higher, likely due to the Ampere Altra cores handling I/O scheduling more efficiently. Sysbench CPU single-thread on CAX11 scored 1,847 events/second versus 2,103 on CX22. The AMD edge matters for CPU-bound single-threaded work. For parallel workloads, ARM holds its own and costs 13% less.

Network: iperf3 from a CX22 in Nuremberg to a CX22 in Helsinki averaged 9.4 Gbps between instances in the same private network. Public internet throughput to a test node in Frankfurt averaged 4.2 Gbps sustained. Latency between Hetzner's Nuremberg and Helsinki datacenters averaged 8ms RTT. The private network (Hetzner Cloud Networks) is a flat L2 overlay with configurable subnets and adds no meaningful latency compared to public routing between instances.

# fio 4K random read benchmark
fio --name=randread --ioengine=libaio --iodepth=64 \
  --rw=randread --bs=4k --direct=1 --size=4G \
  --numjobs=4 --runtime=60 --group_reporting \
  --filename=/dev/sda

# sysbench CPU test
sysbench cpu --cpu-max-prime=20000 --threads=4 run

# iperf3 between two instances
# On server:
iperf3 -s
# On client:
iperf3 -c 10.0.0.2 -P 8 -t 30
// advertisement

Networking: Private Networks, Floating IPs, and Load Balancers

Hetzner Cloud Networks let you create private subnets across your instances in a region. We used a /16 in the 10.0.0.0/8 range for a Kubernetes cluster. VXLAN is used underneath, but from inside the VM it presents as a standard eth1 interface. MTU is 1450 to account for encapsulation overhead - set this explicitly or you will see fragmentation issues with some workloads.

Floating IPs (now called 'Primary IPs' in the API) cost €1/month when unattached. They persist independent of the server and can be reassigned in under 3 seconds via API. We tested a failover scenario 20 times: average reassignment time was 2.4 seconds. That is usable for basic HA if you pair it with a health check loop, though you will want a proper load balancer for production.

Hetzner's managed Load Balancer starts at €5.83/month for LB11. It supports HTTP, HTTPS, and TCP targets, automatic Let's Encrypt certificate provisioning, and sticky sessions. Health check intervals are configurable down to 3 seconds. It handled 12,000 concurrent connections in our test without measurable latency increase. The one limitation: no UDP load balancing. For game servers or DNS, you are routing around this or using a third-party solution.

# Create a private network and attach server
hcloud network create --name prod-net --ip-range 10.0.0.0/16
hcloud network add-subnet prod-net \
  --network-ip-range 10.0.0.0/16 \
  --type cloud \
  --ip-range 10.0.1.0/24 \
  --zone eu-central

hcloud server attach-to-network prod-web-01 \
  --network prod-net \
  --ip 10.0.1.10

# Set MTU on the interface inside the VM
ip link set eth1 mtu 1450

Storage: Volumes, Snapshots, and Object Storage

Hetzner Cloud Volumes are network-attached SSD block storage at €0.052/GB/month. We provisioned a 100 GB volume, formatted it ext4, and mounted it. fio on the volume showed 8,400 read IOPS and 5,200 write IOPS - significantly lower than local NVMe, which is expected. Use volumes for persistent data where you need to detach and reattach across server replacements, not for I/O-intensive workloads.

Snapshots cost €0.0119/GB/month based on the compressed size. A stock Ubuntu 24.04 server with basic tooling installed compressed to 2.3 GB, costing under €0.03/month to store. We automated snapshot rotation with a simple cron job calling hcloud.

Hetzner Object Storage launched in 2024 as an S3-compatible service. Pricing is €0.0059/GB/month for storage and €0.0090/GB for egress outside Hetzner's network. Egress to other Hetzner services is free. We tested it with the standard aws CLI using a custom endpoint and it worked without modification. rclone, s3cmd, and boto3 all work correctly. This makes Hetzner a viable full-stack host for projects that previously required a separate object storage provider.

# Create and mount a volume
hcloud volume create --name data-vol --size 100 --server prod-web-01
# Volume appears as /dev/disk/by-id/scsi-0HC_Volume_XXXXXXXX
mkfs.ext4 /dev/disk/by-id/scsi-0HC_Volume_XXXXXXXX
mount /dev/disk/by-id/scsi-0HC_Volume_XXXXXXXX /mnt/data

# Automate snapshot with hcloud CLI
# /etc/cron.daily/hetzner-snapshot
#!/bin/bash
hcloud server create-image prod-web-01 \
  --description "daily-$(date +%Y%m%d)" \
  --type snapshot
# Delete snapshots older than 7 days
hcloud image list --type snapshot --output json | \
  jq -r '.[] | select(.created < (now - 604800 | todate)) | .id' | \
  xargs -I{} hcloud image delete {}

# S3-compatible object storage
aws s3 ls s3://your-bucket \
  --endpoint-url https://fsn1.your-objectstorage.com

Reliability, SLA, and Support

Hetzner's SLA is 99.9% uptime per instance, which is standard and not impressive on paper. In practice, our six-month monitoring of three CX22 instances showed zero unplanned downtime. One scheduled maintenance window required a 15-minute restart in March 2025; we received 72 hours notice by email.

Support is ticket-based only. There is no phone support and no live chat. Response times on our tickets averaged 4 hours during European business hours, 11 hours outside that window. The quality was technically competent - responses came from engineers who understood Linux infrastructure, not tier-1 scripted replies. If you need 24/7 immediate response SLA, Hetzner is not the right choice. If you are a team that resolves most issues independently and just needs vendor support for platform-level issues, it is adequate.

One reliability concern worth naming: Hetzner's abuse handling has historically been aggressive. If your IP ends up on a blocklist or you get flagged for network activity, response times slow and resolution can take days. We have not experienced this personally but it is well-documented in community forums. VPN providers and high-volume email senders have had poor experiences. For standard web, API, and compute workloads, it is a non-issue.

# Monitor instance health with a simple check
# Add to /etc/cron.d/hetzner-health
*/5 * * * * root curl -sf https://status.hetzner.com/api/v2/status.json \
  | jq -r '.status.indicator' >> /var/log/hetzner-status.log
// advertisement

Practical Use Cases: Where Hetzner Excels

Self-hosted Kubernetes is where Hetzner shines most. k3s on three CCX13 nodes (€37.47/month total) gives you a production-grade cluster with dedicated CPUs that would cost over $200/month on managed EKS or GKE without even counting node costs. The Hetzner Cloud Controller Manager (hcloud-controller-manager) and the CSI driver for volumes are both maintained by Hetzner and work reliably. We ran a 5-node k3s cluster with the hcloud CCM for four months without any platform-related issues.

CI/CD ephemeral runners work well given the fast provisioning times. GitHub Actions self-hosted runners on CX22 instances, spun up via the hcloud API on job start and destroyed on completion, cost a fraction of GitHub's hosted runners for equivalent CPU time. Pair this with a tool like Terraform or a lightweight orchestrator - if you are evaluating AI-assisted DevOps automation for managing these pipelines, taskbotshub.ai covers Hetzner-specific runner orchestration workflows worth reviewing.

For teams bootstrapping new projects, Hetzner's low cost means you can run staging environments that mirror production without the bill becoming a line-item argument. When naming and registering domains for those environments, nicename.me covers availability checking and registration if you want to consolidate that step alongside your infrastructure provisioning workflow.

Hetzner is a poor fit for latency-sensitive workloads targeting North American users from a single region. Their US presence is limited to Ashburn (Virginia) as of 2025. For Asia-Pacific coverage, you are looking at a different provider entirely.

# k3s install on CCX13 with hcloud CCM support
curl -sfL https://get.k3s.io | sh -s - \
  --disable-cloud-controller \
  --kubelet-arg="cloud-provider=external" \
  --token=YOUR_TOKEN \
  --tls-san=YOUR_FLOATING_IP

# Deploy hcloud CCM
kubectl apply -f https://github.com/hetznercloud/hcloud-cloud-controller-manager/releases/latest/download/ccm.yaml

Terraform and Infrastructure as Code Integration

The hetznercloud/hcloud Terraform provider is at version 1.49 as of mid-2025. It covers servers, networks, volumes, load balancers, firewalls, SSH keys, and placement groups. The provider is stable and has no significant outstanding bugs in the 1.4x series.

One useful pattern we use: placement groups to ensure instances land on different physical hosts. Hetzner supports spread placement groups at no extra cost. For any HA setup, add a placement group as a matter of routine.

Firewall rules are managed at the hypervisor level, not inside the VM. This means they apply even if iptables inside the VM is misconfigured. We define them in Terraform and apply a default-deny inbound policy with explicit allows. The firewall resource supports both inbound and outbound rules and can be applied at instance creation time.

# Minimal Terraform config for a hardened CX22
terraform {
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.49"
    }
  }
}

resource "hcloud_placement_group" "web" {
  name = "web-spread"
  type = "spread"
}

resource "hcloud_firewall" "web" {
  name = "web-fw"
  rule {
    direction = "in"
    protocol  = "tcp"
    port      = "22"
    source_ips = ["YOUR_MGMT_IP/32"]
  }
  rule {
    direction = "in"
    protocol  = "tcp"
    port      = "443"
    source_ips = ["0.0.0.0/0", "::/0"]
  }
}

resource "hcloud_server" "web" {
  name               = "prod-web-01"
  server_type        = "cx22"
  image              = "ubuntu-24.04"
  location           = "hel1"
  placement_group_id = hcloud_placement_group.web.id
  firewall_ids       = [hcloud_firewall.web.id]
}