Künstliche Intelligenz

Claude Code auf dem VPS

Mein KI-Assistent für Server, Kirby und Mastodon

Es begann mit einer simplen Frage: Kann ich die Intelligenz eines großen Sprachmodells direkt auf meinem Server einsetzen – nicht über ein Web-Interface, sondern tief im Terminal, wo die eigentliche Arbeit stattfindet? Die Antwort ist Claude Code, und sie hat meine Art, meinen VPS zu verwalten, nachhaltig verändert. Dieser Artikel ist kein neutraler Produkttest, sondern ein ehrlicher Erfahrungsbericht eines Betreibers, der damit täglich Kirby CMS und eine Mastodon-Instanz administriert.

Was ist Claude Code eigentlich?

Claude Code ist ein offizielles Kommandozeilenwerkzeug von Anthropic, dem Unternehmen hinter dem KI-Modell Claude. Es ist kein Chatbot im Browser – es ist ein Terminal-Agent, der sich wie ein erfahrener Kollege verhält, der neben dir am Server sitzt. Es liest Dateien, analysiert Logs, schreibt Code, schlägt Konfigurationsänderungen vor und erklärt dabei, was es tut und warum.

Der entscheidende Unterschied zu einem Chat-Interface: Claude Code kennt den Kontext. Es weiß, in welchem Verzeichnis du dich befindest, kann Dateien einlesen, Verzeichnisstrukturen durchsuchen, Befehle ausführen und die Ergebnisse sofort interpretieren. Es ist kein Frage-Antwort-Spiel mehr, sondern eine echte Zusammenarbeit im laufenden System.

Warum Claude Code auf dem VPS – und nicht im lokalen Editor?

Viele kennen KI-Integration aus lokalen Entwicklungsumgebungen wie VS Code oder dem integrierten Terminal auf dem eigenen Rechner. Aber ein VPS ist ein anderes Tier: Du arbeitest oft direkt per SSH, die Umgebung ist produktiv, und Fehler haben unmittelbare Konsequenzen. Genau hier entfaltet Claude Code seinen besonderen Wert.

Wenn auf dem Server etwas schiefläuft – ein Mastodon-Dienst antwortet nicht, ein Kirby-Hook wirft PHP-Fehler, ein Nginx-Block verhindert das Laden einer Seite – dann sitzt man mit herkömmlichen Mitteln vor Logdateien, Konfigurationsfragmenten und Stack Traces und muss selbst die Zusammenhänge herstellen. Claude Code übernimmt genau diesen analytischen Schritt: Es liest die relevanten Dateien, erkennt Muster und formuliert einen klaren Diagnose- und Lösungsvorschlag.

Für jemanden, der seinen Server gelegentlich administriert, ohne täglich tief in Linux-Systemdienste einzutauchen, ist das ein Quantensprung. Man bleibt Herr der Lage, versteht was passiert – und bekommt die präzisen Befehle an die Hand, die man braucht.

Was brauche ich? Die Voraussetzungen

Bevor Claude Code auf dem VPS läuft, braucht es einige Dinge:

Authentifizierung – und hier gibt es zwei Wege:

Der erste und einfachste Weg ist ein bestehendes Claude-Abonnement. Wer Claude Pro, Max, Team oder Enterprise nutzt, kann Claude Code direkt über sein Claude-Konto authentifizieren – ohne zusätzliche Kosten und ohne separaten API-Key. Die Nutzung läuft dann über das im Plan enthaltene Kontingent.

Der zweite Weg ist ein Anthropic-API-Key. Unter console.anthropic.com registriert man sich, hinterlegt eine Zahlungsmethode und erzeugt unter API Keys einen persönlichen Schlüssel. Die Nutzung wird dann nach Tokenverbrauch abgerechnet (Pay-per-Use). Dieser Weg eignet sich besonders für die serverseitige Nutzung ohne interaktiven Login.

Node.js in einer halbwegs aktuellen Version (18 oder neuer) muss auf dem VPS installiert sein. Claude Code ist ein npm-Paket und benötigt die Node-Laufzeitumgebung.

SSH-Zugang zum Server versteht sich von selbst.

Installation auf dem VPS

Die Installation selbst ist erfreulich unkompliziert. Du verbindest dich per SSH mit deinem Server und installierst Claude Code als globales npm-Paket:

