Migration Guides

Migrating a Hetzner Cloud Stack to AnubizHost

Hetzner Cloud's strength is also its lock-in: Cloud Networks, Volumes, Floating IPs, and Load Balancers all assume you'll keep paying. This guide shows how to extract the entire stack and rebuild it on AnubizHost offshore infrastructure with crypto billing and no KYC.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

Export the Hetzner Cloud Topology

Use the hcloud CLI to dump your topology: hcloud server list -o json > servers.json, hcloud network list -o json > networks.json, hcloud load-balancer list -o json > lbs.json. This gives you a precise inventory to recreate on AnubizHost.

For each server, note the type (CX21, CCX13, etc.), datacenter, image, attached volumes, and any user-data scripts. Volumes need to be unmounted and copied as filesystem trees (not as raw block devices) for cross-provider portability.

Recreate Topology on AnubizHost

For each Hetzner server, order an equivalent AnubizHost VPS. Cloud Networks (private RFC1918 subnets) can be recreated using AnubizHost's private network feature or by setting up a WireGuard mesh between your nodes - WireGuard scales to dozens of nodes with minimal overhead and works across datacenters.

Load Balancers are reproduced with HAProxy or nginx on a small dedicated VPS. Floating IPs are not portable; you adjust DNS to point at the new IPs and update any IP-dependent code.

Sync Application Data

For each application server, rsync filesystem data as in our Hetzner VPS migration guide. For databases, use pg_dump or mysqldump as appropriate. For object storage (Hetzner Storage Box), use rclone to copy to an AnubizHost storage VPS or to S3-compatible offshore storage.

For Hetzner Volumes, mount them on the source, then rsync the contents to the equivalent location on the target. Most volumes are just ext4/xfs filesystems with no Hetzner-specific format.

Cut Over DNS, SSL, and Internal Service Discovery

Lower TTL 24 hours ahead, flip records at the cutover moment, re-issue Let's Encrypt on each public endpoint. If you use service discovery (Consul, etcd, Kubernetes DNS), update the addresses inside the cluster. WireGuard tunnels established earlier mean internal traffic continues to flow regardless of public DNS state.

Decommission Hetzner Cloud resources gradually: servers first (after 7 days), then volumes (after backups verified), then the cloud project itself. Each resource is billed per hour, so granular cleanup matters.

Why Move the Whole Stack

Partial migration leaves operational dependencies in the country you're trying to leave. Moving the whole stack to AnubizHost gives you uniform offshore jurisdiction, single-vendor billing in crypto, and consistent privacy posture. Related reading: offshore VPS, Hetzner VPS migration, DigitalOcean Droplet migration.

Why Anubiz Host

100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Anubiz Chat AI

Online
Migrate Hetzner Cloud to AnubizHost - Full Stack Guide