Homelab

Auch im Proxmox-Cluster habe ich gründlich aufgeräumt. Nach vielen Experimenten mit unterschiedlichsten Containern und VMs bin ich letztlich bei einer Handvoll Kernsysteme gelandet, die ich wirklich regelmäßig nutze und pflege:

• Nginx Proxy Manager (Reverse Proxy & SSL)
• AdGuard Home (Netzwerkweiter DNS-Filter)
• Forgejo & Forgejo Runner (Git-Hosting & CI/CD)
• Immich (Foto- und Videoverwaltung)
• Restic Backup (Automatisierte Backups)
• Nextcloud (Dateien & Synchronisation)
• Debian-LXC (Testumgebung für Webprojekte und Software)

Alle übrigen Instanzen habe ich konsequent abgeschaltet oder gelöscht. Das Ausprobieren war lehrreich, aber Dienste, die nach einer Woche ohnehin ungenutzt im Leerlauf drehen, brauche ich im Alltag schlichtweg nicht.

Forgejo Runner + Debian LXC + Webhook

Ich wollte es wissen und habe vor einer Weile einen Teil meiner Projekte von GitHub zu Codeberg umgezogen. GitHub gehört zu Microsoft, und der Reflex, proprietäre Plattformen zu meiden, ist nachvollziehbar. Doch auch bei Codeberg ist nicht alles Gold, was glänzt: Wiederkehrende Ausfälle und kleinere Hürden haben mich schließlich dazu bewogen, meine Repositories komplett selbst via Forgejo zu hosten.

Forgejo ist ein Community-Fork von Gitea und bietet alle gewohnten Features moderner Plattformen. Die Software ist extrem leichtgewichtig, schont die Systemressourcen und lief dank der Proxmox-Community-Templates innerhalb weniger Minuten.

Für automatisierte CI/CD-Pipelines läuft in einem separaten LXC-Container ein Forgejo Runner. Dieser führt Build-Jobs isoliert mittels Podman in Containern aus, wodurch Host-System und Abhängigkeiten sauber getrennt bleiben.

Ich teste diesen Workflow derzeit mit zwei Projekten: einer statischen Website mit Hugo sowie einer Python-Anwendung auf Basis von FastHTML. Jeder Push triggert den Runner, baut das Projekt im isolierten Container, durchläuft Tests und schiebt das fertige Artefakt direkt auf den Produktivserver.

Mein bisheriges Setup war dagegen spürbar fehleranfälliger: Ein einfacher Webhook informierte den Webserver, woraufhin ein lokales Skript das Repository pullte, Abhängigkeiten direkt auf dem Zielsystem installierte und alles via rsync verschob. Der größte Nachteil: Der gesamte Git-Tree sowie sämtliche Compiler und Build-Tools lagen direkt auf dem produktiven Webserver. Mit dem Forgejo Runner bleibt das Produktivsystem frei von Build-Altlasten – deployt wird ausschließlich das fertige Release.

Immich + Restic Backup

Immich und Nextcloud haben sich in den vergangenen Monaten als verlässliche Säulen erwiesen. Immich läuft bei mir in einem Debian-LXC und verwaltet Fotos sowie Videos.

Fotos schieße ich weiterhin mit dem Smartphone über Apple Fotos. Sobald ein Album jedoch abgeschlossen ist, wandert der Export direkt zu Immich. Einerseits möchte ich die Hoheit über meine eigenen Mediendaten behalten, andererseits überzeugt mich die Immich-Weboberfläche: Das Verwalten und Teilen von Alben fühlt sich um Längen flüssiger an als in iCloud Fotos.

Die Mediathek liegt auf einer separaten Partition, die als Read-Only in den Restic-Container eingebunden ist – ein versehentliches Löschen oder Überschreiben ist damit ausgeschlossen. Der Restic-Gegenpart läuft als Docker-Container auf dem NAS, wo die Backups verschlüsselt landen.

Dank einer direkten 2,5-GBit-LAN-Verbindung zwischen Mini-PC und NAS laufen die täglichen Backups in Rekordzeit durch. Sollte eine Platte abrauchen, steht jederzeit ein konsistenter Stand bereit.

Nextcloud

Nextcloud läuft bei mir bewusst in einer vollwertigen VM statt in einem LXC-Container, um dedizierte CPU- und RAM-Ressourcen fest zuzuweisen. So gerät das System auch bei Lastspitzen nicht ins Stocken. Als Basis dient wie gewohnt Debian.

