• •Hetzner API tokens are project-scoped: each token is valid only for the project it was created in and must be separately generated per project. OpenStack Keystone application credentials are user-scoped and can be used across projects when the user has appropriate roles.
• •Hetzner has no OAuth2/OIDC integration for API access; all programmatic access requires a static bearer token. Keystone supports OIDC federation, LDAP backends, and federated identity (SAML2).
• •Hetzner tokens have no built-in expiry and must be manually rotated; there is no token TTL or refresh concept. Keystone tokens have configurable TTLs (default 1 hour) and support re-authentication.
• •Hetzner tokens are either read-only or read-write with no fine-grained scope. OpenStack roles (admin, member, reader) provide service-level access control per project.

• •S3 API (PUT Bucket requires specific headers like x-amz-acl limited to private/public-read, LocationConstraint); Swift uses POST/PUT Container with broader ACLs via X-Container-Read/Write.
• •Public access via https://bucket.location.your-objectstorage.com/object; Swift public via temp URLs or ACLs.
• •Up to 100 buckets per account; Swift has no hard limit.

• •Proprietary REST API over HTTPS with Bearer token auth, not OpenStack Identity API (keystone) endpoints or mechanisms.
• •Base URL https://api.hetzner.cloud/v1/ with resource-specific endpoints (e.g., /servers) vs OpenStack service endpoints (nova, cinder).
• •No multi-project handling in single auth; separate per-project tokens vs keystone scopes/projects.
• •Missing identity/catalog endpoints; no service discovery via API.

• •Provisioned via CCM using annotations like load-balancer.hetzner.cloud/location=fsn1 on Services type LoadBalancer.
• •Separate billed resource with HTTP, TCP, and UDP support plus TLS termination; integrates with private networks.
• •Provider-managed regional load balancers use a simpler model than self-managed reverse proxies or Kubernetes LoadBalancer Services.
• •L4 TCP/UDP support and two balancing algorithms differ from application-layer routing configured on a self-managed edge.

• •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).

• •Provisioned via Hetzner CSI driver (csi.hetzner.cloud), ReadWriteOnce only, min 10GB, NVMe-based.
• •Billed €0.044/GB/month until deleted, no pause; attach/detach via CSI, unlike Cinder's broader access modes (RWX via Manila).
• •Snapshots supported but no volume encryption at rest by default; location-specific (e.g., fsn1).
• •Proprietary REST API at https://api.hetzner.cloud/v1/volumes using Bearer token auth, not OpenStack Cinder API (v3 JSON over Keystone). Endpoints like POST /volumes/{id}/actions/attach, POST /volumes/{id}/actions/resize (upsize only). No /v3/{project_id}/volumes/{volume_id}/action os-extend.

• •Flat monthly billing €3/IPv4 or hourly equivalent, not usage-based per hour ().
• •Locked to specific location/zone, cannot move across datacenters unlike global pools in OpenStack ().
• •Hot-reassign without server reboot but requires manual OS config (e.g., ifupdown/netplan) post-change ().
• •Limits: 10/account default, 20/server max; single assignment at a time ().

• •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.

No specific divergences documented yet.

• •Hetzner bills servers per hour with a monthly cap; if a server is deleted before month end, only the hourly rate applies. Servers are billed even when powered off because resources remain allocated. Quake AI's billing model is operator-defined.
• •Hetzner pricing is embedded in the server type API response (GET /v1/server_types): each type includes a prices array with hourly and monthly (net/gross) for each location. This makes Hetzner pricing programmatically discoverable, unlike AWS/Azure/GCP which require separate pricing APIs.
• •Hetzner includes a traffic allowance per server (e.g. 20 TB/month for CX21); overage is billed per 100MB block rounded up. Quake AI's bandwidth pricing is operator-defined.
• •Hetzner snapshots are billed per GB of compressed snapshot storage per month; backups are billed at 20% of the server price for up to 7 automated backup slots.

• •Hetzner's network model has three main primitives: Private Networks (L3 SDN), Floating IPs (public IP reassignment), and Firewalls (stateful L3/L4 rules). Neutron separates these into networks, subnets, routers, ports, floating IPs, security groups, and FWaaS rules as independently addressable resources.
• •Hetzner does not have a concept of external networks, provider networks, or network types (flat/VLAN/VXLAN). All private networking is via Hetzner's proprietary SDN; Neutron supports multiple backend drivers (OVN, OVS, ML2 plugins).
• •IPv6 on Hetzner private networks is not supported as of April 2026; only public interfaces can have IPv6 addresses. Neutron supports dual-stack subnets (IPv4+IPv6) on private networks.
• •Hetzner network limits: max 100 servers per private network, max 50 private networks per project. Neutron quotas are operator-defined and typically much higher.

• •Hetzner Object Storage endpoint format is location-scoped: {bucket}.{location}.your-objectstorage.com (e.g. my-bucket.fsn1.your-objectstorage.com); Quake AI uses a regional endpoint. Credentials are project-scoped and must be regenerated per project.
• •Hetzner does not publish a full S3 compatibility matrix; advanced operations (S3 Select, Object Lock, Replication, Lifecycle rules) are not documented as supported. Both Hetzner and Quake AI use Ceph RGW, so core S3 CRUD, multipart upload, and SigV4 auth work on both.
• •Hetzner credentials are project-bound access key/secret pairs separate from Hetzner API tokens; the same S3 credential cannot be used across projects. Quake AI EC2 credentials are tied to a Keystone user and scoped per project via role assignments.
• •Hetzner Object Storage locations (fsn1, nbg1, hel1) are distinct endpoints; buckets in different locations require separate credentials and aliases. Quake AI object storage uses a single regional endpoint per deployment.

• •Includes system images (OS), user images (snapshots/backups).
• •API /v1/images; create via server action create_image (type=snapshot/backup).
• •Billed per GB/month; backups cost 20% of server price.
• •No direct image upload; custom via ISO attach or rebuild.

• •No support for volume snapshots in API or console; explicitly stated 'we do not provide Backups or Snapshots for Volumes' and server snapshots exclude volumes.
• •Workarounds like rsync/dd to new volume required, unlike Cinder's create/delete/get/manage_snapshot API.
• •Recent confirmations (2026) show no addition of feature.
• •Created as Image type='snapshot' via server action; stored under /images.

