What we like
- Competitive resource pricing in European cloud regions
- Hourly billing with monthly caps
- Choice of shared and dedicated CPU families
- IPv6 is free on Cloud servers
Strong infrastructure value when its available regions fit your audience.
Hetzner is one of the most frequently discussed VPS and cloud providers among developers because its European Cloud plans have historically offered a strong amount of compute, memory, storage, and transfer for the price. That reputation is useful context, but it can also make old comparisons misleading. Hetzner changed Cloud pricing in June 2026, and the cheapest plan depends on architecture, region, and current capacity.
This review looks at the decision as it exists now: current Cloud pricing, where Hetzner actually has regions, what public IPv4 costs, the difference between cost-optimized, regular shared CPU, and dedicated CPU products, and the kinds of WordPress, Docker, development, and production workloads for which Hetzner makes sense.
Hetzner is most compelling when Germany or Finland is a good location for your users and you want a lot of usable infrastructure for the monthly price. It becomes a less obvious choice when you need a specific global region, guaranteed capacity on the cheapest tier, or a single all-in price that already includes public IPv4.
Hetzner adjusted Cloud prices for new orders and instance resizes on June 15, 2026. In Germany and Finland, the x86 CX23 moved from $4.99 to $6.49 per month before public IPv4. The Arm-based CAX11 moved from $5.49 to $6.99 per month. That matters because many older VPS lists still describe Hetzner as a sub-$5 cloud option using prices that no longer apply to new orders.
The base Cloud server price also does not include a public IPv4 address. Hetzner currently charges $0.60 per month for a Primary IPv4, while Primary IPv6 is free. A buyer comparing providers should therefore treat the published server price as the compute component, then add IPv4, backups, Volumes, snapshots, tax, and any other resources actually needed by the workload.
Hetzner bills Cloud servers hourly up to a monthly cap. If you delete a server before the end of the month, you pay the hourly usage rather than the full monthly cap. Powering a server off is not the same as deleting it: the server still exists and billing continues until you remove the resource.
Hetzner Cloud currently lists six locations across four network zones: Falkenstein and Nuremberg in Germany, Helsinki in Finland, Ashburn in Virginia, Hillsboro in Oregon, and Singapore. That is enough coverage for many projects, but it is not the same geographic footprint as clouds that operate in dozens of metros.
For European users, Hetzner is particularly easy to shortlist because Germany and Finland are core Cloud regions and the cost-optimized product family is published there. For a US-focused application, Ashburn can serve East Coast users while Hillsboro provides a western US option. Singapore gives Hetzner an Asia-Pacific region, but the plan catalog and pricing are not identical across all locations.
Do not choose a region simply because it appears on the location list. Test latency from the networks your audience uses, check whether the server family you want is actually offered in that region, and compare the region-specific price. Hetzner publishes different Cloud prices for Europe, the United States, and Singapore.
Provider prices and capacity can change by region. Use the official catalog to verify the exact server family, location, IP choice, and final monthly total before ordering.
Open Hetzner official Cloud page →Hetzner separates Cloud servers into shared-resource and dedicated-resource categories. Its cost-optimized family uses proven, older hardware generations and is aimed at low-to-medium CPU usage, development environments, prototypes, smaller websites, private blogs, and similar workloads. Hetzner explicitly notes that capacity for this family can be limited.
Shared CPU is usually appropriate for websites, development, small APIs, bots, VPNs, and workloads that burst rather than saturate processors continuously. The trade-off is that CPU performance can vary more because host resources are shared. If a database, build system, encoding workload, analytics job, or application needs sustained and predictable CPU, Hetzner also offers dedicated-resource Cloud instances.
Architecture matters too. CAX plans use Arm64 while CX and other x86 families use Intel or AMD compatible architecture. Arm can be excellent value when your application, container images, packages, and build pipeline support it. It is not a drop-in choice when part of the software stack requires x86.
Hetzner can be a strong WordPress host when you are comfortable managing Linux or use a management layer on top of the VM. A small WordPress site benefits more from correct RAM sizing, caching, database configuration, backups, and a nearby region than from choosing a provider solely because it appears in a benchmark chart.
For production WordPress, a 2 GB server is a practical minimum for a modest site, while 4 GB provides more headroom for heavier plugins, staging, WooCommerce, object caching, and traffic spikes. The server should be paired with a backup plan that covers both WordPress files and the database. If you attach Hetzner Volumes, remember that Hetzner says server Backups and Snapshots do not include those attached Volumes.
The important question is operational responsibility. Hetzner Cloud is infrastructure, not a fully managed WordPress product. You are responsible for system updates, SSH access, firewall rules, the web stack, monitoring, and recovery unless you deliberately add tooling or a managed service that takes over those jobs.
Docker is a natural Hetzner use case because Cloud servers expose a standard Linux environment, API-driven infrastructure, private networking, firewalls, Volumes, and snapshots. A small Compose stack can fit on a modest shared-CPU server, while heavier stacks can move to larger shared plans or dedicated resources when sustained CPU becomes the bottleneck.
For self-hosted applications, storage planning matters as much as CPU. Container images, databases, logs, media files, and backup copies all consume disk. Keep irreplaceable application data separate from disposable containers, define a restore process, and understand which data lives on the server disk versus attached Volumes.
Hetzner is also attractive for short-lived development environments because hourly billing allows servers to be created and deleted as needed. The cost advantage only exists if unused resources are actually removed rather than left powered off.
Hetzner Cloud Backups are automatic copies of the server disk and use seven backup slots. Once the available slots are full, the oldest backup is replaced by a new one. Snapshots are created manually and remain until you delete them. Both can be used to rebuild a server or create another server from the captured state.
These features are useful, but they are not a complete backup architecture. Hetzner explicitly states that attached Volumes are not included in server Backups or Snapshots. Databases may also require application-consistent backup procedures rather than relying only on a disk-level capture. For important workloads, keep at least one recovery copy outside the server you are protecting and test the restore process.
Snapshots are also useful for repeatable environments. You can configure a base server, create a snapshot, and use it to create additional instances with the same initial state. Infrastructure-as-code and image-building tools can take that idea further when deployments become frequent.
Hetzner is easy to recommend as a shortlist candidate for developers, small SaaS projects, WordPress sites, Docker hosts, staging environments, VPNs, and self-hosted applications when one of its locations fits the audience. The strongest argument is usually infrastructure value rather than a huge catalog of managed application services.
It is less compelling when a project needs a city or country Hetzner does not serve, when the cheapest cost-optimized capacity is unavailable, or when the team wants managed application support instead of raw infrastructure. The separate IPv4 charge also means comparisons should use the effective monthly total rather than the compute-only headline price.
For globally distributed applications, compare Hetzner with providers that offer a larger number of regions. For developer workflows where documentation, managed databases, or platform integrations matter more than the lowest infrastructure cost, DigitalOcean can be worth comparing. For broad location choice and multiple compute families, Vultr is another natural comparison.
Vultr is the most obvious alternative when geographic coverage matters more than minimizing the European compute bill. Its broader region catalog can reduce latency for users in places where Hetzner has no nearby location. DigitalOcean is another useful alternative for teams that value a polished developer experience, extensive tutorials, and an ecosystem of managed services.
The better comparison is not provider versus provider in the abstract. Compare the exact region and server family that would run your workload. A Hetzner CX instance in Germany, a Vultr Cloud Compute instance in the US, and a DigitalOcean Droplet may differ in CPU behavior, bandwidth, backups, billing granularity, and included network resources even when their RAM looks similar.
If the workload is simple, deploy test servers for a few days and measure your own application. Real response times, CPU behavior, disk latency, network routes, and operational workflow are more useful than a generic benchmark taken from a different plan.
For new orders in Germany and Finland after the June 15, 2026 price adjustment, Hetzner published the CX23 at $6.49 per month before public IPv4 and VAT. Prices differ by server family and region.
No. Hetzner documents public IP addresses separately from Cloud servers. A Primary IPv4 currently costs $0.60 per month excluding VAT, while Primary IPv6 is free.
Hetzner currently lists Falkenstein and Nuremberg in Germany, Helsinki in Finland, Ashburn in Virginia, Hillsboro in Oregon, and Singapore.
Yes when the region suits your visitors and you are comfortable managing the server or using a management layer. WordPress performance depends on RAM, CPU, caching, database tuning, backups, and application configuration as well as the provider.
Yes. Standard Linux Cloud servers, API access, networking, firewalls, Volumes, snapshots, and hourly billing make Hetzner suitable for Docker and self-hosted stacks. Size memory and persistent storage for the containers you actually run.
No. Hetzner states that Cloud server billing continues until the server is deleted. Deleting a server before the monthly cap means you are billed for its hourly usage.
They are useful for server-disk recovery, but Hetzner states that attached Volumes are not included. Important workloads should also use application-aware backups and at least one recovery copy outside the server being protected.
Current prices, IP charges, locations, billing rules, and backup behavior can change. These primary sources support the time-sensitive claims in this review.
Hetzner Cloud price adjustment — June 15, 2026 →Hetzner Cloud server overview and IPv4 pricing →Hetzner Cloud locations →Hetzner cost-optimized Cloud →Hetzner Backups and Snapshots overview →