---
schema_version: "1.0"
project_name: "reasons"
updated_at: "2026-06-05T02:22:01+00:00"
node_count: 476
generator: ftl-reasons/0.43.0
---

# Belief Registry
<!-- Generated by reasons export-markdown. Do not edit — operate through reasons. -->

## Repos
- Date: 2026-03-11
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8

## Claims

### api-architecture-tripartite-incompatible-auth [IN] OBSERVATION
Hetzner's API architecture spans three distinct endpoints (Cloud API, Robot API, Storage Box) with two different authentication mechanisms (Bearer tokens for Cloud/Robot, separate credentials for Storage Box), requiring separate credential management for each product line.

### async-api-poll-convergence-pattern [IN] OBSERVATION
Hetzner Cloud API operations are asynchronous with action tracking — the CLI polls at 500ms intervals and the Go SDK requires explicit `WaitFor()` calls, establishing a converge-and-poll pattern as the standard automation idiom.

### async-propagates-through-automation-stack [IN] OBSERVATION
Hetzner's asynchronous API design propagates through the entire automation stack — CLI polls at 500ms intervals, Go SDK requires explicit WaitFor() calls, and Terraform (built on hcloud-go) inherits the same async convergence requirement — making action completion handling a universal automation concern.

### automation-toolchain-three-layer-coverage [IN] OBSERVATION
Hetzner provides automation tools at three layers: the hcloud-go SDK for programmatic access, the hcloud CLI for interactive and scripted management, and the Terraform provider (built on hcloud-go) for infrastructure-as-code workflows.

### backup-two-strategies-cost-control-tradeoff [IN] OBSERVATION
Hetzner offers two complementary data protection strategies with inverse cost/control tradeoffs: automatic backups (simple, fixed 20% server cost, max 7 retained, no user intervention) and manual snapshots (full control over timing and retention, per-GB billing, unlimited count).

### billing-deceptive-simplicity [IN] OBSERVATION
Hetzner's billing model appears simple (hourly with monthly caps, no commitment) but contains material cost traps: powered-off servers still billed, IPv4 charged when unassigned, and 40x regional traffic asymmetry — requiring active cost governance despite the pay-as-you-go branding.

### billing-location-coupling-creates-irreversible-cost-profile [IN] OBSERVATION
As location consolidation makes location the sole billing axis and cross-location migration remains impossible, initial location choice creates an irreversible cost profile for the deployment's lifetime.

### ccm-dev-requires-opentofu-k3sup-docker-skaffold [IN] OBSERVATION
CCM development environment requires OpenTofu, k3sup, Docker, and Skaffold.
- Source: entries/2026/03/11/cloud-controller-manager-readme.md
- Source hash: fa21437e18cb5215
- Date: 2026-03-11

### ccm-integrates-cloud-and-robot-api [IN] OBSERVATION
The Hetzner Cloud Controller Manager integrates Kubernetes with both the Hetzner Cloud API and the Robot API (dedicated servers).
- Source: entries/2026/03/11/cloud-controller-manager-readme.md
- Source hash: fa21437e18cb5215
- Date: 2026-03-11

### ccm-lb-algorithm-types [IN] OBSERVATION
The CCM load balancer algorithm annotation supports `round_robin` (default) and `least_connections`.
- Source: entries/2026/03/11/cloud-controller-manager-readme.md
- Source hash: fa21437e18cb5215
- Date: 2026-03-11

### ccm-lb-config-via-annotations [IN] OBSERVATION
Hetzner Cloud Load Balancers are configured via Kubernetes annotations on Service objects (e.g., `load-balancer.hetzner.cloud/algorithm-type`).
- Source: entries/2026/03/11/cloud-controller-manager-readme.md
- Source hash: fa21437e18cb5215
- Date: 2026-03-11

### ccm-robot-env-vars [IN] OBSERVATION
Robot API integration requires `ROBOT_ENABLED=true`, `ROBOT_USER`, and `ROBOT_PASSWORD` environment variables.
- Source: entries/2026/03/11/cloud-controller-manager-readme.md
- Source hash: fa21437e18cb5215
- Date: 2026-03-11

### ccm-v1-30-0-crash-july-2026 [IN] OBSERVATION
CCM versions <= v1.30.0 will panic and crash after July 2026 due to removal of the `server.datacenter` API field; minimum safe version is v1.30.1.
- Source: entries/2026/03/11/cloud-controller-manager-readme.md
- Source hash: fa21437e18cb5215
- Date: 2026-03-11

### cli-context-project-scoped-isolation [IN] OBSERVATION
The hcloud CLI enforces project-scoped isolation — each context binds to a single API token/project, only one is active at a time, switching is explicit (use/unset), and creation is interactive — establishing a single-project-at-a-time operational model that prevents accidental cross-project mutations.

### cli-uniform-resource-identity-pattern [IN] OBSERVATION
The hcloud CLI follows a consistent resource identity pattern across all major resource types: describe commands accept name-or-ID, output supports JSON/YAML/custom format, and resources share the same label management subcommand structure.

### cost-optimization-requires-location-aware-architecture [IN] OBSERVATION
Cost optimization on Hetzner is inseparable from architecture — the 40x regional traffic asymmetry makes location selection a billing decision, while resource binding (volumes, IPs, networks) makes location selection an architectural commitment, so cost-efficient architectures must account for location as a first-class design parameter from day one rather than treating it as a deployment detail.

### csi-driver-docker-swarm-nomad-unofficial [IN] OBSERVATION
Docker Swarm and HashiCorp Nomad support for the CSI driver is community-contributed and unofficial.
- Source: entries/2026/03/11/csi-driver-readme.md
- Source hash: 6f51e02f4c2b369c
- Date: 2026-03-11

### csi-driver-license-mit [IN] OBSERVATION
The Hetzner Cloud CSI driver is licensed under MIT.
- Source: entries/2026/03/11/csi-driver-readme.md
- Source hash: 6f51e02f4c2b369c
- Date: 2026-03-11

### csi-driver-min-k8s-1-19 [IN] OBSERVATION
The Hetzner Cloud CSI driver requires Kubernetes 1.19 or newer.
- Source: entries/2026/03/11/csi-driver-readme.md
- Source hash: 6f51e02f4c2b369c
- Date: 2026-03-11

### csi-driver-rwo-only [IN] OBSERVATION
The Hetzner Cloud CSI driver supports only ReadWriteOnce (RWO) access mode — not ReadWriteMany or ReadOnlyMany.
- Source: entries/2026/03/11/csi-driver-readme.md
- Source hash: 6f51e02f4c2b369c
- Date: 2026-03-11

### data-migration-between-locations-impossible [IN] OBSERVATION
Hetzner resources are location-coupled (servers, volumes, networks bound to their creation location), meaning moving workloads between locations requires recreating resources rather than migrating them in place.

### data-protection-requires-explicit-strategy [IN] OBSERVATION
Server operations include destructive paths (rebuild replaces root disk, poweroff/reset are non-graceful) and Hetzner's two data protection strategies have inverse cost/control tradeoffs (automatic backups: simple but capped at 7; snapshots: flexible but manual and per-GB), meaning data protection requires deliberate architectural decisions — there is no implicit safety net covering both convenience and retention depth.

### datacenter-sovereignty-split-model [IN] OBSERVATION
German datacenters (NBG1, FSN1) are self-operated by Hetzner while international locations (US, Singapore) use third-party facilities, creating a sovereignty distinction relevant for data residency requirements.

### datacenter-to-location-deprecation-wave [IN] OBSERVATION
Hetzner is systematically deprecating datacenter-level resource placement in favor of location-level across servers, Primary IPs, and resource attributes — a coordinated API migration signaling that datacenter IDs will become internal implementation details.

### ddos-protection-free-hardware-based [IN] OBSERVATION
Hetzner DDoS protection is free and hardware-based, applied at the datacenter perimeter.
- Source: entries/2026/03/11/hetzner-cloud-networking.md
- Source hash: 490d8986b7c63e22
- Date: 2026-03-11

### destructive-operation-multi-layer-safeguards [IN] OBSERVATION
Hetzner Cloud employs multiple safeguard layers against destructive operations: resource protection (must disable before delete), deprecated image blocking (opt-in required), and explicit required flags — preventing accidental data loss through defense in depth.

### dns-full-bind-compatible-management [IN] OBSERVATION
Hetzner DNS provides full BIND-compatible zone management with 16 record types, three mutation strategies per RRSet (append/replace/delete), and support for both primary and secondary zones with AXFR.

### dns-to-tls-end-to-end-lifecycle [IN] OBSERVATION
Hetzner provides an end-to-end managed TLS lifecycle within a single provider — BIND-compatible DNS zone management for domain hosting, automatic managed certificate issuance via Let's Encrypt, and Load Balancer TLS termination with HTTP/2 and HTTP-to-HTTPS redirect — eliminating external DNS and certificate provider dependencies.

### economic-model-aggressively-entry-friendly [IN] OBSERVATION
Hetzner's economic model is aggressively entry-friendly — no minimum contracts, hourly billing with monthly caps, and comprehensive free infrastructure services (firewalls, DDoS, private networks, IPv6, support) minimize both financial risk and ongoing overhead for new deployments.

### elastic-billing-no-commitment [IN] OBSERVATION
Hetzner Cloud's billing model is fully elastic with no minimum commitment — hourly metering with monthly caps means costs scale linearly with usage but never exceed fixed rates.

### eu-data-sovereignty-complete-but-non-exportable [IN] OBSERVATION
EU data sovereignty is achievable using Hetzner's self-operated German datacenters with co-located Object Storage, but this sovereignty model cannot extend internationally — non-EU locations use third-party facilities and lack Object Storage entirely, making the EU sovereignty architecture a dead end for global expansion.

### firewall-decoupled-dynamic-policy [IN] OBSERVATION
Hetzner Cloud Firewalls operate as decoupled top-level resources with many-to-many server relationships and dynamic label-selector application, enabling policy-as-code security management where firewall rules automatically apply to any server matching a label selector.

### firewall-dynamic-policy-with-protocol-complexity [IN] OBSERVATION
Hetzner Cloud firewalls combine powerful dynamic policy primitives (decoupled many-to-many server relationships, label-selector auto-application across the fleet) with protocol-specific configuration complexity (port valid only for TCP/UDP, direction-driven IP flag requirements, CIDR notation) — powerful at the policy level but requiring protocol-aware rule templating for reliable automation.

### firewall-rules-protocol-asymmetric-requirements [IN] OBSERVATION
Firewall rule configuration has protocol-asymmetric requirements — port specification is valid only for TCP/UDP (not ICMP/ESP/GRE), direction determines which IP flag is required (source for inbound, destination for outbound), and CIDR notation is mandatory for all IP specifications.

### firewalls-stateless-and-free [IN] OBSERVATION
Hetzner Cloud Firewalls are stateless and incur no additional cost.
- Source: entries/2026/03/11/hetzner-cloud-networking.md
- Source hash: 490d8986b7c63e22
- Date: 2026-03-11

### floating-ips-datacenter-scoped [IN] OBSERVATION
Floating IPs are datacenter-scoped (same datacenter only) and persist independently of server lifecycle.
- Source: entries/2026/03/11/hetzner-cloud-networking.md
- Source hash: 490d8986b7c63e22
- Date: 2026-03-11

### ftl2-hcloud-collection-fqcn [IN] OBSERVATION
FTL2 can run hetzner.hcloud collection modules via FQCN syntax (e.g., `ftl.hetzner.hcloud.server(...)`) for all Cloud API resources.
- Source: entries/2026/03/11/automation.md
- Source hash: 25026b86e8ed2e95
- Date: 2026-03-11

### ftl2-native-modules-250x-faster [IN] OBSERVATION
FTL2 native modules execute in-process over SSH, running 250x faster than Ansible subprocess mode for post-provisioning configuration.
- Source: entries/2026/03/11/automation.md
- Source hash: 25026b86e8ed2e95
- Date: 2026-03-11

### ftl2-no-native-hetzner-modules-yet [IN] OBSERVATION
FTL2 has no native Hetzner modules yet; only an AWS EC2 module stub exists as a pattern for future implementation.
- Source: entries/2026/03/11/automation.md
- Source hash: 25026b86e8ed2e95
- Date: 2026-03-11

### ftl2-runs-ansible-modules-without-yaml [IN] OBSERVATION
FTL2 runs Ansible collection modules directly from Python async/await code without YAML playbooks, achieving 3-17x faster execution than ansible-playbook.
- Source: entries/2026/03/11/automation.md
- Source hash: 25026b86e8ed2e95
- Date: 2026-03-11

### ftl2-secret-bindings-hcloud-token [IN] OBSERVATION
FTL2 injects HCLOUD_TOKEN via secret_bindings configuration, preventing token exposure in code or audit logs.
- Source: entries/2026/03/11/automation.md
- Source hash: 25026b86e8ed2e95
- Date: 2026-03-11

### ftl2-state-file-idempotent [IN] OBSERVATION
FTL2 uses a `.ftl2-state.json` state file for idempotent provisioning and crash recovery of infrastructure resources.
- Source: entries/2026/03/11/automation.md
- Source hash: 25026b86e8ed2e95
- Date: 2026-03-11

### hcloud-alias-ips-multiple-per-server [IN] OBSERVATION
Alias IPs allow a single server to hold multiple IP addresses on the same network.
- Source: entries/2026/03/11/hcloud_server_attach-to-network.md
- Source hash: d51ad7faaff9c18b
- Date: 2026-03-11

### hcloud-api-default-endpoint [IN] OBSERVATION
The default Hetzner Cloud API endpoint is `https://api.hetzner.cloud/v1`; the separate Hetzner endpoint is `https://api.hetzner.com/v1`.
- Source: entries/2026/03/11/hcloud_firewall.md
- Source hash: 7fe48d533a5cc4c8
- Date: 2026-03-11

### hcloud-api-endpoint [IN] OBSERVATION
The default Hetzner API endpoint is `https://api.hetzner.com/v1`.
- Source: entries/2026/03/11/hcloud_volume_describe.md
- Source hash: 7d9b56fdfc0b7af0
- Date: 2026-03-11

### hcloud-api-endpoints [IN] OBSERVATION
The default Hetzner Cloud API endpoint is `https://api.hetzner.cloud/v1` and the default Hetzner (non-cloud) API endpoint is `https://api.hetzner.com/v1`.
- Source: entries/2026/03/11/hcloud_load-balancer_describe.md
- Source hash: e224d23641abc402
- Date: 2026-03-11

### hcloud-attach-network-ip-auto-assigned [IN] OBSERVATION
When attaching a server to a network, IP address and subnet are auto-assigned by default; explicit assignment is optional.
- Source: entries/2026/03/11/hcloud_server_attach-to-network.md
- Source hash: d51ad7faaff9c18b
- Date: 2026-03-11

### hcloud-attach-network-required-flag [IN] OBSERVATION
The `--network` flag is the only required option for `hcloud server attach-to-network`.
- Source: entries/2026/03/11/hcloud_server_attach-to-network.md
- Source hash: d51ad7faaff9c18b
- Date: 2026-03-11

### hcloud-backups-cost-20pct-max-7 [IN] OBSERVATION
Automatic backups cost 20% of instance price, with a maximum of 7 retained
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-cax-arm-most-cost-efficient [IN] OBSERVATION
The CAX (ARM Ampere) server series is the most cost-efficient Hetzner Cloud series.
- Source: entries/2026/03/11/hetzner-cloud-pricing-billing.md
- Source hash: 77bd045e7fa9b939
- Date: 2026-03-11

### hcloud-ccx-dedicated-higher-ram-ratio [IN] OBSERVATION
CCX (dedicated vCPU) servers have higher RAM-to-CPU ratios than shared lines (e.g., CCX13 = 2 vCPU / 8GB vs CX22 = 2 vCPU / 4GB).
- Source: entries/2026/03/11/hetzner-cloud-pricing-billing.md
- Source hash: 77bd045e7fa9b939
- Date: 2026-03-11

### hcloud-certificate-retry-managed-only [IN] OBSERVATION
The `hcloud certificate retry` subcommand applies only to managed certificates, re-attempting automatic issuance after a failure.
- Source: entries/2026/03/11/hcloud_certificate.md
- Source hash: 31003d708527f381
- Date: 2026-03-11