• •Hetzner has no managed NAT gateway service. Outbound internet access for private servers requires provisioning a server with a public IP, enabling Linux IP forwarding (net.ipv4.ip_forward=1), and configuring iptables MASQUERADE. Neutron provides managed SNAT via the L3 agent when a router has an external gateway attached.
• •The NAT server must be provisioned as a regular billable server (minimum ~€3.29/month); Neutron SNAT is a control-plane service with no additional instance cost.
• •Hetzner SDN routes traffic to the NAT server via a static network route (destination: 0.0.0.0/0, gateway: <nat-server-private-ip>); this must be manually configured and updated if the NAT server IP changes. Neutron manages routing automatically when a router has an external gateway.
• •No native HA NAT option; high availability requires a custom keepalived/VRRP setup. Neutron L3 HA routers support active-standby failover.

• •Hetzner has no port concept. Network attachment is managed at the server level via POST /v1/servers/{id}/actions/attach_to_network with an optional fixed IP. In Neutron, a port is an independent resource that can exist without a server attached, has its own UUID, security groups, and fixed IP.
• •Neutron ports support multiple fixed IPs per port, allowed-address-pairs for virtual IP failover (VRRP/keepalived), and port security disable. Hetzner network attachment has no equivalent of allowed-address-pairs or port security controls.
• •In Neutron, ports are the attachment point for security groups (POST /v2.0/ports with security_groups). Hetzner uses Firewalls (POST /v1/firewalls) attached to servers or server groups directly, not to network interfaces.
• •Neutron port status transitions (ACTIVE/DOWN/BUILD) are observable via API. Hetzner server network attachment status is an action result with no independent port lifecycle.

• •Hetzner has no managed router resource. Inter-subnet and internet routing is configured via static routes in the network (POST /v1/networks/{id}/routes) pointing to a gateway server IP. Neutron provides a managed router resource (POST /v2.0/routers) with a dedicated control-plane service.
• •Adding an external gateway in Neutron (connecting a router to the external network for floating IP allocation) is a single API call. On Hetzner, internet egress requires provisioning a server with IP forwarding and iptables MASQUERADE configured as a NAT gateway — all manual or IaC-managed steps.
• •Neutron router interfaces can be hot-added and removed. Hetzner routes are defined at the network level and take effect in the SDN without a dedicated router resource to manage.
• •Dynamic routing protocols (BGP, OSPF) are not supported on Hetzner private networks; Neutron supports BGP via the neutron-dynamic-routing extension.

• •Hetzner has no subscription or commitment model; all billing is usage-based with monthly invoices. There are no reserved instance discounts or committed use discounts. Quake AI's pricing model is operator-defined.
• •Hetzner invoices are generated per project at the end of each month; multiple projects are invoiced separately even under the same Hetzner account. There is no consolidated invoice across projects.
• •Hetzner has no free tier or trial credits for new accounts (unlike AWS, GCP, Azure which offer free tiers). Resource usage begins billing immediately on provisioning.
• •Hetzner invoices include VAT for private customers in Germany (19%); business customers in EU can provide a VAT ID. Quake AI's tax handling is operator-defined.

• •Private networks (vSwitch-like but called Networks) created via API, up to 10.0.0.0/8 subnets, attach to servers/LBs.
• •CCM supports route controller for pod networking when enabled; no native provider networks like OpenStack.
• •Limited to Hetzner regions, IPv4 only for private (IPv6 public).
• •Networks are free with no usage charges, unlike potential metering in OpenStack clouds ().

• •Similar self-managed model to Quake AI; both require users to provision servers and install Kubernetes with tools like OpenTofu/Terraform and k3s/kubeadm. Hetzner provides a Cloud Controller Manager and CSI driver, while Quake AI uses OpenStack-compatible storage and network integrations.
• •Hetzner-specific cloud-provider=external CCM must be deployed manually in kube-system namespace.
• •No cluster API or web UI for cluster lifecycle; all via Hetzner Cloud API token and kubectl.

• •Supported in both, but Hetzner S3 limited NoncurrentVersionExpiration to NoncurrentDays only.

• •Only 'spread' type (anti-affinity: servers on different physical hosts); no 'affinity' or policy-based like OpenStack.
• •Max 10 servers/group (spread), 50 groups/project, 1 group/server.
• •Free; add servers via API action (must be off for existing).
• •No rack/host-level control; protects against single host failure only.

• •Hetzner subnets are defined with a network_zone (e.g. eu-central) and an IP range within the parent network CIDR via POST /v1/networks/{id}/subnets; Neutron subnets are independently addressable resources not scoped to zones.
• •Hetzner private networks are limited to 100 servers per network; Neutron networks have no hardcoded server limit (quota-limited by project).
• •Hetzner SDN operates at strictly Layer 3 (no broadcast, multicast, or unknown unicast traffic); Neutron supports L2 broadcast domains with ML2 backends (OVN/OVS).
• •Hetzner subnets cannot be deleted individually while servers are attached; Neutron supports port removal and subnet deletion independently.

• •Hourly pro-rated with monthly cap, invoiced monthly post-usage to project Owner vs real-time OpenStack usage data via Ceilometer/gnocchi.
• •No billing API endpoints; view invoices in console vs queryable meters/resources via APIs.
• •Owner always billed for all project resources irrespective of member actions vs flexible billing/project assignment in OpenStack.
• •Traffic overage in 100MB blocks with notifications to owner.

• •Console/email invite-based with fixed roles (Owner/Admin/Member/Restricted); no Keystone users/roles/groups API.
• •Owner uniquely billed for project resources regardless of creator vs OpenStack project owners/admins configurable.
• •Light accounts for externals limited to project (no own projects/products) vs full user accounts with multi-project access.
• •Admin role manages members/tokens via UI; no API for users/roles; migrating user must re-invite via console.

• •Hetzner has no organization or team hierarchy above the project level. Multiple Hetzner accounts cannot be grouped into an organization; access sharing across projects requires inviting individual accounts to each project separately.
• •Hetzner API tokens are project-scoped bearer tokens with no cross-project token or service account concept. Keystone application credentials are user-scoped and work across projects when the user has appropriate roles.
• •Hetzner projects are billing containers invoiced separately even under the same account; there is no consolidated billing across projects. OpenStack has no native billing hierarchy.
• •Hetzner projects have no RBAC beyond owner vs. member; members cannot be restricted to specific resource types. OpenStack Keystone roles (admin, member, reader) provide granular per-project access control.

