Meine Home-Lab-AI-Entwicklungsplattform

 (rsgm.dev)
8 Punkte von GN⁺ 6 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Um die Services im Home-Lab zu verwalten, wurde OpenCode Web UI mit Git-Zugriff ausgestattet und ein Ablauf aufgebaut, bei dem AI-Änderungen nach PR-Review per GitOps ausgerollt werden
  • Rund 12 docker compose-Stacks wurden zu Arcane migriert und per GitOps verwaltet; AI-Tools werden für die Wartung der Services eingesetzt
  • Bei Container-Updates dauerte das Prüfen von Release Notes, das Kontrollieren von Breaking Changes und die manuelle Verifikation früher mehrere Stunden; jetzt lassen sich Zusammenfassungen der Release Notes in wenigen Minuten lesen, wodurch Versions-Upgrades einfacher und sicherer werden
  • OpenCode läuft als Server und bietet Terminal, Dateibrowser, Git-Diff und git worktree; außerdem synchronisiert es dauerhafte Coding-Sessions über mehrere Geräte hinweg
  • Die AI hat keinen direkten Zugriff auf produktive Services und kann nur Git-Branches pushen, sodass nicht geprüfter Code nicht ausgerollt werden kann

Verwaltungsablauf im Home-Lab

  • Dem OpenCode Web UI wurde Git-Zugriff gegeben, um die Verwaltung des Home-Labs zu vereinfachen; wenn OpenCode Änderungen zu Git pusht, genehmigt ein Mensch den PR und anschließend rollt GitOps die Änderungen aus
  • OpenCode läuft als Server, und dauerhafte Coding-Sessions werden über mehrere Geräte hinweg synchronisiert
  • Es werden etwa 12 docker compose-Stacks verwaltet, die kürzlich zu Arcane migriert wurden und nun per GitOps verwaltet und ausgerollt werden
  • Der erste Anwendungsfall für AI-Tools war das Aktualisieren von Containern
    • Früher musste man für jeden Service die Release Notes suchen, Breaking Changes prüfen, das Update durchführen und Probleme in jedem Service manuell kontrollieren
    • Dieser Prozess dauerte mehrere Stunden, aber jetzt lassen sich Zusammenfassungen der Release Notes in wenigen Minuten lesen, wodurch Versions-Upgrades einfacher und sicherer werden
    • AI wurde genutzt, um den meisten Containern Healthchecks hinzuzufügen, damit Probleme schneller erkannt werden können

OpenCode

  • Zunächst wurde hauptsächlich Claude Code verwendet, aber weil AI-Anbieter durch Token-Limits den Kundennutzen verringern, wurde nach Alternativen gesucht
  • Gewünscht war ein Tool, das nicht an einen bestimmten Vendor gebunden ist und eine Coding-Umgebung bietet, die von den wichtigsten Plugins unterstützt wird
  • Nach dem Ausprobieren mehrerer Coding-Umgebungen fiel die Wahl auf OpenCode, das unter den getesteten Optionen am meisten überzeugte
  • Dass OpenCode einen eingebauten Webserver und ein Web-UI bietet, war der Auslöser für die Idee einer AI-Entwicklungsplattform im Home-Lab

AI-Entwicklungsplattform

  • Auf dem Truenas-Host wurde eine einfache VM mit grundlegenden Entwickler-Tools erstellt und der OpenCode-Webserver als systemd unit hinzugefügt
  • Diese Umgebung bietet eingebautes Terminal, Dateibrowser, Git-Diff und Unterstützung für git worktree, sodass mehrere Coding-Sessions gleichzeitig verwaltet werden können
  • Das mobile Web-UI von OpenCode gefiel besonders wegen des sehr guten Frage-und-Antwort-Pop-ups
  • Auf dem Git-Server wurden ein dedizierter Benutzer und ein dedizierter SSH-Key nur für OpenCode eingerichtet
    • OpenCode kann Projekte klonen und Branches pushen
    • Direktes Pushen auf den Deployment-Branch ist nicht möglich
  • Im Workflow steht die AI vor dem PR-Review: OpenCode erstellt die Änderungen, und ein Mensch merged sie direkt im PR
    • Diese Struktur verhindert, dass ungeprüfter Code ausgerollt wird
  • Die VM kann auf das Internet und den Git-Server zugreifen, aber nicht auf die tatsächlichen Services
    • Weil der Wirkungskreis klein ist, wurde entschieden, dass OpenCode bei Bedarf VM-Root-Rechte erhalten darf, etwa wenn Build-Tools oder Test-Abhängigkeiten installiert werden müssen
  • Diese Struktur kann zu einer produktiven Entwicklerplattform im Stil temporärer Container für Entwickler ausgebaut werden, mit vorinstallierten Tools, Zugriffsleitplanken und Audit-Logs
  • Die aktuelle Konfiguration liefert die benötigten Funktionen, ohne zu viele Komponenten zu umfassen

