Coming from Hetzner Cloud
Coming from another cloud?
▸Hetzner·Cloud Servers, Volumes, Object Storage, Private Networks, hcloud_firewall, Load Balancers, Kubernetes
Cloud Servers
- Servers provisioned individually via Hetzner API (hcloud), not OpenStack Nova flavors; fixed instance types like CX11 (1 vCPU, 2GB RAM, 20GB NVMe).
- No flavor customization; choose from predefined shared/dedicated vCPU series.
- Billing hourly with monthly cap per server (e.g., €3.29/mo cap for CX11), charged even when powered off until deleted, unlike typical OpenStack stop-to-pause billing.
- Custom REST API at api.hetzner.cloud/v1/servers instead of OpenStack Nova /v2.1/servers (different auth, payloads, response formats).
Firewalls
- Applies only to Cloud Servers (not Load Balancers), up to 5/server, 500 rules max; free ().
- Default: inbound blocked, outbound allowed; uses label selectors for auto-apply; statefulness not specified but likely stateless given rules ().
- No per-port/per-network granularity like Neutron SG rules; connection limits (80k concurrent/server) ().
- Custom Hetzner API vs Neutron security-groups API.
Coming from Hetzner Cloud
If you have been using Hetzner Cloud, here is how Quake AI maps to what you run today. Quake AI maps compute, storage, networking, and Kubernetes to OpenStack-backed services with fixed monthly pricing on infrastructure. Quake AI runs on OpenStack: the services below expose standard OpenStack APIs with upstream documentation. Networking is the main model change: Hetzner abstracts subnets and routing, while Quake AI exposes networks, subnets, and routers you configure through the Network service (OpenStack Neutron).
Quick reference#
| Hetzner Cloud | Quake AI | OpenStack project | Key difference |
|---|---|---|---|
| Cloud Server | Instance | Nova | hcloud API vs Nova API; CX/CPX fixed sizes vs Quake AI flavors; Hetzner bills hourly to monthly cap even when powered off |
| Volume | Volume | Cinder | Same attach model; both NVMe-backed |
| Object Storage | Container | Swift | Both S3-compatible; endpoint and credential change only |
| Private Network | Network | Neutron | Neutron adds explicit routers, subnets, and floating IPs that Hetzner abstracts away |
| Firewall | Security Group | Neutron | Hetzner Firewall is network-level; Neutron security groups are per-instance port |
| Load Balancer | Self-managed edge proxy or API gateway | Nova + Neutron | Translate routes, backends, and health checks into Caddy, SafeLine, or APISIX |
| Floating IP | Floating IP | Neutron | Same concept and semantics |
| Snapshot | Snapshot | Glance | Hetzner snapshots are stored as images; Nova creates a snapshot that Glance stores as an image |
| SSH Key | Key Pair | Nova | Direct equivalent |
| Project | Project | Keystone | Same isolation concept |
Compute: Hetzner Cloud servers → instances#
What maps directly: You still pick an image, a size, SSH keys, and optional volumes. Instances are backed by OpenStack Nova.
What is different: Hetzner publishes fixed plans (the CX Gen3 and CPX Gen2 series, for example CX23 or CPX32) with hourly billing that caps at a monthly maximum. The hourly meter runs even when a server is powered off. On Quake AI, you choose from flavors (for example, m2a.large for 2 vCPU and 8 GiB RAM on a general-purpose shape) with fixed monthly pricing per resource tier. Stopped instances do not accrue compute charges at the same rate as running ones. See Flavors.
CLI: Where you run hcloud server create, you use the OpenStack client against Nova:
openstack server create \
--flavor m2a.large \
--image "Ubuntu 24.04" \
--network PublicEphemeral \
--key-name "MY_SSH_KEY_NAME" \
"MY_INSTANCE_NAME"For the full workflow, see Create an instance. For workload migration steps, see Migrate from Hetzner Cloud Servers.
Object storage: Hetzner object storage → containers (Swift, s3-compatible)#
What maps directly: Both products expose an S3-compatible API. The same tools (rclone, aws-cli, s3cmd) work with an endpoint and credential change.
What is different: Object versioning is available on both platforms. Hetzner added versioning to Object Storage in 2024, so confirm your versioning configuration and migrate versioned objects during the cutover. Quake AI's Swift endpoint exposes the same S3 API surface.
See Object storage and Migrate from Hetzner Object Storage for compatibility detail and cutover steps.
Networking: Hetzner private networks → Neutron networks#
Hetzner Cloud private networks abstract away most of the underlying topology: you create a network, pick a CIDR range, and attach servers. Subnets, routing, and external connectivity are handled behind the scenes.
On Quake AI, networking uses OpenStack Neutron, which exposes three separate objects that you compose:
- Network: the L2 broadcast domain (like Hetzner's private network)
- Subnet: the IP range and DHCP configuration attached to a network
- Router: connects subnets to each other and to the external network
No internet gateway or NAT gateway object exists. The router attaches directly to the external network for outbound access. You control subnet sizing, routing between multiple subnets, and which subnets have external connectivity.
See Networks for the full topology. For network migration steps, see Migrate from Hetzner Networks.
Security: Hetzner firewalls → Neutron security groups#
What maps directly: You still express allow rules by protocol, port, and source CIDR. Both platforms default to deny-inbound.
What is different: Hetzner Firewalls apply at the network level or via label selectors across multiple servers. Neutron security groups bind to each instance port. When migrating, re-create your firewall rules as security group rules with the same port and CIDR matrix.
Follow Create a security group.
Kubernetes: from Hetzner Kubernetes to Magnum#
What maps directly: You get a Kubernetes API, worker nodes, and cluster-scoped resources. Clusters are provisioned through OpenStack Magnum.
Kubernetes Services with type: LoadBalancer keep the same workload-facing contract after migration. The cluster provisions the public endpoint without exposing a tenant-managed load balancer service.
What is different: Hetzner Kubernetes provides a managed control plane with auto-healing worker nodes and node pools you manage through the Console or API. Magnum gives you a managed control plane from a cluster template, but worker nodes are Nova instances you size, patch, and scale directly.
Cluster operations and templates are covered in Kubernetes. For cluster migration steps, see Migrate from Hetzner Kubernetes.
Block storage: volumes → Cinder volumes#
What maps directly: You create a volume, attach it to one server, format, mount, and detach. Both Hetzner and Quake AI use NVMe-backed storage.
What is different: Block storage uses OpenStack Cinder instead of hcloud. The attach and detach lifecycle is the same.
See Create a volume.
Load balancing: Hetzner load balancers to a self-managed edge#
Hetzner load-balancer concepts still apply: frontend protocols, backend pools, and health checks.
On Quake AI, run an edge reverse proxy, edge WAF, or API gateway on a VM with a floating IP. Translate forwarding rules into proxy routes and targets into backend lists. Choose an external service or software appliance for UDP and other protocol-specific requirements.
Automation: from the Hetzner Terraform provider to OpenTofu#
If you manage Hetzner infrastructure with the hcloud Terraform provider, the migration target is OpenTofu with the openstack provider. You rewrite resources one at a time; the existing guide covers the mapping in detail.
See Migrate from Hetzner Terraform for the full translation.
Platform differences#
- Explicit subnet and router model: Neutron exposes routers, subnets, and external-network attachment as separate objects you compose. Hetzner private networking abstracts these behind a single network object.
- Outbound transfer: Hetzner includes a monthly transfer allowance per server type with overage charges beyond the allowance (see Hetzner Cloud pricing). Quake AI includes outbound transfer in plan pricing, so there is no separate egress line item to model.
- OpenStack portability: Public APIs use standard OpenStack projects including Nova, Neutron, Cinder, Swift, Magnum, and Keystone. The same toolchains transfer to other OpenStack clouds.
Self-managed services and deployment patterns#
Quake AI provides infrastructure primitives: compute, networking, storage, Kubernetes, and automation. Application-level managed services are not part of the platform. You compose your own stack from these primitives, using the same open-source tools you already know.
| Hetzner service | Status on Quake AI | Alternative |
|---|---|---|
| Managed Database | Not available | Self-managed on VMs with automation templates |
| CDN | Not available | Cloudflare or self-managed caching |
| DNS (Hetzner DNS) | Not available | External DNS provider (Cloudflare or similar) |
Next steps#
Usage Guidelines
The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.
Comparisons to third-party providers in this material reflect publicly documented behavior as of the validation date below. Pricing, quotas, service limits, and feature availability change frequently on every cloud. Verify provider-specific claims against the provider's own current documentation before relying on them for a procurement, architecture, or migration decision.
For the full policy, see Usage Guidelines.
Last validated: 22.06.2026