• •Project-scoped keys valid for all buckets in project by default; restrict via policy on key (Hetzner-specific?); Quake AI/Swift uses Keystone tokens/roles/EC2 creds for S3 compat or user roles for native.
• •Up to 200 credentials across projects; Swift unlimited via Keystone.
• •SSE-C only (no SSE-S3/KMS); Swift supports encryption via Ceph backend but API varies.

• •Hetzner server snapshots are created via POST /v1/servers/{id}/actions/create_image with type: snapshot. Hetzner recommends powering off the server first for data consistency, though live snapshots are supported. Nova createImage does not require VM shutdown.
• •Hetzner snapshots are billed per gigabyte of compressed snapshot size per month (billed for the fraction of the month if deleted early). OpenStack image storage pricing is operator-defined.
• •Hetzner snapshots are stored within the project and location where the server resides; cross-project sharing requires downloading and re-uploading. Glance images can be shared across OpenStack projects using image visibility controls.
• •Hetzner has no snapshot scheduling API; snapshots are manual only. Automated backups (7 slots, 20% of server price/month) are a separate feature. OpenStack has no built-in snapshot scheduling.

• •Fixed predefined types (e.g. CX11, CPX31) with shared_vcpu (noisy neighbors) vs dedicated_vcpu.
• •GET /v1/server_types lists all; no custom flavor creation like OpenStack.
• •Includes pricing (hourly/monthly net/gross), included_traffic, architecture (x86/amd64/arm).
• •Resize via change_type action, but limited to compatible types.

• •API /v1/ssh_keys; POST public_key, name; inject array of ssh_keys on server create.
• •No private key management; user provides public keys only.
• •Fingerprint-based listing/filtering; labels support.
• •Injected via cloud-init on boot.

• •Hetzner API tokens are project-scoped: each token is valid only for the project it was created in and must be separately generated per project. OpenStack Keystone application credentials are user-scoped and can be used across projects when the user has appropriate roles.
• •Hetzner has no OAuth2/OIDC integration for API access; all programmatic access requires a static bearer token. Keystone supports OIDC federation, LDAP backends, and federated identity (SAML2).
• •Hetzner tokens have no built-in expiry and must be manually rotated; there is no token TTL or refresh concept. Keystone tokens have configurable TTLs (default 1 hour) and support re-authentication.
• •Hetzner tokens are either read-only or read-write with no fine-grained scope. OpenStack roles (admin, member, reader) provide service-level access control per project.

• •S3 API (PUT Bucket requires specific headers like x-amz-acl limited to private/public-read, LocationConstraint); Swift uses POST/PUT Container with broader ACLs via X-Container-Read/Write.
• •Public access via https://bucket.location.your-objectstorage.com/object; Swift public via temp URLs or ACLs.
• •Up to 100 buckets per account; Swift has no hard limit.

• •Proprietary REST API over HTTPS with Bearer token auth, not OpenStack Identity API (keystone) endpoints or mechanisms.
• •Base URL https://api.hetzner.cloud/v1/ with resource-specific endpoints (e.g., /servers) vs OpenStack service endpoints (nova, cinder).
• •No multi-project handling in single auth; separate per-project tokens vs keystone scopes/projects.
• •Missing identity/catalog endpoints; no service discovery via API.

• •Provisioned via CCM using annotations like load-balancer.hetzner.cloud/location=fsn1 on Services type LoadBalancer.
• •Separate billed resource with HTTP, TCP, and UDP support plus TLS termination; integrates with private networks.
• •Provider-managed regional load balancers use a simpler model than self-managed reverse proxies or Kubernetes LoadBalancer Services.
• •L4 TCP/UDP support and two balancing algorithms differ from application-layer routing configured on a self-managed edge.

• •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).

• •Provisioned via Hetzner CSI driver (csi.hetzner.cloud), ReadWriteOnce only, min 10GB, NVMe-based.
• •Billed €0.044/GB/month until deleted, no pause; attach/detach via CSI, unlike Cinder's broader access modes (RWX via Manila).
• •Snapshots supported but no volume encryption at rest by default; location-specific (e.g., fsn1).
• •Proprietary REST API at https://api.hetzner.cloud/v1/volumes using Bearer token auth, not OpenStack Cinder API (v3 JSON over Keystone). Endpoints like POST /volumes/{id}/actions/attach, POST /volumes/{id}/actions/resize (upsize only). No /v3/{project_id}/volumes/{volume_id}/action os-extend.

• •Flat monthly billing €3/IPv4 or hourly equivalent, not usage-based per hour ().
• •Locked to specific location/zone, cannot move across datacenters unlike global pools in OpenStack ().
• •Hot-reassign without server reboot but requires manual OS config (e.g., ifupdown/netplan) post-change ().
• •Limits: 10/account default, 20/server max; single assignment at a time ().

• •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.

No specific divergences documented yet.

• •Hetzner bills servers per hour with a monthly cap; if a server is deleted before month end, only the hourly rate applies. Servers are billed even when powered off because resources remain allocated. Quake AI's billing model is operator-defined.
• •Hetzner pricing is embedded in the server type API response (GET /v1/server_types): each type includes a prices array with hourly and monthly (net/gross) for each location. This makes Hetzner pricing programmatically discoverable, unlike AWS/Azure/GCP which require separate pricing APIs.
• •Hetzner includes a traffic allowance per server (e.g. 20 TB/month for CX21); overage is billed per 100MB block rounded up. Quake AI's bandwidth pricing is operator-defined.
• •Hetzner snapshots are billed per GB of compressed snapshot storage per month; backups are billed at 20% of the server price for up to 7 automated backup slots.