Workflow

  • Der grundlegende Arbeitsablauf beginnt mit dem Planen einer Funktion oder Verbesserung in OpenCode
    • Die Planung umfasst Spezifikation, Implementierungsplan und Self-Review
  • Wenn möglich, werden Änderungen getestet oder validiert
  • Was nicht gefällt, wird iterativ zusammen mit OpenCode nachgebessert
  • OpenCode pusht die Änderungen auf einen Feature-Branch
  • Für diesen Branch wird ein PR geöffnet, und wenn alles passt, wird der PR gemergt
  • Nach dem Merge übernimmt GitOps das Deployment
    • Änderungen an docker-Services werden von Arcane verarbeitet
    • Änderungen an der Home-Assistant-Konfiguration werden vom GitOps-Plugin verarbeitet
    • Änderungen am Blog werden vom Cloudflare Pages worker verarbeitet

Kombination aus Arcane GitOps und OpenCode

  • Die Services wurden von Truenas in ein Arcane-GitOps-Projekt migriert; das Hauptziel war, alle zuvor auf Truenas laufenden docker compose-Stacks in einem Git-basierten Repository zu verwalten
  • Zusammen mit OpenCode funktioniert dieser Ansatz besser als erwartet
  • Selbst vom Smartphone aus lässt sich das Networking aller Container aktualisieren, wodurch die verteilte Konfigurationsverwaltung deutlich einfacher wird
  • Früher dauerte es mehrere Stunden, alle Compose-Stacks durchzugehen und Netzwerkverbindungen nachzuverfolgen
  • Jetzt kann man OpenCode Codebasis und Ziel vorgeben, die erzeugten PR-Änderungen prüfen und danach mergen

Verbleibende Einschränkungen und Zugriffskontrolle

  • Die größte Lücke ist CI-Feedback
  • Auf GitHub können Coding-Agenten Actions-Logs einsehen und fehlgeschlagene Tests, Linter-Fehler, Stack-Traces und Änderungen in IaC-Plänen diagnostizieren
  • Dieser Ansatz hilft dabei, selbst bei Änderungen, die nicht durch Unit-Tests abgedeckt werden, eine schnelle Feedback-Schleife aufrechtzuerhalten
  • In Forgejo ist dieser Ablauf schwieriger
    • Forgejo Actions stellt Job-Logs nicht über eine öffentliche API bereit
    • Es gibt zwar eine undokumentierte API, aber darauf möchte man die Konfiguration nicht aufbauen
  • Die aktuelle Konfiguration ermöglicht es der AI, Änderungen an der Home-Infrastruktur von jedem Gerät aus zu erstellen, ohne direkten Zugriff auf die Ziel-Services zu haben
  • Änderungen können am Computer begonnen, der PR am Smartphone geprüft und das Deployment anschließend von GitOps übernommen werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 시간 전
