Claude Code auf dem eigenen Server betreiben

Zwei Wege, und sie lösen unterschiedliche Probleme

Weg 1: Du installierst Claude Code auf deinem VPS und arbeitest per SSH damit. Der Code liegt auf deinem Server, die Builds laufen dort, du erreichst interne Dienste. Funktioniert mit jedem Claude-Plan.

Weg 2: Self-hosted Environments. Damit laufen die Cloud-Sessions, die du sonst im Browser, in der Mobile- oder Desktop-App startest, auf deinen Maschinen statt auf denen von Anthropic. Das gibt es seit Version 2.1.224 vom 7. August 2026, als Public Beta für Team- und Enterprise-Pläne.

Wenn du allein oder im kleinen Team arbeitest, ist Weg 1 fast immer der richtige.

Weg 1: Claude Code auf deinem VPS installieren

Was dein Server dafür braucht

Ein schlanker Linux-VPS reicht. Claude Code selbst zieht wenig Ressourcen — was wirklich Leistung braucht, sind deine Builds, Tests und Container. Du brauchst SSH-Zugang mit Root-Rechten und Git auf dem System.

Ein klassisches Webhosting-Paket funktioniert nicht. Ohne Shell-Zugang lässt sich kein CLI-Tool installieren.

Die Einrichtung

Installiere Claude Code über einen der offiziellen Wege — den nativen Installer, Homebrew oder die apt-, dnf- beziehungsweise apk-Repositories. Der native Installer liefert im Kanal latest jede Version sofort aus; stable, der Homebrew-Cask und die stabilen Paketquellen hinken rund eine Woche hinterher. Für Produktivsysteme ist das eher ein Vorteil.

Danach meldest du dich mit claude auth login an. Mit claude --version prüfst du, welche Version läuft, claude doctor meldet Probleme mit der Umgebung.

Ein Punkt, über den fast jeder einmal stolpert: Sobald du die SSH-Verbindung trennst, ist deine Session weg. Starte Claude Code deshalb in tmux oder screen. Dann läuft die Sitzung weiter, auch wenn dein Notebook zuklappt.

Für Skripte und Cronjobs gibt es den nicht-interaktiven Modus:

claude -p "führe die Testsuite aus und fasse die Fehler zusammen"

Session vom Handy weitersteuern

Remote Control ist der Teil, den viele übersehen. Damit steuerst du eine Session, die auf deinem eigenen Server läuft, vom Browser oder vom Handy aus weiter. Der Prozess bleibt auf deiner Maschine — du bekommst nur eine zweite Oberfläche dazu.

Für einen VPS ist das praktisch: Du startest morgens einen längeren Refactoring-Lauf, gehst aus dem Haus und schaust unterwegs nach, wo er steht.

Weg 2: Self-hosted Environments

Was dabei passiert

Du legst im Admin-Bereich von claude.ai eine Environment an — ein benanntes Ziel, an das Sessions geschickt werden. Auf deinem Server startest du einen Runner: einen dauerhaft laufenden Prozess, der sich bei dieser Environment registriert und auf Arbeit wartet. Startet jemand eine Session und wählt deine Environment aus, holt der Runner sie und startet einen Claude-Code-Prozess dafür.

Wer schon einmal einen Self-hosted Runner für GitHub Actions aufgesetzt hat, kennt das Muster.

Voraussetzungen

Auf der claude.ai-Seite muss ein Owner oder Admin auf der Admin-Seite Cloud environments die Option „Allow self-hosted environments" aktivieren. Vorher erscheint der New-Button gar nicht erst. Claude Code on the web muss ebenfalls aktiv sein.

Auf dem Host brauchst du:

• Linux oder macOS, direkt oder im Container. Windows geht nicht als Runner-Host — dort läuft der Runner in einem Linux-Container.
• Claude Code ab 2.1.224. Ältere Versionen kennen den Unterbefehl self-hosted-runner nicht.
• Git 2.24 oder neuer.
• Ausgehendes HTTPS zu api.anthropic.com, zu claude.ai und zu deinem Git-Host.
• Eine per NTP synchronisierte Uhr. Weicht sie mehr als fünf Minuten ab, scheitert die Authentifizierung.

