Migrate from Hetzner Cloud Networks to Quake AI

Hetzner Cloud's private networking, firewall, and floating IP models map closely to Quake AI's OpenStack Neutron. The primary structural addition on Quake AI is the explicit router object: Hetzner handles internet routing implicitly, while Neutron requires you to create a router and attach your subnet to it. Neutron's security group references (--remote-group) also provide a more precise alternative to Hetzner's CIDR-based inter-tier rules.

Service mapping#

Prerequisites#

• A Quake AI account with application credentials
• The OpenStack CLI installed and configured
• An inventory of your Hetzner resources: Networks, Subnets, Cloud Firewalls, Floating IPs, Load Balancers, and DNS zones
• An SSH key pair imported to Quake AI (openstack keypair create --public-key)

Topology mapping#

The mapping is close between Hetzner and Neutron. The main structural difference is the explicit router object required on Quake AI.

Set up the Neutron equivalent#

openstack network create my-network

openstack subnet create my-subnet \
  --network my-network \
  --subnet-range 10.0.0.0/24 \
  --gateway 10.0.0.1 \
  --dns-nameserver 8.8.8.8

openstack router create my-router
openstack router set my-router --external-gateway PublicStatic
openstack router add subnet my-router my-subnet

On Hetzner, you create a Network and Subnet, then attach servers. On Quake AI, you add the explicit router step. This router handles both outbound SNAT and inbound DNAT (via floating IPs).

Security rule translation#

Hetzner Cloud Firewalls and Neutron security groups share the same fundamental model.

The notable improvement: Hetzner firewalls can only reference source IPs by CIDR. Neutron security groups support --remote-group references, enabling more precise inter-tier rules that follow instances regardless of IP address changes.

3-tier app example#

Hetzner source:

• fw-web: inbound TCP 80/443 from 0.0.0.0/0; inbound TCP 22 from admin CIDR
• fw-app: inbound TCP 8080 from 10.0.0.0/24 (web-tier subnet CIDR)
• fw-db: inbound TCP 5432 from 10.0.0.0/24 (app-tier subnet or specific IPs)

Neutron target (upgraded to security group references):

openstack security group create sg-web
openstack security group rule create sg-web \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0 --ingress
openstack security group rule create sg-web \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0 --ingress
openstack security group rule create sg-web \
  --protocol tcp --dst-port 22 --remote-ip ADMIN_CIDR --ingress

openstack security group create sg-app
openstack security group rule create sg-app \
  --protocol tcp --dst-port 8080 --remote-group sg-web --ingress

openstack security group create sg-db
openstack security group rule create sg-db \
  --protocol tcp --dst-port 5432 --remote-group sg-app --ingress

Load balancer migration#

Replace a Hetzner Load Balancer with a reverse proxy such as HAProxy, Nginx, Caddy, Traefik, or Envoy. Assign a floating IP to the proxy instance and route requests to application instances over a private network.

Configure forwarding, health checks, sticky sessions, redirects, and Proxy Protocol in the proxy. Use Certbot or Caddy for certificate issuance and renewal. Put an external CDN or WAF in front of the proxy when you need an edge service.

Floating IP setup#

Hetzner Floating IPs are the closest conceptual match to Neutron Floating IPs of all five providers.

The key implementation difference: Hetzner Floating IPs require manual OS-level configuration (adding the IP as an alias on the network interface) and the config does not survive reboot without persistent setup. Neutron Floating IPs work via DNAT on the router. The instance OS sees only its private IP; no OS configuration is needed.

openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE FLOATING_IP_ADDRESS

DNS cutover#

Hetzner provides a managed DNS console. Migrate your zones to an external provider.

1. Export zone file: From Hetzner DNS Console, export the zone as a BIND-format zone file.
2. Clean up TTL mismatches: Hetzner DNS requires that records with the same name and type have identical TTLs. Resolve any inconsistencies before exporting.
3. Lower TTLs: Set all records to 300 seconds; wait for the current TTL period to expire.
4. Import at new provider: Upload the zone file or use Terraform with the DNS provider.
5. Validate: dig @NEW_NAMESERVER example.com A
6. Update registrar NS records.
7. Monitor for 48 hours and restore TTLs after successful cutover.

Validation checklist#

• Neutron network, subnet, and router are operational (router is the key addition vs. Hetzner)
• Security group rules match your Cloud Firewall rules
• Label-based firewall groups are replaced by security group assignments on the correct ports
• CIDR-based inter-tier rules have been upgraded to security group references where appropriate
• Floating IPs are associated with the correct instance ports (no OS-level config needed)
• Reverse proxy health checks pass for application backends
• TLS renewal automation is in place (certbot or cert-manager)
• DNS records resolve to the proxy floating IP or external edge hostname
• Applications respond correctly through the full network path

Provider-specific gotchas#

See also#

• Migrating from Hetzner Cloud to Quake AI: full cross-service migration hub
• Migrate from Hetzner Cloud Servers: compute workload migration
• Network migration guides: all provider guides
• Create a router: the key Neutron object Hetzner does not have