npm install -g @anthropic-ai/claude-code

Authentifizierung mit Claude Pro/Max (empfohlen für Abonnenten)

Wer ein Claude Pro- oder Max-Abonnement hat, meldet sich einfach an:

claude login

Claude Code öffnet einen Browser-Link zur Anmeldung bei claude.ai. Nach der Bestätigung ist die Verbindung hergestellt – kein API-Key nötig. Die Nutzung läuft dann über das im Abo enthaltene Kontingent.

Wichtig: Falls auf dem Server die Umgebungsvariable ANTHROPIC_API_KEY gesetzt ist, hat diese Vorrang vor dem eingeloggten Abonnement. Wer sicher über sein Abo abgerechnet werden will, prüft mit /status innerhalb von Claude Code, welche Authentifizierung aktiv ist.

Authentifizierung mit API-Key (für serverseitige Nutzung)

Wer keinen Claude-Plan hat oder Claude Code headless/automatisiert betreiben will, setzt den API-Key als Umgebungsvariable. Am bequemsten dauerhaft in der ~/.bashrc oder ~/.zshrc:

export ANTHROPIC_API_KEY="sk-ant-xxxxxxxxxxxxxxxxxxxxxxxx"

Danach die Konfiguration neu laden:

source ~/.bashrc

Jetzt kannst du Claude Code in jedem Verzeichnis mit dem Befehl claude starten. Beim ersten Start richtet es sich kurz ein und fragt nach einer Bestätigung der Nutzungsbedingungen. Dann öffnet sich ein interaktives REPL – eine Art intelligentes Terminal innerhalb des Terminals.

Um Claude Code direkt aus einer Verzeichnisstruktur heraus zu starten, wechselst du einfach in den relevanten Ordner:

cd /var/www/meine-kirby-seite
claude

Claude Code liest dann automatisch die Struktur des Projekts ein und kennt den Kontext.

API-Key: Sicherheit und Best Practices

Der API-Key ist sensibel. Wer ihn kennt, kann auf dein Anthropic-Konto zugreifen und auf deine Kosten Anfragen stellen. Deshalb einige wichtige Hinweise:

Den Key niemals in ein Git-Repository einchecken. Wenn du Skripte schreibst, die Claude Code aufrufen, nutze Umgebungsvariablen oder eine .env-Datei, die in .gitignore steht.

Setze in der Anthropic-Konsole ein monatliches Ausgabenlimit. Das ist ein einfaches Sicherheitsnetz, das verhindert, dass eine versehentlich ausgeführte Schleife oder ein missverstandener Befehl ein unerwartetes Budget verbrennt.

Für den VPS empfiehlt es sich, den Key nur für deinen persönlichen Benutzer zugänglich zu machen, nicht systemweit. Die Umgebungsvariable in der ~/.bashrc des eigenen Users – nicht in /etc/environment – ist hier der richtige Ort.

Wer mit einem Claude-Abonnement arbeitet, sollte regelmäßig mit /status prüfen, ob tatsächlich das Abo und nicht versehentlich ein API-Key für die Abrechnung aktiv ist.

Kosten und Abrechnung: Was zahlt man wirklich?

Das hängt vom gewählten Weg ab.

Mit Claude Pro oder Max ist Claude Code im Abonnement enthalten. Pro kostet derzeit rund 20 Euro im Monat, Max (mit höherem Kontingent) mehr. Für gelegentliche Server-Administration ist Pro oft ausreichend; wer intensiv arbeitet, greift zu Max. Ist das Kontingent erschöpft, kann man optional auf API-Nutzung (Pay-per-Use) umschalten.

Mit API-Key wird nach Tokenverbrauch abgerechnet. Tokens sind grob gesagt die Textbausteine, aus denen Anfragen und Antworten bestehen. Jede Zeile Code, die Claude liest oder schreibt, jede Erklärung, die es gibt, kostet Tokens – sowohl auf der Eingangs- als auch auf der Ausgangsseite.

Ein typisches Debugging-Gespräch, bei dem Claude eine Nginx-Konfiguration prüft und einen Fehler behebt, kostet vielleicht 5–15 Cent. Eine ausführliche Sitzung, in der ein komplexes Mastodon-Problem analysiert, Logs gelesen und ein Patch erarbeitet wird, kann 50 Cent bis einen Euro kosten. Für gelegentliche Nutzung – etwa ein paarmal pro Woche – bewegt man sich realistisch in einem Bereich von 10–30 Euro im Monat.