Ob der Host bereit ist, prüfst du so:

claude self-hosted-runner --help

Kommt statt der Runner-Hilfe die allgemeine claude --help-Ausgabe, ist die Version zu alt.

Das Setup

Es gibt einen geführten Weg über claude self-hosted-runner setup — eine interaktive Session, die dich durch die Anlage der Environment führt und am Ende einen Spickzettel schreibt. Auf Hosts ohne interaktive Sitzung geht es manuell:

claude self-hosted-runner \
  --environment-secret-file '/etc/claude/environment-secret' \
  --base-dir '/dein/schreibbarer/pfad'

Das Environment-Secret bekommst du beim Anlegen der Environment genau einmal zu sehen. Speichere es sofort, danach lässt es sich nicht mehr abrufen. Es läuft 365 Tage nach der Erstellung ab.

Ohne --base-dir nutzt der Runner /workspace. Das klappt nur, wenn das Verzeichnis existiert und beschreibbar ist. Kann der Runner den Pfad nicht anlegen, beendet er sich beim Start mit einer Fehlermeldung, statt sich zu registrieren.

Im Admin-Bereich springt der Status innerhalb weniger Sekunden von „No runners deployed" auf „Healthy".

Was du dabei einplanen musst

Ein Runner bedient immer nur einen Nutzer. Beim ersten Session-Claim bindet er sich an dessen Konto, damit ausgecheckter Code nicht zwischen Nutzern vermischt wird. Für ein Team heißt das: Du planst nicht ob, sondern wie viele Runner.

Außerdem beendet sich ein Runner, sobald seine aktiven Sessions durch sind. Produktiv läuft er deshalb unter einem Orchestrator — Kubernetes oder Compose —, der ihn neu startet. Alternativ betreibst du den Autoscaling-Orchestrator von Anthropic, der Runner hochfährt, wenn Sessions in der Warteschlange stehen.

Anthropic selbst schreibt dazu deutlich, dass die gehostete Variante für die meisten Teams die bessere Wahl ist. Self-hosted lohnt sich, wenn Netzwerk, Tooling oder Compliance-Vorgaben es verlangen.

Seit Version 2.1.238 vom 20. August 2026 sind zwei Flags dazugekommen, die im Betrieb helfen: --defer-shutdown-max-min hält bei SIGTERM laufende Sessions noch eine definierte Zeit am Leben, und --proxy-authorization-command beziehungsweise --proxy-authorization-file bedienen Egress-Proxys, die bei jeder Verbindung einen frischen Proxy-Authorization-Header verlangen.

Was die Beta noch nicht kann

Organisationen mit einer Zero-Data-Retention-Vereinbarung können Self-hosted Environments nicht nutzen. Und Inference lässt sich bei self-gehosteten Sessions nicht über Bedrock, Google Cloud, Microsoft Foundry oder ein LLM-Gateway leiten — sie geht direkt an die Anthropic-API.

Was dabei nicht auf deinem Server läuft

Das ist der Punkt, an dem die meisten Artikel zu diesem Thema unsauber werden.

Self-hosting bedeutet hier: Die Ausführung wandert auf deine Infrastruktur. Repository-Checkouts, Build-Artefakte, Secrets, gelesene und geschriebene Dateien, ausgeführte Shell-Befehle — das alles bleibt bei dir.

Das Modell wandert nicht mit. Prompts, Antworten und Tool-Ergebnisse gehen weiterhin per HTTPS an die Anthropic-API. Wer ein Sprachmodell auf eigener Hardware betreiben will, braucht ein offenes Modell und passende GPUs. Das ist ein anderes Projekt.

Claude Code mit deinen eigenen Systemen verbinden