Hacker-News-Kommentare

  • Ich suche noch nach der richtigen Art der AI-Integration für meine Umgebung. Im Moment gibt es keine Interaktion zwischen Forgejo und dem Coding-Agenten, und ich habe auch mit einem Forgejo-Actions-Runner experimentiert, aber das Kontextmanagement war unklar.
    Inhalte aus Issues oder PRs kann man übernehmen, aber wenn es mehrere Hin-und-Her-Runden gibt oder die Diskussion sich von einem Issue zu einem PR verlagert, wird es schnell unübersichtlich.

  • Ich mache etwas Ähnliches und nutze einen Workflow, der opencode innerhalb eines Forgejo-Action-Runners ausführt, statt einen persistenten opencode-Server zu betreiben: https://codeberg.org/dragonfyre13/forgejo-opencode
    Ist noch in Arbeit, aber die Idee ist, Opencode in einem Forgejo-Issue mit /oc aufzurufen, woraufhin es mit einem PR zur Prüfung zurückkommt.

  • Manchmal fühlt es sich so an, als würden viele Leute in der Tech-Branche fast gleichzeitig unabhängig voneinander sehr ähnliche Dinge erleben, aber nur wenige schreiben oder sprechen darüber.
    Ich baue auch ein ähnliches System, und beim Lesen des Artikels und der Kommentare hat es mich gefreut zu sehen, dass offenbar alle durch ähnliche Phasen gehen.

    • Das gilt nicht nur für die Tech-Branche, das ist ein verbreitetes Phänomen. So originell sind wir nicht.
    • Ich habe das auch schon auf drei Arten gebaut und e2b.dev ausprobiert; das war ein guter Service.
      Das Problem ist, dass wir 99 % unserer Zeit damit verbringen, coole Dinge zu hacken, und nur 1 % damit, darüber zu reden. Wir sollten mehr darüber reden.
    • Ich glaube, das liegt daran, dass Leute in der Tech-Branche erwarten, alles kostenlos zu bekommen.
      Ich sprach mit einem Anwalt, und als unsere Zeit fast um war, wollte ich noch „nur eine Frage“ stellen. Der Anwalt meinte: „Buchen wir noch 30 Minuten und sprechen dann darüber.“ Das ist fair.

  • Ich suchte gerade nach einem Anstoß, endlich über mein AI-Lab zu schreiben, und dieser Beitrag war genau der Impuls, den ich gebraucht habe.
    Mein Setup basiert auf einer ähnlichen Idee, nutzt aber n8n/git/argo/k3s und ist vor allem für automatisierte Workflows gedacht, die größtenteils von Qwen oder Gemma4 erledigt werden können.

  • Weiß jemand, warum diese Domain bei Quad9-Resolvern blockiert wird? Quad9 filtert die Domain, sodass sich die Website nicht öffnen lässt.
    dig @9.9.9.9 rsgm.dev NS liefert EDE: 17 (Filtered).

    • Meine Vermutung wäre, dass die Registrierung noch sehr neu ist. Sie ist erst seit etwa 8 Stunden registriert, Erstellungszeitpunkt ist 2026-06-15 14:01:25 UTC.

  • Die beiden Hauptgründe, warum ich dieses Setup noch nicht nutze, sind die Ressourcen, die man der VM geben muss, auf der opencode läuft, damit das Projekt gebaut werden kann, und die schnelleren Tests.
    Ich lasse meinen pi-Coding-Agenten direkt auf dem Mac laufen und starte daneben auch komplette Software-Bundles wie redis, postgres und kratos. Wenn der Coding-Agent auf dem primären Entwicklungsrechner läuft, kann er schneller bauen, und ich kann Änderungen schneller prüfen, indem ich nur das Backend neu baue und neu starte und dann direkt im UI-Client teste.

  • Ich mache es ebenfalls sehr ähnlich. Ich betreibe OpenCode in einem Proxmox-LXC und habe darüber noch eine Kimaki-Schicht für die Discord-Integration gelegt.
    Ob man es mag oder nicht: Mit der Codebase chatten zu können ist ziemlich cool, und wenn man möchte, sogar per Sprachnachricht.

  • Großartig. HomeLab-AI klingt nach einer Menge Spaß.
    Im Moment lasse ich Claude mein HomeLab über alle Geräte hinweg verwalten, und dadurch hat sich HomeLab-Setup und -Wartung von einer „jahrelang faszinierenden, aber nie ganz funktionierenden und Zeit fressenden Falle“ zu etwas entwickelt, das tatsächlich eine gute Idee ist und meine Fähigkeiten erweitert.

    • Selbst mit aktuellen Modellen gab es zwar kleine Bereiche, in denen ich Zeit sparen konnte, aber oft führte eine subtile Konfigurationsproblematik zu massivem Debugging, sodass es sich insgesamt eher nicht lohnte.
      Für sehr eng abgegrenzte Aufgaben wie „Erstell mir eine docker-compose-Datei“ oder „Gib mir eine NSD-Konfiguration“ ist es okay, aber selbst dann muss man schon wissen, welche Basistechnologien nötig sind und was man überhaupt fragen muss.

  • Ein Setup, bei dem man dem OpenCode Web UI Git-Zugriff gibt, um die HomeLab-Verwaltung zu erleichtern, und OpenCode dann nach Git pusht, ich den PR genehmige und GitOps die Änderungen ausrollt, klingt ziemlich gut.
    Bevor ich weiterlese, frage ich mich nur, ob man für etwas Ähnliches mehrere tausend Dollar für RAM und GPU einplanen muss.

    • Es könnten auch 0 Dollar sein. OpenCode ist nur ein Harness, man kann es also an jedes beliebige online gehostete Modell anschließen.

  • Wir machen etwas Ähnliches, lassen den Agenten aber auch PRs öffnen und verfolgen Release-Metadaten sowie Agent-Sessions mit dem ReARM-System.
    Vor Kurzem haben wir außerdem eine Option veröffentlicht, mit der der Agent über ReARM Helm-basierte Deployments nachverfolgen kann: https://docs.rearmhq.com/workflows/devops.html

    • Diesen Teil hatte ich nicht erwähnt, aber während ich den Beitrag geschrieben habe, wurde mir klar, dass man leicht einen Skill hinzufügen könnte, der die Forgejo-PR-API aufruft.
      Leider hat Forgejo anders als GitHub keine CLI.