Betrieb & Dokumentation › Hetzner-Migrations-Runbook
Hetzner-Migrations-Runbook
DokumentUnklarQuelle geändert seit PrüfungEin Deploy läuft in festen Schritten: neuen Branch pushen, auf dem Server per Fast-Forward mergen, Dateirechte korrigieren, ein Skript ausführen, das baut und startet. Vorher wird eine Rückfall-Markierung gesetzt, damit man im Fehlerfall sofort zurück kann. Reine Text-/Logikänderungen brauchen nur einen Neustart, sichtbare Frontend-Variablen (NEXT_PUBLIC_*) brauchen einen kompletten Neubau des Images.
Bild folgt
Ein Deploy läuft über ein festes Skript: den gewünschten Branch auf dem Server auschecken, Dateirechte für den Container-Nutzer korrigieren, das Web-Image neu bauen und starten, danach zwei automatische Prüfungen laufen lassen — einen Gesundheitscheck und einen Kontrast-Wächter gegen unsichtbaren Text. Vorher wird eine Rückfall-Markierung gesetzt, damit im Fehlerfall ein sofortiger Rücksprung möglich ist. Rein inhaltliche Änderungen brauchen nur einen Neustart, öffentlich sichtbare Frontend-Einstellungen dagegen einen kompletten Neubau des Images, weil sie fest in das gebaute Paket einfließen. In den Projektunterlagen stehen daneben mehrere ältere, sich widersprechende Beschreibungen des vorgeschalteten Webservers (Hetzner-Server + Docker) — welche davon den heutigen Server tatsächlich beschreibt, ist ungeklärt.
- Neue Frontend-Einstellung erscheint nicht live → prüfen, ob nur neu gestartet statt neu gebaut wurde; sichtbare Einstellungen brauchen einen echten Neubau des Images.
- Deploy bricht am Kontrast-Wächter ab → er meldet nur, verhindert den Deploy in der Praxis nicht automatisch; den gemeldeten Kontrast trotzdem prüfen, statt ihn zu übergehen.
- Nach einem Deploy fehlt der Stand auf GitHub → das eigentliche Deploy-Ziel ist ein anderer Server-Fernzugriff als GitHub; GitHub muss danach eigens nachgezogen werden.
Gebraucht von
Genutzt von
- MASTERPLAN.md Abgelöst
Enthält
- Zweites Claude-Gedächtnis auf dem Server Live
- Domain & DNS (kfz-bozo.at) Teilweise
- Hetzner-Server + Docker Live
- Backup & Wiederherstellung Unklar
- Betriebs-Überwachung Teilweise
Gehört zu
Geregelt durch
Nutzt
- Domain & DNS (kfz-bozo.at) Teilweise
- Betriebs-Überwachung Teilweise
- docs/hetzner-migration-runbook.md
- DEPLOY.md
- scripts/deploy-prod.sh
- CLAUDE.md
- docker-compose.yml
| wiederverwendbar | teils — Konventionen (kfz_net, kfz- Prefix) noch gültig, Ablaufschritte teils durch deploy-prod.sh ersetzt |
|---|---|
| dubletten | DEPLOY.md, docker-compose.yml-Kommentare |
| zielgruppe | Entwickler (Serverzugriff) |
| schritte | git push Branch -> git merge --ff-only auf Server -> chown -R 1001:65533 data -> bash scripts/deploy-prod.sh -> Healthcheck (curl 127.0.0.1:3100) -> Kontrast-Gate |
| rollback | Tag backup/pre-<thema>-<datum> vor jedem Deploy, danach mitpushen |
| konflikt | docker-compose.yml sagt explizit 'KEIN Caddy, KEIN cloudflared', Caddyfile im selben Repo beschreibt einen Cloudflare-Tunnel-Modus mit 'auto_https off' + reverse_proxy — beide Dateien beschreiben unterschiedliche, sich ausschliessende Netzwerk-Topologien; MASTERPLAN.md nennt genau diesen Widerspruch bereits 2026-05-23 als offen, seither nicht sichtbar aufgeloest |
| nach-server-deploy | origin/main MUSS mitgepusht werden (Hausregel 6), sonst haengt GitHub hinterher |
Beleg: docs/hetzner-migration-runbook.md wird von DEPLOY.md referenziert ('fuer Kontext'), aktueller Deploy-Weg laeuft ueber scripts/deploy-prod.sh + Hausregel 5
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: ops-deploy (Dokument · Betrieb & Dokumentation · unklar · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: Ein Deploy läuft in festen Schritten: neuen Branch pushen, auf dem Server per Fast-Forward mergen, Dateirechte korrigieren, ein Skript ausführen, das baut und startet. Vorher wird eine Rückfall-Markierung gesetzt, damit man im Fehlerfall sofort zurück kann. Reine Text-/Logikänderungen brauchen nur einen Neustart, sichtbare Frontend-Variablen (NEXT_PUBLIC_*) brauchen einen kompletten Neubau des Images.
Lies zuerst (Lesebereich, nicht der ganze Baum):
docs/hetzner-migration-runbook.md
DEPLOY.md
scripts/deploy-prod.sh
CLAUDE.md
docker-compose.yml
Hängt zusammen mit:
data-schema-pflege (lib/db/index.ts) · doc-masterplan (docs/MASTERPLAN.md) · doc-projekt-briefe (README.md) · doc-server-zweites-gedaechtnis (MEM:server-claude-zweites-gedaechtnis.md) · int-domains (MEM:wizard-arbeiten-buehne-2026-09-01.md) · int-hetzner (CLAUDE.md) · ops-backup (docs/RESTORE.md) · int-hetzner (CLAUDE.md)
Offene Fragen der Seite:
keine
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/betrieb-doku/ops-deploy.md).