• •Hetzner's network model has three main primitives: Private Networks (L3 SDN), Floating IPs (public IP reassignment), and Firewalls (stateful L3/L4 rules). Neutron separates these into networks, subnets, routers, ports, floating IPs, security groups, and FWaaS rules as independently addressable resources.
• •Hetzner does not have a concept of external networks, provider networks, or network types (flat/VLAN/VXLAN). All private networking is via Hetzner's proprietary SDN; Neutron supports multiple backend drivers (OVN, OVS, ML2 plugins).
• •IPv6 on Hetzner private networks is not supported as of April 2026; only public interfaces can have IPv6 addresses. Neutron supports dual-stack subnets (IPv4+IPv6) on private networks.
• •Hetzner network limits: max 100 servers per private network, max 50 private networks per project. Neutron quotas are operator-defined and typically much higher.

• •Hetzner Object Storage endpoint format is location-scoped: {bucket}.{location}.your-objectstorage.com (e.g. my-bucket.fsn1.your-objectstorage.com); Quake AI uses a regional endpoint. Credentials are project-scoped and must be regenerated per project.
• •Hetzner does not publish a full S3 compatibility matrix; advanced operations (S3 Select, Object Lock, Replication, Lifecycle rules) are not documented as supported. Both Hetzner and Quake AI use Ceph RGW, so core S3 CRUD, multipart upload, and SigV4 auth work on both.
• •Hetzner credentials are project-bound access key/secret pairs separate from Hetzner API tokens; the same S3 credential cannot be used across projects. Quake AI EC2 credentials are tied to a Keystone user and scoped per project via role assignments.
• •Hetzner Object Storage locations (fsn1, nbg1, hel1) are distinct endpoints; buckets in different locations require separate credentials and aliases. Quake AI object storage uses a single regional endpoint per deployment.

• •Includes system images (OS), user images (snapshots/backups).
• •API /v1/images; create via server action create_image (type=snapshot/backup).
• •Billed per GB/month; backups cost 20% of server price.
• •No direct image upload; custom via ISO attach or rebuild.

• •No support for volume snapshots in API or console; explicitly stated 'we do not provide Backups or Snapshots for Volumes' and server snapshots exclude volumes.
• •Workarounds like rsync/dd to new volume required, unlike Cinder's create/delete/get/manage_snapshot API.
• •Recent confirmations (2026) show no addition of feature.
• •Created as Image type='snapshot' via server action; stored under /images.

• •Hetzner has no managed NAT gateway service. Outbound internet access for private servers requires provisioning a server with a public IP, enabling Linux IP forwarding (net.ipv4.ip_forward=1), and configuring iptables MASQUERADE. Neutron provides managed SNAT via the L3 agent when a router has an external gateway attached.
• •The NAT server must be provisioned as a regular billable server (minimum ~€3.29/month); Neutron SNAT is a control-plane service with no additional instance cost.
• •Hetzner SDN routes traffic to the NAT server via a static network route (destination: 0.0.0.0/0, gateway: <nat-server-private-ip>); this must be manually configured and updated if the NAT server IP changes. Neutron manages routing automatically when a router has an external gateway.
• •No native HA NAT option; high availability requires a custom keepalived/VRRP setup. Neutron L3 HA routers support active-standby failover.

• •Hetzner has no port concept. Network attachment is managed at the server level via POST /v1/servers/{id}/actions/attach_to_network with an optional fixed IP. In Neutron, a port is an independent resource that can exist without a server attached, has its own UUID, security groups, and fixed IP.
• •Neutron ports support multiple fixed IPs per port, allowed-address-pairs for virtual IP failover (VRRP/keepalived), and port security disable. Hetzner network attachment has no equivalent of allowed-address-pairs or port security controls.
• •In Neutron, ports are the attachment point for security groups (POST /v2.0/ports with security_groups). Hetzner uses Firewalls (POST /v1/firewalls) attached to servers or server groups directly, not to network interfaces.
• •Neutron port status transitions (ACTIVE/DOWN/BUILD) are observable via API. Hetzner server network attachment status is an action result with no independent port lifecycle.

• •Hetzner has no managed router resource. Inter-subnet and internet routing is configured via static routes in the network (POST /v1/networks/{id}/routes) pointing to a gateway server IP. Neutron provides a managed router resource (POST /v2.0/routers) with a dedicated control-plane service.
• •Adding an external gateway in Neutron (connecting a router to the external network for floating IP allocation) is a single API call. On Hetzner, internet egress requires provisioning a server with IP forwarding and iptables MASQUERADE configured as a NAT gateway — all manual or IaC-managed steps.
• •Neutron router interfaces can be hot-added and removed. Hetzner routes are defined at the network level and take effect in the SDN without a dedicated router resource to manage.
• •Dynamic routing protocols (BGP, OSPF) are not supported on Hetzner private networks; Neutron supports BGP via the neutron-dynamic-routing extension.

• •Hetzner has no subscription or commitment model; all billing is usage-based with monthly invoices. There are no reserved instance discounts or committed use discounts. Quake AI's pricing model is operator-defined.
• •Hetzner invoices are generated per project at the end of each month; multiple projects are invoiced separately even under the same Hetzner account. There is no consolidated invoice across projects.
• •Hetzner has no free tier or trial credits for new accounts (unlike AWS, GCP, Azure which offer free tiers). Resource usage begins billing immediately on provisioning.
• •Hetzner invoices include VAT for private customers in Germany (19%); business customers in EU can provide a VAT ID. Quake AI's tax handling is operator-defined.

• •Private networks (vSwitch-like but called Networks) created via API, up to 10.0.0.0/8 subnets, attach to servers/LBs.
• •CCM supports route controller for pod networking when enabled; no native provider networks like OpenStack.
• •Limited to Hetzner regions, IPv4 only for private (IPv6 public).
• •Networks are free with no usage charges, unlike potential metering in OpenStack clouds ().

• •Similar self-managed model to Quake AI; both require users to provision servers and install Kubernetes with tools like OpenTofu/Terraform and k3s/kubeadm. Hetzner provides a Cloud Controller Manager and CSI driver, while Quake AI uses OpenStack-compatible storage and network integrations.
• •Hetzner-specific cloud-provider=external CCM must be deployed manually in kube-system namespace.
• •No cluster API or web UI for cluster lifecycle; all via Hetzner Cloud API token and kubectl.

• •Supported in both, but Hetzner S3 limited NoncurrentVersionExpiration to NoncurrentDays only.

