Hetzner Cloud Servers and Projects: Getting Oriented

Two Hetzner products, and people mix them up

Hetzner Online has been selling hosting from Germany for a long time, and the catalog reflects that history. Newcomers often arrive expecting one product and find two, so it is worth separating them before anything else.

Hetzner Cloud is the modern virtualised platform: cloud servers billed by the hour, an API, an official CLI, private networks, volumes, firewalls and load balancers. It is the product this guide is about, and it lives in its own console.

Alongside it sit the dedicated root servers, managed through a separate interface with its own ordering process, including the well-known auction listings for previously used hardware. Dedicated machines are physically yours for the term, which suits sustained heavy workloads but does not give you the elasticity of the cloud product. The general trade is covered in dedicated servers versus cloud VMs.

There are also adjacent services such as Storage Boxes and the DNS console. They are useful, but they are not part of the cloud API, so treat them as separate products rather than as features of a cloud server.

Projects are the real boundary

Hetzner Cloud organises everything into projects, and the project is a firmer boundary than most people assume from a platform this simple. Servers, volumes, private networks, firewalls, load balancers, snapshots, SSH keys and API tokens all belong to exactly one project.

Two consequences shape how you use it. An API token is issued per project and can do nothing outside it, which makes projects an effective way to limit what an automation credential can reach. And resources cannot casually reference each other across projects, so a private network in one project cannot attach a server from another.

Because of that, the natural pattern is one project per environment or per client. Production and staging in separate projects means a token leaked from a staging pipeline cannot touch production, and it also gives you a clean per-project view of what exists. Resource limits are tracked per project as well, so a runaway script in one does not exhaust the ceiling in another.

Billing does not follow the project boundary. Usage from every project consolidates onto the single customer account that owns them, which is convenient for accounting and worth remembering when you are tempted to treat a project as a spending limit. It is not one.

Decoding the server type codes

Hetzner server types are short codes such as cx22, cpx31, cax21 and ccx33. The letters identify the line and the processor architecture; the digits indicate the size within it.

The Arm line is the one worth a second look. Arm64 instances are frequently good value per unit of work, and the modern container ecosystem makes multi-architecture images routine. The catch is any dependency that ships only an x86 binary, so confirm your stack before committing a production service to it.

As on every shared-CPU platform, the shared lines are subject to fair-use expectations. If a service holds its cores at full tilt for hours, the dedicated CCX line is the right home for it.

Locations, network zones and what they imply

Hetzner Cloud runs in a small, deliberately chosen set of locations: Falkenstein, Nuremberg and Helsinki in Europe, Ashburn and Hillsboro in the United States, and Singapore. Each location belongs to a network zone, and that grouping is the detail that actually affects design.

Private networks and floating IP addresses operate within a network zone. Servers in Falkenstein, Nuremberg and Helsinki share the central European zone, so they can join the same private network despite being in different cities. A server in Ashburn cannot join that network, because it sits in a different zone.

Volumes are stricter still: block storage attaches only to a server in the same location, never across locations. Plan data placement accordingly, because a volume is not a portable object.

Notice what is absent. There are no customer-visible availability zones, so resilience is a matter of running in two locations rather than two zones, with the trade-offs set out in picking a cloud location.

The building blocks around a server

Primary IPs are addresses modelled as their own resource. Because they exist independently, an address can survive the deletion of the server that used it, which matters when a DNS record or an allow-list somewhere else refers to it. IPv4 and IPv6 primary addresses are managed separately, and a server can run with IPv6 only if your stack supports it.

Floating IPs are movable addresses routable within a network zone. Reassigning one between servers is the classic lightweight failover mechanism, described in floating IPs and failover on developer clouds.

Private networks give servers an internal interface with private addressing, keeping internal traffic off the public internet. This is where database connections and service-to-service calls belong, as argued in private networking between cloud servers.

Firewalls are stateful and applied outside the server, so rules take effect before packets reach the operating system. They can be attached to servers by label selector, which means a newly created machine carrying the right label picks up the correct rules automatically.

Snapshots and backups cover different needs. Snapshots are manual images you create and keep, usable as templates for new servers. Backups are an automated per-server option that keeps a rolling set of restore points. Both consume storage that is billed, so set a retention habit.

Placement groups ask Hetzner to spread selected servers across different physical hosts, which is the only host-level anti-affinity control the platform exposes. Use one for any pair of machines that must not fail together.

Getting comfortable with hcloud

The official CLI is hcloud, and it is unusually pleasant to use. It works against a context, which is simply a stored API token for one project, so switching between environments is a single command:

hcloud context create production

hcloud server-type list

hcloud location list

Creating a server takes one line, and passing a cloud-init file keeps first-boot configuration reproducible:

hcloud server create --name app-01 --type cax21 --image ubuntu-24.04 --location hel1 --ssh-key laptop --network internal --user-data-from-file ./cloud-config.yaml

Everyday follow-ups include hcloud server list -o columns=id,name,status,ipv4 for an inventory, hcloud firewall apply-to-resource for attaching rules, and hcloud server create-image for turning a configured machine into a snapshot. Hetzner keeps the full reference, including the API, in its cloud documentation.

Questions about Hetzner Cloud