homelab-infra/docs/STRATEGISCHE_BEWERTUNG_2026-05-23.md

Strategische Bewertung KalliLab CORE

Status (Stand 2026-05-30): Historischer Snapshot vom 2026-05-23, inhaltlich grossteils ueberholt.

Dieses Dokument bleibt im Repo als Audit-Anker und als "wo standen wir am 2026-05-23". Die konkreten Befunde, Top-5-Listen und Mehrwert-Fahrplaene sind durch den Audit-Zyklus 2026-05-25 zu einem grossen Teil abgearbeitet, bewusst nicht umgesetzt oder explizit geparkt.

• Nicht als TODO-Liste lesen. Aktuelle Arbeitsliste: docs/AUDIT_2026-05-25_TODO.md.
• Originaltext nicht aendern. Statt Inline-Annotationen steht der pro-Punkt-Status in einer Tabelle am Ende des Dokuments (Abschnitt "Status-Anhang 2026-05-30").
• Schulnote 2- gilt nicht mehr. Mit den Konsolidierungen seit 2026-05-25 sind die meisten Notenabzieher behoben; eine neue Note wuerde hier eher bei 1- bis 2 landen, ist aber kein Selbstzweck.

Stand: 2026-05-23 Bewertet von: externer Blick auf den Repo-Sollzustand

Diese Bewertung ist bewusst kein Sicherheits- oder Konfigurations-Audit, sondern eine ganzheitliche Einordnung: was das Setup heute leistet, wo es stark ist, wo es zu komplex ist, und wo der nächste echte Mehrwert liegt.

---

Vorbemerkung und Methode

Bewertet wurde der Repo-Stand auf master, nicht der Live-Zustand auf dem Host. Grundlage waren HOMELAB_ARCHITECTURE_MASTER_V2.md, docs/WORKFLOW.md, docs/SERVICE_CATALOG.md, docs/REPO_MAP.md, docs/DISASTER_RECOVERY.md, docs/RESTORE_MATRIX.md, docs/SECRETS_MAP.md, docs/AI_CONTEXT.md, docs/GITOPS_DRIFT_RUNBOOK.md, docs/HOME_ASSISTANT_INFLUXDB_ECOWITT.md, docs/ALERTING_MAP.md, ops/borg-ui/BACKUP_SCOPE.md, ops/policy-checks/last-report.md, ops/restore-tests/schedule.md, repräsentative Compose-Dateien (Paperless, Monitoring) sowie die Memory-Notiz zum Post-Restore-Sprint.

Ehrliche Einschätzung in einem Satz: Das ist kein Bastel-Homelab mehr. Das ist eine kleine private Plattform mit dokumentationsbasierter Disziplin, die ein paar Lasten mitschleppt, die man jetzt bewusst loswerden sollte, bevor noch mehr dazukommt.

---

1. Architektur und Grundidee

Der Aufbau ist nicht gewachsen, er ist gestaltet. Das sieht man sofort an drei Stellen:

Erstens trennt das Repo Verantwortlichkeiten konsequent über die Top-Level-Ordner core/, security/, infra/, apps/, ops/, host-services/, monitoring/, traefik/ und services/. Das ist keine willkürliche Kosmetik, das spiegelt die Tier-Hierarchie aus DR und Restore wider. Ein neuer Dienst weiß durch das Einordnungsschema in HOMELAB_ARCHITECTURE_MASTER_V2.md Abschnitt 6 sofort, wo er hin gehört und in welche Netze er kommt. Das ist überdurchschnittlich.

Zweitens ist das Netzmodell schlicht und gleichzeitig diszipliniert: frontend_net für alles mit Web-UI oder Internetbedarf, backend_net internal: true für DB/Redis, und app-interne Netze (mealie_internal, immich_default, nextcloud_internal, monitoring_net) für Stack-Isolation. Es gibt keine Kunstnetze wie admin_net oder media_net aus reiner Symmetriesucht. Das ist genau die Linie, die viele Homelabs verfehlen, weil sie entweder alles in ein Bridge-Netz werfen oder fünfzehn semantische Netze erfinden, ohne dass sie was tun.

Drittens ist die Source-of-Truth-Hierarchie explizit (Gitea Online → lokaler Clone → Komodo → Docker → Host) und es gibt ein Drift-Runbook (docs/GITOPS_DRIFT_RUNBOOK.md) mit echter Messreihenfolge. Das schlägt 95% der "Selfhoster mit Portainer und Glück".

Wo es trotzdem hakt: Die Trennung Monitoring/Spielerei ist noch nicht sauber. Es gibt ops/grafana-influxdb (Altstand), ops/loki (Altstand) und monitoring/ (Zielstack) gleichzeitig im Repo. Solange die Migration nicht abgeschlossen und die Altstände nicht entfernt sind, ist das echte Doppelpflege-Risiko — und genau so entstehen die Bugs, die man nachher zwei Wochen sucht. Die Doku sagt klar "nicht parallel betreiben", aber das Repo macht es trotzdem möglich. Das ist eine offene Baustelle, kein Architekturproblem.

Note für diesen Block: 1-2.

---

2. Nutzen und Mehrwert

Hier wird es ehrlicher: Das Setup hat sehr viel Substanz, aber auch klare Spielereien.

Echter Alltagsnutzen, der den Aufwand rechtfertigt:

• Vaultwarden als Passwort-Tresor — der Klassiker, der wirklich täglich genutzt wird.
• Paperless-ngx mit Scan-Inbox, Barcode/ASN-Workflow und Tika aus — das ist klassische Familien-Dokumentenverwaltung mit echtem Wert, sobald man Briefe digitalisiert. Die Barcode-Konfiguration (PAPERLESS_CONSUMER_BARCODE_DPI=600, PAPERLESS_CONSUMER_ENABLE_ASN_BARCODE=1) zeigt, dass der Workflow durchdacht ist.
• Immich für Fotos, mit family_archive-Mount — das ersetzt sinnvoll Google Photos für eine Familie.
• Nextcloud für Dateifreigabe und WebDAV/CardDAV — wenn das wirklich genutzt wird, ist es ein echtes Google-Drive/iCloud-Replacement.
• Mealie für Rezepte — nett, aber das ist ein Lebensmittel-Ding, nicht Infrastruktur.
• Mail-Archiver — sehr persönlicher Mehrwert, wenn IMAP-Archive aus GMX/Gmail langfristig durchsuchbar bleiben sollen.
• ntfy als Push-Backbone für homelab-alerts und homelab-info — operativ unverzichtbar.
• Gitea — primär als GitOps-Quelle. Für andere Projekte ein Bonus.
• AdGuard Home + Unbound — ja, das hat Alltagsnutzen für alle Geräte im LAN.
• Tailscale — Remote-Zugang ohne Port-Freigabe nach außen, klar wertvoll.