Aktuell sichere ich die VM noch per Vollbackup auf dem NAS. Mittelfristig plane ich jedoch, zumindest die Datenpartition auf inkrementelle Backups umzustellen: Die Wiederherstellung erfordert dann zwar einen Handgriff mehr, spart im Gegenzug aber massiv Speicherplatz und Backup-Laufzeit.

Hardware & Arbeitsalltag

Mein täglicher Begleiter bleibt das MacBook Air M4. Es ist leicht, geräuschlos, hält gefühlt ewig durch und reicht für alltägliche Entwicklungsaufgaben vollkommen aus.

Geht es allerdings an lokale Sprachmodelle, werfe ich den Desktop-PC an: Dessen GPU-Power liefert bei LLMs schlichtweg eine ganz andere Taktrate. Die klare Trennung funktioniert für mich ideal – das MacBook mobil für den Flow, die Workstation für rechenintensive Experimente.

Tee & Rituale

In den letzten Monaten hat Tee den Kaffee bei mir spürbar verdrängt – daher gibt es nun auch die neue Kategorie Tee im Blog.

Die Zubereitung ist für mich ein echtes Pausenritual geworden: Wasser aufsetzen, Ziehzeit abwarten, kurz durchatmen und den Kopf vom Bildschirm lösen. Ich habe einige hervorragende lose Teesorten für mich entdeckt – auch wenn ich pragmatisch genug bin, an hektischen Tagen ohne schlechtes Gewissen zum Teebeutel zu greifen.

Ein kleiner Wermutstropfen: Unser bisheriger Stammhändler Azafran liefert aufgrund der europäischen EPR-Regelungen vorerst keinen Tee mehr in die Niederlande. Ich halte also aktuell die Augen nach guten Alternativen offen.

Abschied von GoBlogger

GoBlogger war ein spannendes Projekt, bei dem ich eine Menge gelernt habe. Allerdings fehlte mir zuletzt schlichtweg die Zeit, die Entwicklung so voranzutreiben, wie ich es mir vorgestellt hatte. Ich habe mich daher entschieden, Domain und Repository ruhen zu lassen. Manchmal gehört Loslassen einfach dazu.

Gedanken zu Open Source, Nischenprojekten & KI

Aktuell liegen bei mir ohnehin vor allem kleinere, sehr spezifische Tools auf der Werkbank: ein Python-Skript zum automatisierten Herunterladen gekaufter Anleitungen via Ravelry-API, ein noch unfertiges PHP-Projekt und Golang zum Journaling sowie eine Paar eigener DokuWiki-Plugins (EditorPlus, MarkdownToolbar), die ich auf meiner Forgejo-Instanz pflege.

Solche Werkzeuge baue ich primär für meinen ganz eigenen Alltag. Veröffentlicht man sie jedoch, entsteht fast automatisch ein unausgesprochenes Erwartungsmanagement. Die romantisierte Vorstellung, durch den Release Gleichgesinnte zu finden, die gemeinsam am Code feilen, erweist sich bei kleinen Nischen meist als Illusion. Am Ende bleibt man fast immer Einzelkämpfer.

Blickt man in die Open-Source-Landschaft, mutieren viele Maintainer rasch zu unbezahlten Support-Mitarbeitern, die dutzende gleichförmige Issue-Reports abarbeiten müssen. Im Zeitalter von LLMs hat sich dieser Trend noch beschleunigt: Tickets und Pull Requests sind in Sekunden generiert, während der Maintainer die kognitive Last der Prüfung und Pflege trägt.

Gleichzeitig verändert generative KI das Verhältnis zu Software grundlegend: Warum sollte sich jemand monatelang in eine fremde Nischen-Codebasis einarbeiten oder auf ein Feature warten, wenn man sich mit einem Prompt und einem LLM binnen einer Stunde eine maßgeschneiderte Lösung stricken kann?

Große Fundamente wie Linux, curl, PostgreSQL oder SQLite zeigen natürlich weiterhin eindrucksvoll, wie unverzichtbar offene Kollaboration ist. Doch für kleine Liebhaberprojekte schwindet der Anreiz externer Mitarbeit in Zeiten automatisierter Codegenerierung zusehends.

Daraus entsteht ein gewisser Zwiespalt: Einerseits macht es Spaß, Skripte und Basteleien öffentlich bereitzustellen. Andererseits frage ich mich bisweilen, wie viel Sinn das noch ergibt, wenn ohnehin jeder in der Lage ist, sich die passende Lösung auf Knopfdruck selbst zu generieren.

Vielleicht ist das aber auch völlig in Ordnung. Manchmal reicht es völlig, wenn ein Werkzeug genau das eine Problem löst, für das man es selbst gebaut hat.