• •Only 'spread' type (anti-affinity: servers on different physical hosts); no 'affinity' or policy-based like OpenStack.
• •Max 10 servers/group (spread), 50 groups/project, 1 group/server.
• •Free; add servers via API action (must be off for existing).
• •No rack/host-level control; protects against single host failure only.

• •Hetzner subnets are defined with a network_zone (e.g. eu-central) and an IP range within the parent network CIDR via POST /v1/networks/{id}/subnets; Neutron subnets are independently addressable resources not scoped to zones.
• •Hetzner private networks are limited to 100 servers per network; Neutron networks have no hardcoded server limit (quota-limited by project).
• •Hetzner SDN operates at strictly Layer 3 (no broadcast, multicast, or unknown unicast traffic); Neutron supports L2 broadcast domains with ML2 backends (OVN/OVS).
• •Hetzner subnets cannot be deleted individually while servers are attached; Neutron supports port removal and subnet deletion independently.

• •Hourly pro-rated with monthly cap, invoiced monthly post-usage to project Owner vs real-time OpenStack usage data via Ceilometer/gnocchi.
• •No billing API endpoints; view invoices in console vs queryable meters/resources via APIs.
• •Owner always billed for all project resources irrespective of member actions vs flexible billing/project assignment in OpenStack.
• •Traffic overage in 100MB blocks with notifications to owner.

• •Console/email invite-based with fixed roles (Owner/Admin/Member/Restricted); no Keystone users/roles/groups API.
• •Owner uniquely billed for project resources regardless of creator vs OpenStack project owners/admins configurable.
• •Light accounts for externals limited to project (no own projects/products) vs full user accounts with multi-project access.
• •Admin role manages members/tokens via UI; no API for users/roles; migrating user must re-invite via console.

• •Hetzner has no organization or team hierarchy above the project level. Multiple Hetzner accounts cannot be grouped into an organization; access sharing across projects requires inviting individual accounts to each project separately.
• •Hetzner API tokens are project-scoped bearer tokens with no cross-project token or service account concept. Keystone application credentials are user-scoped and work across projects when the user has appropriate roles.
• •Hetzner projects are billing containers invoiced separately even under the same account; there is no consolidated billing across projects. OpenStack has no native billing hierarchy.
• •Hetzner projects have no RBAC beyond owner vs. member; members cannot be restricted to specific resource types. OpenStack Keystone roles (admin, member, reader) provide granular per-project access control.

• •Project-scoped keys valid for all buckets in project by default; restrict via policy on key (Hetzner-specific?); Quake AI/Swift uses Keystone tokens/roles/EC2 creds for S3 compat or user roles for native.
• •Up to 200 credentials across projects; Swift unlimited via Keystone.
• •SSE-C only (no SSE-S3/KMS); Swift supports encryption via Ceph backend but API varies.

• •Hetzner server snapshots are created via POST /v1/servers/{id}/actions/create_image with type: snapshot. Hetzner recommends powering off the server first for data consistency, though live snapshots are supported. Nova createImage does not require VM shutdown.
• •Hetzner snapshots are billed per gigabyte of compressed snapshot size per month (billed for the fraction of the month if deleted early). OpenStack image storage pricing is operator-defined.
• •Hetzner snapshots are stored within the project and location where the server resides; cross-project sharing requires downloading and re-uploading. Glance images can be shared across OpenStack projects using image visibility controls.
• •Hetzner has no snapshot scheduling API; snapshots are manual only. Automated backups (7 slots, 20% of server price/month) are a separate feature. OpenStack has no built-in snapshot scheduling.

• •Fixed predefined types (e.g. CX11, CPX31) with shared_vcpu (noisy neighbors) vs dedicated_vcpu.
• •GET /v1/server_types lists all; no custom flavor creation like OpenStack.
• •Includes pricing (hourly/monthly net/gross), included_traffic, architecture (x86/amd64/arm).
• •Resize via change_type action, but limited to compatible types.

• •API /v1/ssh_keys; POST public_key, name; inject array of ssh_keys on server create.
• •No private key management; user provides public keys only.
• •Fingerprint-based listing/filtering; labels support.
• •Injected via cloud-init on boot.

• •S3 API (PUT Bucket requires specific headers like x-amz-acl limited to private/public-read, LocationConstraint); Swift uses POST/PUT Container with broader ACLs via X-Container-Read/Write.
• •Public access via https://bucket.location.your-objectstorage.com/object; Swift public via temp URLs or ACLs.
• •Up to 100 buckets per account; Swift has no hard limit.

• •Hetzner Object Storage endpoint format is location-scoped: {bucket}.{location}.your-objectstorage.com (e.g. my-bucket.fsn1.your-objectstorage.com); Quake AI uses a regional endpoint. Credentials are project-scoped and must be regenerated per project.
• •Hetzner does not publish a full S3 compatibility matrix; advanced operations (S3 Select, Object Lock, Replication, Lifecycle rules) are not documented as supported. Both Hetzner and Quake AI use Ceph RGW, so core S3 CRUD, multipart upload, and SigV4 auth work on both.
• •Hetzner credentials are project-bound access key/secret pairs separate from Hetzner API tokens; the same S3 credential cannot be used across projects. Quake AI EC2 credentials are tied to a Keystone user and scoped per project via role assignments.
• •Hetzner Object Storage locations (fsn1, nbg1, hel1) are distinct endpoints; buckets in different locations require separate credentials and aliases. Quake AI object storage uses a single regional endpoint per deployment.

• •Supported in both, but Hetzner S3 limited NoncurrentVersionExpiration to NoncurrentDays only.

• •Project-scoped keys valid for all buckets in project by default; restrict via policy on key (Hetzner-specific?); Quake AI/Swift uses Keystone tokens/roles/EC2 creds for S3 compat or user roles for native.
• •Up to 200 credentials across projects; Swift unlimited via Keystone.
• •SSE-C only (no SSE-S3/KMS); Swift supports encryption via Ceph backend but API varies.

