Hetzner is one of the few providers where the same account gives you both hourly cloud servers and monthly dedicated root servers, which turns “cloud or dedicated” from a vendor choice into a per-component design decision. This article gives a method for making that decision on Hetzner specifically: what each layer is, where each wins, and how to combine them. It assumes you already understand the limit-based options on the Buy Hetzner Account page, which are explained in Hetzner server limits explained.
The two layers
| Cloud servers | Dedicated root servers | |
|---|---|---|
| What you get | Virtual machine on shared or dedicated vCPU, or ARM; local NVMe | An entire physical machine: all cores, memory and disks |
| Billing | Hourly with a monthly cap | Fixed monthly |
| Provisioning | Minutes, via console or API | Ordered; auction servers appear at lower rates |
| Scaling | Resize, snapshot, clone, add volumes | Move to a bigger machine |
| Extras | Private networks, floating IPs, firewalls, load balancers, snapshots | Custom OS or hypervisor, exclusive I/O |
What cloud servers are good at
Cloud servers are the elastic layer. Shared-vCPU instances suit development, staging and tolerant services; dedicated-vCPU instances allocate exclusive CPU capacity for production or CPU-bound work; ARM instances give efficient price-to-performance for compatible Linux workloads. Because billing is hourly with a monthly ceiling, a server that runs all month costs its cap and a server that runs for an afternoon costs an afternoon.
The surrounding features are what make it a platform rather than a VPS: private networks keep inter-server traffic off the public internet, floating IPs move between servers during maintenance or failover, snapshots capture state for cloning or recovery, and volumes grow storage without rebuilding. All of it is scriptable through the API, CLI and Terraform provider.
What dedicated servers are good at
A dedicated root server is exclusive hardware. Nobody shares your cores, your memory bus or your disks, so I/O and CPU behaviour are consistent hour to hour. That consistency is the point: databases with heavy write loads, search clusters, build farms and long-running data processing all behave better without neighbours. You can install any operating system or a hypervisor and carve the machine up yourself.
Auction or previously used servers sometimes appear at lower monthly rates, which gives cost-conscious teams access to substantial resources. The cost of that value is rigidity: a dedicated server bills monthly whether busy or idle, and moving to a bigger one is a migration, not a resize.
A decision method by component
- List each component of the stack: web, API, worker, cache, database, search, CI, monitoring, staging.
- Mark its utilisation pattern. Bursty or variable means cloud. Steady and high means a dedicated candidate.
- Mark its sensitivity to neighbours. If you measure tail latency or disk throughput and it matters, dedicated moves up the list.
- Mark its need for elasticity. Anything you scale out, replace often or run only sometimes stays on cloud.
- Apply the tie-breaker: when in doubt, start on cloud, measure for a month, and move only what the graphs justify.
For most small production stacks the result is one dedicated server for the database, with everything else on cloud servers. The general right-sizing method behind step two is in choosing instance sizes.
Combining the layers
The layers connect over private networking, so a dedicated database can serve cloud web servers without traffic crossing the public internet. Keep the elastic tier stateless so it can be resized, snapshotted and replaced freely, and treat the dedicated server as the stateful core with its own backup regime. Because a dedicated machine has no snapshot button, backups there must be explicit: scheduled dumps or replication to a second location, tested with a real restore, following the backup and recovery baseline.
Regions and the self-managed model
Data centres are in Germany and Finland with additional presence in the United States and Singapore, so European latency and residency are the natural fit, with other regions available when needed. Both layers are self-managed: you receive root access and own patching, security configuration, monitoring and backups. Teams without that operational capacity should weigh a managed alternative, and the trade against a provider with more managed services is discussed in Scaleway vs Hetzner accounts. Recurring questions are collected in the Hetzner section of the Cloud FAQ.
