Server-Flotte im Griff: Mein halbes Homelab verwalte ich jetzt aus Claude Code

Wer mehr als einen Linux-Server betreibt, kennt das Spiel: der Raspberry Pi im Schrank, die VPS beim Hoster, der Mini-PC mit den Docker-Containern. Für jeden tippst du ssh user@…, suchst den richtigen Port und versuchst dich zu erinnern, ob das jetzt 192.168.1.5 oder .15 war. Drei Terminals, fünf SSH-Configs — und spätestens beim vierten Server verlierst du den Überblick.

Genau an diesem Punkt habe ich angefangen, Fleet Manager zu bauen: ein Plugin für Claude Code, das deine komplette Server-Flotte in eine einzige Session holt. Statt Verbindungen zu jonglieren, sagst du /status, /health-summary oder /compose-up monitoring — und Claude weiß, welcher Server gemeint ist.

TL;DR

Was: Claude-Code-Plugin für Multi-Server-SSH-Management
Für wen: Homelabber und Admins mit mehreren Linux-Hosts
Kosten: keine — Open Source unter MIT
Kernidee: ein Inventar, ein aktiver Server, klare Befehle statt SSH-Chaos

Das eigentliche Problem ist nicht SSH — es ist der Kontext

SSH funktioniert tadellos. Was nervt, ist der Kontext drumherum: Welcher Server war noch mal welcher? Läuft auf dem Pi der Monitoring-Stack oder auf der VPS? Habe ich das Backup-Verzeichnis schon gespiegelt? Dieses Wissen lebt normalerweise in deinem Kopf (oder in einer unübersichtlichen ~/.ssh/config).

Fleet Manager schreibt dieses Wissen in ein Inventar: pro Server ein Profil mit Verbindungsdaten, erkanntem Betriebssystem, Docker-Status und den erlaubten Operationen. Einer der Server ist immer der aktive — das Standardziel, wenn du keinen Namen angibst. Und damit du nie versehentlich auf dem falschen Host landest, druckt jeder Befehl zuerst sein Ziel:

→ Ziel: homeserver (pi@192.168.1.5:22)

In fünf Minuten eingerichtet

Die Einrichtung ist bewusst geführt. Nach der Installation des Plugins startest du den Onboarding-Assistenten:

/plugin marketplace add CallMeTechie/fleet-manager
/plugin install fleet-manager@fleet-manager
/first-run

Ein Intake-Agent fragt dich nach Name, Host, Port und SSH-Benutzer. Dann kümmert sich /setup-ssh um den Schlüssel — Fleet Manager nutzt einen eigenen, dedizierten Ed25519-Key und vermischt sich nicht mit deinen sonstigen Schlüsseln. Den öffentlichen Teil deployst du mit einer Zeile, die das Plugin dir zum Kopieren gibt:

! ssh-copy-id -p 22 -i ~/.ssh/fleet-manager_ed25519.pub pi@192.168.1.5

Das führende ! ist wichtig — es öffnet in Claude Code ein echtes Terminal für die Passwort-Eingabe. Zum Schluss prüft /diag, ob alles steht: SSH, sudo, Docker, Plattenplatz. Fertig.

Die Befehle, die ich täglich nutze

Mein erster Griff am Morgen ist der Flotten-Überblick:

/health-summary
  SERVER        STATUS  OS            DISK/ LOAD MEM   DOCKER
* homeserver    UP      Ubuntu 24.04  45%   0.8  62%   yes
  vps-web       UP      Debian 12     28%   1.2  71%   no
Verdict: 2/2 up

Eine Zeile pro Server, ein SSH-Aufruf je Host — und ich sehe sofort, ob etwas aus dem Ruder läuft. Danach geht es ins Detail:

/status vps-web — Disk, RAM, Uptime und Load eines einzelnen Servers
/compose-list und /docker-list --all — welche Stacks und Container laufen?
/compose-up monitoring bzw. /compose-update monitoring — Stack starten oder Images aktualisieren
/logs homeserver sshd --tail 50 — schnell ins Journal schauen

Und wenn ich eine Compose-Datei oder ein Backup verschieben muss, übernehmen /copy und /sync den Transfer — mit der praktischen <server>:<pfad>-Syntax:

/copy ./docker-compose.yml homeserver:/srv/monitoring/
/sync /srv/data homeserver:/backup/data            # Vorschau (Dry-Run)
/sync /srv/data homeserver:/backup/data --apply    # wirklich übertragen

Sicherheit: bewusst ein bisschen paranoid

Ein Tool, das per SSH auf mehreren Servern Befehle ausführt, muss vorsichtig sein. Deshalb steckt die Sicherheit bei Fleet Manager im Design:

Scopes pro Server: Jedes Profil gibt nur frei, was erlaubt ist. Ohne docker_compose kein /compose-down, ohne file_transfer kein /sync — der Befehl verweigert sich schlicht.
Dry-Run als Standard: /sync zeigt erst, was passieren würde. Löschen (--delete) verlangt obendrein ein getipptes Bestätigungs-Token.
Kritische Stacks unter Schutz: Projekte in critical_compose_projects lassen sich nur mit --confirm=<project> stoppen.
Kein blindes Vertrauen: Fleet Manager schaltet die Host-Schlüssel-Prüfung nicht ab. Die erste Verbindung zu einem unbekannten Host scheitert bewusst, statt einen womöglich untergeschobenen Schlüssel zu akzeptieren.
Deine Daten bleiben lokal: Hosts, Benutzer und Schlüssel landen nie in Git — die echten Profile sind git-ignoriert, nur Vorlagen werden eingecheckt.

Ehrlich bleibt dabei: Die Bestätigungs-Token sind ein Schutz gegen versehentliche Läufe, kein unüberwindbares Gate. Sie machen die Absicht in der Befehlszeile sichtbar — mehr, aber auch nicht weniger.

Fazit

Fleet Manager nimmt mir nicht das Denken ab, aber das Jonglieren. Ich muss mir keine Hosts, Ports und Benutzer mehr merken, sehe den Zustand meiner ganzen Flotte in einer Zeile und steuere Docker-Stacks, ohne mich erst durchzuhangeln. Für ein Homelab mit einer Handvoll Servern ist das genau die richtige Mischung aus Komfort und Kontrolle — und weil es Open Source ist, kostet es dich nichts außer fünf Minuten Einrichtung.

Der Code liegt auf GitHub. Wenn du mehrere Linux-Server betreibst und Claude Code nutzt: ausprobieren und mir erzählen, was noch fehlt.