Skip to content

Infrastructure Roadmap

Prioritized backlog for philipp.info infrastructure. Stand: 2026-03-01. Archiv der erledigten Punkte: roadmap-archive-2026-02.md

Priority Matrix

# Item Criticality Effort Value Priority
1 phil-app Swap einrichten Medium Low High P1
2 Redis maxmemory setzen Medium Low High P1
3 Renovate für Image-Updates Low Low Medium P2
4 docker system prune automatisieren Low Low Medium P2
5 IPv6-Readiness: Docker + Shorewall Medium Medium High P2
6 Nextcloud & Paperless Verdrahtung Low Low Low P3
7 Nextcloud Object Storage (SSHFS ablösen) Medium High High P4

Completed

# Item Date
1 phil-app Swap: 8 GB at /var/swapfile, vm.swappiness=10 2026-03-01
2 Redis maxmemory: 256mb + allkeys-lru on friendica.me + opensocial 2026-03-01
3 Renovate: Docker image pinning (58 images) + Forgejo Actions runner deployed 2026-03-02
4 docker-prune systemd timer: weekly Sunday 03:00, prunes images/containers/networks >168h 2026-03-01

P2 — Open: IPv6-Readiness

Status: Offen. Aktueller Workaround in pre_update_hook.sh schreibt "ipv6": true in /etc/docker/daemon.json ohne Docker-Neustart — befriedigt mailcows update.sh-Check, aber Docker läuft weiterhin ohne echtes IPv6. Shorewall bleibt unberührt.

Warum hochgestuft: mailcow update.sh bricht ohne diesen Workaround ab (upstream-Bug: configure_ipv6() ignoriert ENABLE_IPV6=n wenn IPv6 am Host verfügbar ist). Die dauerhafte Lösung ist echtes IPv6 statt des Hacks.

Problem mit echtem IPv6: - Docker mit ipv6: true + Neustart fügt eigene ip6tables-Chains ein (DOCKER, DOCKER-ISOLATION-*) - Shorewall verwaltet ip6tables selbst — Konflikte → falsche FORWARD-Rules → alle Dienste geblockt

Ziel: - Docker-Daemon mit IPv6 (ipv6: true, ULA-Prefix oder Hetzner-Prefix) - Shorewall6-Konfiguration: DOCKER-Zone + ip6tables-Regeln - mailcow: ENABLE_IPV6=y, IPv6-Bindings für SMTP/IMAP/HTTPS - Workaround in pre_update_hook.sh entfernen - DNS: AAAA-Records für alle öffentlichen Dienste

Vorgehen: 1. Hetzner IPv6-Prefix für phil-app bestimmen (/64 → Subnetz ableiten) 2. Shorewall6-Konfiguration: DOCKER-Zone + ip6tables NAT/FORWARD 3. Docker daemon.json: ipv6: true + fixed-cidr-v6, mit Neustart 4. Erreichbarkeit aller Dienste verifizieren (Traefik, SSH, Mail-Ports) 5. mailcow ENABLE_IPV6=y, Workaround aus pre_update_hook.sh entfernen 6. AAAA-Records setzen

Aufwand: 1-2 Sessions. Risiko: kurze Downtime beim Shorewall+Docker-Neustart.


P3 — Nextcloud & Paperless Verdrahtung

Status: Integration funktioniert (Shared Volume, Bind-Mount, gemeinsames Keycloak OIDC).

Verbesserungsoptionen: - Nextcloud External Storage App: Paperless-Archiv als External Storage in Nextcloud UI sichtbar machen - Nextcloud Flow-Rules: PDFs automatisch in Paperless-Consume-Ordner kopieren

Aufwand: Gering. Niedrige Priorität — bestehende Integration ist funktional.


P4 — Nextcloud Object Storage (SSHFS ablösen)

Status: Offen. Nextcloud-Daten laufen über SSHFS-gemountetes StorageBox-Volume — fragil, FUSE-Overhead, kein nativer S3-Zugriff.

Ziel: Hetzner Object Storage als S3 Primary Storage für Nextcloud.

Risiken: - Migration aller bestehenden Dateien (Stunden bis Tage) - S3-Latenz höher als lokales FS (Preview-Generierung, Thumbnails) - Backup-Strategie muss angepasst werden (Borg kann nicht direkt auf S3)

Vorgehen: 1. Hetzner Object Storage Bucket anlegen 2. Nextcloud-Testinstanz auf S3 Primary Storage umstellen 3. Daten migrieren via occ files:scan + occ maintenance:repair 4. Performance validieren 5. Backup-Strategie anpassen (S3 Lifecycle Rules) 6. SSHFS-Mount eliminieren

Aufwand: 2-3 Sessions.