# Migrate from Hetzner Cloud Servers to Quake AI Compute Source: https://docs.quake.ai/docs/compute/migration/migrate-from-hetzner-servers Markdown: https://docs.quake.ai/docs/compute/migration/migrate-from-hetzner-servers.md --- # Migrate from Hetzner Cloud servers to Quake AI compute This guide covers migrating compute workloads from Hetzner Cloud to Quake AI (OpenStack Nova). Hetzner does not support image export, so the recommended approach is rebuild and rsync. Hetzner users typically provision from standard images with configuration management tooling, making rebuild the natural migration path. ## Service mapping ## Prerequisites - A Quake AI account with [application credentials](/docs/tools/generate-app-credentials) - The [OpenStack CLI](/docs/tools/install-openstack-client) installed and configured - SSH access to your Hetzner Cloud Servers - An SSH key pair imported to Quake AI (`openstack keypair create --public-key`) ## Image portability Hetzner Cloud does not provide an API or UI for downloading server snapshots or images. A `dd`-based workaround exists using rescue mode, but it produces full-disk images regardless of data usage and requires server downtime. **Recommendation:** Do not attempt image export. Hetzner servers are typically provisioned from standard images with config management: rebuild is the right approach. ## Flavor mapping Hetzner uses three CPU families: CX/CPX (shared, ~2:1 ratio), and CCX (dedicated AMD, 4:1 ratio). Shared Hetzner servers map to Quake AI s1a at smaller sizes, but step up to m2a for larger configurations since s1a caps at 8 vCPU / 8 GiB. Dedicated CCX maps cleanly to m2a. | Hetzner Server | vCPUs | RAM (GiB) | Quake AI Flavor | vCPUs | RAM (GiB) | Notes | |---|---|---|---|---|---|---| | CX22 (Shared Intel) | 2 | 4 | s1a.medium | 2 | 4 | Both shared CPU | | CX32 (Shared Intel) | 4 | 8 | s1a.large | 4 | 8 | Both shared CPU | | CX42 (Shared Intel) | 8 | 16 | m2a.2xlarge | 8 | 32 | Quake AI has more RAM at this tier | | CX52 (Shared Intel) | 16 | 32 | m2a.4xlarge | 16 | 64 | Quake AI has more RAM at this tier | | CPX21 (Shared AMD, pre-2024) | 3 | 4 | s1a.medium | 2 | 4 | Approximate, fewer vCPUs on Quake AI | | CPX31 (Shared AMD, pre-2024) | 4 | 8 | s1a.large | 4 | 8 | Close match | | CPX41 (Shared AMD, pre-2024) | 8 | 16 | m2a.2xlarge | 8 | 32 | Quake AI has more RAM | | CCX13 (Dedicated AMD) | 2 | 8 | m2a.large | 2 | 8 | Exact ratio match | | CCX23 (Dedicated AMD) | 4 | 16 | m2a.xlarge | 4 | 16 | Exact ratio match | | CCX33 (Dedicated AMD) | 8 | 32 | m2a.2xlarge | 8 | 32 | Exact ratio match | | CCX43 (Dedicated AMD) | 16 | 64 | m2a.4xlarge | 16 | 64 | Exact ratio match | | CCX53 (Dedicated AMD) | 32 | 128 | m2a.8xlarge | 32 | 128 | Exact ratio match | | CCX63 (Dedicated AMD) | 48 | 192 | m2a.16xlarge | 64 | 256 | No exact match; m2a.16xlarge is larger. If you do not need 48 vCPUs, consider m2a.8xlarge (32 vCPU / 128 GiB). | Hetzner relaunched its shared plans in June 2024 under new names such as CX22 and CPX22. The CPX rows above reference the pre-2024 series (CPX21 at 3 vCPU, CPX31 at 4 vCPU); the current CPX22 has 2 vCPU. Confirm the vCPU count for your server in the Hetzner Cloud Console before you map it. Hetzner has no memory-optimized line, so there is no direct equivalent of Quake AI's r2a family. If your workloads are memory-intensive, Quake AI's r2a flavors offer 8 GiB RAM per vCPU, an upgrade from Hetzner's maximum 4:1 ratio. ## Migration approach ### Option 1: Containerized workloads (recommended) If your Hetzner servers run Docker containers, migrate images and redeploy. 1. Push images to a portable registry: ```bash docker push registry.example.com/MY_APP:latest ``` 2. Provision a Nova instance on Quake AI: ```bash openstack server create \ --image "Ubuntu-22.04" \ --flavor m2a.xlarge \ --network MY_NETWORK \ --key-name MY_KEY \ --security-group MY_SECURITY_GROUP \ MY_INSTANCE_NAME ``` 3. Install Docker and deploy: ```bash ssh ubuntu@FLOATING_IP sudo apt update && sudo apt install -y docker.io sudo docker pull registry.example.com/MY_APP:latest sudo docker run -d -p 80:8080 registry.example.com/MY_APP:latest ``` ### Option 2: Rebuild and rsync (non-containerized) 1. Provision a Nova instance with the same base OS: ```bash openstack server create \ --image "Ubuntu-22.04" \ --flavor m2a.xlarge \ --network MY_NETWORK \ --key-name MY_KEY \ --security-group MY_SECURITY_GROUP \ MY_INSTANCE_NAME ``` 2. Assign a floating IP: ```bash openstack floating ip create PublicStatic openstack server add floating ip MY_INSTANCE_NAME FLOATING_IP ``` 3. Install your application stack. Replay Ansible playbooks, cloud-init configs, or provisioning scripts. 4. Transfer application data: ```bash rsync -avz --progress -e "ssh -i ~/.ssh/MY_KEY" \ root@HETZNER_IP:/path/to/app/data \ ubuntu@FLOATING_IP:/path/to/app/data ``` 5. Migrate databases: ```bash pg_dump -h HETZNER_IP -U MY_USER MY_DATABASE | \ psql -h FLOATING_IP -U MY_USER MY_DATABASE ``` Hetzner includes monthly traffic with every server plan, but the allowance depends on location. EU-hosted servers include 20 TB (CX/CPX) or 20-60 TB (CCX). US and Singapore locations include less, between 0.5 TB and 8 TB depending on plan. This allowance covers migration data transfer. These figures reflect post-April 2026 pricing. ## Key pair and security setup ### Import your SSH key ```bash openstack keypair create --public-key ~/.ssh/id_ed25519.pub my-key ``` ### Translate Hetzner Firewalls to security groups Hetzner Firewalls apply at the network level or via label selectors. Neutron security groups apply per instance (per port). Translate your rules: ```bash openstack security group create web-tier openstack security group rule create web-tier \ --protocol tcp --dst-port 22 --remote-ip 0.0.0.0/0 openstack security group rule create web-tier \ --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0 openstack security group rule create web-tier \ --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0 ``` ## Validation checklist After migrating each workload, verify: - [ ] Application responds correctly on the Quake AI instance - [ ] All expected ports are accessible through the security group - [ ] Data integrity: compare file checksums or row counts between source and destination - [ ] Database connectivity from the application to any migrated databases - [ ] DNS records updated to point to the new Quake AI floating IP - [ ] Monitoring in place (self-managed Prometheus + Grafana) - [ ] cloud-init or configuration management runs cleanly on the new instance - [ ] SSL/TLS certificates installed and renewed ## Provider-specific gotchas | Topic | Detail | |---|---| | Billing for stopped servers | Hetzner charges for powered-off servers; billing covers the reserved capacity regardless of power state. Quake AI similarly bills for provisioned resources while instances are stopped. Keep both source and target running only as long as needed during validation, then decommission the source. | | Price increase (April 2026) | Hetzner announced pricing changes effective 01.04.2026 affecting both existing products and new orders. Community reports describe increases of roughly 30-50% for cloud servers; Hetzner's official statement does not give a figure. This may be a migration motivator. Verify current pricing at [hetzner.com/cloud](https://www.hetzner.com/cloud/). | | ARM instances (CAX) | No ARM equivalent on Quake AI. Workloads on CAX servers must be rebuilt for x86 (AMD EPYC). Check for architecture-specific dependencies in your binaries and containers. | | Hetzner Robot | This guide covers Hetzner Cloud only. Dedicated server migration (Robot) involves IPMI/KVM access and is a different procedure. | | Snapshots not portable | Hetzner snapshots are internal-only. Treat them as rollback targets on the source side, not migration artifacts. | ## See also - [Migrating from Hetzner Cloud to Quake AI](/resources/migration/from-hetzner): full cross-service migration hub - [Coming from Hetzner Cloud](/resources/migration/coming-from-hetzner): concept translation reference - [Create an instance](/docs/compute/how-to/create-instance): full instance provisioning workflow - [Compute migration guides](/docs/compute/migration): all provider guides