• •Hetzner API tokens are project-scoped: each token is valid only for the project it was created in and must be separately generated per project. OpenStack Keystone application credentials are user-scoped and can be used across projects when the user has appropriate roles.
• •Hetzner has no OAuth2/OIDC integration for API access; all programmatic access requires a static bearer token. Keystone supports OIDC federation, LDAP backends, and federated identity (SAML2).
• •Hetzner tokens have no built-in expiry and must be manually rotated; there is no token TTL or refresh concept. Keystone tokens have configurable TTLs (default 1 hour) and support re-authentication.
• •Hetzner tokens are either read-only or read-write with no fine-grained scope. OpenStack roles (admin, member, reader) provide service-level access control per project.

• •S3 API (PUT Bucket requires specific headers like x-amz-acl limited to private/public-read, LocationConstraint); Swift uses POST/PUT Container with broader ACLs via X-Container-Read/Write.
• •Public access via https://bucket.location.your-objectstorage.com/object; Swift public via temp URLs or ACLs.
• •Up to 100 buckets per account; Swift has no hard limit.

• •Proprietary REST API over HTTPS with Bearer token auth, not OpenStack Identity API (keystone) endpoints or mechanisms.
• •Base URL https://api.hetzner.cloud/v1/ with resource-specific endpoints (e.g., /servers) vs OpenStack service endpoints (nova, cinder).
• •No multi-project handling in single auth; separate per-project tokens vs keystone scopes/projects.
• •Missing identity/catalog endpoints; no service discovery via API.

• •Provisioned via CCM using annotations like load-balancer.hetzner.cloud/location=fsn1 on Services type LoadBalancer.
• •Separate billed resource with HTTP, TCP, and UDP support plus TLS termination; integrates with private networks.
• •Provider-managed regional load balancers use a simpler model than self-managed reverse proxies or Kubernetes LoadBalancer Services.
• •L4 TCP/UDP support and two balancing algorithms differ from application-layer routing configured on a self-managed edge.

• •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).

• •Provisioned via Hetzner CSI driver (csi.hetzner.cloud), ReadWriteOnce only, min 10GB, NVMe-based.
• •Billed €0.044/GB/month until deleted, no pause; attach/detach via CSI, unlike Cinder's broader access modes (RWX via Manila).
• •Snapshots supported but no volume encryption at rest by default; location-specific (e.g., fsn1).
• •Proprietary REST API at https://api.hetzner.cloud/v1/volumes using Bearer token auth, not OpenStack Cinder API (v3 JSON over Keystone). Endpoints like POST /volumes/{id}/actions/attach, POST /volumes/{id}/actions/resize (upsize only). No /v3/{project_id}/volumes/{volume_id}/action os-extend.

• •Flat monthly billing €3/IPv4 or hourly equivalent, not usage-based per hour ().
• •Locked to specific location/zone, cannot move across datacenters unlike global pools in OpenStack ().
• •Hot-reassign without server reboot but requires manual OS config (e.g., ifupdown/netplan) post-change ().
• •Limits: 10/account default, 20/server max; single assignment at a time ().

• •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.

No specific divergences documented yet.

• •Hetzner bills servers per hour with a monthly cap; if a server is deleted before month end, only the hourly rate applies. Servers are billed even when powered off because resources remain allocated. Quake AI's billing model is operator-defined.
• •Hetzner pricing is embedded in the server type API response (GET /v1/server_types): each type includes a prices array with hourly and monthly (net/gross) for each location. This makes Hetzner pricing programmatically discoverable, unlike AWS/Azure/GCP which require separate pricing APIs.
• •Hetzner includes a traffic allowance per server (e.g. 20 TB/month for CX21); overage is billed per 100MB block rounded up. Quake AI's bandwidth pricing is operator-defined.
• •Hetzner snapshots are billed per GB of compressed snapshot storage per month; backups are billed at 20% of the server price for up to 7 automated backup slots.

• •Hetzner's network model has three main primitives: Private Networks (L3 SDN), Floating IPs (public IP reassignment), and Firewalls (stateful L3/L4 rules). Neutron separates these into networks, subnets, routers, ports, floating IPs, security groups, and FWaaS rules as independently addressable resources.
• •Hetzner does not have a concept of external networks, provider networks, or network types (flat/VLAN/VXLAN). All private networking is via Hetzner's proprietary SDN; Neutron supports multiple backend drivers (OVN, OVS, ML2 plugins).
• •IPv6 on Hetzner private networks is not supported as of April 2026; only public interfaces can have IPv6 addresses. Neutron supports dual-stack subnets (IPv4+IPv6) on private networks.
• •Hetzner network limits: max 100 servers per private network, max 50 private networks per project. Neutron quotas are operator-defined and typically much higher.

• •Hetzner Object Storage endpoint format is location-scoped: {bucket}.{location}.your-objectstorage.com (e.g. my-bucket.fsn1.your-objectstorage.com); Quake AI uses a regional endpoint. Credentials are project-scoped and must be regenerated per project.
• •Hetzner does not publish a full S3 compatibility matrix; advanced operations (S3 Select, Object Lock, Replication, Lifecycle rules) are not documented as supported. Both Hetzner and Quake AI use Ceph RGW, so core S3 CRUD, multipart upload, and SigV4 auth work on both.
• •Hetzner credentials are project-bound access key/secret pairs separate from Hetzner API tokens; the same S3 credential cannot be used across projects. Quake AI EC2 credentials are tied to a Keystone user and scoped per project via role assignments.
• •Hetzner Object Storage locations (fsn1, nbg1, hel1) are distinct endpoints; buckets in different locations require separate credentials and aliases. Quake AI object storage uses a single regional endpoint per deployment.

• •Includes system images (OS), user images (snapshots/backups).
• •API /v1/images; create via server action create_image (type=snapshot/backup).
• •Billed per GB/month; backups cost 20% of server price.
• •No direct image upload; custom via ISO attach or rebuild.

• •No support for volume snapshots in API or console; explicitly stated 'we do not provide Backups or Snapshots for Volumes' and server snapshots exclude volumes.
• •Workarounds like rsync/dd to new volume required, unlike Cinder's create/delete/get/manage_snapshot API.
• •Recent confirmations (2026) show no addition of feature.
• •Created as Image type='snapshot' via server action; stored under /images.