Spielerei oder Overengineering, das ehrlich auf den Prüfstand gehört:

• Plex zusätzlich zu Jellyfin: Beide sind Medienserver mit derselben Bibliothek (/mnt/user/media, /mnt/user/photos). Plex bringt zwar Remote-Streaming und bessere Clients, Jellyfin bringt native Open-Source-Auth und keine Lizenz. Einen davon kann man weglassen — die ehrlichste Antwort ist, das nach 30 Tagen Nutzungs-Tracking zu entscheiden.
• Glance + Homepage + Komodo-UI als drei parallele Dashboards: Homepage als Startseite, Glance als zweites Dashboard mit Widgets, Komodo als Stack-Sicht. Hier ist mindestens eines redundant. Glance ist erst seit kurzem live und wirkt eher wie "weil cool" als "weil nötig".
• paperless-gpt: Coole Idee (LLM für Tagging), aber wenn das nicht aktiv genutzt wird, ist es nur ein Container, der idle Ressourcen frisst. Frage an dich: Wann hast du das letzte Mal eine GPT-Vorschlags-Tag-Liste angenommen?
• BentoPDF: Ist als "vorbereitet" markiert, Fachabnahme offen. Wenn du in zwei Monaten noch keine PDFs verarbeitet hast: weglassen.
• Hermes-Agent: Das ist die eindeutigste Spielerei. Ein LLM-Agent über SSH-Runner zu einer separaten VM, mit eigenem Dashboard, dessen NAS-Seite bewusst deaktiviert ist, weil die VM-Seite "offen" ist. Komplexes Modell C, abhängig von einer dedizierten Linux-VM, mit Provider-Keys und Dashboard-Domain. Das ist klassisches Nerd-Lieblingsprojekt-ohne-klaren-Alltagsnutzen-Symptom. Solange du nicht ehrlich beschreiben kannst, was Hermes für dich täglich tut, ist es Reifegrad "Experiment".
• Speedtest-Tracker: Nett für Monitoring der ISP-Qualität, aber ein einziger Speedtest-Container für eine private Leitung ist eher "ich messe gerne" als "ich brauche das wirklich".
• code-server: Web-IDE im Browser. Sinnvoll, wenn du wirklich vom iPad aus arbeitest. Sonst: VSCode lokal reicht.

Use Cases, die echten Mehrwert hätten und fehlen:

• Finanzen: Im DR-Doc steht /mnt/user/finance als Share, aber kein App-Stack. Firefly III oder Actual Budget würden hier sofort spürbaren Alltagsnutzen liefern — Konten konsolidieren, Budgets verfolgen, Steuer-Vorbereitung.
• Familien-SSO: Du hast Authelia, aber Authelia ist primär für Admin-UIs konfiguriert. Wenn deine Familie Nextcloud, Immich, Mealie und Vaultwarden mit einem Login nutzen könnte (Authelia OIDC-Provider), wäre das ein echter Mehrwert für andere als dich.
• Smartphone-Foto-Auto-Backup: Immich kann das nativ. Wenn das nicht eingerichtet ist und alle Familien-Smartphones automatisch in immich landen würden, wäre das die Killer-App für deine Frau und Kinder, nicht für dich.
• Tagliche Familien-Übersicht auf einem Wandtablet: Homepage oder Glance auf einem alten Tablet im Flur, mit Kalender (Nextcloud), Wetter (Ecowitt), und ntfy-Notifications.
• Kalender/Aufgaben/CardDAV-Nutzung: Nextcloud kann das, aber ich sehe in der Doku keinen Hinweis, dass die Familie das tatsächlich nutzt. Wenn nicht: Migration weg von Google Calendar/iCloud wäre ein echter Souveränitäts-Gewinn.

Note für diesen Block: 2-3. Die infrastrukturelle Substanz ist top, aber der Anteil "Container läuft, weil ich ihn ausprobieren wollte" ist höher als nötig.

---

3. Best Practices

Was richtig gut ist gemessen an dem, was professionelle Setups machen würden:

• Image-Pinning mit Tag und Digest für Stateful Services (Postgres 17.9, Redis 7.4-alpine, Mongo 7.0.32, alle mit @sha256:...). Das machen die wenigsten Homelabs. Echt vorbildlich.
• Secrets via Docker _FILE-Mounts oder Komodo Stack ENV, niemals im Git — und das ist konsequent durchgezogen, inklusive .gitignore für .env-Dateien und expliziter Doku in docs/SECRETS_MAP.md.
• no-new-privileges:true als Standard, mit dokumentierten Ausnahmen für Scrutiny (SMART) und Glances (Host-Observability) statt versteckter Lockerungen.
• Policy-as-Code light über ops/policy-checks/check_repo.ps1 — der letzte Report zeigt 0 Critical und 4 dokumentierte Warnings. Das ist Tooling-Disziplin, die viele Firmen nicht haben.
• Restore-Tests mit Schedule (ops/restore-tests/schedule.md): wöchentliche Freshness-Checks, monatliche Mini-Restores für Vaultwarden und Gitea, alle zwei Monate Paperless. Erfolg ist explizit als "Smoke-Test passt", nicht "Container startet" definiert. Das ist seltene Reife.
• Pre-Backup-Dumps statt rohe Live-DB-Verzeichnisse als primärer Restore-Pfad — das ist die Lehre, die viele erst nach dem ersten kaputten Restore lernen.
• Posture-Check + Docker-Critical-Events → ntfy als Live-Alarmierung, bereits mit Wiederholungsschutz (ALERT_REPEAT_SECONDS=86400) und Dedup. Das ist Operations-Reife.
• Cloudflare DNS Challenge für ACME statt HTTP-01, ermöglicht Wildcard-Zertifikate und keine Port-80-Abhängigkeit für Erneuerung.
• GitOps mit Webhook-Pflicht für neue Stacks (docs/WORKFLOW.md, Abschnitt "Pflicht bei neuen Komodo-Stacks"). Das verhindert "deployed-once-then-forgotten"-Stacks.

