Blog ·
CloudPanel on Hetzner Cloud: install it, then sell on it
Installing CloudPanel on a Hetzner Cloud server is a ten-minute job. Selling hosting on it is three layers, and only one of them is the panel.
By Provibr
"CloudPanel on Hetzner" is two different questions wearing one search box. The first is how to get the panel running on a Hetzner Cloud server, which is a documented ten-minute job with an installer that knows Hetzner by name. The second is what you have to build on top before that server is a hosting product you can charge for, and that one is three layers deep, with the panel being only the middle one.
This page answers both, and it is honest about which parts we measured ourselves and which we read from the vendors.
The install is genuinely the easy part
CloudPanel publishes a per-provider installer, and Hetzner Cloud is one of the providers it names.
CloudPanel's stated requirements are at least 1 CPU core, 2 GB of RAM and 10 GB of disk, on x86 or ARM64, running Ubuntu 26.04, 24.04 or 22.04, or Debian 13, 12 or 11. Hetzner Cloud is listed among the providers with dedicated installation instructions, alongside AWS, DigitalOcean, Google Compute Engine, Azure, Oracle Cloud and Vultr.
CloudPanel's Hetzner Cloud page recommends at least 1 vCPU with 2 GB of memory and notes that the CPX line was fastest for web applications in their testing. The installer is fetched from installer.cloudpanel.io, verified against a published SHA-256 checksum, and run with
CLOUD=hetznerand aDB_ENGINEof your choice; the panel then answers on port 8443, and the page advises opening that port only for your own IP address using Hetzner's firewall.
Two notes on running that. Read the checksum off CloudPanel's own page at the moment you install rather than from any article, including this one. It changes with the script, and a stale checksum either fails loudly or, worse, gets pasted past. And the firewall advice is the part people skip: port 8443 is a login form, on a public IP, on a machine that will be holding other people's websites within the hour. Hetzner's cloud firewall is a separate object you attach to the server, so it sits in front of the panel rather than on the machine you are still setting up.
The ARM question resolves itself: CloudPanel supports ARM64, so Hetzner's CAX line is available to you. Whether it is the right choice depends on what your customers run, not on the panel.
Three layers, and each one owns different things
The reason "CloudPanel on Hetzner" gets confusing as a product plan is that people expect one of the two halves to cover more than it does. It helps to write down who owns what.
| Layer | What it owns | What it cannot do |
|---|---|---|
| Hetzner Cloud | The machine: size, image, IP addresses, snapshots, the firewall in front of it, hourly billing | Knows nothing about sites, customers or invoices. Has no idea a machine is oversold |
| CloudPanel | The sites on that one machine: NGINX vhosts, PHP-FPM pools, site users, databases, certificates | No tenants, no packages, no quotas, no suspend verb, no list command |
| You | Customers, plans, invoices, dunning, capacity, who on your team may do what | Nothing the other two layers can take off you |
The gap between rows two and three is where hosting businesses actually get built, and it does not shrink because the machine is a Hetzner one.
What Hetzner Cloud tells you, and what it only appears to tell you
We built the Hetzner Cloud integration against the live API, and two of its fields read like answers and are not.
The catalogue's available flag is a stock meter, not a capability flag. We ordered a type the catalogue marked unavailable and it was delivered four times; we ordered a type it marked available and got a 422. If you filter a plan picker on it, your shelves rearrange themselves while the customer is looking at them. The measurements are in Hetzner's available flag predicts nothing and the conclusion is short: let the order be the thing that can fail.
Rebuilding a server keeps its addresses. We measured this twice, on a machine with an IPv4 address and an IPv6 /64: both were identical before and after. That matters here specifically, because "re-image this box and put the panel back" is a real recovery path for a single-server hosting product, and it does not cost you the DNS.
There is no memory graph and no disk-usage graph. Hetzner does not measure guest memory from outside (type=memory returns 422 invalid_input) and there is no guest agent. What exists is CPU, network and disk I/O. Anything that promises your customer a memory graph on a Hetzner Cloud machine is promising something the provider does not sell.
And there is no suspend. A Hetzner Cloud server that is switched off is billed in full for as long as it exists. Whatever "suspended" means in your product, it cannot mean powered off at this layer without you paying for it.
What CloudPanel does not do when you sell on it
Three gaps, and we have written them up in full elsewhere, so here they are in one line each with the detail one link away.
- There is no suspend.
clpctlhassite:add:*andsite:deleteand nothing in between. Suspension has to be invented, and the sane form is a marked edit to every public server block in the vhost rather than stopping a PHP-FPM pool. A stopped pool produces a 502, which reads to your customer as your server being broken rather than their invoice being overdue. - There are no packages. No disk quota, no bandwidth cap, no per-site limits. The closest thing is a vhost template, which is NGINX configuration and not a limit.
- There is no
site:list. Panel logins can be listed; sites live in the panel's own SQLite database on the host, and reading it is what any serious integration ends up doing.
The reasoning behind each is in how to sell web hosting with CloudPanel, and the three moments where money and machines touch are in automating CloudPanel billing and provisioning.
Two integrations, one panel
Provibr's Hetzner Cloud and CloudPanel integrations are both live, and running them together is the shape this page is really about: the machine and the sites on it, counted in the same capacity and appearing on the same invoice.
On the Hetzner side, existing servers in your project are imported rather than adopted automatically. Import lists every server with its name, size and address, and only the ones you tick get a row. From there: start, stop, graceful shutdown, removal, a rebuild onto another image, a console, and CPU, network and disk-I/O graphs.
On the CloudPanel side, the agent connects over SSH and runs clpctl on the host. Creating, suspending, resuming and removing sites works; suspension is the marked return 403; in every public server block, tested with nginx -t before the reload. There is no usage graph, because CloudPanel measures neither disk nor bandwidth per site and a graph permanently at zero is worse than no graph. And the vhost template is fixed once a site exists, so there is no package change.
The credentials are the part to think hardest about
These two integrations ask for very different things, and both are worth a moment.
The CloudPanel credential is an SSH key that runs clpctl as root on the host. That is not an implementation detail you can route around: the tool writes NGINX configuration, creates Linux users and manages system services. Whatever holds that key holds administrative access to a production web server carrying other people's sites.
The Hetzner credential is a project API token, and its boundary is the project. It has no scope, no expiry date and no IP restriction, so there is nothing narrower to hand out. The practical advice that follows is simple: give the integration a Hetzner project of its own, rather than the one that also holds your production estate.
In Provibr both live in the agent's own encrypted vault inside your network. They are pushed there once and the audit row records the field names, not the values.
Read next
- How to sell VPS hosting with Hetzner Cloud: the pricing and capacity side of reselling a rented cloud.
- Hetzner's available flag predicts nothing: the measurements behind the warning above.
- How to sell web hosting with CloudPanel: the three gaps in full, and what has to exist above the panel.
- CloudPanel setup and Hetzner setup: SSH keys, host-key fingerprints, project tokens and importing what is already there.
CloudPanel's requirements and Hetzner installer instructions were read from cloudpanel.io on 1 September 2026 and are quoted with their sources above. The Hetzner Cloud API behaviour (the available flag, the address-preserving rebuild, the absent memory series) was measured against the live API while building the Provibr integration.