• •Hetzner has no managed NAT gateway service. Outbound internet access for private servers requires provisioning a server with a public IP, enabling Linux IP forwarding (net.ipv4.ip_forward=1), and configuring iptables MASQUERADE. Neutron provides managed SNAT via the L3 agent when a router has an external gateway attached.
• •The NAT server must be provisioned as a regular billable server (minimum ~€3.29/month); Neutron SNAT is a control-plane service with no additional instance cost.
• •Hetzner SDN routes traffic to the NAT server via a static network route (destination: 0.0.0.0/0, gateway: <nat-server-private-ip>); this must be manually configured and updated if the NAT server IP changes. Neutron manages routing automatically when a router has an external gateway.
• •No native HA NAT option; high availability requires a custom keepalived/VRRP setup. Neutron L3 HA routers support active-standby failover.

• •Hetzner has no port concept. Network attachment is managed at the server level via POST /v1/servers/{id}/actions/attach_to_network with an optional fixed IP. In Neutron, a port is an independent resource that can exist without a server attached, has its own UUID, security groups, and fixed IP.
• •Neutron ports support multiple fixed IPs per port, allowed-address-pairs for virtual IP failover (VRRP/keepalived), and port security disable. Hetzner network attachment has no equivalent of allowed-address-pairs or port security controls.
• •In Neutron, ports are the attachment point for security groups (POST /v2.0/ports with security_groups). Hetzner uses Firewalls (POST /v1/firewalls) attached to servers or server groups directly, not to network interfaces.
• •Neutron port status transitions (ACTIVE/DOWN/BUILD) are observable via API. Hetzner server network attachment status is an action result with no independent port lifecycle.

• •Hetzner has no managed router resource. Inter-subnet and internet routing is configured via static routes in the network (POST /v1/networks/{id}/routes) pointing to a gateway server IP. Neutron provides a managed router resource (POST /v2.0/routers) with a dedicated control-plane service.
• •Adding an external gateway in Neutron (connecting a router to the external network for floating IP allocation) is a single API call. On Hetzner, internet egress requires provisioning a server with IP forwarding and iptables MASQUERADE configured as a NAT gateway — all manual or IaC-managed steps.
• •Neutron router interfaces can be hot-added and removed. Hetzner routes are defined at the network level and take effect in the SDN without a dedicated router resource to manage.
• •Dynamic routing protocols (BGP, OSPF) are not supported on Hetzner private networks; Neutron supports BGP via the neutron-dynamic-routing extension.

• •Hetzner has no subscription or commitment model; all billing is usage-based with monthly invoices. There are no reserved instance discounts or committed use discounts. Quake AI's pricing model is operator-defined.
• •Hetzner invoices are generated per project at the end of each month; multiple projects are invoiced separately even under the same Hetzner account. There is no consolidated invoice across projects.
• •Hetzner has no free tier or trial credits for new accounts (unlike AWS, GCP, Azure which offer free tiers). Resource usage begins billing immediately on provisioning.
• •Hetzner invoices include VAT for private customers in Germany (19%); business customers in EU can provide a VAT ID. Quake AI's tax handling is operator-defined.

• •Private networks (vSwitch-like but called Networks) created via API, up to 10.0.0.0/8 subnets, attach to servers/LBs.
• •CCM supports route controller for pod networking when enabled; no native provider networks like OpenStack.
• •Limited to Hetzner regions, IPv4 only for private (IPv6 public).
• •Networks are free with no usage charges, unlike potential metering in OpenStack clouds ().

• •Similar self-managed model to Quake AI; both require users to provision servers and install Kubernetes with tools like OpenTofu/Terraform and k3s/kubeadm. Hetzner provides a Cloud Controller Manager and CSI driver, while Quake AI uses OpenStack-compatible storage and network integrations.
• •Hetzner-specific cloud-provider=external CCM must be deployed manually in kube-system namespace.
• •No cluster API or web UI for cluster lifecycle; all via Hetzner Cloud API token and kubectl.

• •Supported in both, but Hetzner S3 limited NoncurrentVersionExpiration to NoncurrentDays only.

• •Only 'spread' type (anti-affinity: servers on different physical hosts); no 'affinity' or policy-based like OpenStack.
• •Max 10 servers/group (spread), 50 groups/project, 1 group/server.
• •Free; add servers via API action (must be off for existing).
• •No rack/host-level control; protects against single host failure only.

• •Hetzner subnets are defined with a network_zone (e.g. eu-central) and an IP range within the parent network CIDR via POST /v1/networks/{id}/subnets; Neutron subnets are independently addressable resources not scoped to zones.
• •Hetzner private networks are limited to 100 servers per network; Neutron networks have no hardcoded server limit (quota-limited by project).
• •Hetzner SDN operates at strictly Layer 3 (no broadcast, multicast, or unknown unicast traffic); Neutron supports L2 broadcast domains with ML2 backends (OVN/OVS).
• •Hetzner subnets cannot be deleted individually while servers are attached; Neutron supports port removal and subnet deletion independently.

• •Hourly pro-rated with monthly cap, invoiced monthly post-usage to project Owner vs real-time OpenStack usage data via Ceilometer/gnocchi.
• •No billing API endpoints; view invoices in console vs queryable meters/resources via APIs.
• •Owner always billed for all project resources irrespective of member actions vs flexible billing/project assignment in OpenStack.
• •Traffic overage in 100MB blocks with notifications to owner.

• •Console/email invite-based with fixed roles (Owner/Admin/Member/Restricted); no Keystone users/roles/groups API.
• •Owner uniquely billed for project resources regardless of creator vs OpenStack project owners/admins configurable.
• •Light accounts for externals limited to project (no own projects/products) vs full user accounts with multi-project access.
• •Admin role manages members/tokens via UI; no API for users/roles; migrating user must re-invite via console.

• •Hetzner has no organization or team hierarchy above the project level. Multiple Hetzner accounts cannot be grouped into an organization; access sharing across projects requires inviting individual accounts to each project separately.
• •Hetzner API tokens are project-scoped bearer tokens with no cross-project token or service account concept. Keystone application credentials are user-scoped and work across projects when the user has appropriate roles.
• •Hetzner projects are billing containers invoiced separately even under the same account; there is no consolidated billing across projects. OpenStack has no native billing hierarchy.
• •Hetzner projects have no RBAC beyond owner vs. member; members cannot be restricted to specific resource types. OpenStack Keystone roles (admin, member, reader) provide granular per-project access control.