Was Standard wäre und du sinnvoll davon abweichst:

• Komodo bewusst ohne pauschale ForwardAuth-Middleware — richtig, weil Webhooks, API und Periphery sonst brechen. Die meisten würden hier blind Authelia davor schalten und dann zwei Tage debuggen.
• Authelia ohne Redis-Session-Backend — bewusste Vereinfachung. Du bezahlst dafür mit Re-Login nach Authelia-Restart, gewinnst dafür weniger Tier-1-Abhängigkeiten. Vertretbarer Trade-off.
• Traefik dynamic config als manuelle Host-Sync-Ausnahme — pragmatisch dokumentiert, statt eines komplexen Auto-Sync-Workarounds.

Wo du gefährlich von Best Practice abweichst:

• Externer Repo-Mirror als DR-Voraussetzung ist offenes TODO (docs/DISASTER_RECOVERY.md, Abschnitt 11). Wenn Gitea ausfällt — und Gitea hängt auch noch an Traefik und PostgreSQL — kannst du Komodo nicht aus Git deployen, kannst die Repo-Doku nicht lesen, und je nach Schaden hast du den lokalen Clone als einzigen Pfad. Das ist ein echter Single Point of Failure. Ein Push-Mirror nach GitHub/GitLab (privat) oder zumindest ein versionierter Sync nach BorgBase würde das in 30 Minuten lösen.
• Unraid USB-Flash-Backup ist offenes TODO. Wenn der USB-Stick stirbt, ist das nicht das Ende der Welt (Daten leben), aber es kostet einen vollen Wiederaufsetzungs-Tag. Unraid hat dafür einen eingebauten Backup-Mechanismus.
• Komodo Self-Stack Drift Mai 2026: Du hattest schon einen Vorfall, wo Komodo selbst nicht mehr sauber managebar war ("Recovery-ENV als Tier-1-Secret-Material"). Das Bootstrap-Problem — Komodo verwaltet Komodo — ist nicht gelöst, nur dokumentiert. Eine echte Lösung wäre: Komodo-Self-Stack explizit aus Komodo herauslassen und nur als docker compose-Script in services/ halten.
• Kein Fail2Ban / CrowdSec vor Traefik. Vaultwarden und Nextcloud sind im Internet erreichbar mit eigener Auth. Die meisten Anti-Brute-Force-Maßnahmen liegen in den Apps selbst, nicht auf Layer 7. Bei einer ernsten Bot-Welle würde Authelia die Last tragen, ohne IP-Bans auszusprechen. CrowdSec als Bouncer für Traefik wäre eine sinnvolle Härtung mit überschaubarem Aufwand.

Note für diesen Block: 2.

---

4. Nerd-Level / Advanced Homelab

Was sehr erfahrene Selfhoster mit so einem Repo zusätzlich machen würden:

• Renovate Bot oder ein vergleichbares Image-Update-Tracking: Du pinnst Digests, was richtig ist, aber damit hast du dich auch in die manuelle Update-Pflicht begeben. Renovate gegen Gitea würde wöchentliche PRs für neue Patch-Versionen auf master öffnen, die du mergen oder ignorieren kannst. Das ist deutlich besser als "irgendwann manuell den Digest aktualisieren".
• Staging-Path: Aktuell hast du master und das ist gleichzeitig produktiv. Ein zweiter Branch (staging) der gegen einen zweiten Komodo-Server (in einer Tailscale-VM oder einem zweiten Unraid-Share) deployed, würde Risiko-Aenderungen testbar machen. Das ist viel Aufwand für ein Homelab, aber wenn dich die Stabilität ernsthaft kümmert, ist es der nächste Reifegrad.
• OIDC-Provider statt nur ForwardAuth: Authelia kann OIDC. Wenn Nextcloud, Immich, Grafana, Komodo (theoretisch), Vaultwarden (via OIDC-Bridge) per SSO laufen, ist das die "echte" Konsolidierung. Heute hast du ForwardAuth für Admin-Dienste, aber Apps mit eigener Auth (Nextcloud, Immich, Jellyfin) sind Eigeninseln.
• Restore-Tests automatisiert in CI: Du hast Skripts und Cron-Slots, aber kein CI gegen das Repo, das die Restore-Test-Skripte syntaktisch und semantisch prüft. Ein Gitea Actions oder Drone-Setup auf dem Host könnte das gegen jeden Commit laufen lassen.
• Backup-Test-Härtung: Restore in eine echte Test-Domain mit Traefik-Route hinter Authelia (heute bewusst ohne Domain — siehe docs/RESTORE_MATRIX.md). Das ist eine bewusste Entscheidung, würde aber einen "End-to-End restore drill" möglich machen, der einmal pro Quartal komplett durchläuft.
• Disk1 NTFS → XFS Phase 2: Im Repo dokumentiert, im posture-check temporär toleriert mit ALLOW_DISK1_NTFS=1. Das ist die offensichtlichste offene Hardening-Baustelle.
• Loki-Retention und Log-Volume mal anschauen: 30 Tage Retention ist gut, aber im aktuellen Stand wirst du irgendwann Storage-Probleme bekommen, wenn du nicht weißt, wie viel der Stack pro Tag produziert.

Was sie bewusst weglassen würden:

• Hermes-Agent: Genau dieses "ich baue mir einen Agenten der über SSH meine VM bedient und ein Dashboard hat" ist das, wovor erfahrene Leute nach dem dritten Homelab warnen. Es bringt Komplexität, Wartungslast und keine messbare Reduktion deiner manuellen Arbeit. Wenn Hermes nicht in den nächsten 60 Tagen produktiv und unverzichtbar wird: entfernen.
• Drei Dashboard-Tools: Sie würden eines wählen (vermutlich Homepage), die anderen rauswerfen.
• Zwei Medienserver: Plex und Jellyfin parallel ist Tool-Sammlerei.
• Eigenes paperless-gpt-Container wenn nicht aktiv im Workflow: lieber das LLM ein-zwei mal manuell auf eine PDF werfen als einen Container 24/7 idle laufen lassen.

Note für diesen Block: 2-3. Sehr nahe am nächsten Reifegrad, aber an drei, vier Stellen würde erfahrene Hand jetzt entrümpeln statt erweitern.