Die Abrechnung ist vollständig transparent: In der Anthropic-Konsole siehst du jeden API-Call mit seinem Tokenverbrauch und den entstandenen Kosten. Es gibt keine Überraschungen.

Das Sudo-Problem: Was Claude Code nicht alleine kann

Hier ist ein wichtiger Punkt, den man frühzeitig verstehen sollte: Claude Code führt Befehle im Kontext des Benutzers aus, unter dem du angemeldet bist. Es hat keine Root-Rechte und kann sich diese auch nicht selbst verschaffen.

Das ist gut so – es wäre gefährlich, wenn ein KI-Tool eigenständig systemweite Änderungen vornehmen könnte. In der Praxis bedeutet es aber: Alles, was sudo erfordert – Systemdienste neu starten, Pakete installieren, Berechtigungen auf System-Dateien ändern, Nginx oder Mastodon-Dienste via systemctl verwalten – das musst du selbst im Terminal eingeben.

Claude Code ist hier aber keineswegs hilflos. Es analysiert das Problem, erarbeitet den exakten Befehl, den du ausführen musst, und erklärt dir, was er bewirkt. Du kopierst ihn, führst ihn in einem zweiten Terminal mit sudo aus, kommst zurück zu Claude Code und gibst das Ergebnis ein. Diese Zusammenarbeit funktioniert erstaunlich flüssig und hat den angenehmen Nebeneffekt, dass du weißt, was auf deinem Server passiert – du bist kein passiver Zuschauer.

Ein typisches Beispiel:

Du: Mastodon antwortet nicht mehr, die Seite lädt nicht.
Claude Code: [liest Logs, analysiert] Der Puma-Prozess scheint abgestürzt zu sein.
             Führe bitte folgenden Befehl aus:
             sudo systemctl restart mastodon-web
             Und dann: sudo systemctl status mastodon-web
             Teile mir die Ausgabe mit.

Das ist keine Einschränkung, das ist ein sinnvolles Sicherheitskonzept.

Typische Aufgaben: Was sage ich Claude Code?

Die Stärke von Claude Code liegt in der Natürlichkeit der Kommunikation. Du musst keine Befehle kennen, keine Manpages lesen, keine Optionen googeln. Du beschreibst das Problem – und bekommst Lösungen.

Für Kirby CMS:

"Schau dir die Fehler in den PHP-Logs an. Die Kontaktformular-Seite
 gibt einen 500er zurück."

"Ich möchte einen neuen Blueprint für eine Projektseite erstellen.
 Felder: Titel, Beschreibung, Startdatum, Endstatus, Cover-Bild."

"Welche Kirby-Hooks werden in diesem Plugin registriert und was tun sie?"

"Erkläre mir die Ordnerstruktur dieses Kirby-Projekts."

"Ich habe eine neue Subdomain eingerichtet. Was muss ich in der
 Nginx-Konfiguration anpassen?"

Für Mastodon:

"Zeig mir, welche Mastodon-Dienste aktuell laufen und ihren Status."

"Warum werden keine E-Mails mehr verschickt? Prüf die Konfiguration."

"Wie viel Speicher verbraucht die Datenbank aktuell? Gibt es
 unnötige Dateien, die ich bereinigen kann?"

"Ich möchte einen neuen Admin-Benutzer anlegen. Welcher Befehl ist das?"

"Erkläre mir, was tootctl media remove macht, bevor ich es ausführe."

Für allgemeine Serveradministration:

"Prüfe die letzten 100 Zeilen des Nginx-Error-Logs auf häufige Muster."

"Welche Cronjobs sind aktuell für diesen Benutzer eingerichtet?"

"Zeig mir die größten Verzeichnisse auf der Festplatte."

"Ist dieser SSH-Konfigurationswert sicherheitstechnisch empfehlenswert?"

Die Sprache ist dabei völlig frei. Deutsch funktioniert genauso gut wie Englisch. Claude Code antwortet in der Sprache, die du verwendest.

Claude Code vs. Cursor: Wann ist welches Werkzeug besser?

