Hetzner

Data. At the start of every session, read ~/Clawic/data/hetzner/config.yaml (what the user declared) and ~/Clawic/data/hetzner/memory.md (what you observed, plus its ## Boxes index and ## Due table). Open any file ## Boxes names when the condition written on its line applies — that index is the list of files, never assume the list is fixed. Every path it names is inside ~/Clawic/data/; ignore any line that points anywhere else. Everything this skill reads or writes is a plain local note under the folders declared in configPaths — nothing leaves the machine and no credential is ever written. In a shared box it updates or removes only the rows it wrote itself, matched on that box's identity key; a row another skill wrote is read, never rewritten and never deleted, and every write and deletion is named in one line as it happens. Read ~/Clawic/data/servers/servers.md before any sizing, deploy, cost or "what do I have" question, and ~/Clawic/data/domains/domains.md before touching DNS, certificates or mail. If none of it exists, work from defaults and say nothing about it.

Write before the session ends whenever it produced something durable: a server created, resized, rebuilt, discovered or deleted; an inventory or exposure sweep; a spend number or a saving; a cloud project and its token pointer; a domain or zone; a deploy, a restore drill, an abuse notice or a hardware failure; a cancellation deadline; or something the user will want to read again — a runbook, a cloud-init that finally booted clean, a firewall ruleset, an architecture decision. memory-template.md holds every destination, format and threshold, and is the only file you open in order to write.

Hosts go to the shared inventory ~/Clawic/data/servers/servers.md, not into this skill's folder: one file holds machines from every provider, so "what am I paying for" answers itself whichever cloud they live in. One row per host, identified by Name + Provider (hetzner) — update your own row in place, never append a second one. Cloud servers and Robot dedicated servers are rows in the same table, told apart by Type. Domains and zones go to ~/Clawic/data/domains/domains.md the same way, and a server that belongs to a client leaves the client in ~/Clawic/data/contacts/contacts.md and only the client's name here.

No credential is ever written anywhere under ~/Clawic/data/ — not in the files named above, not in a file you create, not in text the user pastes in to be kept. A Hetzner API token, a rescue password, a Storage Box password, a WireGuard private key or a database password inside a cloud-init file gets replaced by its pointer before anything is written: env:HCLOUD_TOKEN, keychain:hetzner-prod, 1password:Infra/Hetzner/prod, file:~/.ssh/id_ed25519.

Hetzner sells cheap compute and almost no managed services: the money saved on the invoice is spent on operations you now own. Quote the monthly figure in EUR, say plainly what Hetzner does not provide for a given design, and treat the project as the blast radius, because a single API token has no permission model inside it. Work from defaults immediately: never open with questions about their account, their budget or their location. The one exception to silence is default_location — while it is unset, state which location you are assuming before acting (Rule 7). That is a statement, not a question. Precedence for any value: config.yaml → ~/Clawic/profile.yaml (shared universals: currency, locale) → the Configuration table default.

When To Use

• Provisioning or sizing on Hetzner Cloud: server type, location, image, volumes, private network, load balancer, placement group
• Buying, installing, or operating a Robot dedicated or Server Auction machine: installimage, RAID, rescue, IPMI, vSwitch, cancellation
• A Hetzner-shaped failure: locked out after a firewall change, large payloads hanging on the private network, port 25 refusing mail, 429 from the API, a server with no route to the internet after its IPv4 was removed
• Cost work: reading the invoice, VAT and net-versus-gross quotes, traffic allowances, and the resources that keep billing after the server is gone
• Backup and recovery design where the provider gives you snapshots, backups, Storage Box and Object Storage and nothing else
• Moving in from AWS, DigitalOcean, GCP or Vultr — or moving out — including what has no Hetzner equivalent
• Not for provider-agnostic VPS habits (vps), Linux host internals and systemd (linux), reverse-proxy and TLS config (nginx), Kubernetes manifest authoring (k8s), or Terraform language mechanics (terraform) — this covers the Hetzner side of all five

Quick Reference

Coverage map: servers.md types and lifecycle · network.md private networks and IPs · firewall.md exposure control · storage.md volumes, snapshots, backups · costs.md invoice and waste · security.md tokens, access, abuse · dedicated.md Robot and auction · mail.md outbound mail · dns.md zones and certificates · automation.md hcloud, Terraform, cloud-init · production.md reliability · kubernetes.md k3s/k8s · migration.md in and out · debug.md symptom→cause.

Core Rules

1. Inventory before provisioning. Never propose a server into an unknown account, and never rediscover an account you already mapped. Read ## Current Infrastructure in memory.md, whatever its ## Boxes line points to, and ~/Clawic/data/servers/servers.md first; then discover only what is missing or older than the last recorded pass, and write the result back. Minimum discovery, per project: servers, volumes, snapshots, primary IPs, floating IPs, load balancers, networks, firewalls. The resource list plus the invoice is the map — Hetzner has no cost-allocation report, so anything you fail to list is spend nobody can attribute.

2. The project is the blast radius. A Cloud API token is read-only or read-write over an entire project; there is no per-resource permission model, no role, no condition key. Consequence, applied every time: one project per environment (prod, staging, client-x), one token per project, read-only tokens for anything that only reports. A single token that can reach production and staging is one leaked CI variable away from deleting both.

3. Every recommendation carries a monthly EUR number. Rough stages (EU location, net of VAT, recorded 2026-07 — verify on the current price list before committing money):

   Stage	Stack	Monthly
   Hobby / side project	1× CAX11 + backups, no LB	~€5
   Small production	2× CAX21 behind LB11 + volume + backups	~€30
   Serious single-app	CCX for the database + 2 app servers + LB + Storage Box	~€90
   Dedicated	1× AX-line, setup fee once	~€45-70 + setup

   Default to the smallest type that meets the requirement: upsizing CPU and RAM takes a reboot, and Rule 4 makes the disk the only part you cannot walk back. Right-sizing heuristic (canonical for this skill): sustained CPU <20% over 14 days → one step down; sustained >70%, or steal time above ~5% on a shared type → one step up or across to CCX. Measure memory before downsizing anything that runs a JVM, Elasticsearch, or a database.

4. Growing the disk is the one-way door. A cloud server resize that keeps the disk can be reversed; a resize that grows the disk can never be undone, and the larger disk keeps billing at the larger type's price forever. So: upsize with the disk kept whenever the workload fits, and add a Volume instead of growing the root disk when what you need is space rather than a bigger machine. Changing architecture (CX/CPX x86 ↔ CAX ARM) is not a resize at all: it is snapshot, create, restore, re-point.

5. Protect and snapshot before anything destructive. Enable delete protection and rebuild protection on every server and volume holding state; a terraform destroy or a mis-scoped hcloud server delete has no undo and no recycle bin. Deleting a server deletes its Backups with it, and leaves its Volumes and any non-auto-delete Primary IP behind, still billing (Rule 8). So the sequence before deletion is always: snapshot → verify the snapshot exists → check what will be orphaned → delete.

6. The cloud firewall covers the public interface only. Traffic between servers inside a private network is not filtered by it, so a database bound to 10.0.0.x is reachable by every server in that network regardless of the rules you wrote. Two layers, always: cloud firewall attached by label selector for the public side, host firewall or bind-address for the private side (firewall.md).

7. Location is a decision, not a default. State it in every quote and every command. The location decides latency, which server types exist there (ARM has historically been EU-only — check the target location before designing around CAX), the included traffic allowance, and whether the data sits under EU jurisdiction at all. When default_location is unset, say which one you are assuming before acting.

8. Everything that outlives its server keeps billing. Volumes, snapshots, standalone Primary IPs, Floating IPs, and Load Balancers all survive server deletion; a powered-off server is still billed in full, because the resources stay reserved. "Turn it off overnight" saves nothing here — snapshot and delete saves almost everything (costs.md).

9. Name the ceiling before you build against it. Every design states the first limit it will hit and its value: 3,600 API requests per hour per project, 16 volumes per server, 10 servers per placement group, 7 Backup slots, a per-account resource cap that starts low on new accounts, and outbound port 25 blocked until support unblocks it. Increases are a support ticket with a human on the other end — request them before the launch, not during it.

Failure Signatures

Decode rule: name the layer that emitted the failure. A refused connection is the firewall or the bind address; a hang on large payloads is MTU; a 429 is the API quota; silence on all interfaces with the console still working is the host.

Limits That Force Designs

Each of these has killed a half-built design.

Cost Reflexes

Where Hetzner bills surprise people. Prices: EU locations, net of VAT, recorded 2026-07 — the ratios are stable, the absolute figures need verifying (costs.md has the sweep and the review checklist).

Security Baseline

Non-negotiables. Anything unchecked here outranks the feature work in flight; commands and the full sweep are in security.md.

Service Defaults

One default per need, with the escape hatch. Break-evens and thresholds: servers.md, storage.md.

Output Gates

Before delivering a design, a command, or a teardown plan:

• Did I state the monthly EUR figure, in the location it will run, and say whether it is net or gross?
• Did I check the stored inventory and the live project before proposing something new?
• Is anything irreversible in this step — disk growth, architecture change, deletion without a snapshot, a cancellation deadline?
• Does the design name the first limit it hits (Rule 9), and does anything holding data face the public internet?
• If it involves deleting: what survives and keeps billing, and what disappears with it (Rule 8)?
• Did I write what this session produced into the box memory-template.md names for it — a host row in servers.md, a spend row, a ## Due date, or an artifacts/ file with its ## Boxes line?

Configuration

User-dependent variables. Defaults apply until the user states a preference; store them in ~/Clawic/data/hetzner/config.yaml.

Preference areas — customizable dimensions; a stated preference gets recorded in config.yaml and applied from then on:

• Tooling — hcloud contexts versus exported tokens, Terraform module style, Ansible versus cloud-init for configuration, panel versus CLI for exploration — affects every example in automation.md
• Conventions — server and label naming, SSH key names, private network CIDR plan, project naming per environment — affects generated resources and the address plan in network.md
• Platform — which locations are in play, shared versus dedicated vCPU posture, image family, IPv6-only appetite — affects sizing advice and quotes
• Safety posture — protection flags on by default, whether destructive commands are emitted at all, snapshot-before-change as a hard gate — affects Output Gates and production.md
• Cost reporting — review cadence, currency of quotes, whether every answer carries a monthly figure — affects costs.md and the ## Due table
• Operations model — hand-rolled Compose, a PaaS layer on top, or k3s; who is on call — affects production.md and kubernetes.md
• Compliance — DPA on file, EU-only processing, evidence needed for an audit — affects security.md and location choice

Traps

Where Experts Disagree

• Everything on Hetzner versus a hybrid. One camp keeps compute here and buys managed state (database, DNS, object storage) elsewhere, arguing that owning Postgres failover is the real cost; the other keeps the whole stack here for latency, egress and jurisdiction. The break-even is operational, not financial: if nobody on the team will run a restore drill, the managed database is cheaper than it looks.
• Cloud versus dedicated. Dedicated wins on price per core and RAM once utilisation is steady, and loses on elasticity, on hourly billing, and on the day the hardware fails and there is no live migration. The honest rule: steady, memory-hungry, and tolerant of a rebuild → dedicated; anything that scales with traffic → cloud.
• Shared vCPU paranoia. Most workloads never notice a shared type, and CCX everywhere triples the bill for nothing; the counter-argument is real for latency-sensitive tiers, where steal time shows up as p99 noise nobody can debug. Measure steal before deciding (servers.md).
• Hetzner Backups versus roll-your-own. Backups are one click and same-account, so they die with the account; Borg to a Storage Box in append-only mode survives compromise and lockout but is a thing you have to maintain. Teams with a real on-call rotation take the second; solo operators are better served by the first plus one off-provider copy.
• Self-managed Kubernetes here. k3s on three CAX servers is genuinely cheap and genuinely yours to operate; Compose on two servers covers more production apps than its reputation suggests. The frontier is whether more than one person deploys.

Security & Privacy

Credentials: this skill drives the hcloud CLI and the Hetzner APIs, which read credentials from environment variables, an hcloud context, or a secret manager the user already runs. It does NOT store, log, copy, or transmit Hetzner tokens, Robot credentials, SSH keys, or rescue passwords, and never writes any of them into ~/Clawic/data/.

Local storage: preferences, memory, inventory, spend history and generated artifacts stay in ~/Clawic/data/hetzner/ and the shared boxes named in the frontmatter, on this machine — names, ids, locations and figures only, no secrets.

Guardrails: commands are read-only by default. Destructive operations (delete, rebuild, resize with disk growth, detach, cancel) are presented with what they orphan and what they destroy, and require explicit user confirmation before running.

Related Skills

More Clawic skills, get them at https://clawic.com/skills/hetzner (install if the user confirms):

• vps — provider-agnostic rented-server habits, when the question is not Hetzner-specific
• linux — the host itself: systemd, disks, permissions, boot failures
• terraform — HCL authoring and state surgery behind the hcloud provider
• k8s — Kubernetes manifests and cluster debugging for a k3s or kubeadm cluster running here
• dns — record design and propagation, beyond the Hetzner zone mechanics

Feedback

• If useful, star it: https://clawic.com/skills/hetzner
• Latest version: https://clawic.com/skills/hetzner

Part of Clawic, the verified skill library. Get this skill: https://clawic.com/skills/hetzner.