---

5. Betrieb und Wartbarkeit

Hier ist die Bewertung am eindeutigsten positiv. Dieses Setup ist langfristig wartbar.

Die Dokumentation ist auf einem Niveau, das ich selten sehe. docs/SERVICE_CATALOG.md ist ein vollständiger Dienst-Katalog mit Restore-Quelle, Smoke-Test und Besonderheiten pro Dienst. docs/REPO_MAP.md ist eine technische Landkarte. docs/RESTORE_MATRIX.md ist nicht nur "wo ist das Backup", sondern "was ist die führende Quelle", "welche Dumps", "welche Secrets müssen vor Start da sein", "was ist der Smoke-Test". Das ist Doku, die in sechs Monaten noch funktioniert.

Der Workflow ist klar (docs/WORKFLOW.md): Fetch → Pull → ändern → Commit → Push → Komodo. Es gibt eine explizite Stop-Regel ("wenn zwei Reparaturversuche nicht funktionieren, Pflichtmatrix ausfüllen"), die viele Selfhoster nicht haben und stattdessen in Mut-Spiralen rutschen.

Drei Stellen, wo Wartbarkeit gefährdet ist:

• Hermes-Agent: Spätestens nach sechs Monaten ohne aktive Pflege verstehst du die Model-C-Architektur nicht mehr ohne ops/hermes-agent/README.md zu lesen — und dann ist die Frage, warum überhaupt.
• Doppelter Monitoring-Stack (ops/grafana-influxdb, ops/loki, monitoring/): Solange beide Welten im Repo sind, vergisst du in einem halben Jahr, welche live ist. Die Migration muss abgeschlossen und die Altstände müssen entfernt werden.
• Authelia Repo-Baseline vs. Host-Config: Du dokumentierst selbst, dass die Repo-configuration.yml "manuell auf den Host gemerged" werden muss, mit OIDC und Secrets hostseitig. Das ist Drift-Risiko per Design. Ein zweiter Mechanismus (z. B. das manuelle Pendant zum Traefik-dynamic-Sync) oder mindestens ein expliziter Diff-Check vor jeder Auth-Änderung wäre Pflicht.

Note für diesen Block: 1-2.

---

6. Sicherheit und Zugriff

Du hast eine durchdachte Schichtung:

• Authelia für Admin-UIs (uptime, borg, files, code, grafana, monitoring, pdf, glance, glances, scrutiny, paperless-gpt, speedtest, hermes, traefik-Dashboard, homepage).
• Native App-Auth für User-Apps (vaultwarden, nextcloud, immich, jellyfin, paperless).
• Komodo mit eigener Auth ohne ForwardAuth (bewusste Ausnahme).
• Tailscale für Admin-Zugriff von außen.

Was wirklich gut ist:

• Authelia mit Argon2id, iterations=3, memory=65536, parallelism=4, key_length=32, salt_length=16 — das ist solide Konfiguration, nicht Default-Müll.
• Secrets durchgängig per File-Mount oder Komodo Stack ENV, nie im Compose im Klartext.
• Gitea Webhook-Allowlist (GITEA__webhook__ALLOWED_HOST_LIST=komodo-core,localhost,127.0.0.1,192.168.178.0/24) und Registrierung deaktiviert — das schließt Webhook-SSRF-Vektoren.
• cloudflare_dns_api_token als Docker Secret, nicht als ENV.

Wo du härter trennen solltest:

• AdGuard Admin-Port 8082 ist direkt am LAN gebunden ohne Authelia. Das ist im Architekturdokument als offenes TODO ("Block F") markiert. Im Home-LAN ist das verschmerzbar, aber wenn du eines Tages einen Gast im WLAN hast oder ein IoT-Gerät kompromittiert wird, ist das ein direkter Pfad in die DNS-Konfiguration.
• Nextcloud läuft ohne ForwardAuth (bewusst wegen WebDAV/CardDAV). Wenn deine Familie schwache Passwörter setzt, ist Nextcloud im Internet das primäre Angriffsziel. Nextcloud-eigene Maßnahmen (Brute-Force-Protection, 2FA-Pflicht für Admin) sollten dokumentiert aktiv sein.
• 2FA-Pflicht in Authelia: In der Doku nicht klar erwähnt. Wenn 2FA nur "optional" ist, läuft die Härtung ins Leere.

Wo Komfort wichtiger ist und das sinnvoll so bleibt:

• Komodo ohne ForwardAuth — richtig.
• Authelia ohne Redis-Session-Backend — vertretbar.
• Plex/Jellyfin mit nativer Auth — sinnvoll, weil die Clients eigene Auth machen.

Note für diesen Block: 2.

---

7. Backup und Disaster Recovery

Das ist eine der stärksten Säulen.

Was du richtig machst:

• Borg statt Backrest — dokumentierte Entscheidung, eine Backup-Technologie statt zwei.
• Pre-Backup-Dumps als kanonische Restore-Quelle, nicht rohe Live-DB-Verzeichnisse. Explizit dokumentiert in ops/borg-ui/BACKUP_SCOPE.md ("Do not back up raw live database storage directories as the primary recovery artifact").
• Restore-Tests mit Schedule und expliziter Erfolgsregel ("Container läuft reicht nicht — Smoke-Test muss greifen").
• Dump-Skript für SQLite-Container (Gitea, Vaultwarden, Uptime-Kuma, Speedtest-Tracker), BoltDB-Snapshot für Filebrowser, pg_dump für die einzelnen Postgres-Datenbanken, mongodump für Komodo-Mongo.
• Borg-Scope erweitert um /mnt/user/services für GitOps-Recovery (Repo, Stack-Workspaces, Posture-Check-State).
• Tier-Modell in docs/RESTORE_MATRIX.md mit klarer Reihenfolge.
• Dokumentierte Restore-Lab-Praxis: Testpfad /mnt/user/backups/restore-lab/<dienst>, Reports unter /mnt/user/backups/restore-reports, ohne Traefik-Route — keine Vermischung von Test und Produktion.

Was wirklich offen ist:

