Unsichtbare Betriebsarbeit: ManaMeme übersteht jetzt einen Server-Neustart zuverlässiger und kommt von selbst wieder hoch, statt im falschen Zustand hängen zu bleiben. Für dich ändert sich nichts — außer dass die App seltener kurz weg ist.
Tag 17 · Samstag, 6. Juni 2026
Samstag, 2026-06-06 — Tag 17
Spieler-Sicht
Macher-Sicht
Stats: 2 Commits, +20 / -4 LoC, 2 Files
Top-Dirs: infrastructure/docker-compose.production.yml (50%), deploy.sh (50%)
Tags: deploy
Session: 16:48 → 19:27 (~0 aktive Min, längster Fokus 0 Min)
Betriebs-Härtung am Deploy-Pfad.
- DB/MinIO
restart=always— verhindert Orphaning nach Docker-Daemon-Neustart — die Daten-Container starten nach einem Daemon-Neustart automatisch wieder; ohnerestart=alwaysbleiben sie unten und der App-Container findet keine DB/Storage mehr (verwaiste Abhängigkeit). deploy.sh: Build-Retry +up --wait, echte Fehler-Propagation (deploy) — Build-Retry fängt transiente Fehler ab,up --waitblockiert, bis die Container wirklich gesund sind, und echte Fehler-Propagation sorgt dafür, dass ein gescheiterter Deploy mit Exit-Code abbricht statt scheinbar durchzulaufen.
Stats
2
Commits
+20/-4
Zeilen
2
Files
0.0 h
Aktiv
- Erster Commit
- 16:48 (Samstag)
- Letzter Commit
- 19:27
- Spannweite
- 2.6 Stunden
- Aktiv (ohne Pausen > 30min)
- 0.0 Stunden
- Pausen
- 1
- Längster Fokus
- 0.0 Stunden
Wo wurde gearbeitet
- 50% infrastructure/docker-compose.production.yml
- 50% deploy.sh
Commits (2)
Volle Liste aufklappen
- 9584398 infra: DB/MinIO restart=always — verhindert Orphaning nach Docker-Daemon-Neustart
- abc006e chore(deploy): Build-Retry + up --wait, echte Fehler-Propagation