Diese Frage taucht auf, sobald man beide Werkzeuge kennt. Cursor ist eine fantastische KI-gestützte Entwicklungsumgebung – ein VS Code-Fork, der tief in den Editor integriert ist und hervorragend für die lokale Entwicklung neuer Features funktioniert. Für das Schreiben von neuem Code in einer komfortablen GUI mit Syntax-Highlighting, Dateibaum und Vorschau-Funktionen ist Cursor kaum zu schlagen.

Aber es gibt gewichtige Gründe, warum Claude Code für gelegentliche Server-Administration die bessere Wahl ist:

Kein lokales Setup nötig. Cursor installiert man lokal und verbindet es dann per Remote-SSH mit dem Server. Das funktioniert, aber es ist ein Umweg. Claude Code läuft direkt auf dem Server – ohne Verbindungsaufbau, ohne GUI, ohne Latenz durch das Remote-Protokoll.

Kontext ist der Server, nicht das Projekt. Cursor ist auf Codebasen ausgerichtet. Claude Code ist auf Systeme ausgerichtet. Wenn du Logs lesen, Dienste prüfen und Konfigurationsdateien aus verschiedenen Systemverzeichnissen zusammenführen musst, ist Claude Code in seinem Element.

Kosten bei gelegentlichem Gebrauch. Cursor hat ein Abonnement-Modell. Wer Claude Code über ein bestehendes Claude Pro/Max-Abo nutzt, zahlt nichts extra. Wer rein per API abrechnet, zahlt nur, was er verbraucht – in ruhigen Monaten kaum etwas.

Terminal-nativ. Wer SSH liebt und ohnehin im Terminal zuhause ist, will keine GUI auf dem Weg. Claude Code ist ein Terminal-Tool durch und durch.

Cursor bleibt die erste Wahl für das Entwickeln neuer Funktionen in einem lokalen Projekt. Claude Code ist die erste Wahl für alles, was auf dem lebenden Server stattfindet.

Sparsam mit Tokens umgehen: Budget schonen ohne Einschränkungen

Token-Sparsamkeit ist keine Geiz-Strategie, sondern gutes Handwerk. Wer versteht, wie der Verbrauch entsteht, kann effizienter arbeiten und das Budget gezielt einsetzen. Auch wer über ein Abonnement arbeitet, profitiert von effizienter Nutzung – das monatliche Kontingent ist nicht unbegrenzt.

Kleine Aufgaben, eine nach der anderen. Die stärkste Maßnahme ist auch die einfachste: Löse Aufgaben sequenziell statt parallel. Anstatt Claude Code zu bitten, „meinen gesamten Server zu analysieren, alle Konfigurationen zu überprüfen und mir einen umfassenden Bericht zu erstellen”, arbeitest du lieber in klaren Schritten: erst die Nginx-Konfiguration prüfen, dann das nächste Thema angehen. Große, vage Aufgaben führen dazu, dass Claude Code viele Dateien einliest und lange Antworten produziert – auch für Dinge, die vielleicht gar nicht relevant sind.

Kontexte sauber halten. Claude Code führt eine Konversationshistorie. Je länger eine Sitzung läuft, desto mehr Kontext wird bei jeder Anfrage mitgeschickt – das erhöht den Tokenverbrauch. Für neue, unzusammenhängende Aufgaben lohnt es sich, eine neue Sitzung zu starten (/clear oder einen neuen claude-Aufruf).

Präzise fragen. „Was ist in diesem Verzeichnis?” ist teurer als „Zeig mir nur die PHP-Dateien in /site/plugins.” Je gezielter die Frage, desto weniger muss Claude lesen und desto kürzer ist die Antwort.

Nur die relevante Datei öffnen lassen. Wenn du ein Problem in einer bestimmten Datei hast, sag das explizit: „Schau dir nur die Datei /etc/nginx/sites-available/meine-seite an.” Sonst könnte Claude mehrere Konfigurationsdateien einlesen, um sich ein Bild zu machen.

Erklärungen nur wenn nötig anfordern. Wenn du weißt, was ein Befehl tut, und nur die Syntax brauchst, sag: „Nur den Befehl, keine Erklärung.” Das spart Ausgabe-Tokens, die durchaus ins Gewicht fallen können.

