Hetzner Projects — Inventar
Pro Kunde eigenes Hetzner Project — Mandanten-Trennungs-Konstrukt analog AWS-Sub-Account (siehe aws-multi-account-strategie Doktrin, gilt 1:1 für Hetzner).
Account-Setup
Klärungs-Status (Stand 2026-05-13): offen. Entscheidung Account-Pfad A/B/C steht aus, Details siehe account. Erste Klärung vor Unit 1 vom plan.
Sobald geklärt:
| Feld | Wert |
|---|---|
| Account-Name | tbd (nach Marvin-Decision) |
| Account-Email | tbd (hello@marvinkuehlmann.com bei UG-Account, privat@ bei Migration-Variante) |
| Account-Owner | Marvin Kühlmann |
| Default-Region | eu-central (Frankfurt / Nürnberg / Falkenstein) |
Projects (aktiv)
| Project | Status | Kunde | Region | Bestand | Detail |
|---|---|---|---|---|---|
av-mayday (vermutlich, je nach Account-Klärung) | live | mayday | tbd | VPS + Coolify + Postgres + R2 | tbd — siehe Kunden-File, Migration ins Vault offen |
av-tools (Default-Project unter aktuellem HCLOUD_TOKEN — Name in Konsole verifizieren) | live (seit 2026-05-15) | intern (kein Kunde) | nbg1 | 1× cx23 (Stirling PDF) + Firewall + SSH-Key | av-tools |
Projects (geplant / in Anlage)
| Project | Geplanter Status | Kunde | Sprint | Bestand | Detail |
|---|---|---|---|---|---|
av-<industriekunde-slug> | tbd Anlage Unit 2 | tbd Lead-Briefing offen | nach Account-Klärung + Lead-Briefing | wird Unit 2-7 angelegt: 2× Cloud Server (CCX23 + CCX13), Volume, Network, Firewall, 2× Object Storage Bucket | av-<slug>.md wird angelegt nach Project-Provisioning |
Project-Anlage — Step-by-Step
Schritt-für-Schritt für den nächsten av-<kunde>:
- Hetzner Cloud Console öffnen → Project-Auswahl-Dropdown oben links → „Add Project”
- Project-Name:
av-<kunde-slug>(kebab-case ASCII, keine Umlaute — siehe naming-konvention) - Optional: Project-Description (Kunde-Name + AV-Internal-Kennung)
- Im neuen Project: Security → API Tokens → Generate API Token → Read + Write Scope, Name
marvin-operations - Token in 1Password speichern unter
Hetzner / av-<kunde-slug> / api-token-operations - Lokale
~/.config/hcloud/cli.tomlergänzen:hcloud context create av-<kunde-slug> # → fragt nach Token, einfügen aus 1Password - Verifizieren:
hcloud --context av-<kunde-slug> server list(sollte leer aber ohne Fehler antworten) - Project-File anlegen:
intern/capabilities/hetzner/av-<kunde-slug>.mdnach Vorbild av-becker mit Header-Tabelle (Project-Name, Region, Erstellt, Kunde, Projekt-Wikilinks) + leere Sub-H3-Sektionen pro Service-Kategorie (Cloud Server, Volume, Network, Firewall, Object Storage, sonstige) - In diese Tabelle oben Project-Eintrag ergänzen
- Cost-Limit setzen (Hetzner Console → Project → Settings → Cost Limit): Soft 80% Budget, Hard 100% Budget (optional Server-Stop), Email-Verteiler hello@marvinkuehlmann.com
- Erste Resources anlegen (Servers, Volumes etc.) — siehe plan Unit 2
API-Token-Konvention
| Zweck | Name | Scope | Wo gespeichert |
|---|---|---|---|
| Marvin-Operations | marvin-operations | Read + Write | 1Password Hetzner / <project> / api-token-operations |
| CI/CD (wenn Sprint einen separaten Workflow hat) | ci-cd | Read + Write | 1Password Hetzner / <project> / api-token-ci |
| Terraform-State (wenn aktiviert — in 1. MVP-Iteration deferred) | terraform | Read + Write | 1Password + GitHub-Actions-Secrets |
Rotation: alle 6 Monate als Default. Bei Verdacht oder Mitarbeiter-Austritt sofort.
Best-Practice: ein Token pro Project + Zweck, nicht ein Master-Token für alles.
Cross-Project-Access
Hetzner unterstützt kein Cross-Project-IAM wie AWS-AssumeRole. Wenn Workloads über mehrere Projects laufen müssen (z.B. Marvin-Operations-Skripte gegen alle AV-Projects), brauchen sie eigene Tokens pro Project.
Workaround in Tooling: lazyants-MCP kann mehrere Tokens als ENV-Var-Suffix laden (HETZNER_API_TOKEN_AV_PROD, HETZNER_API_TOKEN_AV_ICKING etc.) — wenn relevant in eigener Iteration zu konfigurieren.
Related
- _index — Capability-Dashboard
- storage — Bucket-Inventar (Cross-Project)
- accounts — Vergleichs-Pattern AWS-Multi-Account
- aws-multi-account-strategie — Mandanten-Trennungs-Doktrin