Ein Server bringt dir vor allem dann etwas, wenn Claude Code dort auch an etwas herankommt. Genau dafür gibt es MCP-Server.

MCP steht für Model Context Protocol — ein offener Standard, über den ein KI-Modell auf externe Daten und Funktionen zugreift. Statt für jedes Tool eine eigene Anbindung zu bauen, sprechen beide Seiten dieselbe Sprache. Praktisch heißt das: Du gibst Claude Code kontrollierten Zugriff auf deine Datenbank, dein Ticketsystem oder ein internes Repository, ohne Zugangsdaten in den Prompt zu schreiben.

Claude Code bringt die Verwaltung mit. Mit claude mcp list siehst du, welche Server konfiguriert sind, /mcp zeigt den Status während einer Session. Projektbezogene Server hinterlegst du in einer .mcp.json im Repository — das Verzeichnis muss dafür als vertrauenswürdig bestätigt sein.

Auf einem eigenen Server ergibt das besonders Sinn: Ein MCP-Server, der eine interne Datenbank anbindet, muss nicht ins öffentliche Netz. Er läuft neben Claude Code auf derselben Maschine oder im selben Netz. Wenn du tiefer einsteigen willst, haben wir MCP-Server ausführlich erklärt — inklusive der Frage, was der dauerhafte Betrieb voraussetzt.

Ein Hinweis zur Sorgfalt: Ein MCP-Server ist eine Zugriffsschnittstelle. Gib ihm nur die Rechte, die er wirklich braucht — Lesezugriff, wo Lesen reicht.

Welche Variante passt zu dir

Sicherheit: worauf du achten solltest

Ein Agent mit Shell-Zugriff auf deinem Server verdient etwas Sorgfalt:

Lege Secret-Dateien so an, dass nur der Besitzer sie lesen kann — umask 077 beim Schreiben oder chmod 600 danach. Lass Claude Code nicht als root laufen, sondern unter einem eigenen Nutzer mit genau den Rechten, die er braucht. Halte SSH auf Key-Authentifizierung statt Passwort. Und richte Backups ein, bevor du einen Agenten auf ein Repository loslässt, nicht danach.

Ein separater Server für diese Experimente ist die einfachere Lösung, als ein Produktivsystem abzusichern.

Häufige Fragen

Kann ich Claude Code auf einem Webhosting-Paket installieren?

Nein. Claude Code ist ein Kommandozeilen-Werkzeug und braucht SSH-Zugang mit Root-Rechten. Ein Webhosting-Tarif bietet das nicht. Dafür brauchst du einen VPS oder einen dedizierten Server.

Läuft das KI-Modell dann auf meinem Server?

Nein. Auch bei Self-hosted Environments geht die Modell-Anfrage an api.anthropic.com. Auf deinem Server läuft die Ausführung: Datei-Zugriffe, Shell-Befehle, Builds.

Welches Betriebssystem braucht der Runner?

Linux oder macOS, direkt auf dem Host oder im Container. Windows wird als Runner-Host nicht unterstützt — dort betreibst du den Runner in einem Linux-Container. Für Entwickler-Arbeitsplätze spielt das keine Rolle, weil Sessions ohnehin im Browser starten.

Was passiert, wenn mein Server neu startet?

Bei Weg 1 startest du deine Session neu — nutze tmux oder screen, damit sie nicht schon beim Trennen der SSH-Verbindung endet. Bei Self-hosted Environments beendet sich der Runner ohnehin, sobald seine Sessions fertig sind. Deshalb läuft er produktiv unter einem Orchestrator, der ihn neu startet.

Brauche ich für Self-hosted Environments einen bestimmten Plan?

Ja. Das Feature ist Public Beta für Team- und Enterprise-Organisationen, standardmäßig deaktiviert. Ein Owner oder Admin muss es erst freischalten. Organisationen mit Zero-Data-Retention-Vereinbarung sind ausgeschlossen.