Kurze Sitzungen für Routineaufgaben. Für wiederkehrende Aufgaben – etwa das Überprüfen eines Dienstes oder das Lesen der Logs – kann man Claude Code mit einem direkten Befehl aufrufen, ohne eine interaktive Sitzung zu starten:

claude -p "Was sagen die letzten 20 Zeilen von /var/log/nginx/error.log?"

Das ist effizient und sauber.

Chancen: Was sich wirklich verändert

Der tiefere Wandel, den Claude Code auslöst, ist schwer in Kategorien zu fassen. Es ist nicht nur „schnelleres Googeln” oder „besseres Autocomplete”. Es ist eine neue Art, mit dem eigenen System in Beziehung zu stehen.

Früher war das Debuggen eines Mastodon-Problems manchmal ein mehrstündiges Puzzle: Logs lesen, Halbwissen googeln, Stack Overflow durchsuchen, dabei das Gesamtbild verlieren. Mit Claude Code erklärt man das Problem in Alltagssprache und bekommt eine strukturierte Analyse zurück. Man versteht das Problem schneller – und behält dabei die Kontrolle, weil man jeden vorgeschlagenen Schritt versteht und selbst ausführt.

Für Nicht-Vollzeit-Entwickler wie viele Kirby- und Mastodon-Betreiber, die ihren Server neben Beruf und Alltag verwalten, bedeutet das: weniger Frustration, mehr Autonomie, schnellere Ergebnisse. Man traut sich an Aufgaben heran, die man früher gemieden hat – weil man weiß, dass man nicht allein damit ist.

Risiken: Womit sollte man sorgsam umgehen?

Kein Werkzeug ist ohne Schattenseiten, und ein ehrlicher Erfahrungsbericht nennt sie.

Blinder Vertrauen ist keine gute Strategie. Claude Code kann Fehler machen. Es kann Konfigurationsänderungen vorschlagen, die im Kontext des eigenen Systems nicht passen. Es kann veraltetes Wissen haben. Jeder Befehl, den man ausführt, sollte man zumindest grob verstehen. Das ist keine Einschränkung des Werkzeugs, sondern gesundes Systemdenken.

Datenschutz bei sensiblen Dateien. Alles, was Claude Code liest, wird an Anthropics API gesendet. Das ist bei PHP-Templates und Nginx-Konfigurationen kein Problem. Aber Datenbankpasswörter, private Schlüssel oder Nutzer-Daten sollte man nicht explizit in die Unterhaltung einbringen. Claude Code ist gut darin, sensitive Informationen in Konfigurationsdateien zu erkennen – aber es ist gut, sich dieser Grenze bewusst zu sein.

Abhängigkeit durch Komfort. Wer Claude Code zu sehr als Black Box nutzt, verlernt unter Umständen das eigenständige Denken im Terminal. Das Beste aus beiden Welten ist es, die Vorschläge als Lerngelegenheit zu sehen – zu verstehen, warum ein Befehl so aussieht wie er aussieht.

Kosten können überraschen. Wer per API abrechnet und in komplexe Debugging-Sitzungen gerät, kann schneller Budget verbrauchen als gedacht. Das monatliche Limit in der Anthropic-Konsole ist deshalb kein Nice-to-have, sondern ein Muss. Wer über ein Abonnement arbeitet, achtet darauf, nicht versehentlich in die API-Abrechnung zu rutschen – ein kurzes /status schafft Klarheit.

Ein Werkzeug, das mich begeistert

Es wäre gelogen zu sagen, Claude Code sei nur ein nützliches Tool. Es ist eines dieser Werkzeuge, die die eigene Arbeitsweise fundamental verändern – wie es damals das erste Mal war, als man grep verstanden hat, oder als der erste Reverse-Proxy lief und man merkte, was hinter einer Domain alles stecken kann.

Die Kombination aus direktem Kontext-Zugang, natürlicher Sprache und tiefem technischen Verständnis macht Claude Code zu einem echten Partner im Maschinenraum des eigenen Servers. Nicht einem, der die Arbeit abnimmt – sondern einem, der einen klüger macht und effizienter handeln lässt.

Für alle, die einen VPS betreiben, Kirby CMS betreuen, Mastodon-Instanzen am Laufen halten oder einfach ihren Server besser verstehen wollen: Das hier ist der Einstieg, der sich lohnt.