• Externer Backup-Mirror oder Off-Site-Ziel: BorgBase ist erwähnt (ops/borg-ui als Borg-UI auf BorgBase-Repo), aber die Frage "was passiert, wenn der Unraid-Host und BorgBase gleichzeitig down sind" hat keine dokumentierte Antwort. Zwei Repos (z. B. BorgBase + ein zweites lokales NAS oder ein Hetzner Storage Box) wären die Standardlösung.
• Externer Repo-Mirror als DR-Voraussetzung — in DR.md als TODO markiert. Wenn Gitea nicht aufsteht, ist das Repo nur über deinen lokalen Clone erreichbar.
• Unraid USB-Flash-Backup — in DR.md als TODO markiert.
• Borg-Passphrase extern sicher hinterlegt — als TODO markiert. Das ist die typische "wenn das Haus brennt"-Frage. Vaultwarden hilft dir nicht, wenn Vaultwarden gerade restauriert werden soll. Eine zweite Kopie der Passphrase (verschlüsselt auf einem USB-Stick im Bankschließfach, oder bei einem Familienmitglied) ist Standard.
• Komodo-Mongo Dump nach Major-Upgrades verifizieren — als Watchpoint dokumentiert, aber nicht im automatischen Restore-Test-Cron.

Restore-Tests sind monatlich für Vaultwarden und Gitea, alle zwei Monate für Paperless, "später" für Immich. Das ist gut, aber Immich-Restore-Tests sind die kritischsten, weil dort die größten Datenmengen liegen und ein silent corruption am schmerzhaftesten wäre.

Note für diesen Block: 1-2. Wenn die offenen DR-Vorbereitungs-TODOs abgehakt wären, klare 1.

---

8. Monitoring und Transparenz

Das ist der Bereich mit dem größten Übergang. Du hast viele Tools, mit Überschneidungen, und der zentrale Monitoring-Stack ist im Aufbau.

Was du heute hast:

• Uptime-Kuma: HTTP/TCP-Uptime-Checks mit Web-UI.
• Glances: Live-System-Sicht (CPU/RAM/Disk pro Host).
• Scrutiny: SMART-Monitoring für Laufwerke.
• Speedtest-Tracker: Periodische Speedtests gegen den ISP.
• Glance: Status-Dashboard mit Widgets (Immich, AdGuard, Speedtest, Docker-Container).
• Homepage: Start-Dashboard mit Service-Cards.
• Posture-Check: Host-Filesystem, NVMe-SMART, Mover, Füllstand → ntfy.
• Docker-Critical-Events: die/oom/kill → ntfy.
• monitoring/-Zielstack: Prometheus, Alertmanager, ntfy-Bridge, Blackbox, Loki, Promtail, Grafana, node-exporter, cAdvisor, InfluxDB 3 Core.

Was richtig gut ist:

• Ein zentraler Alert-Pfad: alle problemrelevanten Meldungen landen auf homelab-alerts per ntfy. Das ist die wichtigste Disziplin und du hast sie. docs/ALERTING_MAP.md listet alle Sender.
• Prometheus-Stack mit Alertmanager + Bridge zu ntfy, also nicht "Grafana sendet Email" sondern "Alertmanager-Pflicht-Pfad".
• Blackbox-Exporter ersetzt mittelfristig Uptime-Kuma (richtige Strategie).
• 30 Tage Retention für Prometheus und Loki — sinnvoll für Diagnose-Daten, kein Backup-Surrogat.
• node-exporter + cAdvisor + Traefik-Metrics → wirklich vollständige Infrastruktur-Telemetrie.

Was fehlt oder zu viel ist:

• Doppelte Beobachtungs-Tools nebeneinander: Uptime-Kuma vs. Blackbox, Glances vs. node-exporter+cAdvisor, Glance vs. Homepage. Du weißt das, die Migration ist im Gang. Bis sie fertig ist, gibt es Verwirrung darüber, welches die "Wahrheit" ist.
• Smoke-Test-Dashboards: In monitoring/grafana/dashboards/ sind ein paar Dashboards, aber die "Family-View" — "alles grün, alles erreichbar, Backup heute Nacht durchgelaufen" — fehlt als explizites Dashboard. Das wäre der Wert für dich selbst: morgens kurz draufschauen und wissen, ob etwas die Aufmerksamkeit braucht.
• Alert-Regeln explizit listen: monitoring/prometheus/alerts.yml existiert, aber eine kurze Doku, welche Regeln wann feuern (Disk > 90%, Borg älter 36h, Cert läuft in 14 Tagen ab, etc.), würde die Operations-Reife komplettieren.
• Cert-Token-Check läuft (laut ALERTING_MAP) — gut, das ist die einzige sinnvolle Methode, "TLS-Cert läuft ab" früh genug zu sehen.

Note für diesen Block: 3. Bricht ab, sobald die Monitoring-Migration sauber abgeschlossen ist und die Altstände entfernt sind — dann eine 2.

---

9. Konkreter Mehrwert-Fahrplan

Quick Wins (≤ eine Woche, hoher Nutzen)

• Externer Push-Mirror für das Repo nach GitHub privat einrichten. Das ist ein Webhook in Gitea + ein leerer GitHub-Privat-Repo. 30 Minuten. Löst das wichtigste DR-Risiko.
• Borg-Passphrase auf einen USB-Stick im Bankschließfach oder in eine versiegelte Umschlag-Box. Eine analoge Sicherung gegen das digitale Worst-Case-Szenario.
• Plex oder Jellyfin entscheiden: einen davon weg. 14 Tage Nutzungs-Tracking via Server-Logs oder einfach beobachten, wer welchen Client öffnet. Dann den ungenutzten Stack archivieren.
• Glance ODER Homepage als einziges Dashboard wählen. Heute laufen beide. Es gibt keinen technischen Grund für zwei.
• Authelia 2FA-Pflicht für alle aktiven User verifizieren — wenn nicht gesetzt, jetzt setzen.
• Disk1 NTFS → XFS Phase 2 abschließen — das ist im Repo dokumentiert und im posture-check als Übergangsausnahme markiert. Loswerden.

Phase 1 (zwei bis vier Wochen, Stabilität und Ordnung)

