# Migrating from Hetzner Cloud to Quake AI

Source: https://docs.quake.ai/docs/platform/migration/from-hetzner
Markdown: https://docs.quake.ai/docs/platform/migration/from-hetzner.md

---

# Migrating from Hetzner Cloud to Quake AI

This guide walks you through moving workloads from Hetzner Cloud to Quake AI, service by service. Hetzner has a well-developed cross-service migration path: both the IaC and object storage guides already exist. Networking is the biggest conceptual shift.

If you have not reviewed the concept differences, start with [Coming from Hetzner Cloud](/docs/platform/migration/coming-from-hetzner) for the full mapping table.

## Before you migrate

- Review the [concept translation guide](/docs/platform/migration/coming-from-hetzner) for how Hetzner services map to Quake AI
- Inventory your Hetzner resources: Cloud Servers, Volumes, Object Storage buckets, Private Networks, Firewalls, Load Balancers, and Floating IPs
- Identify Managed Database or DNS dependencies that need self-managed alternatives

## Migration phases

### 1. Evaluate and plan

Inventory your Hetzner resources: Cloud Servers, Volumes, Object Storage buckets, Private Networks, Firewalls, Load Balancers. Networking is the biggest shift: Hetzner abstracts subnets and routing, while Quake AI exposes them as separate Neutron objects you configure explicitly.

### 2. Account setup

Create your Quake AI project, generate application credentials, and install the OpenStack CLI.

- [Quickstart](/docs/quickstart)
- [Generate application credentials](/docs/platform/access/generate-app-credentials)
- [Access & Credentials](/docs/platform/access/) for the OpenStack CLI

### 3. Object storage

Hetzner Object Storage is S3-compatible (Ceph-based). Migration to Quake AI's Swift endpoint requires an endpoint and credential change. Use rclone for the transfer.

**What to watch for:** Hetzner Object Storage supports versioning and object locking. If you have versioning-enabled buckets, plan to re-enable versioning on Swift after migration. Swift's S3 gateway handles versioning through the S3 API; verify the behavior matches your workflow.

For the full cutover procedure, see [Migrate from Hetzner Object Storage](/docs/object/migration/migrate-from-hetzner).

### 4. Infrastructure as code (hcloud → OpenTofu)

This is Hetzner's strongest migration path. The `hcloud` Terraform provider maps directly to the `openstack` provider. The existing guide covers the full resource-by-resource rewrite.

**Key resource mappings:**

| Hetzner (Terraform) | Quake AI (OpenTofu) |
|---|---|
| `hcloud_server` | `openstack_compute_instance_v2` |
| `hcloud_volume` | `openstack_blockstorage_volume_v3` |
| `hcloud_firewall` | `openstack_networking_secgroup_v2` |
| `hcloud_network` + `hcloud_network_subnet` | `openstack_networking_network_v2` + `openstack_networking_subnet_v2` |
| `hcloud_floating_ip` | `openstack_networking_floatingip_v2` |
| `hcloud_load_balancer` | Edge reverse proxy, WAF, or API gateway on Nova with a Neutron floating IP |

For the full translation, see [Migrate from Hetzner Terraform](/docs/automation/migration/from-hetzner).

### 5. Compute (Cloud Servers → Nova)

Hetzner Cloud Servers support snapshots and snapshot transfer between projects, but cross-platform image compatibility (drivers, cloud-init configuration, kernel choices) is often imperfect. The practical migration approach is to provision new instances and migrate application data:

**Containerized applications:** Migrate container images and deploy on Nova instances. Hetzner does not offer a managed Kubernetes service, so Kubernetes on Hetzner Cloud Servers runs as self-managed clusters (via RKE2, k3s, or similar). Self-managed K8s on Nova (via RKE2 or k3s) is the recommended path; see [Migrate from Hetzner K8s to Kubernetes on Quake AI](/docs/kubernetes/migration/migrate-from-hetzner-k8s) for the full guide.

**Non-containerized applications:** Provision a new Nova instance with the same base image, install your application stack, and rsync data from the Hetzner server.

**Billing note:** Hetzner charges for powered-off servers at the same rate as running ones (hourly billing to a monthly cap). Quake AI uses fixed monthly plan pricing; stopped instances continue to count against provisioned plan capacity. Confirm your plan's billing model before keeping parallel environments running during validation.

See [Create an instance](/docs/compute/how-to/create-instance) for the full workflow. For the full guide, see [Migrate from Hetzner Cloud Servers to Quake AI Compute](/docs/compute/migration/migrate-from-hetzner-servers).

### 6. Networking (private networks → Neutron)

Build your Hetzner private network topology from explicit Neutron objects:

1. **Create a network**: the L2 broadcast domain
2. **Create a subnet**: attach an IP range and DHCP configuration
3. **Create a router**: connect subnets to each other and to the external network

**Hetzner Firewall → Security Groups:** Hetzner applies firewall rules at the network level or via label selectors. Quake AI applies security groups per instance (per port). Re-create your firewall rules as security group rules with the same protocol, port, and source CIDR.

**Floating IPs → Floating IPs:** These map 1:1 between Hetzner and Quake AI. Allocate from the external pool and associate with your instance's port. Update DNS records to point to the new addresses.

**CDN:** If you need a CDN, plan for an external CDN layer such as Cloudflare or Fastly. Neither Hetzner nor Quake AI provides one.

Key how-to guides:
- [Create a network](/docs/network/how-to/create-network)
- [Create a security group](/docs/network/how-to/create-security-group)
- [Allocate floating IPs](/docs/network/how-to/allocate-floating-ips)

For topology diagrams, security rule translation, and public-address migration, see [Migrate from Hetzner Cloud Networks to Quake AI](/docs/network/migration/migrate-from-hetzner-networks). Translate forwarding rules and backends into an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) or [API gateway](/build/iac-templates/api-gateway).

### 7. Validation and cutover

Before decommissioning Hetzner resources:

- [ ] Verify that applications respond on Quake AI instances with the expected behavior
- [ ] Confirm object storage data integrity between Hetzner and Swift
- [ ] Update DNS records to point to Quake AI floating IPs; use low TTLs during the transition
- [ ] Validate security group rules match your Hetzner Firewall configuration
- [ ] Confirm monitoring and alerting are in place (self-managed Prometheus, Grafana, or equivalent)
- [ ] Run IaC plans (`tofu plan`) to verify infrastructure state matches expectations

## Service mapping reference

The table below shows how Hetzner Cloud services map to Quake AI equivalents, with confidence ratings and documented divergences. The `<ProviderMappings>` component reads from the platform knowledge graph.

<ProviderMappings provider="hetzner" />

## Self-managed services and deployment patterns

| Hetzner service | Status on Quake AI | Alternative |
|---|---|---|
| Managed Database | Not available | Self-managed on VMs with [automation templates](/build/iac-templates) |
| DNS (Hetzner DNS) | Not available | External DNS provider (Cloudflare or similar) |

## Next steps

- [Coming from Hetzner Cloud](/docs/platform/migration/coming-from-hetzner): concept translation reference
- [Migrate from Hetzner Terraform](/docs/automation/migration/from-hetzner)
- [Migrate from Hetzner Object Storage](/docs/object/migration/migrate-from-hetzner)
- [All migration guides](/docs/platform/migration)