### hcloud-certificate-two-types [IN] OBSERVATION
Hetzner Cloud certificates can be either uploaded (user-provided) or managed (issued automatically by Hetzner via Let's Encrypt integration).
- Source: entries/2026/03/11/hcloud_certificate.md
- Source hash: 31003d708527f381
- Date: 2026-03-11

### hcloud-cli-completions-bash-zsh-fish-powershell [IN] OBSERVATION
The hcloud CLI supports shell completions for bash, zsh, fish, and PowerShell.
- Source: entries/2026/03/11/cli-setup-tutorial.md
- Source hash: 33f243b275327416
- Date: 2026-03-11

### hcloud-cli-config-path [IN] OBSERVATION
The hcloud CLI config file is stored at `~/.config/hcloud/cli.toml`.
- Source: entries/2026/03/11/cli-setup-tutorial.md
- Source hash: 33f243b275327416
- Date: 2026-03-11

### hcloud-cli-default-config-path [IN] OBSERVATION
The default hcloud CLI config file location is `~/.config/hcloud/cli.toml`.
- Source: entries/2026/03/11/hcloud_server_describe.md
- Source hash: a29580fce8792cbe
- Date: 2026-03-11

### hcloud-cli-default-poll-interval [IN] OBSERVATION
The default hcloud CLI poll interval for action progress is 500ms.
- Source: entries/2026/03/11/hcloud_server_list.md
- Source hash: aa554e0633b9464c
- Date: 2026-03-11

### hcloud-cli-docker-image-alpine [IN] OBSERVATION
The hcloud CLI Docker image (`hetznercloud/cli`) is Alpine-based with config mounted at `/config.toml`.
- Source: entries/2026/03/11/cli-setup-tutorial.md
- Source hash: 33f243b275327416
- Date: 2026-03-11

### hcloud-cli-repo [IN] OBSERVATION
The hcloud CLI is hosted at `github.com/hetznercloud/cli`.
- Source: entries/2026/03/11/cli-setup-tutorial.md
- Source hash: 33f243b275327416
- Date: 2026-03-11

### hcloud-cloud-api-endpoint [IN] OBSERVATION
The default Hetzner Cloud API endpoint is `https://api.hetzner.cloud/v1`.
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-config-default-path [IN] OBSERVATION
The hcloud CLI default config file path is `~/.config/hcloud/cli.toml` (TOML format).
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-context-bound-to-project [IN] OBSERVATION
Each hcloud context binds to a Hetzner Cloud API token, which is scoped to a single Hetzner Cloud project.
- Source: entries/2026/03/11/hcloud_context.md
- Source hash: 9a147f172c3c9085
- Date: 2026-03-11

### hcloud-context-create-interactive [IN] OBSERVATION
`hcloud context create <name>` is interactive and prompts for the API token.
- Source: entries/2026/03/11/cli-setup-tutorial.md
- Source hash: 33f243b275327416
- Date: 2026-03-11

### hcloud-context-one-active [IN] OBSERVATION
Only one hcloud context is active at a time; it determines which project API calls target, and can be overridden per-command with `--context`.
- Source: entries/2026/03/11/hcloud_context.md
- Source hash: 9a147f172c3c9085
- Date: 2026-03-11

### hcloud-context-use-vs-unset [IN] OBSERVATION
`hcloud context use` sets the active context persistently; `hcloud context unset` clears/deactivates the current context.
- Source: entries/2026/03/11/hcloud_context.md
- Source hash: 9a147f172c3c9085
- Date: 2026-03-11

### hcloud-create-image-labels-repeatable [IN] OBSERVATION
Labels on `hcloud server create-image` use `key=value` syntax and can be specified multiple times via repeated `--label` flags.
- Source: entries/2026/03/11/hcloud_server_create-image.md
- Source hash: 14e63a237e89f7bc
- Date: 2026-03-11

### hcloud-create-image-type-required [IN] OBSERVATION
The `--type` flag is required for `hcloud server create-image` and must be `snapshot` or `backup`.
- Source: entries/2026/03/11/hcloud_server_create-image.md
- Source hash: 14e63a237e89f7bc
- Date: 2026-03-11

### hcloud-datacenter-attribute-deprecated [IN] OBSERVATION
The `datacenter` attribute is deprecated for Primary IPs and Servers in hcloud CLI v1.59.0; `location` is the replacement concept.
- Source: entries/2026/03/11/hetzner-cli-changelog-recent.md
- Source hash: 4700c15482f6cb74
- Date: 2026-03-11

### hcloud-datacenter-read-only [IN] OBSERVATION
The `hcloud datacenter` command group is read-only with only two subcommands: `list` and `describe`.
- Source: entries/2026/03/11/hcloud_datacenter.md
- Source hash: f1fc80539d5fd52b
- Date: 2026-03-11

### hcloud-ddos-protection-free [IN] OBSERVATION
DDoS protection is free and implemented via hardware appliances
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-default-api-endpoint [IN] OBSERVATION
The default Hetzner Cloud API endpoint is `https://api.hetzner.cloud/v1`.
- Source: entries/2026/03/11/hcloud_placement-group_create.md
- Source hash: 84a8217663c2825f
- Date: 2026-03-11

### hcloud-default-config-path [IN] OBSERVATION
The default hcloud CLI config file location is `~/.config/hcloud/cli.toml`
- Source: entries/2026/03/11/hcloud_ssh-key_create.md
- Source hash: f351d1cae0072169
- Date: 2026-03-11

### hcloud-default-poll-interval [IN] OBSERVATION
The hcloud CLI default poll interval for checking action progress is 500ms.
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-default-poll-interval-500ms [IN] OBSERVATION
The default poll interval for the `hcloud` CLI is 500ms.
- Source: entries/2026/03/11/hcloud_firewall_describe.md
- Source hash: c2102fe489e368c5
- Date: 2026-03-11

### hcloud-dns-16-supported-record-types [IN] OBSERVATION
Hetzner DNS supports 16 record types: A, AAAA, CAA, CNAME, DS, HINFO, HTTPS, MX, NS, PTR, RP, SOA, SRV, SVCB, TLSA, TXT.
- Source: entries/2026/03/11/hcloud_zone_rrset_create.md
- Source hash: 44017c79f609d1fb
- Date: 2026-03-11

### hcloud-dns-api-endpoint [IN] OBSERVATION
The Hetzner DNS API uses the endpoint `https://api.hetzner.com/v1`, distinct from the Cloud API at `api.hetzner.cloud`.
- Source: entries/2026/03/11/hcloud_zone_describe.md
- Source hash: ad001b367ab3a945
- Date: 2026-03-11

### hcloud-dns-api-ga-v1-57 [IN] OBSERVATION
DNS API support graduated to GA (no longer experimental) in hcloud CLI v1.57.0.
- Source: entries/2026/03/11/hetzner-cli-changelog-recent.md
- Source hash: 4700c15482f6cb74
- Date: 2026-03-11

### hcloud-experimental-features-break-in-minor [IN] OBSERVATION
Both hcloud-go and hcloud-python experimental features may introduce breaking changes in minor releases.
- Source: entries/2026/03/11/hcloud-python-readme.md
- Source hash: 601589321e5115fb
- Date: 2026-03-11

### hcloud-firewall-apply-type-required [IN] OBSERVATION
The `--type` flag is required when applying a firewall to a resource, with two valid values: `server` and `label_selector`.
- Source: entries/2026/03/11/hcloud_firewall_apply-to-resource.md
- Source hash: a0ae1f71b7b7b6b3
- Date: 2026-03-11

### hcloud-firewall-create-name-required [IN] OBSERVATION
The `--name` flag is required when creating a firewall with `hcloud firewall create`.
- Source: entries/2026/03/11/hcloud_firewall_create.md
- Source hash: 8050a3a2ec7daa17
- Date: 2026-03-11

### hcloud-firewall-create-rules-file-stdin [IN] OBSERVATION
`hcloud firewall create` accepts `--rules-file` to load rules from a JSON file, or `-` to read from stdin.
- Source: entries/2026/03/11/hcloud_firewall_create.md
- Source hash: 8050a3a2ec7daa17
- Date: 2026-03-11

### hcloud-firewall-describe-accepts-name-or-id [IN] OBSERVATION
`hcloud firewall describe` accepts either a firewall name or ID as the positional argument.
- Source: entries/2026/03/11/hcloud_firewall_describe.md
- Source hash: c2102fe489e368c5
- Date: 2026-03-11

### hcloud-firewall-describe-output-formats [IN] OBSERVATION
`hcloud firewall describe` supports `json`, `yaml`, and custom `format` output via the `-o` flag.
- Source: entries/2026/03/11/hcloud_firewall_describe.md
- Source hash: c2102fe489e368c5
- Date: 2026-03-11

### hcloud-firewall-five-protocols [IN] OBSERVATION
Hetzner Cloud firewall rules support five protocols: `tcp`, `udp`, `icmp`, `esp`, and `gre`.
- Source: entries/2026/03/11/hcloud_firewall_add-rule.md
- Source hash: 0f4938f814407c0a
- Date: 2026-03-11

### hcloud-firewall-ips-cidr-notation [IN] OBSERVATION
Firewall rule IP addresses must be specified in CIDR notation (e.g., `0.0.0.0/0` for all IPv4).
- Source: entries/2026/03/11/hcloud_firewall_add-rule.md
- Source hash: 0f4938f814407c0a
- Date: 2026-03-11

### hcloud-firewall-label-selector-dynamic-application [IN] OBSERVATION
Using `--type label_selector` with `hcloud firewall apply-to-resource` dynamically applies the firewall to all resources matching the label.
- Source: entries/2026/03/11/hcloud_firewall_apply-to-resource.md
- Source hash: a0ae1f71b7b7b6b3
- Date: 2026-03-11

### hcloud-firewall-many-to-many-with-servers [IN] OBSERVATION
Firewalls are decoupled from servers in a many-to-many relationship, applied individually via `apply-to-resource` and removed via `remove-from-resource`.
- Source: entries/2026/03/11/hcloud_firewall.md
- Source hash: 7fe48d533a5cc4c8
- Date: 2026-03-11

### hcloud-firewall-port-only-tcp-udp [IN] OBSERVATION
The `--port` flag on firewall rules is only valid for `tcp` and `udp` protocols; it cannot be used with `icmp`, `esp`, or `gre`.
- Source: entries/2026/03/11/hcloud_firewall_add-rule.md
- Source hash: 0f4938f814407c0a
- Date: 2026-03-11

### hcloud-firewall-port-range-dash-syntax [IN] OBSERVATION
Firewall rule port ranges use dash syntax (e.g., `80-85`).
- Source: entries/2026/03/11/hcloud_firewall_add-rule.md
- Source hash: 0f4938f814407c0a
- Date: 2026-03-11

### hcloud-firewall-rule-direction-determines-ip-flag [IN] OBSERVATION
Firewall rule direction determines the required IP flag: `in` requires `--source-ips`, `out` requires `--destination-ips`.
- Source: entries/2026/03/11/hcloud_firewall_add-rule.md
- Source hash: 0f4938f814407c0a
- Date: 2026-03-11

### hcloud-firewall-rule-management-two-approaches [IN] OBSERVATION
Firewall rules can be managed individually (`add-rule`/`delete-rule`) or replaced in bulk from a file (`replace-rules`).
- Source: entries/2026/03/11/hcloud_firewall.md
- Source hash: 7fe48d533a5cc4c8
- Date: 2026-03-11

### hcloud-firewall-top-level-resource [IN] OBSERVATION
Firewalls are a top-level resource in Hetzner Cloud, managed through the `hcloud firewall` command group.
- Source: entries/2026/03/11/hcloud_firewall.md
- Source hash: 7fe48d533a5cc4c8
- Date: 2026-03-11

### hcloud-firewalls-stateless-and-free [IN] OBSERVATION
Hetzner Cloud Firewalls are stateless (not stateful) and free of charge
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-free-services-list [IN] OBSERVATION
DDoS protection, firewalls, private networks, 24/7 support, and IPv6 are all free on Hetzner Cloud.
- Source: entries/2026/03/11/hetzner-cloud-pricing-billing.md
- Source hash: 77bd045e7fa9b939
- Date: 2026-03-11

### hcloud-german-dcs-self-operated [IN] OBSERVATION
German datacenters (NBG1, FSN1) are Hetzner-operated; US and Singapore use third-party facilities
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-go-async-actions-must-await [IN] OBSERVATION
Hetzner Cloud API operations are async — `client.Action.WaitFor()` must be called before using results.
- Source: entries/2026/03/11/hcloud-go-readme.md
- Source hash: 816ed32a2d866d72
- Date: 2026-03-11

### hcloud-go-install-no-version [IN] OBSERVATION
Go-built hcloud binaries do not have the correct version embedded.
- Source: entries/2026/03/11/cli-setup-tutorial.md
- Source hash: 33f243b275327416
- Date: 2026-03-11

### hcloud-go-supports-latest-two-go-versions [IN] OBSERVATION
hcloud-go supports the latest two Go minor versions, matching Go's official release policy.
- Source: entries/2026/03/11/hcloud-go-readme.md
- Source hash: 816ed32a2d866d72
- Date: 2026-03-11

### hcloud-go-v1-unsupported-feb-2025 [IN] OBSERVATION
hcloud-go v1 has been unsupported since February 2025.
- Source: entries/2026/03/11/hcloud-go-readme.md
- Source hash: 816ed32a2d866d72
- Date: 2026-03-11

### hcloud-go-v2-id-int64 [IN] OBSERVATION
The key v1-to-v2 breaking change in hcloud-go was `ID` fields moving from `int` to `int64`.
- Source: entries/2026/03/11/hcloud-go-readme.md
- Source hash: 816ed32a2d866d72
- Date: 2026-03-11

### hcloud-go-v2-import-path [IN] OBSERVATION
The hcloud-go v2 import path is `github.com/hetznercloud/hcloud-go/v2/hcloud`.
- Source: entries/2026/03/11/hcloud-go-readme.md
- Source hash: 816ed32a2d866d72
- Date: 2026-03-11

### hcloud-hetzner-api-endpoint [IN] OBSERVATION
The default Hetzner API endpoint is `https://api.hetzner.com/v1`, separate from the Cloud API endpoint.
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-hourly-billing-monthly-cap [IN] OBSERVATION
Hetzner Cloud uses hourly billing with monthly price caps — customers never pay more than the fixed monthly rate.
- Source: entries/2026/03/11/hetzner-cloud-pricing-billing.md
- Source hash: 77bd045e7fa9b939
- Date: 2026-03-11

### hcloud-ipv4-charged-even-unassigned [IN] OBSERVATION
Primary IPv4 addresses are charged even when unassigned to a server; IPv6 is always free.
- Source: entries/2026/03/11/hetzner-cloud-pricing-billing.md
- Source hash: 77bd045e7fa9b939
- Date: 2026-03-11

### hcloud-iso-attach-to-server [IN] OBSERVATION
ISOs can be attached to servers during creation via `hcloud server create --iso` or mounted later for rescue/installation.
- Source: entries/2026/03/11/hcloud_iso.md
- Source hash: 7bb324fa7a1de4fa
- Date: 2026-03-11

### hcloud-iso-distinct-from-image [IN] OBSERVATION
ISOs (vendor-provided installation media) are distinct from images (user-created snapshots/backups managed via `hcloud image`).
- Source: entries/2026/03/11/hcloud_iso.md
- Source hash: 7bb324fa7a1de4fa
- Date: 2026-03-11

### hcloud-iso-not-user-uploadable [IN] OBSERVATION
Users cannot upload custom ISOs through the `hcloud` CLI; ISOs are managed/provided by Hetzner.
- Source: entries/2026/03/11/hcloud_iso.md
- Source hash: 7bb324fa7a1de4fa
- Date: 2026-03-11

### hcloud-iso-read-only-cli [IN] OBSERVATION
ISOs in Hetzner Cloud are read-only resources via the CLI — only `list` and `describe` subcommands exist, with no create or delete operations.
- Source: entries/2026/03/11/hcloud_iso.md
- Source hash: 7bb324fa7a1de4fa
- Date: 2026-03-11

### hcloud-lb-algorithm-default-round-robin [IN] OBSERVATION
The Load Balancer algorithm defaults to `round_robin` if `--algorithm-type` is not specified; the other option is `least_connections`.
- Source: entries/2026/03/11/hcloud_load-balancer_create.md
- Source hash: 25000966517adf26
- Date: 2026-03-11

### hcloud-lb-algorithm-round-robin-or-least-connections [IN] OBSERVATION
Hetzner Cloud Load Balancer supports two algorithms: round_robin (default) and least_connections.
- Source: entries/2026/03/11/hetzner-operational-patterns.md
- Source hash: ac3a343119d96d0b
- Date: 2026-03-11

### hcloud-lb-attach-ip-range-cidr [IN] OBSERVATION
The `--ip-range` flag on `hcloud load-balancer attach-to-network` accepts a CIDR block (ipNet type) specifying which subnet to attach to.
- Source: entries/2026/03/11/hcloud_load-balancer_attach-to-network.md
- Source hash: 9d02212c740286ba
- Date: 2026-03-11

### hcloud-lb-attach-network-cmd [IN] OBSERVATION
The `hcloud load-balancer attach-to-network` command attaches a Hetzner Cloud Load Balancer to a private Network.
- Source: entries/2026/03/11/hcloud_load-balancer_attach-to-network.md
- Source hash: 9d02212c740286ba
- Date: 2026-03-11

### hcloud-lb-attach-network-flag-required [IN] OBSERVATION
The `--network` flag is the only required option for `hcloud load-balancer attach-to-network`; IP and subnet are auto-assigned if omitted.
- Source: entries/2026/03/11/hcloud_load-balancer_attach-to-network.md
- Source hash: 9d02212c740286ba
- Date: 2026-03-11

### hcloud-lb-change-algorithm-post-creation [IN] OBSERVATION
The load balancer balancing algorithm can be changed after creation using `hcloud load-balancer change-algorithm`.
- Source: entries/2026/03/11/hcloud_load-balancer.md
- Source hash: a077c6ab2e3620d2
- Date: 2026-03-11

### hcloud-lb-change-type-post-creation [IN] OBSERVATION
Load Balancer type can be changed after creation using `hcloud load-balancer change-type`, enabling vertical scaling.
- Source: entries/2026/03/11/hcloud_load-balancer.md
- Source hash: a077c6ab2e3620d2
- Date: 2026-03-11

### hcloud-lb-create-network-at-creation [IN] OBSERVATION
A Load Balancer can be attached to a network at creation time using the `--network` flag on `hcloud load-balancer create`.
- Source: entries/2026/03/11/hcloud_load-balancer_create.md
- Source hash: 25000966517adf26
- Date: 2026-03-11

### hcloud-lb-create-required-flags [IN] OBSERVATION
`hcloud load-balancer create` requires both `--name` and `--type` flags.
- Source: entries/2026/03/11/hcloud_load-balancer_create.md
- Source hash: 25000966517adf26
- Date: 2026-03-11

### hcloud-lb-describe-expand-targets [IN] OBSERVATION
The `--expand-targets` flag on `hcloud load-balancer describe` resolves label_selector targets to show the actual matched resources.
- Source: entries/2026/03/11/hcloud_load-balancer_describe.md
- Source hash: e224d23641abc402
- Date: 2026-03-11

### hcloud-lb-detach-from-network-inverse [IN] OBSERVATION
The inverse of `hcloud load-balancer attach-to-network` is `hcloud load-balancer detach-from-network`.
- Source: entries/2026/03/11/hcloud_load-balancer_attach-to-network.md
- Source hash: 9d02212c740286ba
- Date: 2026-03-11

### hcloud-lb-http-redirect-80-to-443 [IN] OBSERVATION
The `--http-redirect-http` flag on `add-service` redirects port 80 traffic to port 443.
- Source: entries/2026/03/11/hcloud_load-balancer_add-service.md
- Source hash: a202773279c01286
- Date: 2026-03-11

### hcloud-lb-label-selector-targets-dynamic [IN] OBSERVATION
Label-selector targets on Load Balancers are dynamic — servers matching the selector are automatically included or excluded.
- Source: entries/2026/03/11/hcloud_load-balancer_add-target.md
- Source hash: 1893888b57d00ced
- Date: 2026-03-11

### hcloud-lb-metrics-alpha [IN] OBSERVATION
The `hcloud load-balancer metrics` subcommand is marked as ALPHA and is not stable/GA.
- Source: entries/2026/03/11/hcloud_load-balancer.md
- Source hash: a077c6ab2e3620d2
- Date: 2026-03-11

### hcloud-lb-private-ip-requires-shared-network [IN] OBSERVATION
Using `--use-private-ip` for Load Balancer targets requires the load balancer to be attached to a network that the target is also part of.
- Source: entries/2026/03/11/hcloud_load-balancer_add-target.md
- Source hash: 1893888b57d00ced
- Date: 2026-03-11

### hcloud-lb-private-only-mode [IN] OBSERVATION
Hetzner Cloud Load Balancers can operate without a public interface (private-only mode) when attached to a network.
- Source: entries/2026/03/11/hcloud_load-balancer.md
- Source hash: a077c6ab2e3620d2
- Date: 2026-03-11

### hcloud-lb-protection-type-delete-only [IN] OBSERVATION
The only protection type available for Hetzner Cloud Load Balancers is `delete`.
- Source: entries/2026/03/11/hcloud_load-balancer_create.md
- Source hash: 25000966517adf26
- Date: 2026-03-11

### hcloud-lb-service-default-health-check [IN] OBSERVATION
Default health check values for Load Balancer services are: interval 15s, timeout 10s, retries 3.
- Source: entries/2026/03/11/hcloud_load-balancer_add-service.md
- Source hash: a202773279c01286
- Date: 2026-03-11

### hcloud-lb-service-protocols [IN] OBSERVATION
Load Balancer services support three protocols: HTTP, HTTPS, and TCP.
- Source: entries/2026/03/11/hcloud_load-balancer_add-service.md
- Source hash: a202773279c01286
- Date: 2026-03-11

### hcloud-lb-sticky-sessions-cookie-based [IN] OBSERVATION
Load Balancer sticky sessions are cookie-based, requiring `--http-sticky-sessions` plus `--http-cookie-name` and `--http-cookie-lifetime` configuration.
- Source: entries/2026/03/11/hcloud_load-balancer_add-service.md
- Source hash: a202773279c01286
- Date: 2026-03-11

### hcloud-lb-tcp-requires-ports [IN] OBSERVATION
TCP protocol services require both `--listen-port` and `--destination-port` flags; HTTPS requires `--http-certificates`; HTTP needs only `--protocol`.
- Source: entries/2026/03/11/hcloud_load-balancer_add-service.md
- Source hash: a202773279c01286
- Date: 2026-03-11

### hcloud-lb-three-target-types [IN] OBSERVATION
Load Balancer targets come in three mutually exclusive types per invocation: `--server` (name/ID), `--label-selector` (dynamic group), or `--ip` (direct IP address).
- Source: entries/2026/03/11/hcloud_load-balancer_add-target.md
- Source hash: 1893888b57d00ced
- Date: 2026-03-11

### hcloud-lb-type-read-only [IN] OBSERVATION
The `hcloud load-balancer-type` command group is read-only with only `list` and `describe` subcommands — load balancer types are predefined by Hetzner.
- Source: entries/2026/03/11/hcloud_load-balancer-type.md
- Source hash: e7fb70804be0b77e
- Date: 2026-03-11

### hcloud-local-ssd-raid10 [IN] OBSERVATION
Cloud Server local SSD storage uses RAID10 configuration for fault tolerance
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-location-datacenter-relationship [IN] OBSERVATION
Locations are grouped into datacenters; a single location can contain multiple datacenters.
- Source: entries/2026/03/11/hcloud_location.md
- Source hash: dd2386d931874206
- Date: 2026-03-11

### hcloud-location-read-only [IN] OBSERVATION
The `hcloud location` command group is read-only with only `list` and `describe` subcommands — locations are immutable infrastructure metadata defined by Hetzner.
- Source: entries/2026/03/11/hcloud_location.md
- Source hash: dd2386d931874206
- Date: 2026-03-11

### hcloud-locations-contain-datacenters [IN] OBSERVATION
Hetzner Cloud locations contain datacenters; datacenters are referenced when creating servers, volumes, and other location-bound resources.
- Source: entries/2026/03/11/hcloud_datacenter.md
- Source hash: f1fc80539d5fd52b
- Date: 2026-03-11

### hcloud-network-add-route-destination-is-ipnet-gateway-is-ip [IN] OBSERVATION
In `hcloud network add-route`, `--destination` accepts `ipNet` type (CIDR notation) and `--gateway` accepts `ip` type (single address).
- Source: entries/2026/03/11/hcloud_network_add-route.md
- Source hash: ab78d7976320a5bf
- Date: 2026-03-11

### hcloud-network-add-route-network-must-exist [IN] OBSERVATION
Routes are added to existing networks — the network must already exist before adding a route with `hcloud network add-route`.
- Source: entries/2026/03/11/hcloud_network_add-route.md
- Source hash: ab78d7976320a5bf
- Date: 2026-03-11

### hcloud-network-add-route-requires-destination-and-gateway [IN] OBSERVATION
The `hcloud network add-route` command requires both `--destination` (CIDR notation) and `--gateway` (single IP) flags.
- Source: entries/2026/03/11/hcloud_network_add-route.md
- Source hash: ab78d7976320a5bf
- Date: 2026-03-11

### hcloud-network-add-subnet-requires-type-and-network-zone [IN] OBSERVATION
The `hcloud network add-subnet` command requires `--type` and `--network-zone` as mandatory flags.
- Source: entries/2026/03/11/hcloud_network_add-subnet.md
- Source hash: 505518735023adb9
- Date: 2026-03-11

### hcloud-network-create-requires-name-and-ip-range [IN] OBSERVATION
The `hcloud network create` command requires `--name` and `--ip-range` as mandatory flags.
- Source: entries/2026/03/11/hcloud_network_create.md
- Source hash: 35a89b4d4734950a
- Date: 2026-03-11

### hcloud-network-describe-accepts-name-or-id [IN] OBSERVATION
The `hcloud network describe` command accepts either a network name or numeric ID as the argument.
- Source: entries/2026/03/11/hcloud_network_describe.md
- Source hash: 002449a06632aa1b
- Date: 2026-03-11

### hcloud-network-expose-routes-to-vswitch-option [IN] OBSERVATION
Networks support `--expose-routes-to-vswitch` to bridge cloud network routes with dedicated server vSwitch connections.
- Source: entries/2026/03/11/hcloud_network_create.md
- Source hash: 35a89b4d4734950a
- Date: 2026-03-11

### hcloud-network-expose-routes-vswitch [IN] OBSERVATION
The `hcloud network expose-routes-to-vswitch` subcommand enables hybrid connectivity between Hetzner Cloud networks and dedicated server vSwitches.
- Source: entries/2026/03/11/hcloud_network.md
- Source hash: c05b2c03982b01f6
- Date: 2026-03-11

### hcloud-network-ip-range-changeable [IN] OBSERVATION
The IP range of an existing Hetzner Cloud network can be changed after creation using `hcloud network change-ip-range`.
- Source: entries/2026/03/11/hcloud_network.md
- Source hash: c05b2c03982b01f6
- Date: 2026-03-11

### hcloud-network-only-protection-type-is-delete [IN] OBSERVATION
Delete protection is the only protection type available for Hetzner Cloud networks.
- Source: entries/2026/03/11/hcloud_network_create.md
- Source hash: 35a89b4d4734950a
- Date: 2026-03-11

### hcloud-network-reference-id-or-name [IN] OBSERVATION
Networks can be referenced by either ID or name in hcloud CLI commands.
- Source: entries/2026/03/11/hcloud_server_attach-to-network.md
- Source hash: d51ad7faaff9c18b
- Date: 2026-03-11

### hcloud-network-resource-protection [IN] OBSERVATION
Hetzner Cloud Networks support resource protection that must be explicitly enabled/disabled via `enable-protection` and `disable-protection` subcommands.
- Source: entries/2026/03/11/hcloud_network.md
- Source hash: c05b2c03982b01f6
- Date: 2026-03-11

### hcloud-network-sub-resources [IN] OBSERVATION
Hetzner Cloud Networks support three sub-resource types: subnets, routes, and labels.
- Source: entries/2026/03/11/hcloud_network.md
- Source hash: c05b2c03982b01f6
- Date: 2026-03-11

### hcloud-network-subnet-ip-range-optional-auto-allocated [IN] OBSERVATION
The `--ip-range` flag on `hcloud network add-subnet` is optional; if omitted, Hetzner auto-allocates from the network's IP range.
- Source: entries/2026/03/11/hcloud_network_add-subnet.md
- Source hash: 505518735023adb9
- Date: 2026-03-11

### hcloud-network-subnet-three-types [IN] OBSERVATION
Hetzner Cloud network subnets have exactly three types: `cloud`, `server`, and `vswitch`.
- Source: entries/2026/03/11/hcloud_network_add-subnet.md
- Source hash: 505518735023adb9
- Date: 2026-03-11

### hcloud-network-subnet-vswitch-requires-vswitch-id [IN] OBSERVATION
The `--vswitch-id` flag is required when subnet type is `vswitch` and only relevant for that type.
- Source: entries/2026/03/11/hcloud_network_add-subnet.md
- Source hash: 505518735023adb9
- Date: 2026-03-11

### hcloud-network-subnets-scoped-to-network-zone [IN] OBSERVATION
Hetzner Cloud subnets are scoped to a network zone (e.g., `eu-central`), not to a specific datacenter location.
- Source: entries/2026/03/11/hcloud_network_add-subnet.md
- Source hash: 505518735023adb9
- Date: 2026-03-11

### hcloud-no-minimum-contract [IN] OBSERVATION
Hetzner Cloud has no minimum contract; it is pure pay-as-you-go.
- Source: entries/2026/03/11/hetzner-cloud-pricing-billing.md
- Source hash: 77bd045e7fa9b939
- Date: 2026-03-11

### hcloud-object-storage-base-eur-4-99 [IN] OBSERVATION
Hetzner Object Storage base tier is EUR 4.99/month including 1TB storage and 1TB egress.
- Source: entries/2026/03/11/hetzner-cloud-pricing-billing.md
- Source hash: 77bd045e7fa9b939
- Date: 2026-03-11

### hcloud-object-storage-empty-bucket-billed [IN] OBSERVATION
Empty active buckets in Hetzner Object Storage still incur hourly charges.
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-object-storage-eu-only-three-regions [IN] OBSERVATION
Hetzner Object Storage is available in three EU regions only: FSN1, HEL1, NBG1 (no US or Singapore).
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-object-storage-free-ingress-and-api [IN] OBSERVATION
Ingress traffic, internal eu-central zone traffic, and all S3 API calls are free for Hetzner Object Storage.
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-object-storage-limits [IN] OBSERVATION
Hetzner Object Storage limits: 100 buckets per account, 100 TB per bucket, 50M objects per bucket.
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-object-storage-min-64kb-billing [IN] OBSERVATION
Objects smaller than 64 KB in Hetzner Object Storage are billed as 64 KB.
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-object-storage-no-quota-rollover [IN] OBSERVATION
Unused included storage and egress in Hetzner Object Storage does not roll over month to month.
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-object-storage-overage-pricing [IN] OBSERVATION
Hetzner Object Storage overage: storage EUR 0.0067/TB-h, egress EUR 1.00/TB.
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-object-storage-tb-hours-billing [IN] OBSERVATION
Object Storage uses TB-hours billing: storage consumption = TB stored × hours stored; monthly quota is 744 TB-h (1 TB × 744 hours).
- Source: entries/2026/03/11/hetzner-object-storage.md
- Source hash: d563a91337623b73
- Date: 2026-03-11

### hcloud-official-sdks-go-python [IN] OBSERVATION
Hetzner Cloud provides official SDKs for Go and Python; community libraries exist for other languages
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-placement-group-assigned-at-server-create [IN] OBSERVATION
Servers are assigned to placement groups at creation time via `hcloud server create --placement-group`.
- Source: entries/2026/03/11/hcloud_placement-group_create.md
- Source hash: 84a8217663c2825f
- Date: 2026-03-11

### hcloud-placement-group-assigned-at-server-creation [IN] OBSERVATION
Placement Groups are assigned to servers at creation time to control physical host distribution.
- Source: entries/2026/03/11/hcloud_placement-group.md
- Source hash: dbdc66bd474be3f9
- Date: 2026-03-11

### hcloud-placement-group-create-requires-name-and-type [IN] OBSERVATION
The `hcloud placement-group create` command requires both `--name` and `--type` flags.
- Source: entries/2026/03/11/hcloud_placement-group_create.md
- Source hash: 84a8217663c2825f
- Date: 2026-03-11

### hcloud-placement-group-describe-accepts-name-or-id [IN] OBSERVATION
The `hcloud placement-group describe` command accepts either a name or ID as the `<placement-group>` argument.
- Source: entries/2026/03/11/hcloud_placement-group_describe.md
- Source hash: 6fb7042f87404920
- Date: 2026-03-11

### hcloud-placement-group-only-spread-strategy [IN] OBSERVATION
Hetzner Cloud Placement Groups use the "spread" strategy (the only type currently supported) to ensure servers run on different physical hosts.
- Source: entries/2026/03/11/hcloud_placement-group.md
- Source hash: dbdc66bd474be3f9
- Date: 2026-03-11

### hcloud-placement-group-seven-subcommands [IN] OBSERVATION
The `hcloud placement-group` command has seven subcommands: create, delete, describe, list, update, add-label, and remove-label.
- Source: entries/2026/03/11/hcloud_placement-group.md
- Source hash: dbdc66bd474be3f9
- Date: 2026-03-11

### hcloud-placement-group-type-spread [IN] OBSERVATION
The known placement group type is `spread`, which distributes servers across different physical hosts.
- Source: entries/2026/03/11/hcloud_placement-group_create.md
- Source hash: 84a8217663c2825f
- Date: 2026-03-11

### hcloud-powered-off-still-billed [IN] OBSERVATION
Powered-off Cloud Servers are still billed because resources remain allocated; billing stops only on deletion
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-poweroff-vs-shutdown [IN] OBSERVATION
`hcloud server poweroff` is a hard power cut; `hcloud server shutdown` is a graceful ACPI shutdown.
- Source: entries/2026/03/11/hcloud_server.md
- Source hash: 2db6f8b39bde1fe6
- Date: 2026-03-11

### hcloud-primary-ip-assign-requires-server-flag [IN] OBSERVATION
The `hcloud primary-ip assign` command requires the `--server` flag (accepting name or ID) to specify the target server.
- Source: entries/2026/03/11/hcloud_primary-ip_assign.md
- Source hash: 742551cacafe319b
- Date: 2026-03-11

### hcloud-primary-ip-assignee-type-server-only [IN] OBSERVATION
The only currently supported assignee type for Primary IPs is `server`.
- Source: entries/2026/03/11/hcloud_primary-ip_assign.md
- Source hash: 742551cacafe319b
- Date: 2026-03-11

### hcloud-primary-ip-auto-delete-option [IN] OBSERVATION
Primary IPs support an `--auto-delete` flag that automatically deletes the IP when its assigned resource is deleted; without it, the IP persists.
- Source: entries/2026/03/11/hcloud_primary-ip_create.md
- Source hash: 51f816ae414bc4d8
- Date: 2026-03-11

### hcloud-primary-ip-create-requires-type-and-name [IN] OBSERVATION
The `hcloud primary-ip create` command requires both `--type` (ipv4 or ipv6) and `--name` flags.
- Source: entries/2026/03/11/hcloud_primary-ip_create.md
- Source hash: 51f816ae414bc4d8
- Date: 2026-03-11

### hcloud-primary-ip-datacenter-flag-deprecated [IN] OBSERVATION
The `--datacenter` flag on `hcloud primary-ip create` is deprecated; `--location` or `--assignee-id` should be used instead (per 2025-12-16 datacenter phase-out).
- Source: entries/2026/03/11/hcloud_primary-ip_create.md
- Source hash: 51f816ae414bc4d8
- Date: 2026-03-11

### hcloud-primary-ip-independent-of-server [IN] OBSERVATION
Primary IPs are independent resources that persist when a server is deleted, unlike default server IPs.
- Source: entries/2026/03/11/hcloud_primary-ip.md
- Source hash: 9e9d55d44e3d838d
- Date: 2026-03-11

### hcloud-primary-ip-protection-type-delete-only [IN] OBSERVATION
The `--enable-protection` flag on `hcloud primary-ip create` only supports the `delete` protection type.
- Source: entries/2026/03/11/hcloud_primary-ip_create.md
- Source hash: 51f816ae414bc4d8
- Date: 2026-03-11

### hcloud-primary-ip-supports-rdns [IN] OBSERVATION
Reverse DNS (rDNS) records can be configured directly on Primary IPs via `hcloud primary-ip set-rdns`.
- Source: entries/2026/03/11/hcloud_primary-ip.md
- Source hash: 9e9d55d44e3d838d
- Date: 2026-03-11

### hcloud-primary-ip-vs-floating-ip [IN] OBSERVATION
Primary IPs replace a server's default public IP, while Floating IPs are additional addresses routed via alias IPs or IP configuration.
- Source: entries/2026/03/11/hcloud_primary-ip.md
- Source hash: 9e9d55d44e3d838d
- Date: 2026-03-11

### hcloud-private-only-server-access-methods [IN] OBSERVATION
Private-only servers (no public IP) require a jump host, VPN, or load balancer for access.
- Source: entries/2026/03/11/hetzner-operational-patterns.md
- Source hash: ac3a343119d96d0b
- Date: 2026-03-11

### hcloud-python-create-returns-response-object [IN] OBSERVATION
`client.servers.create()` returns a response object with `.server` and `.root_password` attributes, not the server directly.
- Source: entries/2026/03/11/hcloud-python-readme.md
- Source hash: 601589321e5115fb
- Date: 2026-03-11

### hcloud-python-license-mit [IN] OBSERVATION
The hcloud Python library is MIT licensed.
- Source: entries/2026/03/11/hcloud-python-readme.md
- Source hash: 601589321e5115fb
- Date: 2026-03-11

### hcloud-python-pypi-package-name [IN] OBSERVATION
The official Hetzner Cloud Python SDK is installed via `pip install hcloud`.
- Source: entries/2026/03/11/hcloud-python-readme.md
- Source hash: 601589321e5115fb
- Date: 2026-03-11

### hcloud-python-resource-typed-objects [IN] OBSERVATION
The hcloud Python SDK references resources via typed objects: `ServerType(name=...)`, `Image(name=...)`.
- Source: entries/2026/03/11/hcloud-python-readme.md
- Source hash: 601589321e5115fb
- Date: 2026-03-11

### hcloud-reboot-vs-reset [IN] OBSERVATION
`hcloud server reboot` is a graceful reboot; `hcloud server reset` is a hard reset.
- Source: entries/2026/03/11/hcloud_server.md
- Source hash: 2db6f8b39bde1fe6
- Date: 2026-03-11

### hcloud-rebuild-destructive [IN] OBSERVATION
`hcloud server rebuild` reinstalls the OS and is a destructive operation that replaces the root disk.
- Source: entries/2026/03/11/hcloud_server.md
- Source hash: 2db6f8b39bde1fe6
- Date: 2026-03-11

### hcloud-rescue-default-type-linux64 [IN] OBSERVATION
The default rescue type for `hcloud server enable-rescue` is `linux64`.
- Source: entries/2026/03/11/hcloud_server_enable-rescue.md
- Source hash: 9b0a78b23c2ae822
- Date: 2026-03-11

### hcloud-rescue-no-automatic-reboot [IN] OBSERVATION
Enabling rescue mode with `hcloud server enable-rescue` does not automatically reboot the server; a separate reboot or reset action is required.
- Source: entries/2026/03/11/hcloud_server_enable-rescue.md
- Source hash: 9b0a78b23c2ae822
- Date: 2026-03-11

### hcloud-rescue-ssh-key-repeatable [IN] OBSERVATION
SSH keys for `hcloud server enable-rescue` are specified via `--ssh-key` and can be repeated for multiple keys; keys are referenced by ID or name.
- Source: entries/2026/03/11/hcloud_server_enable-rescue.md
- Source hash: 9b0a78b23c2ae822
- Date: 2026-03-11

### hcloud-resource-subcommands [IN] OBSERVATION
The hcloud CLI resource management subcommands are: certificate, firewall, floating-ip, image, load-balancer, network, placement-group, primary-ip, server, ssh-key, storage-box, volume, zone.
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-server-create-datacenter-deprecated [IN] OBSERVATION
The `--datacenter` flag on `hcloud server create` is deprecated; `--location` should be used instead (per 2025-12-16 changelog).
- Source: entries/2026/03/11/hcloud_server_create.md
- Source hash: 1146b2517ecee700
- Date: 2026-03-11

### hcloud-server-create-deprecated-images-blocked [IN] OBSERVATION
Deprecated images are blocked by default on `hcloud server create`; opt in with `--allow-deprecated-image`.
- Source: entries/2026/03/11/hcloud_server_create.md
- Source hash: 1146b2517ecee700
- Date: 2026-03-11

### hcloud-server-create-ipv4-ipv6-default [IN] OBSERVATION
Servers created with `hcloud server create` receive both IPv4 and IPv6 by default; either can be disabled with `--without-ipv4` or `--without-ipv6`.
- Source: entries/2026/03/11/hcloud_server_create.md
- Source hash: 1146b2517ecee700
- Date: 2026-03-11

### hcloud-server-create-protection-options [IN] OBSERVATION
Server protection options are limited to `delete` and `rebuild`, set via `--enable-protection`.
- Source: entries/2026/03/11/hcloud_server_create.md
- Source hash: 1146b2517ecee700
- Date: 2026-03-11

### hcloud-server-create-required-flags [IN] OBSERVATION
The `hcloud server create` command requires three flags: `--name`, `--type`, and `--image`.
- Source: entries/2026/03/11/hcloud_server_create.md
- Source hash: 1146b2517ecee700
- Date: 2026-03-11

### hcloud-server-create-start-after-create-default [IN] OBSERVATION
`hcloud server create` starts the server automatically after creation by default (`--start-after-create` defaults to true).
- Source: entries/2026/03/11/hcloud_server_create.md
- Source hash: 1146b2517ecee700
- Date: 2026-03-11

### hcloud-server-create-user-data-from-file [IN] OBSERVATION
User data for `hcloud server create` is loaded from a file via `--user-data-from-file`, not passed inline; use `-` for stdin.
- Source: entries/2026/03/11/hcloud_server_create.md
- Source hash: 1146b2517ecee700
- Date: 2026-03-11

### hcloud-server-create-without-ipv4-ipv6-flags [IN] OBSERVATION
Private-only servers are created with `--without-ipv4 --without-ipv6 --network <net>` flags on `hcloud server create`.
- Source: entries/2026/03/11/hetzner-operational-patterns.md
- Source hash: ac3a343119d96d0b
- Date: 2026-03-11

### hcloud-server-describe-name-or-id [IN] OBSERVATION
`hcloud server describe` accepts a server identifier by either name or ID.
- Source: entries/2026/03/11/hcloud_server_describe.md
- Source hash: a29580fce8792cbe
- Date: 2026-03-11

### hcloud-server-describe-output-formats [IN] OBSERVATION
`hcloud server describe` supports three output formats: `json`, `yaml`, and Go template `format` strings via `-o`.
- Source: entries/2026/03/11/hcloud_server_describe.md
- Source hash: a29580fce8792cbe
- Date: 2026-03-11

### hcloud-server-list-22-columns [IN] OBSERVATION
`hcloud server list` has 22 available output columns including `placement_group`, `rescue_enabled`, `private_net`, and `backup_window`.
- Source: entries/2026/03/11/hcloud_server_list.md
- Source hash: aa554e0633b9464c
- Date: 2026-03-11

### hcloud-server-list-label-selector-flag [IN] OBSERVATION
`hcloud server list` uses `-l`/`--selector` for label filtering, not `--labels`.
- Source: entries/2026/03/11/hcloud_server_list.md
- Source hash: aa554e0633b9464c
- Date: 2026-03-11

### hcloud-server-list-output-formats [IN] OBSERVATION
`hcloud server list` output format (`-o`) accepts `noheader`, `columns=...`, `json`, and `yaml`.
- Source: entries/2026/03/11/hcloud_server_list.md
- Source hash: aa554e0633b9464c
- Date: 2026-03-11

### hcloud-server-list-status-multi-value [IN] OBSERVATION
The `--status` flag on `hcloud server list` accepts multiple statuses (strings type).
- Source: entries/2026/03/11/hcloud_server_list.md
- Source hash: aa554e0633b9464c
- Date: 2026-03-11

### hcloud-server-metrics-alpha [IN] OBSERVATION
The `hcloud server metrics` command is an ALPHA feature.
- Source: entries/2026/03/11/hcloud_server.md
- Source hash: 2db6f8b39bde1fe6
- Date: 2026-03-11

### hcloud-server-rebuild-image-required [IN] OBSERVATION
The `--image` flag is required for `hcloud server rebuild`; rebuild cannot proceed without specifying a source image.
- Source: entries/2026/03/11/hcloud_server_rebuild.md
- Source hash: 5c4588d38ea93654
- Date: 2026-03-11

### hcloud-server-rebuild-preserves-resource [IN] OBSERVATION
`hcloud server rebuild` destroys the root disk but preserves the server resource (ID, IPs, volumes).
- Source: entries/2026/03/11/hcloud_server_rebuild.md
- Source hash: 5c4588d38ea93654
- Date: 2026-03-11

### hcloud-server-rebuild-user-data-flag [IN] OBSERVATION
The `hcloud server rebuild` command supports a `--user-data` flag for passing cloud-init configuration during rebuild.
- Source: entries/2026/03/11/hetzner-cli-changelog-recent.md
- Source hash: 4700c15482f6cb74
- Date: 2026-03-11

### hcloud-server-resource-protection [IN] OBSERVATION
Server resource protection in Hetzner Cloud prevents accidental deletion and rebuild.
- Source: entries/2026/03/11/hcloud_server.md
- Source hash: 2db6f8b39bde1fe6
- Date: 2026-03-11

### hcloud-server-type-prefix-cax-arm [IN] OBSERVATION
CAX server type prefix denotes shared vCPU on Ampere ARM processors
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-server-type-prefix-ccx-highmem [IN] OBSERVATION
CCX server type prefix denotes dedicated AMD high-memory vCPU
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-server-type-prefix-cpx-dedicated [IN] OBSERVATION
CPX server type prefix denotes dedicated AMD general purpose vCPU
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-server-type-prefix-cx-shared [IN] OBSERVATION
CX server type prefix denotes shared vCPU on Intel/AMD processors
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-server-type-read-only [IN] OBSERVATION
The `hcloud server-type` command group is read-only with two subcommands: `list` and `describe`.
- Source: entries/2026/03/11/hcloud_server-type.md
- Source hash: 83a4d69f40390991
- Date: 2026-03-11

### hcloud-server-types-predefined [IN] OBSERVATION
Server types are predefined by Hetzner — users select from them but cannot create custom types.
- Source: entries/2026/03/11/hcloud_server-type.md
- Source hash: 83a4d69f40390991
- Date: 2026-03-11

### hcloud-six-datacenter-locations [IN] OBSERVATION
Hetzner Cloud has six datacenter locations: NBG1 (Nuremberg), FSN1 (Falkenstein), HEL1 (Helsinki), ASH (Ashburn), HIL (Hillsboro), SIN (Singapore)
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-six-datacenters [IN] OBSERVATION
Hetzner Cloud has six datacenters: nbg1-dc3 (Nuremberg), hel1-dc2 (Helsinki), fsn1-dc14 (Falkenstein), ash-dc1 (Ashburn), hil-dc1 (Hillsboro), sin-dc1 (Singapore).
- Source: entries/2026/03/11/cli-setup-tutorial.md
- Source hash: 33f243b275327416
- Date: 2026-03-11

### hcloud-snapshots-manual-billed-per-gb [IN] OBSERVATION
Snapshots are manual point-in-time server images, billed per GB/month, distinct from automatic backups.
- Source: entries/2026/03/11/hetzner-operational-patterns.md
- Source hash: ac3a343119d96d0b
- Date: 2026-03-11

### hcloud-ssh-key-create-name-required [IN] OBSERVATION
The `--name` flag is required when creating an SSH key with `hcloud ssh-key create`
- Source: entries/2026/03/11/hcloud_ssh-key_create.md
- Source hash: f351d1cae0072169
- Date: 2026-03-11

### hcloud-ssh-key-create-public-key-sources [IN] OBSERVATION
`hcloud ssh-key create` accepts the public key via `--public-key` (inline) or `--public-key-from-file` (file path), and exactly one must be specified
- Source: entries/2026/03/11/hcloud_ssh-key_create.md
- Source hash: f351d1cae0072169
- Date: 2026-03-11

### hcloud-ssh-key-is-top-level-resource [IN] OBSERVATION
SSH keys are a top-level resource in Hetzner Cloud, managed independently from servers
- Source: entries/2026/03/11/hcloud_ssh-key.md
- Source hash: b03ffca50e454084
- Date: 2026-03-11

### hcloud-ssh-key-subcommands [IN] OBSERVATION
The `hcloud ssh-key` command group has seven subcommands: create, delete, describe, list, update, add-label, and remove-label
- Source: entries/2026/03/11/hcloud_ssh-key.md
- Source hash: b03ffca50e454084
- Date: 2026-03-11

### hcloud-storage-box-ga-v1-61 [IN] OBSERVATION
Storage Box support graduated to GA (no longer experimental) in hcloud CLI v1.61.0.
- Source: entries/2026/03/11/hetzner-cli-changelog-recent.md
- Source hash: 4700c15482f6cb74
- Date: 2026-03-11

### hcloud-storage-box-snapshot-seven-subcommands [IN] OBSERVATION
The `hcloud storage-box snapshot` command group has seven subcommands: create, delete, describe, list, update, add-label, remove-label.
- Source: entries/2026/03/11/hcloud_storage-box_snapshot.md
- Source hash: 18146cf57c64efe7
- Date: 2026-03-11

### hcloud-storage-box-subaccount-id-or-name [IN] OBSERVATION
Storage Box subaccounts are identified by `id` or `name` (not `username`) as of CLI v1.60.0.
- Source: entries/2026/03/11/hetzner-cli-changelog-recent.md
- Source hash: 4700c15482f6cb74
- Date: 2026-03-11

### hcloud-three-apis-different-auth [IN] OBSERVATION
Hetzner has three distinct APIs with different auth: Cloud API (Bearer token), Hetzner API (Bearer token for storage boxes), Robot API (Basic auth for dedicated servers).
- Source: entries/2026/03/11/hetzner-operational-patterns.md
- Source hash: ac3a343119d96d0b
- Date: 2026-03-11

### hcloud-traffic-included-by-region [IN] OBSERVATION
Included traffic varies by region: 20TB/month (EU shared), 1TB (US), 0.5TB (Singapore)
- Source: entries/2026/03/11/hetzner-cloud-overview.md
- Source hash: 9d0e732ed4b8bcf5
- Date: 2026-03-11

### hcloud-two-api-endpoints [IN] OBSERVATION
The hcloud CLI bridges two distinct APIs: Hetzner Cloud API (`api.hetzner.cloud`) for cloud resources and Hetzner API (`api.hetzner.com`) for dedicated/DNS/storage-box services.
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-utility-subcommands [IN] OBSERVATION
The hcloud CLI utility subcommands are: all, completion, config, context, version.
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-view-only-subcommands [IN] OBSERVATION
The hcloud CLI view-only (read-only) subcommands are: datacenter, iso, load-balancer-type, location, server-type, storage-box-type.
- Source: entries/2026/03/11/hcloud.md
- Source hash: dc5b729ad16a4404
- Date: 2026-03-11

### hcloud-volume-attach-automount-flag [IN] OBSERVATION
The `hcloud volume attach` command supports an `--automount` flag to automatically mount the volume on the server's filesystem after attachment.
- Source: entries/2026/03/11/hcloud_volume_attach.md
- Source hash: 628f84cc2e1990e5
- Date: 2026-03-11

### hcloud-volume-attach-one-server-at-a-time [IN] OBSERVATION
A Hetzner Cloud Volume can only be attached to one server at a time.
- Source: entries/2026/03/11/hcloud_volume.md
- Source hash: 948938e90bfed6da
- Date: 2026-03-11

### hcloud-volume-attach-server-flag-required [IN] OBSERVATION
The `--server` flag is required for `hcloud volume attach` — the command fails without it.
- Source: entries/2026/03/11/hcloud_volume_attach.md
- Source hash: 628f84cc2e1990e5
- Date: 2026-03-11

### hcloud-volume-create-automount-requires-server [IN] OBSERVATION
The `--automount` flag on `hcloud volume create` requires `--server` to also be specified.
- Source: entries/2026/03/11/hcloud_volume_create.md
- Source hash: b9b6565698429f50
- Date: 2026-03-11

### hcloud-volume-create-formats-ext4-xfs [IN] OBSERVATION
`hcloud volume create` supports only two filesystem formats: ext4 and xfs.
- Source: entries/2026/03/11/hcloud_volume_create.md
- Source hash: b9b6565698429f50
- Date: 2026-03-11

### hcloud-volume-create-name-and-size-required [IN] OBSERVATION
`hcloud volume create` requires both `--name` and `--size` (in GB) as mandatory parameters.
- Source: entries/2026/03/11/hcloud_volume_create.md
- Source hash: b9b6565698429f50
- Date: 2026-03-11

### hcloud-volume-create-protection-only-delete [IN] OBSERVATION
`hcloud volume create --enable-protection` only supports `delete` protection.
- Source: entries/2026/03/11/hcloud_volume_create.md
- Source hash: b9b6565698429f50
- Date: 2026-03-11

### hcloud-volume-describe-accepts-name-or-id [IN] OBSERVATION
The `hcloud volume describe` command accepts either a volume name or numeric ID as its argument.
- Source: entries/2026/03/11/hcloud_volume_describe.md
- Source hash: 7d9b56fdfc0b7af0
- Date: 2026-03-11

### hcloud-volume-describe-output-formats [IN] OBSERVATION
`hcloud volume describe` supports three output formats: `json`, `yaml`, and `format` (custom formatting).
- Source: entries/2026/03/11/hcloud_volume_describe.md
- Source hash: 7d9b56fdfc0b7af0
- Date: 2026-03-11

### hcloud-volume-protection-must-disable-before-delete [IN] OBSERVATION
Volume resource protection must be explicitly disabled before a protected volume can be deleted.
- Source: entries/2026/03/11/hcloud_volume.md
- Source hash: 948938e90bfed6da
- Date: 2026-03-11

### hcloud-volume-resize-enlarge-only [IN] OBSERVATION
Hetzner Cloud volumes can only be resized to a larger size; shrinking is not supported.
- Source: entries/2026/03/11/hcloud_volume_resize.md
- Source hash: 2843ad35d60a4aeb
- Date: 2026-03-11

### hcloud-volume-resize-increase-only [IN] OBSERVATION
Hetzner Cloud Volume resize only allows increasing size, not shrinking.
- Source: entries/2026/03/11/hcloud_volume.md
- Source hash: 948938e90bfed6da
- Date: 2026-03-11

### hcloud-volume-resize-size-in-gb [IN] OBSERVATION
The `hcloud volume resize --size` flag takes an integer value in GB and is required.
- Source: entries/2026/03/11/hcloud_volume_resize.md
- Source hash: 2843ad35d60a4aeb
- Date: 2026-03-11

### hcloud-volumes-expand-only [IN] OBSERVATION
Volumes can be resized without data loss but only expanded (not shrunk), up to 10TB
- Source: entries/2026/03/11/hetzner-cloud-volumes.md
- Source hash: 2c0ba2696c826ec0
- Date: 2026-03-11

### hcloud-volumes-independent-lifecycle [IN] OBSERVATION
Volumes have an independent lifecycle from servers — they persist when the attached server is deleted
- Source: entries/2026/03/11/hetzner-cloud-volumes.md
- Source hash: 2c0ba2696c826ec0
- Date: 2026-03-11

### hcloud-volumes-location-bound [IN] OBSERVATION
Volumes are location-bound and must be in the same datacenter as the attached server
- Source: entries/2026/03/11/hetzner-cloud-volumes.md
- Source hash: 2c0ba2696c826ec0
- Date: 2026-03-11

### hcloud-volumes-max-10tb [IN] OBSERVATION
Maximum Hetzner Cloud Volume size is 10TB per volume
- Source: entries/2026/03/11/hetzner-cloud-volumes.md
- Source hash: 2c0ba2696c826ec0
- Date: 2026-03-11

### hcloud-volumes-max-16-per-server [IN] OBSERVATION
Maximum of 16 volumes can be attached to a single Cloud Server
- Source: entries/2026/03/11/hetzner-cloud-volumes.md
- Source hash: 2c0ba2696c826ec0
- Date: 2026-03-11

### hcloud-volumes-raw-block-devices [IN] OBSERVATION
Volumes are raw block devices that must be formatted before use
- Source: entries/2026/03/11/hetzner-cloud-volumes.md
- Source hash: 2c0ba2696c826ec0
- Date: 2026-03-11

### hcloud-volumes-triple-replicated-ceph [IN] OBSERVATION
Volumes are triple-replicated across physical servers using a Ceph-backed distributed storage system
- Source: entries/2026/03/11/hetzner-cloud-volumes.md
- Source hash: 2c0ba2696c826ec0
- Date: 2026-03-11

### hcloud-windows-32bit-discontinued-v1-58 [IN] OBSERVATION
Windows 32-bit CLI builds were discontinued as of hcloud CLI v1.58.0.
- Source: entries/2026/03/11/hetzner-cli-changelog-recent.md
- Source hash: 4700c15482f6cb74
- Date: 2026-03-11

### hcloud-zone-add-records-auto-creates-rrset [IN] OBSERVATION
`hcloud zone add-records` auto-creates the target RRSet if it does not already exist.
- Source: entries/2026/03/11/hcloud_zone_add-records.md
- Source hash: 7a6a2026a6aac2fd
- Date: 2026-03-11

### hcloud-zone-add-records-positional-args [IN] OBSERVATION
`hcloud zone add-records` requires three positional arguments: zone, record name, and record type.
- Source: entries/2026/03/11/hcloud_zone_add-records.md
- Source hash: 7a6a2026a6aac2fd
- Date: 2026-03-11

### hcloud-zone-add-records-record-and-file-exclusive [IN] OBSERVATION
The `--record` and `--records-file` options in `hcloud zone add-records` are mutually exclusive.
- Source: entries/2026/03/11/hcloud_zone_add-records.md
- Source hash: 7a6a2026a6aac2fd
- Date: 2026-03-11

### hcloud-zone-add-records-ttl-per-rrset [IN] OBSERVATION
TTL in `hcloud zone add-records` is set at the RRSet level, not per individual record.
- Source: entries/2026/03/11/hcloud_zone_add-records.md
- Source hash: 7a6a2026a6aac2fd
- Date: 2026-03-11

### hcloud-zone-bind-format [IN] OBSERVATION
Hetzner Cloud DNS zone files use BIND format per RFC 1034/1035.
- Source: entries/2026/03/11/hcloud_zone.md
- Source hash: 325f6502371442c7
- Date: 2026-03-11

### hcloud-zone-create-default-mode-primary [IN] OBSERVATION
The default zone mode for `hcloud zone create` is `primary`.
- Source: entries/2026/03/11/hcloud_zone_create.md
- Source hash: fde4ebb90903bd98
- Date: 2026-03-11

### hcloud-zone-create-protection-delete-only [IN] OBSERVATION
The `--enable-protection` flag on `hcloud zone create` only supports `delete` as a value.
- Source: entries/2026/03/11/hcloud_zone_create.md
- Source hash: fde4ebb90903bd98
- Date: 2026-03-11

### hcloud-zone-create-secondary-requires-nameservers-file [IN] OBSERVATION
Secondary zones require the `--primary-nameservers-file` option when created with `hcloud zone create`.
- Source: entries/2026/03/11/hcloud_zone_create.md
- Source hash: fde4ebb90903bd98
- Date: 2026-03-11

### hcloud-zone-create-zonefile-stdin [IN] OBSERVATION
The `hcloud zone create --zonefile` flag accepts `-` for stdin input.
- Source: entries/2026/03/11/hcloud_zone_create.md
- Source hash: fde4ebb90903bd98
- Date: 2026-03-11

### hcloud-zone-import-replaces-all-rrsets [IN] OBSERVATION
Zone file import via `hcloud zone import-zonefile` replaces all existing RRSets — it is destructive, not additive.
- Source: entries/2026/03/11/hcloud_zone.md
- Source hash: 325f6502371442c7
- Date: 2026-03-11

### hcloud-zone-protection-prevents-deletion [IN] OBSERVATION
Zone resource protection must be explicitly disabled before a zone can be deleted or modified.
- Source: entries/2026/03/11/hcloud_zone.md
- Source hash: 325f6502371442c7
- Date: 2026-03-11

### hcloud-zone-secondary-primary-nameservers [IN] OBSERVATION
Secondary DNS zones have configurable primary nameservers via `hcloud zone change-primary-nameservers`.
- Source: entries/2026/03/11/hcloud_zone.md
- Source hash: 325f6502371442c7
- Date: 2026-03-11

### hcloud-zone-three-record-operations [IN] OBSERVATION
`hcloud zone add-records` appends to an RRSet, `set-records` replaces an RRSet, and `remove-records` deletes from an RRSet — three distinct operations.
- Source: entries/2026/03/11/hcloud_zone.md
- Source hash: 325f6502371442c7
- Date: 2026-03-11

### hetzner-cli-default-config-path [IN] OBSERVATION
The default hcloud CLI config file location is `~/.config/hcloud/cli.toml`.
- Source: entries/2026/03/11/hcloud_floating-ip_describe.md
- Source hash: 73bfb3f380fe4840
- Date: 2026-03-11

### hetzner-cloud-api-endpoint [IN] OBSERVATION
The default Hetzner Cloud API endpoint is `https://api.hetzner.cloud/v1`; the Hetzner (non-cloud) endpoint is `https://api.hetzner.com/v1`.
- Source: entries/2026/03/11/hcloud_floating-ip_describe.md
- Source hash: 73bfb3f380fe4840
- Date: 2026-03-11

### hetzner-floating-ip-assign-syntax [IN] OBSERVATION
The `hcloud floating-ip assign` command takes two positional arguments: `<floating-ip>` and `<server>`.
- Source: entries/2026/03/11/hcloud_floating-ip_assign.md
- Source hash: 4e9d3c2a88bd021e
- Date: 2026-03-11

### hetzner-floating-ip-create-type-required [IN] OBSERVATION
Creating a Floating IP requires `--type` (ipv4 or ipv6) and exactly one of `--home-location` or `--server`.
- Source: entries/2026/03/11/hcloud_floating-ip_create.md
- Source hash: df74b0eec438c442
- Date: 2026-03-11

### hetzner-floating-ip-explicit-assign-required [IN] OBSERVATION
A Floating IP must be explicitly assigned to a server before it routes traffic to that server.
- Source: entries/2026/03/11/hcloud_floating-ip.md
- Source hash: e617a9c86e13bd4e
- Date: 2026-03-11

### hetzner-floating-ip-ipv6-slash56 [IN] OBSERVATION
Creating a Floating IP with `--type ipv6` allocates a /56 network, while `--type ipv4` gives a single address.
- Source: entries/2026/03/11/hcloud_floating-ip_create.md
- Source hash: df74b0eec438c442
- Date: 2026-03-11

### hetzner-floating-ip-location-bound [IN] OBSERVATION
A Floating IP can only be assigned to servers in its home location.
- Source: entries/2026/03/11/hcloud_floating-ip_create.md
- Source hash: df74b0eec438c442
- Date: 2026-03-11

### hetzner-floating-ip-only-delete-protection [IN] OBSERVATION
Delete protection is the only protection type available for Floating IPs.
- Source: entries/2026/03/11/hcloud_floating-ip_create.md
- Source hash: df74b0eec438c442
- Date: 2026-03-11

### hetzner-floating-ip-reassignable [IN] OBSERVATION
Floating IPs can be reassigned between servers (not permanently bound to one server).
- Source: entries/2026/03/11/hcloud_floating-ip_assign.md
- Source hash: 4e9d3c2a88bd021e
- Date: 2026-03-11

### hetzner-floating-ip-server-independent [IN] OBSERVATION
Floating IPs exist independently of servers and persist after server deletion.
- Source: entries/2026/03/11/hcloud_floating-ip.md
- Source hash: e617a9c86e13bd4e
- Date: 2026-03-11

### hetzner-floating-ip-server-sets-location [IN] OBSERVATION
Specifying `--server` when creating a Floating IP automatically sets the home location based on that server's location.
- Source: entries/2026/03/11/hcloud_floating-ip_create.md
- Source hash: df74b0eec438c442
- Date: 2026-03-11

### hetzner-image-no-direct-create [IN] OBSERVATION
There is no `hcloud image create` subcommand — images are created indirectly via `hcloud server create-image` (snapshots) or uploaded.
- Source: entries/2026/03/11/hcloud_image.md
- Source hash: 3ab5a5e0dc8284d4
- Date: 2026-03-11

### hetzner-image-update-metadata-only [IN] OBSERVATION
The `hcloud image update` command modifies image metadata, not the image content itself.
- Source: entries/2026/03/11/hcloud_image.md
- Source hash: 3ab5a5e0dc8284d4
- Date: 2026-03-11

### hetzner-primary-ip-vs-floating-ip [IN] OBSERVATION
Primary IPs are bound to a server's lifecycle while Floating IPs are independent of any server.
- Source: entries/2026/03/11/hcloud_floating-ip.md
- Source hash: e617a9c86e13bd4e
- Date: 2026-03-11

### hetzner-six-locations [IN] OBSERVATION
Hetzner Cloud resources are available in six locations: FSN1, NBG1, HEL1, HIL, ASH, SIN.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### hetzner-storage-box-api-endpoint-differs-from-cloud [IN] OBSERVATION
The Hetzner Storage Box API endpoint (`api.hetzner.com/v1`) differs from the Cloud API endpoint (`api.hetzner.cloud/v1`), controlled by `--hetzner-endpoint` vs `--endpoint` flags.
- Source: entries/2026/03/11/hcloud_storage-box_snapshot.md
- Source hash: 18146cf57c64efe7
- Date: 2026-03-11

### hybrid-cloud-dedicated-full-stack-convergence [IN] OBSERVATION
Hetzner provides hybrid cloud-dedicated server connectivity at both Layer 2 (vSwitch network subnets with route exposure) and Layer 7 (Load Balancer targets with private IP routing), enabling unified infrastructure management across server types.

### hybrid-cloud-dedicated-layer2-bridge [IN] OBSERVATION
vSwitch provides Layer 2 connectivity between cloud and dedicated servers, with cloud-side support via vswitch-type subnets and route exposure — enabling hybrid architectures that span both Hetzner product lines.

### hybrid-operational-tempo-mismatch [IN] OBSERVATION
Hybrid cloud-dedicated operations have a fundamental temporal mismatch — cloud resources converge through async polling (500ms CLI intervals, SDK WaitFor primitives) measured in seconds, while dedicated server lifecycle operations (boot config effective only on next restart, failover IP pre-staging across all targets) unfold over minutes to hours, creating fundamentally different operational cadences within a single deployment.

### image-lifecycle-indirect-and-metadata-only [IN] OBSERVATION
Hetzner Cloud images have an indirect lifecycle — no direct `image create` command exists (images are created via `server create-image`), updates modify only metadata (not content), deprecated images are blocked by default, and image type must be explicitly specified — making images a derived artifact of server operations rather than an independently managed resource.

### infrastructure-free-tier-comprehensive [IN] OBSERVATION
Hetzner Cloud includes DDoS protection, firewalls, private networks, IPv6, and 24/7 support at no additional cost — infrastructure-level services are not metered separately from compute.

### ingress-pipeline-dns-to-lb-fully-managed [IN] OBSERVATION
Hetzner provides a fully managed ingress pipeline from DNS resolution through TLS termination to hybrid load balancing — BIND-compatible zones with 16 record types, automatic certificate lifecycle via Let's Encrypt, HTTP/2 by default, sticky sessions, and cloud/dedicated server targeting — all within a single provider's control plane with no third-party dependencies required.

### international-constrained-at-every-layer [IN] OBSERVATION
International Hetzner deployments face constraints at every architectural layer: compounded economic disadvantage (40x less traffic, missing Object Storage, third-party-operated facilities) AND structural lock-in (volumes, Floating IPs, and networks all location-bound), making cross-region architectures spanning EU and non-EU locations simultaneously more expensive, less feature-complete, and less flexible than EU-only deployments.

### international-deployment-compounded-cost-risk [IN] OBSERVATION
International Hetzner deployments face compounded disadvantage: systematically reduced included resources (40x less traffic, no Object Storage) AND the same billing traps (powered-off servers billed, IPv4 charged when unassigned), making non-EU total cost highly unpredictable.

### international-locations-second-class [IN] OBSERVATION
Non-EU Hetzner locations are systematically disadvantaged: third-party operated, missing Object Storage, and 20-40x less included traffic than EU sites — making EU the only first-class deployment target.

### ip-address-three-tier-lifecycle-model [IN] OBSERVATION
Hetzner offers three IP types with distinct lifecycle semantics: Primary IPs (server-bound but persistent), Floating IPs (location-scoped, fully independent), and Alias IPs (multiple per server on a network) — each serving different HA and multi-homing patterns.

### lb-hourly-billing-monthly-caps [IN] OBSERVATION
Hetzner Cloud Load Balancers use hourly billing with monthly caps, with pricing varying by region.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### lb-http2-enabled-by-default [IN] OBSERVATION
HTTP/2 is enabled by default on Hetzner Cloud Load Balancers.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### lb-hybrid-cloud-dedicated-targets [IN] OBSERVATION
Load Balancers can target both cloud VMs and dedicated servers, and with private-only mode plus label-selector dynamic targeting, they serve as the traffic entry point for hybrid architectures spanning both Hetzner product lines.

### lb-integrated-tls-termination [IN] OBSERVATION
Hetzner load balancers provide integrated TLS termination with certificate management, health checking, and algorithm selection, serving as a managed ingress layer for both cloud and dedicated server targets.

### lb-service-protocol-asymmetric-requirements [IN] OBSERVATION
Load Balancer service configuration has asymmetric per-protocol requirements — TCP demands explicit port mapping, HTTPS requires certificate attachment, while health checks share defaults (15s/10s/3) across all three protocols.

### lb-targets-cloud-and-dedicated-servers [IN] OBSERVATION
Hetzner Cloud Load Balancers can target both cloud servers and dedicated root servers.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### lb-three-tiers-lb11-lb21-lb31 [IN] OBSERVATION
Hetzner Cloud offers three load balancer tiers: LB11, LB21, and LB31.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### lb-two-algorithms-roundrobin-leastconn [IN] OBSERVATION
Hetzner Cloud Load Balancers support two balancing algorithms: Round Robin and Least Connections.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### lb-unified-ingress-gateway [IN] OBSERVATION
Hetzner Load Balancers serve as unified ingress gateways combining hybrid cloud/dedicated targeting, integrated TLS termination with managed certificates and HTTP/2, dynamic label-selector service discovery, and private-only operation — converging multiple infrastructure concerns in a single resource.

### lb11-limits-5svc-25tgt-10cert-1tb [IN] OBSERVATION
LB11 supports 5 services, 25 targets, 10 SSL certificates, and 1 TB included traffic.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### lb21-limits-15svc-75tgt-25cert-2tb [IN] OBSERVATION
LB21 supports 15 services, 75 targets, 25 SSL certificates, and 2 TB included traffic.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### lb31-limits-30svc-150tgt-50cert-3tb [IN] OBSERVATION
LB31 supports 30 services, 150 targets, 50 SSL certificates, and 3 TB included traffic.
- Source: entries/2026/03/11/hetzner-cloud-load-balancers.md
- Source hash: 53d33a698afd6c96
- Date: 2026-03-11

### location-consolidation-amplifies-billing-risk [IN] OBSERVATION
Consolidating resources in a single Hetzner location simplifies operations but concentrates exposure to location-specific billing characteristics and traffic cost asymmetries.

### location-model-consolidating-and-binding [IN] OBSERVATION
Hetzner is consolidating resource placement around locations (deprecating datacenter-level flags for servers, Primary IPs, and attributes) while simultaneously enforcing location-level resource binding (volumes, Floating IPs, networks) — reinforcing an architecture where location is the fundamental, inescapable unit of deployment and capacity planning.

### managed-private-ingress-complete-and-free [IN] OBSERVATION
Hetzner enables a fully managed private ingress pipeline from DNS resolution through TLS termination to hybrid load balancing at zero additional network/security cost — a complete ingress story without third-party dependencies or per-feature charges.

### multi-project-automation-credential-explosion [IN] OBSERVATION
Multi-project Hetzner deployments require per-project Cloud API tokens plus account-level Robot API and Storage Box credentials, creating a credential management surface that grows with the number of projects.

### network-connections-redundant-10gbit [IN] OBSERVATION
Hetzner Cloud network connections are redundant 10 Gbit.
- Source: entries/2026/03/11/hetzner-cloud-networking.md
- Source hash: 490d8986b7c63e22
- Date: 2026-03-11

### network-hierarchical-zone-topology [IN] OBSERVATION
Hetzner Cloud networks follow a hierarchical zone-based topology — locations contain datacenters, subnets scope to network zones (not individual datacenters), and networks support three sub-resource types (subnets, routes, labels) with three subnet types (cloud, server, vswitch) — creating a multi-layered addressing model where the zone is the fundamental reachability boundary.

### networks-span-single-datacenter-location [IN] OBSERVATION
Hetzner Cloud private networks span within a single datacenter location.
- Source: entries/2026/03/11/hetzner-cloud-networking.md
- Source hash: 490d8986b7c63e22
- Date: 2026-03-11

### object-storage-eu-only-coverage-gap [IN] OBSERVATION
Object Storage is available in only 3 of 6 Hetzner locations (FSN1, HEL1, NBG1 — all EU), leaving US (ASH, HIL) and APAC (SIN) workloads without local object storage.

### operational-safety-requires-external-governance [IN] OBSERVATION
Hetzner's built-in safety mechanisms have parallel gaps across both resource protection (predominantly delete-only, no role-based or conditional guards) and billing (hidden cost traps for idle and international resources), requiring external governance tooling for production-grade operational safety.

### placement-groups-static-single-strategy [IN] OBSERVATION
Hetzner placement groups support only the 'spread' strategy and servers are assigned to a placement group at creation time, providing anti-affinity for fault-domain distribution.

### powered-off-billing-trap [IN] OBSERVATION
The combination of powered-off servers still being billed and IPv4 addresses being charged even when unassigned creates cost traps for idle resources that only deletion eliminates.

### primary-ip-lifecycle-requires-explicit-strategy [IN] OBSERVATION
Primary IPs demand explicit lifecycle strategy decisions at creation time — type-locked (IPv4 vs IPv6), independently persistent by default (surviving server deletion), with optional auto-delete creating a binary choice between resource leak risk (orphaned charged IPs) and accidental deletion risk, while IPv4 charges accrue even on unassigned IPs.

### private-infrastructure-with-free-security [IN] OBSERVATION
Hetzner provides private networking, stateless firewalls, and DDoS protection at no additional cost, enabling network-isolated infrastructure without per-feature security charges.

### private-network-isolation-complete-stack [IN] OBSERVATION
Hetzner Cloud supports fully private infrastructure stacks — servers without public IPs, load balancers in private-only mode, and private networks — accessible only via jump hosts, VPNs, or internal LBs.

### private-secure-ingress-zero-cost [IN] OBSERVATION
Hetzner enables complete private ingress architectures at zero additional network security cost — private-only load balancers with hybrid cloud/dedicated targeting serve as the sole entry point, backed by free stateless firewalls and DDoS protection, with no public IP exposure required for backend compute or storage infrastructure.

### protection-model-broad-but-shallow [IN] OBSERVATION
Hetzner's resource protection is broad in coverage (spans most resource types with multi-layer safeguards) but shallow in granularity — predominantly delete-only, with servers being the sole exception adding rebuild protection — creating a safety net that prevents accidental destruction but not accidental misconfiguration.

### regional-traffic-cost-40x-asymmetry [IN] OBSERVATION
Included traffic varies 40x between EU (20TB) and Singapore (0.5TB), making region selection a primary cost driver for egress-heavy workloads.

### resource-protection-delete-only-dominant-pattern [IN] OBSERVATION
Delete-only protection is the dominant protection pattern across Hetzner Cloud resources (Load Balancers, Primary IPs, Floating IPs, Networks, Volumes, Storage Boxes, Zones, RRSets), with servers being the notable exception that also supports rebuild protection.

### resources-location-coupled-topology [IN] OBSERVATION
Multiple core Hetzner Cloud resources — Volumes, Floating IPs, and private Networks — are bound to a single datacenter location, creating tight regional coupling that prevents cross-location resource mobility and constrains multi-region architecture patterns.

### robot-api-aggressive-security-posture [IN] OBSERVATION
The Robot API enforces an aggressive security posture with IP blocking after 3 failed authentication attempts (10-minute lockout), variable rate limits calibrated to endpoint destructiveness (10/hr for destructive operations up to 5000/hr for queries), and HTTP Basic Auth requiring credential management per request.

### robot-api-base-url [IN] OBSERVATION
The Hetzner Robot API base URL is `https://robot-ws.your-server.de`, distinct from the Cloud API at `api.hetzner.cloud`.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-api-error-response-format [IN] OBSERVATION
Robot API error responses use a structured `{ "error": { "status", "code", "message" } }` JSON format.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-api-http-basic-auth [IN] OBSERVATION
The Robot API uses HTTP Basic Auth with Robot panel credentials, not Bearer tokens or API tokens like the Cloud API.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-api-legacy-but-aggressive [IN] OBSERVATION
The Robot API combines legacy design conventions with aggressive security enforcement — HTTP Basic Auth over URL-encoded POST bodies, but with IP blocking after 3 failures and variable rate limits — creating an API that is simultaneously harder to integrate with and less forgiving of integration mistakes.

### robot-api-legacy-design-patterns [IN] OBSERVATION
The Robot API uses legacy web conventions (HTTP Basic Auth, URL-encoded POST bodies, YAML via URL suffix) that contrast with the Cloud API's modern Bearer-token JSON design, reflecting its older dedicated-server heritage.

### robot-api-manages-dedicated-servers-only [IN] OBSERVATION
The Robot API manages dedicated/bare-metal servers only; cloud VMs are managed through the separate Cloud API.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-api-post-urlencoded-not-json [IN] OBSERVATION
Robot API POST parameters use `application/x-www-form-urlencoded` encoding, not JSON request bodies.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-api-rate-limits-range-10-to-5000 [IN] OBSERVATION
Robot API rate limits vary per endpoint from 10/hr (destructive ops like MAC generation, WOL) to 5000/hr (IP/subnet queries).
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-api-three-failed-auth-ip-block [IN] OBSERVATION
Three failed Robot API authentication attempts block the requesting IP for 10 minutes.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-api-yaml-via-endpoint-suffix [IN] OBSERVATION
Appending `.yaml` to any Robot API endpoint returns YAML output instead of the default JSON.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-boot-config-controls-next-restart [IN] OBSERVATION
Robot API boot configuration endpoints control what boots on the next server restart — rescue, Linux install, VNC install, or Windows install — each activated/deactivated via API.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-failover-ip-preconfigure-all-targets [IN] OBSERVATION
Failover IPs must be configured on all potential destination servers before routing can be switched, not just the active target.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### robot-server-cancellation-create-and-revoke [IN] OBSERVATION
Robot API server cancellations can be both created (POST) and revoked (DELETE).
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### rrset-create-record-and-records-file-mutually-exclusive [IN] OBSERVATION
The `hcloud zone rrset create` flags `--record` and `--records-file` are mutually exclusive.
- Source: entries/2026/03/11/hcloud_zone_rrset_create.md
- Source hash: 44017c79f609d1fb
- Date: 2026-03-11

### rrset-create-required-flags [IN] OBSERVATION
The `hcloud zone rrset create` command requires `--name`, `--type`, and one of `--record` or `--records-file`.
- Source: entries/2026/03/11/hcloud_zone_rrset_create.md
- Source hash: 44017c79f609d1fb
- Date: 2026-03-11

### rrset-groups-records-by-name-and-type [IN] OBSERVATION
An RRSet (Resource Record Set) groups DNS records sharing the same name and type within a zone.
- Source: entries/2026/03/11/hcloud_zone_rrset.md
- Source hash: e27d6cf8cd6cf53a
- Date: 2026-03-11

### rrset-protection-must-disable-before-delete [IN] OBSERVATION
RRSet resource protection must be disabled before the RRSet can be deleted.
- Source: entries/2026/03/11/hcloud_zone_rrset.md
- Source hash: e27d6cf8cd6cf53a
- Date: 2026-03-11

### rrset-three-record-mutation-commands [IN] OBSERVATION
RRSets support three distinct record mutation commands: `add-records` (append), `remove-records` (selective delete), and `set-records` (full replace).
- Source: entries/2026/03/11/hcloud_zone_rrset.md
- Source hash: e27d6cf8cd6cf53a
- Date: 2026-03-11

### rrset-ttl-managed-at-rrset-level [IN] OBSERVATION
TTL is managed at the RRSet level via `change-ttl`, not per individual DNS record.
- Source: entries/2026/03/11/hcloud_zone_rrset.md
- Source hash: e27d6cf8cd6cf53a
- Date: 2026-03-11

### safety-fundamentally-user-responsible [IN] OBSERVATION
Hetzner's safety model is fundamentally user-responsible — both data protection (explicit backup/snapshot strategy with inverse cost/control tradeoffs) and resource protection (shallow delete-only guards without RBAC) require active user management rather than safe-by-default behavior.

### safety-model-requires-external-unification [IN] OBSERVATION
Hetzner's safety and security model requires external unification — built-in protections are both shallow (delete-only, no RBAC) and inconsistent across APIs (aggressive Robot auth vs permissive Cloud), creating gaps that no single platform-native mechanism addresses.

### sdk-migration-cascades-through-automation-ecosystem [IN] OBSERVATION
SDK version migration cascades through the entire Hetzner automation ecosystem — hcloud-go's strict two-version support window and breaking v1→v2 changes (int to int64 IDs) propagate through the three-layer toolchain (CLI → SDK → Terraform provider), potentially forcing coordinated upgrades across all automation layers simultaneously.

### sdk-strict-support-window-and-breaking-migration [IN] OBSERVATION
Hetzner's Go SDK enforces a strict support window — v1 dropped Feb 2025 after v2's breaking ID type change (int to int64), only latest two Go versions supported — requiring proactive dependency management for any Go-based automation.

### secure-hybrid-zero-network-cost [IN] OBSERVATION
Hetzner enables secure hybrid cloud-dedicated architectures at zero additional network security cost — private networks, free firewalls and DDoS protection, vSwitch Layer 2 bridging, and private-mode Load Balancers all compose without per-service charges.

### security-posture-inconsistent-across-products [IN] OBSERVATION
Hetzner's security posture is inconsistent across product lines — the Robot API enforces aggressive authentication security (IP blocking after 3 failures, rate limiting as low as 10/hr) while Cloud resource protection is broad but shallow (predominantly delete-only, no RBAC or conditional guards) — creating uneven security guarantees that require per-product-line security assessment rather than platform-wide assumptions.

### server-create-complex-defaults-matrix [IN] OBSERVATION
Hetzner server creation involves multiple configuration dimensions (server type, image, location, network, SSH keys, user data, labels) where the defaults (auto-assigned IPv4/IPv6, no private network, no volumes) shape the initial topology and must be considered before creation since some are difficult to change afterward.

### server-creation-decision-surface-locks-permanently [IN] OBSERVATION
Server creation involves a wide decision surface where critical choices lock in permanently — placement group assignment is immutable post-creation (spread-only, creation-time binding), location determines all downstream resource constraints (Volumes, IPs, Networks), and the complex defaults matrix means implicit choices (auto-start, dual-stack, no placement group) have lasting architectural consequences.

### server-lifecycle-graceful-hard-spectrum [IN] OBSERVATION
Server lifecycle operations form a graceful-to-destructive spectrum in matched pairs: shutdown/reboot (graceful ACPI), poweroff/reset (hard immediate), rebuild (destructive OS reinstall) — each escalation level trading safety for reliability of effect.

### server-type-four-compute-profiles [IN] OBSERVATION
Hetzner Cloud's four server series (CX shared, CPX dedicated, CCX high-memory dedicated, CAX ARM) span the full compute spectrum from cost-optimized shared workloads to memory-intensive dedicated applications.

### servers-without-primary-ip-private-only [IN] OBSERVATION
Hetzner Cloud servers can be created without Primary IPs to make them private-network-only.
- Source: entries/2026/03/11/hetzner-cloud-networking.md
- Source hash: 490d8986b7c63e22
- Date: 2026-03-11

### sovereignty-international-irreconcilable-within-platform [IN] OBSERVATION
The tension between EU data sovereignty (self-operated German datacenters, co-located Object Storage, complete storage palette) and international reach (third-party facilities, missing Object Storage, 40x traffic cost asymmetry, location-bound resources) is irreconcilable within Hetzner alone — organizations needing both sovereign EU operations and international presence must adopt multi-provider architectures from the start, before location lock-in makes migration prohibitive.

### stateless-security-perimeter-free [IN] OBSERVATION
Hetzner's network security layer — stateless firewalls with 5 protocols and hardware-based DDoS protection — operates at the infrastructure level at no additional cost, but the stateless design requires applications to handle connection tracking.

### storage-box-access-control-granular-but-fragmented [IN] OBSERVATION
Storage Box access control is granular but operationally fragmented — subaccounts provide delegated access, but password management is reset-only (no set), home directory changes require a separate command, and general properties vs access settings use distinct update commands.

### storage-box-create-required-flags [IN] OBSERVATION
Creating a Storage Box requires four flags: `--name`, `--type`, `--location`, and `--password`
- Source: entries/2026/03/11/hcloud_storage-box_create.md
- Source hash: 0eb66ffbd8b1a689
- Date: 2026-03-11

### storage-box-default-isolation-posture [IN] OBSERVATION
Storage Boxes adopt a secure-by-default isolation posture — external reachability is disabled by default requiring explicit opt-in, they operate on the separate Hetzner platform API (not the Cloud API), and they function as network-attached storage architecturally distinct from cloud-native block volumes.

### storage-box-describe-output-formats [IN] OBSERVATION
`hcloud storage-box describe` supports JSON, YAML, and custom format string output formats
- Source: entries/2026/03/11/hcloud_storage-box_describe.md
- Source hash: 5980d88a457143cd
- Date: 2026-03-11

### storage-box-external-reachability-not-default [IN] OBSERVATION
Storage Box external reachability is not enabled by default; it must be explicitly set with `--reachable-externally`
- Source: entries/2026/03/11/hcloud_storage-box_create.md
- Source hash: 0eb66ffbd8b1a689
- Date: 2026-03-11

### storage-box-is-network-attached-storage [IN] OBSERVATION
Storage Boxes are network-attached storage, a separate product from Hetzner Cloud Volumes (which are block storage)
- Source: entries/2026/03/11/hcloud_storage-box.md
- Source hash: 54d2a9eeb6db1a00
- Date: 2026-03-11

### storage-box-multi-protocol-versatility [IN] OBSERVATION
Hetzner Storage Boxes support multiple access protocols (SSH/SCP, SFTP, rsync, Samba/CIFS, WebDAV, HTTPS) providing flexible data access patterns for different use cases from command-line backup to web-based file management.

### storage-box-only-delete-protection [IN] OBSERVATION
Delete protection is the only protection type available for Storage Boxes (unlike servers which also have rebuild protection)
- Source: entries/2026/03/11/hcloud_storage-box_create.md
- Source hash: 0eb66ffbd8b1a689
- Date: 2026-03-11

### storage-box-protocols-cifs-sftp-scp-rsync-borg [IN] OBSERVATION
Storage Boxes are accessible via CIFS/SMB, SFTP, SCP, rsync, and BorgBackup protocols.
- Source: entries/2026/03/11/robot-api-reference.md
- Source hash: 020d05031f709fa8
- Date: 2026-03-11

### storage-box-secure-but-operationally-isolated [IN] OBSERVATION
Storage Boxes occupy an operationally isolated position within the Hetzner ecosystem — secure by default (external reachability disabled) and on a separate API from cloud resources, with fragmented access control (reset-only passwords, separate home directory commands) — making integration into automated cloud workflows disproportionately complex relative to their storage utility.

### storage-box-snapshots-support-labels [IN] OBSERVATION
Storage Box snapshots support the standard Hetzner label system via add-label and remove-label subcommands.
- Source: entries/2026/03/11/hcloud_storage-box_snapshot.md
- Source hash: 18146cf57c64efe7
- Date: 2026-03-11

### storage-box-subaccount-change-home-directory-separate-command [IN] OBSERVATION
Changing a Storage Box subaccount's home directory uses a separate `change-home-directory` command rather than the general `update` command.
- Source: entries/2026/03/11/hcloud_storage-box_subaccount.md
- Source hash: 9587f09b9a0982fa
- Date: 2026-03-11

### storage-box-subaccount-reset-password-not-set [IN] OBSERVATION
Storage Box subaccount password management uses `reset-password` (not set-password) — passwords can only be reset, not arbitrarily set.
- Source: entries/2026/03/11/hcloud_storage-box_subaccount.md
- Source hash: 9587f09b9a0982fa
- Date: 2026-03-11

### storage-box-subaccount-two-update-commands [IN] OBSERVATION
Storage Box subaccounts have two distinct update commands: `update` for general properties and `update-access-settings` for protocol/access controls.
- Source: entries/2026/03/11/hcloud_storage-box_subaccount.md
- Source hash: 9587f09b9a0982fa
- Date: 2026-03-11

### storage-box-supports-snapshot-rollback [IN] OBSERVATION
Storage Boxes support automatic snapshot plans and rollback to a previous snapshot state
- Source: entries/2026/03/11/hcloud_storage-box.md
- Source hash: 54d2a9eeb6db1a00
- Date: 2026-03-11

### storage-box-supports-subaccounts [IN] OBSERVATION
Storage Boxes support subaccounts for delegated or segmented access control
- Source: entries/2026/03/11/hcloud_storage-box.md
- Source hash: 54d2a9eeb6db1a00
- Date: 2026-03-11

### storage-box-supports-zfs-snapshots [IN] OBSERVATION
Storage Boxes support a ZFS snapshot folder feature that can be made visible via `--enable-zfs`
- Source: entries/2026/03/11/hcloud_storage-box_create.md
- Source hash: 0eb66ffbd8b1a689
- Date: 2026-03-11

### storage-box-three-access-protocols [IN] OBSERVATION
Storage Boxes support three access protocols — Samba, SSH, and WebDAV — each toggled independently at creation time
- Source: entries/2026/03/11/hcloud_storage-box_create.md
- Source hash: 0eb66ffbd8b1a689
- Date: 2026-03-11

### storage-box-uses-hetzner-api-not-cloud-api [IN] OBSERVATION
Storage Box commands use the Hetzner platform API (`api.hetzner.com/v1`), distinct from the Hetzner Cloud API (`api.hetzner.cloud/v1`)
- Source: entries/2026/03/11/hcloud_storage-box.md
- Source hash: 54d2a9eeb6db1a00
- Date: 2026-03-11

### terraform-provider-acceptance-tests-create-real-resources [IN] OBSERVATION
Acceptance tests (`make testacc`) create real Hetzner Cloud resources and incur costs; unit tests (`make test`) do not
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-provider-auth-env-var [IN] OBSERVATION
The `HCLOUD_TOKEN` environment variable provides API authentication for the Terraform provider and its tests
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-provider-built-on-hcloud-go [IN] OBSERVATION
The Terraform provider is built on top of the `hcloud-go` Go SDK for API communication
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-provider-go-code-no-compat-guarantee [IN] OBSERVATION
The provider's Go code has no backwards-compatibility guarantee; only HCL usage is considered stable
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-provider-id-hetznercloud-hcloud [IN] OBSERVATION
The Terraform provider registry identifier is `hetznercloud/hcloud` (not `hetzner/hcloud`)
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-provider-local-dev-overrides [IN] OBSERVATION
Local provider development uses `dev_overrides` in a `.tfrc` CLI config file pointed to by `TF_CLI_CONFIG_FILE`
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-provider-plugin-protocol-v6 [IN] OBSERVATION
The Hetzner Cloud Terraform provider uses Terraform Plugin Protocol version 6
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-provider-supports-opentofu [IN] OBSERVATION
The provider supports both Terraform and OpenTofu (any tool implementing Plugin Protocol v6)
- Source: entries/2026/03/11/terraform-provider-readme.md
- Source hash: 4b504e518a68484c
- Date: 2026-03-11

### terraform-testing-no-sandbox-path [IN] OBSERVATION
Terraform provider development has no sandbox path — acceptance tests create real Hetzner Cloud resources incurring actual charges, local development requires CLI config file overrides via `TF_CLI_CONFIG_FILE`, and authentication relies entirely on the `HCLOUD_TOKEN` environment variable with no mock or test-credential alternative.

### txt-record-255-char-quoted-string-limit [IN] OBSERVATION
TXT DNS records must consist of one or many quoted strings of up to 255 characters; the hcloud CLI will auto-format unquoted TXT records.
- Source: entries/2026/03/11/hcloud_zone_rrset.md
- Source hash: e27d6cf8cd6cf53a
- Date: 2026-03-11

### volume-attachment-operationally-non-trivial [IN] OBSERVATION
Volume attachment is an operationally non-trivial workflow with implicit ordering dependencies — exclusive single-server binding enforced, raw block device requiring manual formatting, automount conditional on server being specified at creation, and location co-residency required — making automated volume orchestration a multi-step process that cannot be simplified to a single API call.

### volume-durability-with-constraints [IN] OBSERVATION
Hetzner Cloud Volumes provide durable block storage (triple-replicated Ceph, expand-only resize) but are constrained to a single location and 10TB maximum, making cross-location replication an application-level concern.

### volume-durable-but-single-server-bound [IN] OBSERVATION
Hetzner Volumes are highly durable (triple-replicated Ceph, expand-only resize) but architecturally constrained to single-server use cases — single writer at every layer (Cloud API one-attachment limit, CSI RWO-only) combined with location binding and 10TB caps rules out shared-storage, distributed filesystem, and cross-location replication patterns natively.

### volume-operational-per-server-constraints [IN] OBSERVATION
Hetzner Volumes impose rigid per-server operational constraints beyond their architectural single-writer limitation — maximum 16 attachments per server, raw block devices requiring explicit formatting before use (ext4 or xfs only), and automount dependent on server attachment at creation time.

### volume-single-writer-at-every-layer [IN] OBSERVATION
Hetzner volumes enforce single-writer semantics at every layer of the stack: one server attachment at a time (Cloud API), ReadWriteOnce-only access mode (CSI/Kubernetes), and location-bound placement — ruling out shared-storage patterns without external solutions.

### vswitch-layer2-cloud-dedicated-connectivity [IN] OBSERVATION
vSwitch provides Layer 2 connectivity between Hetzner Cloud servers and dedicated servers.
- Source: entries/2026/03/11/hetzner-cloud-networking.md
- Source hash: 490d8986b7c63e22
- Date: 2026-03-11

### async-credential-explosion-compounds-operations [OUT] OBSERVATION
Multi-project automation faces compound operational complexity — async convergence must be tracked per-action while credentials must be managed per-project-per-API, making error handling a cross-product of two independent complexity dimensions.

### automated-incident-response-doubly-blocked [OUT] OBSERVATION
Automated incident response on Hetzner is blocked at both ends of the detection-recovery pipeline — platform metrics remain ALPHA (inadequate for automated alerting and anomaly detection) while server recovery requires explicit multi-step manual intervention (enable rescue, separate reboot, SSH key reconfiguration), creating a full-stack gap that external tooling must bridge at both detection AND remediation layers simultaneously.

### automated-recovery-impossible-without-external-tooling [OUT] OBSERVATION
Automated server recovery is impossible without comprehensive external tooling — rescue mode requires manual multi-step intervention (explicit reboot, per-attempt SSH key setup, type selection) while the broader safety model is fundamentally user-responsible (explicit backup strategy, shallow protection flags), creating a gap where no platform-native path exists from failure detection to restored operation.

### automation-must-bridge-api-paradigm-gap [OUT] OBSERVATION
Full Hetzner automation requires tools that bridge fundamentally different API paradigms — modern JSON/Bearer token (Cloud) vs legacy URL-encoded/Basic Auth (Robot) — across three toolchain layers (CLI, SDK, IaC), making unified abstraction a prerequisite for multi-product management.

### automation-toolchain-stable-when-experimental-avoided [OUT] OBSERVATION
Hetzner's three-layer automation toolchain (CLI, Go/Python SDKs, Terraform/OpenTofu provider) with uniform resource identity patterns provides a production-stable foundation for infrastructure-as-code — when experimental features are avoided, as both hcloud-go and hcloud-python may introduce breaking changes in minor releases for experimental APIs.

### billing-complexity-pervades-all-products [OUT] OBSERVATION
Billing complexity pervades Hetzner's entire product line, not just compute — compute has powered-off billing traps and IPv4 charges, traffic varies 40x by region with monthly caps, and Object Storage adds 64KB minimum billing, empty bucket charges, TB-hours accounting, and no quota rollover — making accurate TCO modeling a mandatory cross-product exercise rather than a per-resource calculation.

### billing-traps-invisible-without-external-monitoring [OUT] OBSERVATION
Hetzner's billing traps (powered-off server charges, IPv4 idle costs, 64KB minimum object billing, empty bucket charges) pervade all products but are invisible to users relying on platform-native monitoring — since both server and load balancer metrics remain ALPHA, detecting cost anomalies from idle or misconfigured resources requires external billing instrumentation.

### ccm-kubernetes-integration-production-ready [OUT] OBSERVATION
The Hetzner Cloud Controller Manager provides production-ready Kubernetes integration with both Cloud and Robot APIs, including annotation-driven load balancer configuration.

### complete-ingress-zero-downtime-safe [OUT] OBSERVATION
The fully managed Hetzner ingress pipeline — DNS zones with granular RRSet mutation, managed TLS certificates, hybrid load balancers with health checks — supports zero-downtime production traffic management with resource protection and incremental record updates at every layer.

### compute-scales-vertically-storage-plateaus [OUT] OBSERVATION
Hetzner's scaling story is split: compute and load balancing have predictable vertical paths (four server series, three LB tiers at linear 1x/3x/6x ratios), but storage hits different ceilings in each paradigm (10TB volumes, EU-only objects, location-bound blocks) with no universal scaling path.

### compute-storage-scaling-asymmetry-limits-growth [OUT] OBSERVATION
Hetzner's scaling story has a fundamental asymmetry: compute and load balancing scale vertically and predictably, but storage plateaus at every paradigm (10TB Volume cap, single-writer only, EU-only Object Storage, no shared-write) — growing deployments hit storage ceilings that force architectural workarounds while compute has clear upgrade paths.

### cost-transparency-degrades-with-scale [OUT] OBSERVATION
Hetzner's cost transparency degrades super-linearly with deployment complexity — the billing model appears simple at entry but becomes progressively opaque as multi-product traps (powered-off servers, idle IPv4s, small-object penalties, empty buckets, regional traffic asymmetry) accumulate across products without platform-provided cost monitoring.

### deletion-safety-net-comprehensive [OUT] OBSERVATION
Hetzner's multi-layer deletion safeguards (protection flags requiring explicit disable, deprecated image blocking, required flags for destructive operations) combined with the consistent delete-only protection pattern form a comprehensive safety net across all resource types — when the DNS zone import destructive-replace behavior is addressed as the remaining gap.

### dns-zone-management-production-safe [OUT] OBSERVATION
Hetzner DNS zone management supports production-safe workflows with resource protection, granular RRSet-level mutation (append/replace/delete independently), and secondary zone replication for redundancy.

### entry-ease-masks-irreversible-architecture [OUT] OBSERVATION
Hetzner's entry-friendliness masks the criticality of initial architecture decisions — the frictionless on-ramp (no contracts, hourly billing, free infrastructure services) makes casual initial decisions likely, but storage composition and location choices are effectively permanent (no cross-location migration, paradigm-specific constraints), creating an experience where the easiest phase is also the most consequential.

### entry-friendly-but-operationally-demanding [OUT] OBSERVATION
Hetzner's economic model front-loads value (no contracts, hourly billing, free infrastructure services) but back-loads operational burden — deceptive billing traps, user-responsible safety across destructive operations, and mandatory deliberate storage composition create a steep operational maturity curve that only manifests at production scale.

### entry-to-production-single-provider-complete [OUT] OBSERVATION
Hetzner would be viable as a complete entry-to-production single-provider journey — frictionless economic on-ramp, fully managed private ingress pipeline (DNS through TLS through hybrid load balancing), and comprehensive three-layer automation toolchain — if platform-native observability graduated from ALPHA to production-grade, closing the last gap in the autonomous operations lifecycle.

### eu-full-stack-single-provider-viable [OUT] OBSERVATION
Hetzner is viable as a sole infrastructure provider for EU-based workloads — the free managed ingress pipeline, elastic no-commitment billing, and three complementary storage paradigms (block, object, network-attached) cover all infrastructure layers without external dependencies.

### eu-storage-composition-complete-for-standard-workloads [OUT] OBSERVATION
For EU-based workloads with standard object sizes, Hetzner's three storage paradigms compose into a complete solution — triple-replicated block storage for databases (Volumes), S3-compatible object storage for assets, multi-protocol network storage for backups (Storage Boxes with BorgBackup/rsync) — viable when workloads avoid the small-file billing penalty and accept empty-bucket cost overhead.

### external-orchestration-must-scale-with-governance-gap [OUT] OBSERVATION
The external orchestration layer Hetzner demands must itself solve an expanding governance problem — solving today's platform gaps creates tomorrow's orchestration governance burden, as governance complexity grows super-linearly with deployment scale.

### frictionless-onramp-to-irreversible-lock-in [OUT] OBSERVATION
Hetzner's business model creates a structural trap: the same frictionless on-ramp (no contracts, hourly billing, free infrastructure) that attracts deployments systematically obscures the irreversible architectural decisions embedded in initial setup — location, storage paradigm, and placement group choices that cannot be changed later — while growth reveals constraints (compute-storage asymmetry, billing-location coupling) that are too entrenched to escape.

### ftl2-complete-hybrid-lifecycle-orchestrator [OUT] OBSERVATION
FTL2's architecture — async-native execution, 250x native module speed, Ansible collection bridging — precisely matches Hetzner's purpose-built hybrid orchestration requirements, making it the natural lifecycle orchestrator once native Hetzner modules land.

### ftl2-enables-hybrid-convergence-when-native-modules-land [OUT] OBSERVATION
FTL2 could provide unified hybrid Hetzner orchestration — combining 250x-faster native module execution with Ansible collection modules to bridge the Cloud/Robot API paradigm gap in a single async Python tool, eliminating the need for multi-protocol automation wrappers.

### ftl2-hetzner-automation-complete [OUT] OBSERVATION
FTL2 provides complete Hetzner Cloud automation via Ansible collection FQCN modules with secret-safe token injection and idempotent state management.

### full-platform-single-tool-manageable [OUT] OBSERVATION
The full Hetzner platform (cloud VMs, dedicated servers, storage boxes, DNS) can be managed through a single automation tool given the three-layer toolchain and consistent CLI resource identity patterns.

### full-stack-private-infrastructure-viable [OUT] OBSERVATION
Hetzner Cloud supports production-viable fully private infrastructure with no public internet exposure across compute, load balancing, and networking layers.

### governance-gap-widens-at-scale [OUT] OBSERVATION
Hetzner's governance gap widens super-linearly with deployment complexity — single-project deployments face shallow protection and billing traps, but multi-project deployments compound credential explosion with API paradigm bridging requirements, demanding progressively heavier external governance infrastructure as scope grows.

### governance-must-bridge-api-paradigms [OUT] OBSERVATION
External governance tooling for Hetzner must itself bridge the API paradigm gap — resource protection gaps (predominantly delete-only, no RBAC) and billing transparency issues span both the Cloud API (modern Bearer/JSON) and Robot API (legacy Basic/URL-encoded), meaning governance cannot be implemented against a single API surface and no unified governance integration point exists within the platform.

### growing-deployments-face-location-migration-trap [OUT] OBSERVATION
Growing Hetzner deployments face a migration trap — scaling ceilings force multi-provider solutions, but location lock-in makes migration progressively harder as data and dependencies accumulate, creating a narrowing window of escape.

### growth-constrained-along-two-irreversible-axes [OUT] OBSERVATION
Hetzner deployment growth is constrained along two irreversible axes that compound over time — compute-storage scaling asymmetry limits what can be built (storage plateaus while compute scales), and billing-location coupling determines what it costs (40x traffic variance locks to initial location), with both constraints established at deployment inception and neither addressable through platform evolution alone.

### hetzner-complete-lifecycle-trap [OUT] OBSERVATION
Hetzner's architecture creates a complete lifecycle trap: frictionless entry enables rapid adoption, adoption triggers the fundamental scaling paradox, and the paradox demands solutions that deepen the very lock-in making escape from scaling ceilings impossible — a self-reinforcing cycle with no platform-provided exit ramp.

### hetzner-fundamental-scaling-paradox [OUT] OBSERVATION
Hetzner deployments face a fundamental scaling paradox: growth simultaneously creates the problems it demands solutions for — expanding deployments encounter location lock-in, governance gaps, and operational complexity (the double bind) while the orchestration layer needed to solve these must itself solve an ever-expanding governance and complexity problem (the recursive scaling problem) — a self-reinforcing trap where the cost of the solution grows faster than the problems it addresses, with no platform-level escape hatch.

### hybrid-automation-compound-complexity [OUT] OBSERVATION
Hetzner hybrid cloud-dedicated automation faces compound complexity across three axes: fundamentally different API paradigms requiring multi-protocol bridging (Cloud REST/Bearer vs Robot Basic/URL-encoded), asynchronous operations propagating wait/poll patterns through every automation layer (CLI 500ms polling, Go SDK WaitFor, Terraform), and network convergence spanning Layer 2 (vSwitch) and Layer 7 (LB) — requiring automation tooling that handles protocol translation, convergence timing, and multi-layer networking simultaneously.

### hybrid-automation-triple-compound-complexity [OUT] OBSERVATION
Full Hetzner hybrid automation faces triple compound complexity that no single existing tool addresses — different API paradigms (REST/Bearer vs URL-encoded/Basic Auth), different security postures (shallow Cloud protections vs aggressive Robot lockout), AND async propagation through all layers must be bridged simultaneously by any orchestration solution.

### hybrid-dedicated-uniform-automation-contract [OUT] OBSERVATION
Cloud and dedicated server automation would share a uniform API contract — same authentication mechanism, same request encoding, same async convergence model — enabling true single-tool full-stack hybrid management without the multi-paradigm bridging complexity that currently dominates hybrid operations.

### hybrid-growth-double-bind [OUT] OBSERVATION
Growing private hybrid deployments face a double bind — the private hybrid architecture is sound and cost-free at the infrastructure level but demands expensive external orchestration, while scaling creates location lock-in that makes this growing orchestration investment increasingly irreversible, trapping deployments in a cycle where each increment of capability deepens the commitment.

### hybrid-lifecycle-requires-purpose-built-orchestration [OUT] OBSERVATION
Full lifecycle Hetzner hybrid automation requires purpose-built orchestration that simultaneously handles async convergence, multi-protocol API bridging, and external governance — no single off-the-shelf tool covers all three axes.

### hybrid-requires-multi-paradigm-automation [OUT] OBSERVATION
Achieving hybrid cloud-dedicated infrastructure programmatically requires automation that bridges both Layer 2/7 network convergence and fundamentally incompatible API authentication paradigms (Bearer token vs HTTP Basic Auth vs URL-encoded POST).

### hybrid-tempo-mismatch-compounds-automation-complexity [OUT] OBSERVATION
The temporal mismatch between cloud operations (async polling convergence) and dedicated server operations (next-restart configuration) compounds the already triple-complex hybrid automation challenge — the orchestration layer must reconcile fundamentally different convergence models on top of bridging different API paradigms, security postures, and credential systems.

### irreversible-commitment-cascade [OUT] OBSERVATION
Hetzner architecture decisions cascade into increasingly difficult-to-change commitments: location selection locks resources, storage paradigm choice determines data management patterns, and vertical scaling limits create eventual capacity constraints — each layer narrowing future options.

### kubernetes-full-hetzner-integration [OUT] OBSERVATION
Hetzner provides full Kubernetes integration spanning compute management (CCM for cloud and dedicated servers), persistent storage (CSI driver), and service networking (annotation-driven load balancers) — a complete K8s infrastructure layer.

### kubernetes-full-stateful-workload-management [OUT] OBSERVATION
Hetzner Kubernetes deployments have durable persistent storage via CSI-provisioned triple-replicated Volumes, which would support full stateful workload management including databases and distributed storage if the CSI driver supported multi-writer access modes.

### kubernetes-hybrid-orchestration-viable [OUT] OBSERVATION
Kubernetes on Hetzner can orchestrate hybrid workloads across cloud VMs and dedicated servers with unified annotation-driven load balancing targeting both infrastructure types.

### lb-tiers-scale-linearly-six-to-one [OUT] OBSERVATION
Load balancer tiers (LB11→LB21→LB31) scale at 1x/3x/6x ratios across all four dimensions (services, targets, certificates, traffic), enabling predictable capacity planning.

### location-constrains-entire-stack [OUT] OBSERVATION
Location simultaneously constrains scaling (vertical paths locked to region), storage composition (Volumes location-bound, Object Storage EU-only, Storage Boxes location-specific), and cost profile (40x traffic asymmetry) — making it the single binding constraint that threads through every architectural layer of the Hetzner stack.

### location-determines-platform-ceiling-and-exit-cost [OUT] OBSERVATION
Location simultaneously constrains every scaling axis within Hetzner AND determines the difficulty of multi-provider escape — the single most consequential deployment decision also governs how hard it is to leave.

### location-is-primary-architectural-decision [OUT] OBSERVATION
Location is the single most consequential architectural decision on Hetzner — it simultaneously determines cost profile (40x traffic variance), scaling ceiling (resource availability by region), and resource mobility (location-bound resources prevent live relocation).

### location-lock-in-amplifies-operational-risk [OUT] OBSERVATION
Location lock-in amplifies operational risk — since core resources cannot migrate between locations and Hetzner's safety model is user-responsible, mistakes in initial location selection cascade through scaling, cost, and data protection with no platform-assisted recovery path, making day-one architecture decisions irreversible.

### multi-project-billing-governance-explosion [OUT] OBSERVATION
Multi-project Hetzner deployments face a governance explosion across both security and cost dimensions simultaneously — each additional project multiplies credential management burden (per-project tokens across three incompatible APIs) AND billing trap surface area (powered-off servers, idle IPs, storage quirks replicated per project), with no cross-project visibility or aggregated governance tooling.

### multi-project-governance-triply-fragmented [OUT] OBSERVATION
Multi-project Hetzner governance is triply fragmented — credential management multiplies per-project per-API, billing traps multiply per-project per-product, and security models vary per-API with no unification layer — requiring external governance tooling that simultaneously bridges three independently fragmented dimensions.

### multi-project-hybrid-automation-exponential-complexity [OUT] OBSERVATION
Multi-project hybrid automation on Hetzner faces exponential complexity — purpose-built orchestration needed per hybrid topology (async convergence, multi-protocol API bridging, governance bridging) multiplied by credential explosion across projects and three incompatible API paradigms.

### multi-region-data-architecture-viable [OUT] OBSERVATION
Hetzner's storage options (durable triple-replicated Volumes and multi-protocol Storage Boxes) enable viable multi-region data architectures across all six datacenter locations.

### multi-region-private-networking-viable [OUT] OBSERVATION
Hetzner's orthogonal network planes with free security perimeter provide the primitives for sophisticated multi-region private infrastructure — viable once private networks can span across locations.

### network-hybrid-topology-location-unrestricted [OUT] OBSERVATION
Hetzner's hierarchical zone-based network topology with vSwitch Layer 2 bridging enables unrestricted hybrid cloud-dedicated connectivity across all locations.

### network-three-orthogonal-resource-planes [OUT] OBSERVATION
Hetzner's network architecture provides three orthogonal resource planes — zone-based topology for connectivity, decoupled label-driven firewalls for policy, and three IP lifecycle tiers for addressing — each managed independently but all subject to location binding constraints.

### object-storage-billing-hidden-complexity [OUT] OBSERVATION
Object Storage billing has four non-obvious behaviors that complicate cost prediction: 64KB minimum billing per object (penalizes small files), empty active buckets still charged hourly, unused quota does not roll over month-to-month, and TB-hours metering that makes long-lived storage more expensive than equivalent monthly averages suggest.

### object-storage-enterprise-ready [OUT] OBSERVATION
Hetzner Object Storage is enterprise-ready with S3 compatibility, free ingress and API calls, generous limits (100 buckets, 100TB/bucket), and predictable base-tier pricing — suitable for primary object storage workloads.

### object-storage-predictable-cost-model [OUT] OBSERVATION
Hetzner Object Storage offers a predictable cost model with a fixed base tier (EUR 4.99/month), free ingress, and free API calls.

### observability-gap-compounds-safety-burden [OUT] OBSERVATION
Hetzner demands user-managed safety (explicit backup strategies, manual rescue intervention, protection flag discipline) while providing only ALPHA-status platform observability — users must build both the safety net AND the monitoring infrastructure to detect when that safety net is needed, doubling the external tooling burden.

### orchestration-layer-becomes-lock-in-vector [OUT] OBSERVATION
The external orchestration layer Hetzner demands becomes itself a lock-in vector — as it grows to solve expanding governance gaps and exponential automation complexity, the orchestration layer accumulates its own irreversible commitments (protocol bridges, credential management, convergence logic) that deepen platform dependency rather than enabling escape.

### orchestration-recursive-scaling-problem [OUT] OBSERVATION
The external orchestration layer Hetzner demands must simultaneously solve expanding governance gaps (uneven maturity, inconsistent safety) AND exponential multi-project complexity (credential explosion, per-topology hybrid automation), creating a recursive scaling problem where the management layer itself faces the same scaling challenges as the infrastructure it manages.

### platform-demands-external-orchestration-layer [OUT] OBSERVATION
Hetzner's platform demands a comprehensive external orchestration layer — uneven product maturity, an inconsistent safety model requiring external unification, and a fundamentally user-responsible operational posture collectively mean no production deployment can rely on built-in platform capabilities alone.

### platform-maturity-uneven-across-products [OUT] OBSERVATION
Hetzner's platform exhibits uneven maturity across product lines — billing traps and security model inconsistencies pervade compute, storage, and networking differently, requiring product-by-product operational awareness rather than uniform platform assumptions.

### platform-observability-immature [OUT] OBSERVATION
Platform observability is immature — both server metrics and load balancer metrics remain in ALPHA status, leaving production monitoring entirely dependent on external tooling with no platform-native telemetry path to GA.

### private-hybrid-architecture-sound-but-operationally-expensive [OUT] OBSERVATION
The private hybrid ingress reference architecture is sound and cost-free at the infrastructure level, but the external orchestration layer it demands makes total cost of ownership primarily operational rather than financial — Hetzner's pricing advantage shifts cost from infrastructure to engineering.

### private-hybrid-fully-autonomous [OUT] OBSERVATION
Private hybrid cloud-dedicated architectures on Hetzner can operate as fully autonomous private infrastructure — free security perimeter, private-only load balancers as the sole ingress, vSwitch Layer 2 bridging between cloud and dedicated servers — forming a complete private stack requiring zero public internet exposure for production traffic.

### private-hybrid-ingress-reference-architecture [OUT] OBSERVATION
Private hybrid ingress — combining free security perimeter, managed DNS-to-TLS-to-LB pipeline, and zero-cost hybrid cloud/dedicated targeting — forms the natural reference architecture for Hetzner deployments, eliminating the cost-vs-security tradeoff typical of cloud ingress design.

### private-hybrid-scales-beyond-single-location [OUT] OBSERVATION
The private hybrid ingress reference architecture — free security perimeter, managed DNS-to-TLS-to-LB pipeline, zero-cost hybrid cloud/dedicated targeting — scales to multi-location deployments when private networks extend beyond single-datacenter scope, enabling geo-distributed private hybrid topologies.

### production-operations-require-shadow-platform [OUT] OBSERVATION
Production Hetzner operations require building a complete shadow platform — external orchestration for provisioning (bridging uneven maturity and inconsistent safety), external monitoring for observability (ALPHA metrics inadequate), AND external incident response tooling (rescue mode manual-only) — three independent external systems the platform provides no integration points between.

### rescue-mode-manual-intervention-required [OUT] OBSERVATION
Server rescue mode requires explicit manual intervention at every step — no auto-reboot on enable, separate SSH key configuration per attempt, and linux64 as the default type — there is no automated recovery path built into the platform.

### robot-dedicated-lifecycle-multi-step-preconfig [OUT] OBSERVATION
Robot API dedicated server operations require multi-step pre-configuration for every lifecycle event — boot configuration only takes effect on next restart, failover IPs must be pre-configured on all potential targets before routing can switch, and server cancellations are a two-phase create-then-optionally-revoke process.

### scaling-ceiling-forces-multi-provider [OUT] OBSERVATION
Hetzner deployments that outgrow the platform's scaling ceilings (10TB volumes, single-writer storage, EU-only Object Storage) while facing international constraints (missing services, 40x traffic cost, third-party facilities) must adopt external providers — the growth path transitions from vertical within Hetzner to horizontal across providers.

### scaling-paradox-compounded-by-irreversible-commitments [OUT] OBSERVATION
The fundamental scaling paradox is compounded by accumulated irreversibility — growth creates problems that demand solutions, but each solution (location consolidation, storage composition, API integration choice) deepens irreversible commitments that narrow the solution space for future problems, making later-stage architectural pivots progressively impossible.

### scaling-paths-vertical-predictable [OUT] OBSERVATION
Hetzner provides clear vertical scaling paths for both compute (four server series from shared to dedicated ARM/AMD) and load balancing (three LB tiers with linear 1x/3x/6x ratios), enabling predictable capacity planning without architectural changes.

### sdk-migration-adds-temporal-irreversibility [OUT] OBSERVATION
SDK version migration adds an irreversible temporal dimension to the commitment cascade — hcloud-go's strict two-version support window forces upgrade cycles that cascade through Terraform providers and automation tooling, creating time-bounded windows where existing automation becomes unsupported regardless of deployment stability.

### security-automation-must-bridge-dual-postures [OUT] OBSERVATION
Automation bridging Hetzner's API paradigm gap must simultaneously bridge its inconsistent security posture — the Cloud API's shallow protections and the Robot API's aggressive lockouts require fundamentally different defensive strategies within the same automation codebase.

### sovereignty-growth-deadlock [OUT] OBSERVATION
Organizations needing both EU data sovereignty and international reach face a deadlock — sovereignty requires committing to EU locations (self-operated datacenters, co-located Object Storage), but that commitment maximizes exit cost precisely when international scaling ceilings force multi-provider expansion.

### storage-box-integrates-into-cloud-automation [OUT] OBSERVATION
Storage Boxes would integrate seamlessly into private cloud automation workflows — multi-protocol versatility (SFTP, rsync, BorgBackup), ZFS snapshots, subaccount delegation — alongside the free security perimeter and private networking stack, if they shared the Cloud API authentication mechanism rather than requiring separate Hetzner platform API credentials.

### storage-decisions-irreversible-and-location-permanent [OUT] OBSERVATION
Storage composition decisions are effectively permanent — no platform-supported migration exists between locations, so the initial storage strategy and its location coupling are irrevocable architectural commitments.

### storage-irreversibility-amplifies-scaling-ceiling [OUT] OBSERVATION
Storage irreversibility amplifies the scaling ceiling — since storage decisions are permanent (no cross-location migration, paradigm-locked composition) and storage is the dimension that plateaus first (10TB Volumes, EU-only Object Storage, single-writer constraint), the initial storage architecture becomes the binding constraint on overall platform growth, not compute or networking.

### storage-requires-deliberate-composition [OUT] OBSERVATION
Every production Hetzner architecture needs a deliberate storage composition strategy — no single paradigm covers typical needs of durable, scalable, multi-writer, multi-region storage, so deployments must combine Volumes (durable but location-bound single-writer), Object Storage (S3-compatible but EU-only), and Storage Boxes (multi-protocol NAS) with their respective constraints.

### storage-three-paradigms-none-universal [OUT] OBSERVATION
Hetzner offers three persistent storage paradigms (Volumes: block/location-bound/10TB cap, Object Storage: S3-compatible/EU-only, Storage Boxes: multi-protocol NAS/platform API) — each with distinct constraints, and none providing globally available, horizontally scalable storage.

### terraform-development-mirrors-operational-burden [OUT] OBSERVATION
Terraform development for Hetzner requires managing SDK version dependencies and testing against live infrastructure (no sandbox environment), adding development overhead that reflects the platform's operational characteristics.

### terraform-provider-stable-extension-path [OUT] OBSERVATION
The Hetzner Terraform/OpenTofu provider offers a stable extension path for custom automation built on top of the provider's Go SDK layer.

### vertical-scaling-location-locked [OUT] OBSERVATION
Hetzner's scaling story is vertically predictable but geographically locked — four server series and three LB tiers provide clear upgrade paths within a location, but volumes, Floating IPs, and networks being location-bound means capacity planning must be per-location with no transparent cross-location horizontal scaling, forcing multi-location architectures to be explicitly designed rather than elastically discovered.