• Monitoring-Migration abschließen und Altstände entfernen: monitoring/ produktiv, dann ops/grafana-influxdb und ops/loki aus dem Repo löschen (mit Backup-Branch fürs Gewissen).
• Uptime-Kuma ablösen durch Blackbox + Grafana-Alerts: nach den sieben Tagen Parallelbetrieb, die in docs/SERVICE_CATALOG.md als Pflicht stehen.
• Hermes-Agent ehrliche Entscheidung: produktiv machen mit klarem Alltagsnutzen, oder entfernen. Kein "halb da, halb deaktiviert"-Zustand für ein weiteres Quartal.
• paperless-gpt und BentoPDF Status: gleiche Frage. Produktiv oder weg.
• Unraid USB-Flash-Backup einrichten (Unraid hat einen eingebauten Mechanismus).
• Ein Family-View-Dashboard in Grafana bauen: alles-grün-Übersicht für den Morgen-Check.

Phase 2 (vier bis zwölf Wochen, Automatisierung und Transparenz)

• Authelia OIDC-Provider aktivieren und Nextcloud, Immich, Grafana als OIDC-Clients konfigurieren. Echtes SSO für die Familie.
• Renovate Bot gegen Gitea für kontrollierte Image-Updates (PRs statt manuelle Digest-Pflege).
• Restore-Test für Immich als eigener Sprint einplanen — der größte Datentopf und der einzige Tier-2-Dienst ohne Mini-Restore-Test.
• Familie onboarden: Smartphone-Auto-Backup zu Immich für alle Familien-Geräte. Das ist der Schritt vom "ich betreibe Container" zum "meine Familie benutzt aktiv was Selbstgebautes".
• CrowdSec vor Traefik als Bouncer für die öffentlich erreichbaren Apps (Vaultwarden, Nextcloud, Immich, Gitea).

Phase 3 (drei bis sechs Monate, Advanced Nerd-Level)

• Staging-Branch + zweites Komodo-Ziel in einer Tailscale-VM, für Risiko-Änderungen.
• Restore-Test-Automatisierung als CI (Gitea Actions oder Drone).
• Off-Site-Backup zu einem zweiten Ziel (zweites BorgBase-Repo, Hetzner Storage Box, oder zweites NAS bei einem Familienmitglied).
• Cold-Standby-Konzept dokumentieren: was passiert, wenn der Unraid-Host stirbt und du erst in zwei Wochen Ersatz hast?
• Komodo-Self-Stack rausnehmen und als handgepflegten docker compose-Service in services/ halten — löst das Bootstrap-Problem.

Phase 4 (Spielwiese, nice-to-have)

• Firefly III oder Actual Budget für Finanz-Übersicht.
• Wandtablet-Setup im Flur mit Family-Dashboard.
• Smart-Home-Automatisierungen über Home Assistant tiefer mit ntfy verzahnen (Frost-Warnung, PV-Überschuss-Hinweis, Briefkasten-Sensor).
• Ein eigenes kleines Dashboard für Ecowitt-Wetterdaten (sobald die Pipeline aus docs/HOME_ASSISTANT_INFLUXDB_ECOWITT.md läuft).

---

Schulnote, Top-5-Listen, klare Empfehlung

Schulnote

2- (gut bis befriedigend, eher 2).

Auf der Skala "durchschnittliches Homelab" wäre das eine 1. Die strukturelle Disziplin, GitOps-Konsequenz, Doku-Qualität, Backup-Reife und Architektur-Klarheit liegen weit über dem, was die meisten Selfhoster jemals erreichen. Was die Note von einer 1 runterzieht: drei bis fünf offene Baustellen, die nicht trivial sind (externer Repo-Mirror, Monitoring-Migration unfertig, Hermes-Agent im Schwebezustand, zwei Medienserver parallel, AdGuard Admin-Port ohne ForwardAuth). Wenn du Phase 1 abschließt, bist du klar bei einer 1.

Top 5 sofort verbessern

1. Externer Repo-Mirror (GitHub privat, BorgBase, oder zweites Gitea). 30 Minuten Aufwand, schließt das wichtigste DR-Loch.
2. Borg-Passphrase analog außerhalb des Systems sichern (Bankschließfach, Familienmitglied, Tresor).
3. Plex oder Jellyfin entscheiden, einen davon entfernen.
4. Glance oder Homepage als einziges Dashboard wählen.
5. AdGuard Admin-Port hinter Authelia oder mindestens nur via Tailscale erreichbar (heute LAN-direkt).

Top 5 mit dem größten zusätzlichen Mehrwert

1. Smartphone-Auto-Backup zu Immich für die ganze Familie: macht aus deinem Foto-Server eine echte Killer-App für andere als dich.
2. Authelia OIDC-Provider aktivieren und Nextcloud + Immich + Grafana per SSO: ein Login für alle wichtigen Apps.
3. Renovate Bot gegen Gitea: automatisierte Update-PRs für deine Digest-pinnten Images.
4. Family-View-Dashboard in Grafana: morgens 30 Sekunden draufschauen statt Tools-Tour.
5. Finanz-App (Firefly III oder Actual Budget): füllt den /mnt/user/finance-Share mit echtem Alltagsnutzen.

Top 5 lieber NICHT machen

1. Hermes-Agent ausbauen statt loswerden. Wenn du in 60 Tagen nicht ehrlich sagen kannst, was Hermes dir täglich abnimmt: weg damit. Komplexität ohne Gegenwert ist das größte Anti-Pattern in jedem Homelab.
2. Noch mehr Dashboards einbauen. Du hast bereits Homepage, Glance, Komodo-UI und kommst gleich noch mit Grafana-Family-View. Mehr wäre Sammlerei.
3. Pauschale Authelia-ForwardAuth vor Komodo schalten. Dokumentierte Ausnahme aus gutem Grund. Webhooks, API und Periphery würden brechen.
4. Backend_net auf external: true statt internal: true umstellen, weil "ist ja einfacher". Genau das ist die Mauer, die viele Apps vor öffentlichem Zugriff schützt.
5. Komodo Self-Stack komplett über Komodo managen lassen. Du hattest schon einen Drift-Vorfall. Komodo verwaltet Komodo ist ein Bootstrap-Problem ohne befriedigende Lösung.

Klare Empfehlung

Vereinfachen und konsolidieren, NICHT weiter ausbauen.

Du bist an einem Punkt, an dem das Setup mehr Substanz hat, als aktiv genutzt wird. Die nächsten sechs Monate sollten weniger neue Dienste sehen und mehr Entrümpelung (Plex vs. Jellyfin, Glance vs. Homepage, Hermes-Entscheidung, Monitoring-Altstände raus, paperless-gpt/BentoPDF-Entscheidung), mehr Familien-Aktivierung (Immich-Smartphone-Backup, OIDC-SSO, Family-Dashboard), und mehr DR-Resilienz (externer Mirror, Off-Site-Backup-Ziel, Borg-Passphrase analog gesichert).

