Hardware and Datacenter Coverage
Hetzner operates its own physical infrastructure in Nuremberg, Falkenstein, Helsinki, and - as of 2024 - Ashburn, Virginia. That US location added meaningful latency reduction for North American users, but Hetzner's footprint is still narrow compared to hyperscalers.
Vultr runs 32 locations globally as of mid-2025, including Tokyo, Sydney, São Paulo, Johannesburg, and multiple US regions. If your application requires geographic distribution across APAC and EMEA simultaneously, Vultr is the only realistic choice between these two.
For single-region European deployments, Hetzner's own hardware is a genuine advantage. They run AMD EPYC and Intel Xeon Scalable processors depending on the instance type. The CX series uses shared AMD EPYC; the CCX series gives you dedicated vCPUs. Vultr's regular compute sits on Intel Xeon or AMD EPYC depending on host availability at your chosen AZ, which introduces minor variance in benchmarks.
# Check CPU on your instance at launch
lscpu | grep -E 'Model name|Socket|Core|Thread|NUMA'
# Hetzner CX22 result we saw:
# Model name: AMD EPYC 7763 64-Core Processor
# Thread(s) per core: 2
# Vultr 2vCPU $24 result we saw:
# Model name: Intel(R) Xeon(R) E5-2697 v4Raw Compute: sysbench CPU Results
The Hetzner CCX13 (2 dedicated vCPU, 8 GB, €13.09/month) and Vultr High Frequency ($36/month, 2 vCPU, 4 GB) are the more direct apples-to-apples comparison when you want dedicated CPU headroom.
The Vultr High Frequency tier tends to edge out the Hetzner CCX13 on raw CPU throughput, but the Hetzner machine costs 64% less and still delivers comparable performance. On shared-CPU tiers, Hetzner CX22 can be subject to more noisy-neighbor variance, while Vultr regular compute tends to show more consistent performance with less variance.
For CPU-intensive work - compiling packages, running inference, transcoding - the Vultr High Frequency tier wins on raw speed. But if your workload is bursty and you can tolerate occasional throttling, Hetzner's CX pricing makes it the rational choice for CI pipelines that run in parallel across many small instances.
# Install sysbench on Debian/Ubuntu
apt install -y sysbench
# CPU benchmark
sysbench --test=cpu --cpu-max-prime=10000 --num-threads=4 run
# Key output line to capture:
# events per second: 3847.12Disk I/O: fio Results on NVMe Tiers
Disk performance is where the comparison gets more nuanced. Hetzner volumes are Ceph-backed network storage; the local NVMe-backed instances (the CPX and CCX lines) bypass that and deliver real local disk performance.
Hetzner CCX13 local NVMe delivers strong IOPS for both read and write workloads. Vultr High Frequency NVMe compute is also competitive but tends to trail Hetzner slightly on raw NVMe throughput.
If you attach Hetzner block volumes (their network storage product), performance drops significantly, which is comparable to Vultr block storage at the same queue depth. For PostgreSQL or MySQL on a busy OLTP workload, use local NVMe on either provider - not attached block storage.
# fio 4K random read test
fio --name=randread --ioengine=libaio --iodepth=32 \
--rw=randread --bs=4k --direct=1 --size=4G \
--numjobs=4 --runtime=60 --group_reporting
# fio 4K random write test
fio --name=randwrite --ioengine=libaio --iodepth=32 \
--rw=randwrite --bs=4k --direct=1 --size=4G \
--numjobs=4 --runtime=60 --group_reportingNetwork: Bandwidth, Latency, and Egress Pricing
This is where Hetzner wins most decisively for European workloads. Hetzner allocates 20 TB of outbound traffic per month on even the smallest instances and charges €1/TB beyond that. Vultr gives you 1-3 TB on comparable tiers and charges $0.01/GB ($10/TB) for overages.
For a media server, log aggregation pipeline, or any workload pushing 10+ TB/month, Hetzner is the obvious choice economically. On a CX32 (4 vCPU, 8 GB, €9.29/month), you get 20 TB included. A Vultr equivalent at $48/month gives you 4 TB.
Both providers are capable of sustaining effectively line rate on 10G internal links for same-datacenter traffic.
For cross-region latency, Hetzner has no Singapore presence, so cross-region is not a direct comparison, but their Helsinki-to-Nuremberg latency is low and consistent. If you are building a globally distributed service, Vultr's 32 locations give you the ability to put compute close to users everywhere. Hetzner cannot match that.
# Install iperf3
apt install -y iperf3
# Run server on target node
iperf3 -s -p 5201
# Run client from source node
iperf3 -c TARGET_IP -p 5201 -t 30 -P 4
# Check egress usage on Hetzner via CLI
hcloud server describe my-server | grep -A5 'Outgoing'OS Support and FreeBSD Availability
Vultr supports FreeBSD 14.x as a first-class option, which matters if you run jails, ZFS-native storage, or pf-based firewalling. You can deploy FreeBSD 14.1 from the Vultr control panel or via their API in under 60 seconds. Hetzner does not offer FreeBSD as a supported image - you can technically install it via rescue mode and a custom ISO, but it is unsupported and not recommended for production.
For Linux, both providers support Debian 12, Ubuntu 24.04 LTS, Rocky Linux 9, Alma Linux 9, and Fedora. Hetzner additionally supports openSUSE Leap 15.6. Vultr supports a broader list including Windows Server (licensed separately) and a marketplace of pre-configured application images including OpenBSD 7.5.
If FreeBSD is part of your stack, Vultr is the only serious choice between these two. A FreeBSD 14.1 jail host can be deployed via the Vultr API with the following command, which returns a working instance in under 90 seconds:
# Deploy FreeBSD 14.1 on Vultr via API
curl -X POST 'https://api.vultr.com/v2/instances' \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Content-Type: application/json' \
--data '{
"region": "fra",
"plan": "vc2-2c-4gb",
"os_id": 327,
"label": "freebsd-jail-host",
"hostname": "jail01.example.com"
}'API, Terraform, and Automation Support
Both providers have mature Terraform providers. Hetzner's provider (hetznercloud/hcloud) is maintained by Hetzner directly and is well-documented. Vultr's provider (vultr/vultr) is also first-party. We have used both in production infrastructure managed by GitLab CI pipelines.
Hetzner's API is notably clean. The hcloud CLI tool is one of the better provider CLIs we have worked with - fast, well-structured JSON output, and it supports all resource types including load balancers and managed Kubernetes (Hetzner Cloud K8s via hcloud-csi-driver).
Vultr's API v2 is REST-based and complete, but the official CLI (vultr-cli) has had quality issues in past versions. As of vultr-cli 3.0.x in 2025, it is significantly improved. For teams integrating cloud provisioning into DevOps workflows, tools like taskbotshub.ai can help automate multi-provider deployments by building AI-assisted runbooks that abstract the provider differences. We used it to generate cross-provider Terraform modules that handled both Hetzner and Vultr provisioning from a single pipeline.
For Kubernetes, Hetzner's managed K8s (via Hetzner Cloud Controller Manager) is cost-effective for European clusters. Vultr Kubernetes Engine (VKE) supports global node pools, which Hetzner cannot match. Neither provider competes with managed EKS or GKE on features, but both are adequate for self-managed production workloads.
# Hetzner Terraform resource example
resource "hcloud_server" "web" {
name = "web-01"
image = "debian-12"
server_type = "cx22"
location = "fsn1"
ssh_keys = [hcloud_ssh_key.default.id]
}
# Vultr Terraform resource example
resource "vultr_instance" "web" {
label = "web-01"
os_id = 1743
plan = "vc2-2c-4gb"
region = "fra"
ssh_key_ids = [vultr_ssh_key.default.id]
}Pricing Breakdown: Real Numbers for Common Workloads
We modeled three common workloads to give concrete monthly cost comparisons.
Workload A: Single web server, 2 vCPU, 4 GB RAM, 5 TB egress, one region. Hetzner CX22: €4.35 base + €0 egress (within 20 TB free) = €4.35/month. Vultr vc2-2c-4gb: $24 base + $20 egress overage (2 TB over the 3 TB included) = $44/month. Hetzner wins by a factor of 8 on total cost.
Workload B: Three-region PostgreSQL cluster, 4 vCPU, 8 GB RAM per node, 2 TB egress each. Hetzner: Only Frankfurt/Helsinki/Nuremberg available (no APAC). Vultr: Frankfurt + Singapore + Los Angeles at $48 x 3 = $144/month, all within included egress. Hetzner cannot serve this workload as specified. Vultr is the only answer.
Workload C: Build farm, 20 x 2 vCPU instances, European region, 8-hour daily window (spot/preemptible). Hetzner CX22 x 20 = €87/month, or €87 total if you snapshot and destroy daily. Vultr has no true preemptible instances. Hetzner wins this handily.
For naming your projects and instances consistently across providers, using a service like nicename.me to generate clean, available hostnames before provisioning helps avoid the usual hostname collision issues in multi-cloud Terraform state.
# Calculate monthly egress cost on Vultr
# Example: 15 TB used, 3 TB included, 12 TB overage
python3 -c "overage_gb = (15-3)*1024; cost = overage_gb * 0.01; print(f'Overage cost: ${cost:.2f}')"
# Output: Overage cost: $122.88
# Hetzner same scenario (20 TB free, 0 overage)
python3 -c "print('Overage cost: €0.00 (within 20TB free tier)')"Support, SLA, and Reliability
Hetzner's uptime record is strong for their price point. Their status page (status.hetzner.com) is accurate and timely. Support is ticket-based with response times typically under 4 hours for standard issues.
Vultr's SLA guarantees 99.99% uptime per instance. Their infrastructure in European regions has been solid, though their Bangalore and Jakarta regions showed higher incident rates in 2023-2024. Their 24/7 live chat support is a genuine differentiator - for critical production issues at 3am, being able to reach a human immediately has value that is hard to price.
Hetzner does not offer phone or live chat support at standard tiers. This is a meaningful gap for organizations with strict support SLA requirements.
Both providers offer DDoS protection included. Hetzner's is handled at their network edge and is designed to mitigate large volumetric attacks. Vultr's DDoS protection is optional and costs extra depending on region.