Hetzner vs Vultr: EU-centric value vs worldwide footprint

Cheap cores in Europe, or a server near every customer?

There is a particular kind of engineer who keeps two browser tabs open when planning a new environment: one on the Hetzner Cloud console, one on the Vultr customer portal. The instinct is sound, because these two providers answer the same brief from opposite ends. Hetzner concentrates enormous amounts of compute into a small number of European sites and a handful of overseas ones, then charges as little as its own data centre economics allow. Vultr scatters smaller sites across six continents and wraps them in a full set of cloud primitives.

Neither approach is a compromise. Hetzner owns and builds much of what it runs, from the buildings in Falkenstein and Nuremberg to the racks inside them, and that vertical integration is what funds the value proposition. Vultr, operated by The Constant Company from West Palm Beach, buys presence instead: many locations, each with a compute footprint sized to serve a metropolitan audience, plus managed Kubernetes, managed databases, bare metal and GPU capacity on the same API key.

What follows examines the consequences of those two bets for latency, automation, procurement and growth. Accounts for both platforms are listed on AllCloudShop, on the Hetzner account page and the Vultr account page, and the variants described there explain what each login is set up for.

Platform inventory

The table below maps the pieces of each platform rather than ranking them. Read it as a stock check: what can you build from parts the provider already operates, and what will you have to assemble yourself?

Where the machines actually live

Hetzner's footprint is deliberately concentrated. The bulk of its capacity sits in two German locations and one in Finland, with newer cloud regions in the eastern and western United States and in Singapore. That shape has a direct engineering consequence: if your users are in Europe, round trips are short and the network between your own machines is excellent, because many of them will be in the same building. If your users are in Brazil, Japan or South Africa, you are serving them from a long way away.

Vultr inverts the arithmetic. Its locations are numerous and individually modest, chosen so that a developer can put an instance within a short hop of almost any population centre. The trade is that not every product exists in every city. Managed databases, Kubernetes, bare metal and GPU capacity are concentrated in the larger locations, so a design that assumes a managed Valkey cluster next to every edge instance needs checking against the current availability matrix before it is committed to code.

Storage architecture differs in character too. Hetzner cloud servers include local NVMe capacity with the plan, and Cloud Volumes add network-attached space when the local disk is not enough. Vultr separates the two more aggressively, offering several Block Storage tiers so that a database volume and an archive volume can be provisioned with different characteristics. Anyone weighing local against network disks will find the NVMe storage on cloud VMs article a useful companion.

Both hand out IPv6 by default, though their approaches to attack mitigation differ: Hetzner folds protection into the network, while Vultr offers a dedicated distributed denial of service protection option in selected locations. Hetzner's traffic allowances are famously roomy for European instances, a point explored further in the Cloud Journal piece on bandwidth allowances across providers.

Four decisions that follow from the choice

How far your architecture can spread. A Vultr deployment can place read replicas, edge caches and regional API nodes in many cities without leaving one billing account. A Hetzner deployment concentrates instead, which favours designs that keep everything in one region and put a content delivery network in front rather than distributing the application itself.

How much you operate yourself. Vultr will run your Kubernetes control plane and your PostgreSQL primary. Hetzner will not run either. On Hetzner you install the database, configure replication, own the backups and either build a cluster from its cloud controller manager and CSI driver or bring a distribution such as k3s. The managed versus self-hosted database discussion sets out what that really costs in engineer hours.

What a bad month looks like. Hetzner's billing is metered but its plan list is short, so an environment is easy to reason about. Vultr's catalogue is broad enough that costs can accumulate in places nobody is watching: an orphaned block volume, a load balancer left behind by a deleted stack, a snapshot series with no retention policy.

Which hardware you can reach. Vultr offers GPU instances and bare metal through the ordinary console. Hetzner offers dedicated hardware too, but through the separate Robot system with its own ordering flow and its own provisioning cadence, and it does not sell GPU capacity at all. For machine learning work that distinction is decisive.

Day to day in the console and the terminal

Hetzner Cloud groups everything into projects, and a project is a hard boundary: its own API token, its own private networks, its own firewalls. The hcloud command line tool mirrors the console almost exactly, and the Terraform provider is mature enough that most teams never open the web interface after the first week. Server creation accepts cloud-init user data, so a machine can arrive with packages installed, users created and a firewall already configured.

Vultr's console is organised around accounts and teams rather than projects, with tags used to group resources. Startup scripts play the role of user data, the Marketplace supplies preconfigured application images, and custom ISO uploads let you install an operating system the image list does not carry. The vultr-cli tool and Terraform provider cover the same ground as the API, which is documented at the Vultr API reference.