Wenn du das in den nächsten drei Monaten machst, hast du eine private Plattform mit echtem Alltagsnutzen, klarer Wartbarkeit, und einer Wiederherstellbarkeit, die seriöser ist als das, was viele Mittelstandsfirmen für ihre Office-IT haben. Das ist das Ziel, nicht "noch ein Container".

Wenn du dann weiterausbauen willst, bist du in der Position, das aus einer Stärke heraus zu tun, nicht aus dem "ich muss noch das hier probieren"-Reflex.

---

Status-Anhang 2026-05-30

Dieser Anhang ist nicht Teil der Originalbewertung vom 2026-05-23. Er ordnet jedem konkret handelbaren Befund den tatsaechlichen Stand nach den Audit-Sprints zu, damit das Dokument selbststaendig lesbar bleibt.

Block 1 - Architektur

Originalbefund	Stand 2026-05-30
ops/grafana-influxdb + ops/loki + monitoring/ parallel im Repo	erledigt 2026-05-26: Altstaende entfernt, monitoring/ einziger aktiver Observability-Stack

Block 2 - Nutzen und Mehrwert

Originalbefund	Stand 2026-05-30
Plex zusaetzlich zu Jellyfin	erledigt 2026-05-25: Jellyfin entfernt, Plex bleibt einziger Medienserver
Glance + Homepage + Komodo-UI als drei parallele Dashboards	erledigt 2026-05-25: Homepage entfernt, Glance bleibt einziges Dashboard
paperless-gpt — produktiv oder weg?	entschieden 2026-05-28: behalten bis Paperless-NGX 3.0 native KI-Features, dann neu bewerten
BentoPDF — produktiv oder weg?	entschieden 2026-05-28: behalten als situatives Tool (~4 MB RAM-Footprint)
Hermes-Agent als Spielerei, Review-Deadline gesetzt	geparkt mit Review-Deadline 2026-07-25
Speedtest-Tracker als "ich messe gerne"	unveraendert, keine Operator-Entscheidung getroffen
code-server — sinnvoll oder weg?	unveraendert, keine Operator-Entscheidung getroffen
Finanz-App (Firefly III / Actual Budget) als fehlender Mehrwert	offen, nice-to-have ohne aktiven Termin
Familien-SSO ueber Authelia OIDC	geparkt im Auth-Block (F-13)
Smartphone-Auto-Backup zu Immich	offen, Anwendungsentscheidung pro Familienmitglied
Wandtablet im Flur mit Family-Dashboard	offen, Spielwiese
Kalender/Aufgaben/CardDAV-Nutzung dokumentieren	offen, Operator-Frage

Block 3 - Best Practices

Originalbefund	Stand 2026-05-30
Externer Repo-Mirror als DR-Voraussetzung offen	erledigt: GitHub-Push-Mirror michaelkaleschke-spec/homelab-infra aktiv
Unraid USB-Flash-Backup offen	erledigt 2026-05-25: unraid-flash-config.tar.gz im Borg-Scope
Komodo Self-Stack Drift Mai 2026 nur dokumentiert, nicht geloest	teilweise erledigt 2026-05-29/30: Trockenlauf-Skript + erfolgreicher Erstlauf belegen ops/komodo/docker-compose.yml als Recovery-Anker; Self-Stack-Entkopplung selbst bleibt offen
Kein Fail2Ban/CrowdSec vor Traefik	geparkt im Auth-Block (F-14)
Renovate Bot fehlt	erledigt 2026-05-29: live, erster Lauf erfolgreich, 5 PRs in Gitea

Block 4 - Nerd-Level

Originalbefund	Stand 2026-05-30
Renovate Bot oder vergleichbares Update-Tracking	erledigt 2026-05-29
Staging-Path mit zweitem Komodo-Ziel	offen, Phase 3 nice-to-have
OIDC-Provider statt nur ForwardAuth	geparkt im Auth-Block (F-13)
Restore-Tests automatisiert in CI (Gitea Actions / Drone)	offen, Phase 3
End-to-End restore drill mit Test-Domain hinter Traefik	offen, bewusst nicht (Test-Lab bleibt ohne Domain)
Disk1 NTFS -> XFS Phase 2	erledigt (ALLOW_DISK1_NTFS=0 als Default im posture-check, XFS-Erwartung aktiv)
Loki-Retention und Log-Volume bewerten	offen, Detail-Sweep
Hermes-Agent loswerden	geparkt mit Review 2026-07-25
Drei Dashboard-Tools auf eines reduzieren	erledigt: Glance bleibt als einziges
Zwei Medienserver	erledigt: Jellyfin entfernt

Block 5 - Betrieb und Wartbarkeit

Originalbefund	Stand 2026-05-30
Doppelter Monitoring-Stack als Wartbarkeits-Risiko	erledigt 2026-05-26
Authelia Repo-Baseline vs. Host-Config Drift "by design"	erledigt 2026-05-30 (F-10): services/authelia-diff.sh + Posture-Check ueberwacht ACL-Drift automatisch, WORKFLOW.md hat eigene Pflicht-Sektion
Hermes-Agent verstaendnis-kritisch nach 6 Monaten	geparkt mit Review 2026-07-25

Block 6 - Sicherheit und Zugriff

Originalbefund	Stand 2026-05-30
AdGuard Admin-Port 8082 LAN-direkt ohne Authelia	erledigt 2026-05-26: auf Tailscale-IP 100.80.98.33:8082 gebunden, LAN-Zugriff blockiert
Nextcloud ohne ForwardAuth, Brute-Force-Doku offen	geparkt im Auth-Block (F-18)
Authelia 2FA-Pflicht nicht klar dokumentiert	geparkt im Auth-Block (F-04)

Block 7 - Backup und Disaster Recovery