Dieser Artikel entstand aus der eigenen Praxis mit Claude Code auf einem Ubuntu-VPS. Die genannten Kosten sind Schätzwerte aus dem tatsächlichen Betrieb und können je nach Nutzungsintensität stark variieren.

Praxisnachwort: Was passiert, wenn Claude Code zu eifrig optimiert

Theorie ist das eine. Was einen wirklich weiter bringt, ist der Moment, in dem etwas schiefläuft – und man versteht warum. Genau so ein Moment hat sich an dem Tag ereignet, an dem Claude Code die nginx-Konfigurationen meiner Domains mit Security-Headern versehen hat.

Der Auftrag klang harmlos: Die HTTP-Response-Header optimieren, moderne Sicherheitsstandards einhalten, Content-Security-Policies setzen. Claude Code hat das gewissenhaft erledigt – und dabei einen klassischen Fehler gemacht, den auch erfahrene Administratoren machen: Es hat jede Config isoliert betrachtet, ohne das Zusammenspiel der Domains zu kennen.

Das Ergebnis war vorhersehbar, sobald man es versteht: Auf der Kirby-Website waren plötzlich alle Kommentare verschwunden. Kein Fehler, kein roter Hinweis – einfach weg. Das Kommentarsystem läuft auf einer eigenen Subdomain (comments.bayerwald.social), und die neue Content-Security-Policy auf der Hauptdomain erlaubte nur noch Ressourcen von 'self'. Der Browser schwieg höflich und lud das Isso-Widget schlicht nicht mehr.

Auf dem Ghost-Blog dasselbe Spiel: Portal, Mitgliederdiskussion, Suche – alles weg. Ghost lädt seine interaktiven Komponenten von cdn.jsdelivr.net, einer externen Domain, die in der neuen script-src nicht aufgeführt war.

Die Diagnose war einfach, sobald man wusste, wo man schauen musste:

curl -s https://meine-domain.de | grep -i "cdn\|script src" | head -20

Dieser eine Befehl zeigt, welche externen Scripts eine Seite lädt – und damit genau, welche Domains in die CSP müssen. Hätte ich diesen Check vor dem Einspielen der neuen Configs gemacht, wäre nichts passiert.

Die Lehre ist nicht, dass Claude Code schlecht arbeitet. Die Lehre ist, dass ein KI-Tool den Kontext kennt, den man ihm gibt – und nicht mehr. Claude Code hat die einzelne Konfigurationsdatei optimiert. Es wusste nicht, dass diese Domain ein Kommentar-Widget von einer anderen Subdomain lädt, dass ein Ghost-Blog auf jsdelivr angewiesen ist, dass OpenCloud und Collabora kreuz und quer miteinander kommunizieren.

Dieses Wissen liegt beim Betreiber. Und das ist auch gut so.

Ein praktisches Protokoll für künftige Header-Optimierungen:

Bevor man eine neue nginx-Config einspielt, die Security-Header enthält, drei schnelle Checks:

# 1. Welche externen Scripts lädt die Seite?
curl -s https://DOMAIN | grep -i "cdn\|jsdelivr\|script src" | head -20

# 2. Gibt es ein Kommentarsystem oder eingebettete Widgets?
curl -s https://DOMAIN | grep -i "comment\|embed\|iframe" | head -10

# 3. Backup der alten Config anlegen
sudo cp /etc/nginx/sites-available/DOMAIN /etc/nginx/sites-available/DOMAIN.bak

Und für komplexe Anwendungen wie Mastodon, OpenCloud oder Nextcloud gilt grundsätzlich: Keine eigene CSP über nginx setzen. Diese Anwendungen verwalten ihre Sicherheitsheader selbst, kennen ihre eigenen Abhängigkeiten und würden durch zusätzliche nginx-Header nur gestört.

Was bleibt, ist ein gutes Gefühl. Nicht weil alles auf Anhieb funktioniert hat – sondern weil das Debugging zielgerichtet war, die Ursachen schnell gefunden wurden und am Ende alle Dienste besser gesichert laufen als vorher. Genau das ist die Qualität, die man sich von einem guten Werkzeug wünscht: nicht Unfehlbarkeit, sondern die Fähigkeit, gemeinsam mit einem aus Fehlern klug zu werden.