• Both accept SSH keys at creation time and support snapshots, custom images and scheduled backups.
• Hetzner exposes placement groups so that instances in a high availability pair land on different physical hosts.
• Vultr exposes a container registry and managed Kubernetes, which keeps a container pipeline inside one provider.
• Both publish official Terraform providers, so an infrastructure-as-code team can model either platform declaratively.

Documentation depth is comparable, and both maintain current references at the Hetzner Cloud documentation and the Vultr documentation. Where they differ is community volume: Vultr's marketplace and tutorials lean toward application recipes, while Hetzner's audience tends to publish about squeezing more out of a given machine.

Procurement, jurisdiction and support

For a European company, Hetzner is an unusually simple purchase. The contracting entity is German, invoices arrive in euros, and the data protection conversation is short because both the company and most of its capacity sit inside the European Union. Businesses that must answer questions about where records are processed will find that an easier story to tell than one involving a United States parent with European facilities.

Vultr contracts from the United States while operating European sites, which is the same structure most global clouds use and is perfectly workable, but it does introduce the transfer questions that the data residency and sovereignty article walks through. In exchange, a company selling into several continents gets one vendor, one invoice and one API for every market.

Support is ticket-first on both sides. Hetzner's responses come from engineers and tend to be terse and technically accurate, with the caveat that the company does not market a premium support tier in the way an enterprise buyer might expect. Vultr sells escalated support plans above its standard queue. Neither provider manages your operating system, patches your packages or watches your application, so the responsibilities described in the shared responsibility model apply in full on both.

What each provider does unusually well

Hetzner

Value per core and per gigabyte is the obvious answer, but the deeper strength is consistency. Because Hetzner designs its own facilities and buys hardware in volume for a narrow plan list, the experience of a dedicated vCPU instance in Falkenstein is highly predictable, and the network between instances in the same location is fast enough that people build storage clusters across it. The Arm64 line gives teams a genuine efficiency lever for workloads that compile cleanly on that architecture.

The second strength is the bridge to physical hardware. A workload that outgrows virtualisation can move to a Dedicated Root Server, or to an auction machine, without changing providers or leaving the same network neighbourhood. The dedicated servers versus cloud VMs piece explains when that jump is worth making.

Vultr

Reach plus completeness is the combination nobody else in this tier quite matches. Very few providers let you create an instance in a city most clouds ignore, attach block storage, put it behind a load balancer, connect it to a managed database and run the whole thing inside a VPC using one credential. For teams serving a genuinely global audience from a small engineering group, that breadth removes a lot of vendor management.

Vultr also covers the hardware extremes. Bare metal for workloads that dislike a hypervisor and GPU instances for inference or fine-tuning mean a project does not have to leave when its requirements change shape, a path sketched in the GPU cloud instances explainer.

Honest constraints on both sides

Hetzner

The absent managed layer is the headline. No managed Kubernetes, no managed databases, no platform-as-a-service, no serverless option and no GPUs mean that everything above the operating system is your project. Account provisioning is also more deliberate than at a purely self-service cloud, and resource limits on a new account start conservatively and rise as the account establishes a history. Outside Europe the location list is thin, so a Latin American or African audience is served at a distance.

Vultr

Breadth costs uniformity. Product availability varies by location, which complicates any design that assumes feature parity everywhere, and the smaller sites are exactly where the gaps appear. Instance plans are sized for cloud usage rather than for generosity, so memory-hungry or disk-hungry workloads pay for attached storage. Standard support is a ticket queue, and the more capable support experience is a paid upgrade rather than the default.

Making the call

Hetzner is the right answer when your audience is European or your workload is compute-bound and long-lived, when your team is comfortable operating databases and clusters, and when the budget has to stretch further than a conventional cloud allows. Self-hosted platforms, continuous integration fleets, media processing and research computing all sit naturally here. The Hetzner account listing sets out the available options.

Vultr is the right answer when geography is a product requirement, when you want a managed control plane or managed database without moving to a hyperscaler, or when GPUs and bare metal belong in the same account as your web tier. Software companies with customers on several continents get the most from it, and the Vultr account listing is where to start.

Adjacent reading helps if the decision is still open. Hetzner against Linode puts the same value argument next to a mature managed platform, UpCloud against Hetzner introduces a storage-performance specialist, and Contabo against Vultr looks at the bundled alternative to metered compute.

Questions readers ask