Originalbefund	Stand 2026-05-30
Externer Backup-Mirror / zweites Off-Site-Ziel	entschieden 2026-05-28: kein zweites Off-Site; 3-2-1 mit Live + lokalem Borg + Hetzner + H:/-Nearline erfuellt; Hetzner-Haertungen als Folge-TODOs
Externer Repo-Mirror	erledigt: GitHub-Push-Mirror aktiv
Unraid USB-Flash-Backup	erledigt 2026-05-25
Borg-Passphrase analog gesichert	erledigt 2026-05-26: Operator bestaetigt, offline gesichert
Komodo-Mongo Dump-Verifikation nach Major-Upgrades	offen, Watchpoint dokumentiert, nicht im automatischen Cron
Restore-Tests Immich (groesster Datentopf ohne Mini-Restore)	erledigt 2026-05-27: erster Host-Lauf erfolgreich (SUCCESS, 11977 Assets)

Block 8 - Monitoring und Transparenz

Originalbefund	Stand 2026-05-30
Doppelte Tools (Uptime-Kuma vs. Blackbox, Glance vs. Homepage)	erledigt 2026-05-25: Uptime-Kuma und Homepage entfernt
Family-View Dashboard fehlt als Morgens-Check	Spec da, JSON offen: docs/FAMILY_VIEW_DASHBOARD.md definiert Layout/Queries/Thresholds; JSON wird gebaut, sobald Metriken 7+ Tage stabil sind
Alert-Regeln explizit listen	teilweise: monitoring/prometheus/alerts.yml enthaelt Regeln (Borg-Stale, Cert-Expiry, Container-Down), docs/ALERTING_MAP.md mappt Sender — eine Doku-Zusammenfassung "welche Regel feuert wann" ist noch nicht zentralisiert

Block 9 - Konkreter Mehrwert-Fahrplan

Quick Wins (≤ 1 Woche)

Original-Punkt	Stand 2026-05-30
Externer Push-Mirror GitHub privat	erledigt
Borg-Passphrase analog sichern	erledigt 2026-05-26
Plex oder Jellyfin entscheiden	erledigt 2026-05-25: Jellyfin weg
Glance oder Homepage waehlen	erledigt 2026-05-25: Homepage weg
Authelia 2FA-Pflicht aktivieren	geparkt (F-04)
Disk1 NTFS -> XFS Phase 2	erledigt
AdGuard Admin Tailscale-only	erledigt 2026-05-26

Phase 1 (2-4 Wochen)

Original-Punkt	Stand 2026-05-30
Monitoring-Migration abschliessen, Altstaende entfernen	erledigt 2026-05-26
Uptime-Kuma abloesen durch Blackbox + Grafana	erledigt 2026-05-25
Hermes-Agent Entscheidung	geparkt mit Review 2026-07-25
paperless-gpt / BentoPDF Entscheidung	entschieden 2026-05-28: beide behalten mit Begruendung
Unraid USB-Flash-Backup	erledigt 2026-05-25
Family-View-Dashboard	Spec da, JSON wartet

Phase 2 (4-12 Wochen)

Original-Punkt	Stand 2026-05-30
Authelia OIDC fuer Nextcloud/Immich/Grafana	geparkt (F-13)
Renovate Bot gegen Gitea	erledigt 2026-05-29
Restore-Test fuer Immich	erledigt 2026-05-27
Familien-Smartphone-Auto-Backup zu Immich	offen, Operator-Anwendungsentscheidung
CrowdSec vor Traefik	geparkt (F-14)

Phase 3 (3-6 Monate)

Original-Punkt	Stand 2026-05-30
Staging-Branch + zweites Komodo-Ziel	offen
Restore-Test-Automatisierung als CI	offen
Off-Site-Backup zu zweitem Ziel	entschieden 2026-05-28: bewusst nicht
Cold-Standby-Konzept dokumentieren	offen
Komodo-Self-Stack rausnehmen	teilweise erledigt: Bootstrap-Anker und Trockenlauf-Skript da, Entkopplung selbst noch nicht

Phase 4 (Spielwiese)

Original-Punkt	Stand 2026-05-30
Firefly III / Actual Budget	offen
Wandtablet mit Family-Dashboard	offen
Home Assistant + ntfy enger verzahnen	offen
Ecowitt-Wetter-Dashboard	offen

Top-5-Listen vom 2026-05-23

Top 5 sofort verbessern

Original-Top-5	Stand 2026-05-30
1. Externer Repo-Mirror	erledigt
2. Borg-Passphrase analog sichern	erledigt
3. Plex oder Jellyfin entscheiden	erledigt
4. Glance oder Homepage waehlen	erledigt
5. AdGuard Admin-Port haerten	erledigt

Alle 5 erledigt.

Top 5 mit groesstem zusaetzlichen Mehrwert

Original-Top-5	Stand 2026-05-30
1. Smartphone-Auto-Backup zu Immich	offen, Anwendungsentscheidung
2. Authelia OIDC fuer SSO	geparkt
3. Renovate Bot gegen Gitea	erledigt
4. Family-View-Dashboard	Spec da, JSON wartet
5. Finanz-App	offen

Top 5 lieber NICHT machen

Original-Anti-Top-5	Stand 2026-05-30
1. Hermes-Agent ausbauen statt loswerden	gehalten — Agent geparkt mit Review, nicht ausgebaut
2. Noch mehr Dashboards einbauen	gehalten — Homepage entfernt, Glance bleibt einziges
3. Pauschale Authelia vor Komodo	gehalten — Komodo bleibt ohne ForwardAuth
4. backend_net auf external statt internal	gehalten — backend_net bleibt internal
5. Komodo Self-Stack komplett via Komodo	teilweise gehalten — Trockenlauf-Skript als Gegenmaszahme, vollstaendige Entkopplung offen

Zusammenfassung des Status-Anhangs

• Top 5 sofort: 5/5 erledigt.
• Quick Wins (7): 6 erledigt, 1 geparkt.
• Phase 1 (6): 4 erledigt, 1 geparkt, 1 wartend.
• Phase 2 (5): 2 erledigt, 2 geparkt, 1 offen.
• Phase 3 (5): 1 entschieden (nicht umgesetzt), 1 teilweise, 3 offen.
• Phase 4 (Spielwiese): alle offen, bewusst niedrige Prioritaet.
• Auth-Block (F-04/13/14/18): vollstaendig geparkt nach Operator-Entscheidung 2026-05-26, gebuendelte Bearbeitung ausserhalb des aktuellen Zyklus.

Wer hier weiterarbeiten will, schaut auf docs/AUDIT_2026-05-25_TODO.md — dort ist der operative Stand gepflegt.