• •Project-scoped keys valid for all buckets in project by default; restrict via policy on key (Hetzner-specific?); Quake AI/Swift uses Keystone tokens/roles/EC2 creds for S3 compat or user roles for native.
• •Up to 200 credentials across projects; Swift unlimited via Keystone.
• •SSE-C only (no SSE-S3/KMS); Swift supports encryption via Ceph backend but API varies.

• •Hetzner server snapshots are created via POST /v1/servers/{id}/actions/create_image with type: snapshot. Hetzner recommends powering off the server first for data consistency, though live snapshots are supported. Nova createImage does not require VM shutdown.
• •Hetzner snapshots are billed per gigabyte of compressed snapshot size per month (billed for the fraction of the month if deleted early). OpenStack image storage pricing is operator-defined.
• •Hetzner snapshots are stored within the project and location where the server resides; cross-project sharing requires downloading and re-uploading. Glance images can be shared across OpenStack projects using image visibility controls.
• •Hetzner has no snapshot scheduling API; snapshots are manual only. Automated backups (7 slots, 20% of server price/month) are a separate feature. OpenStack has no built-in snapshot scheduling.

• •Fixed predefined types (e.g. CX11, CPX31) with shared_vcpu (noisy neighbors) vs dedicated_vcpu.
• •GET /v1/server_types lists all; no custom flavor creation like OpenStack.
• •Includes pricing (hourly/monthly net/gross), included_traffic, architecture (x86/amd64/arm).
• •Resize via change_type action, but limited to compatible types.

• •API /v1/ssh_keys; POST public_key, name; inject array of ssh_keys on server create.
• •No private key management; user provides public keys only.
• •Fingerprint-based listing/filtering; labels support.
• •Injected via cloud-init on boot.

• •Similar self-managed model to Quake AI; both require users to provision servers and install Kubernetes with tools like OpenTofu/Terraform and k3s/kubeadm. Hetzner provides a Cloud Controller Manager and CSI driver, while Quake AI uses OpenStack-compatible storage and network integrations.
• •Hetzner-specific cloud-provider=external CCM must be deployed manually in kube-system namespace.
• •No cluster API or web UI for cluster lifecycle; all via Hetzner Cloud API token and kubectl.

• •Hetzner API tokens are project-scoped: each token is valid only for the project it was created in and must be separately generated per project. OpenStack Keystone application credentials are user-scoped and can be used across projects when the user has appropriate roles.
• •Hetzner has no OAuth2/OIDC integration for API access; all programmatic access requires a static bearer token. Keystone supports OIDC federation, LDAP backends, and federated identity (SAML2).
• •Hetzner tokens have no built-in expiry and must be manually rotated; there is no token TTL or refresh concept. Keystone tokens have configurable TTLs (default 1 hour) and support re-authentication.
• •Hetzner tokens are either read-only or read-write with no fine-grained scope. OpenStack roles (admin, member, reader) provide service-level access control per project.

• •Console/email invite-based with fixed roles (Owner/Admin/Member/Restricted); no Keystone users/roles/groups API.
• •Owner uniquely billed for project resources regardless of creator vs OpenStack project owners/admins configurable.
• •Light accounts for externals limited to project (no own projects/products) vs full user accounts with multi-project access.
• •Admin role manages members/tokens via UI; no API for users/roles; migrating user must re-invite via console.

• •Hetzner has no organization or team hierarchy above the project level. Multiple Hetzner accounts cannot be grouped into an organization; access sharing across projects requires inviting individual accounts to each project separately.
• •Hetzner API tokens are project-scoped bearer tokens with no cross-project token or service account concept. Keystone application credentials are user-scoped and work across projects when the user has appropriate roles.
• •Hetzner projects are billing containers invoiced separately even under the same account; there is no consolidated billing across projects. OpenStack has no native billing hierarchy.
• •Hetzner projects have no RBAC beyond owner vs. member; members cannot be restricted to specific resource types. OpenStack Keystone roles (admin, member, reader) provide granular per-project access control.

• •Hetzner bills servers per hour with a monthly cap; if a server is deleted before month end, only the hourly rate applies. Servers are billed even when powered off because resources remain allocated. Quake AI's billing model is operator-defined.
• •Hetzner pricing is embedded in the server type API response (GET /v1/server_types): each type includes a prices array with hourly and monthly (net/gross) for each location. This makes Hetzner pricing programmatically discoverable, unlike AWS/Azure/GCP which require separate pricing APIs.
• •Hetzner includes a traffic allowance per server (e.g. 20 TB/month for CX21); overage is billed per 100MB block rounded up. Quake AI's bandwidth pricing is operator-defined.
• •Hetzner snapshots are billed per GB of compressed snapshot storage per month; backups are billed at 20% of the server price for up to 7 automated backup slots.

• •Hetzner has no subscription or commitment model; all billing is usage-based with monthly invoices. There are no reserved instance discounts or committed use discounts. Quake AI's pricing model is operator-defined.
• •Hetzner invoices are generated per project at the end of each month; multiple projects are invoiced separately even under the same Hetzner account. There is no consolidated invoice across projects.
• •Hetzner has no free tier or trial credits for new accounts (unlike AWS, GCP, Azure which offer free tiers). Resource usage begins billing immediately on provisioning.
• •Hetzner invoices include VAT for private customers in Germany (19%); business customers in EU can provide a VAT ID. Quake AI's tax handling is operator-defined.

• •Hourly pro-rated with monthly cap, invoiced monthly post-usage to project Owner vs real-time OpenStack usage data via Ceilometer/gnocchi.
• •No billing API endpoints; view invoices in console vs queryable meters/resources via APIs.
• •Owner always billed for all project resources irrespective of member actions vs flexible billing/project assignment in OpenStack.
• •Traffic overage in 100MB blocks with notifications to owner.

No specific divergences documented yet.

• •Proprietary REST API over HTTPS with Bearer token auth, not OpenStack Identity API (keystone) endpoints or mechanisms.
• •Base URL https://api.hetzner.cloud/v1/ with resource-specific endpoints (e.g., /servers) vs OpenStack service endpoints (nova, cinder).
• •No multi-project handling in single auth; separate per-project tokens vs keystone scopes/projects.
• •Missing identity/catalog endpoints; no service discovery via API.