KI mit dem Server verbinden: So deployt und verwaltet ein KI-Agent Ihren Server

Die meisten Menschen nutzen KI bisher wie einen sehr belesenen Kollegen am Telefon: Man beschreibt ein Serverproblem, bekommt einen Befehl vorgeschlagen, kopiert ihn in die Konsole, kopiert die Fehlermeldung zurück und wiederholt das Spiel, bis es läuft. Sobald Sie die KI mit Ihrem Server verbinden, fällt dieser Umweg weg. Ein KI-Agent wie Claude Code, OpenAI Codex CLI oder Gemini CLI meldet sich per SSH selbst am Server an, liest die Logs, prüft die Konfiguration, spielt Änderungen ein, testet das Ergebnis und schreibt auf, was er getan hat. Sie geben die Aufgabe vor und genehmigen die Schritte, die sich nicht zurückdrehen lassen.

Dieser Beitrag ist ein Praxisbericht. Bei KernelHost arbeitet seit Monaten ein KI-Agent täglich an unserer eigenen Infrastruktur mit: Kundenportal, Überwachung, Zahlungswege, Dokumentation. Wir zeigen, wie die Verbindung zwischen Agent und Server aufgebaut ist, nach welchem Ablauf der Agent auf Produktivsystemen deployt, welche Regeln verhindern, dass dabei etwas schiefgeht oder etwas nach außen dringt, und was ein Server mitbringen muss, damit das Ganze funktioniert. Die Grundlagen zu Werkzeugen und Architekturen stehen im Beitrag AI Managed Server: KI-Agenten sicher verbinden, die Installation auf dem Server in der Anleitung für Claude Code und Codex CLI.

KI mit dem Server verbinden: Was das bedeutet

Eine KI mit dem Server zu verbinden heißt, einem KI-Agenten einen eigenen, kontrollierten Zugang zur Kommandozeile des Servers zu geben, meist über einen SSH-Schlüssel. Ab diesem Moment kann der Agent Befehle nicht nur vorschlagen, sondern selbst ausführen, die Ausgabe lesen und daraus den nächsten Schritt ableiten. Das Sprachmodell selbst läuft weiterhin beim Anbieter (Anthropic, OpenAI oder Google), auf Ihrem Rechner oder Server läuft nur ein schlankes Kommandozeilenwerkzeug, das die Befehle absetzt.

Entscheidend ist das Wort „kontrolliert". Ein Agent mit Serverzugang ist kein Autopilot, sondern ein sehr schneller Mitarbeiter, der vor jeder eingreifenden Aktion fragt. Wie viel er ohne Rückfrage darf, legen Sie selbst fest: vom reinen Lesezugriff bis zum eigenständigen Einspielen von Updates nach einem festen Ablauf.

Chatbot oder Agent: der Unterschied in einer Tabelle

Aus einer halben Stunde Hin und Her werden so oft wenige Minuten, und die Fehlerquelle „falsch abgetippt" verschwindet ganz.

Was ein KI-Agent auf dem Server erledigt: Beispiele aus unserem Betrieb

Die folgenden Beispiele stammen aus unserem Alltag. Namen, Adressen und Zugangsdaten lassen wir weg, die Abläufe sind echt.

Deployments mit Sicherung und Rückweg

Wenn wir am Kundenportal oder an einem Serverskript etwas ändern, übernimmt der Agent das Einspielen. Er vergleicht zuerst die Datei auf dem Server mit dem letzten bekannten Stand, damit er keine fremde Änderung überschreibt. Dann legt er eine datierte Sicherung außerhalb des Webverzeichnisses an, schreibt ein Rückweg-Skript, prüft die Syntax der neuen Datei, spielt sie mit denselben Eigentümern und Rechten ein wie vorher und testet danach die betroffene Funktion. Erst wenn alles grün ist, meldet er Vollzug. Der genaue Ablauf steht weiter unten im Abschnitt über das Deployen.

Fehlersuche: vom Symptom zur Ursache in Minuten

„Die Website ist von unserem Büro aus nicht erreichbar, von unterwegs schon." Früher hätte das eine längere Suche bedeutet. Der Agent prüft die Firewall-Regeln, durchsucht die Protokolle der Schutzsoftware nach der Büroadresse, findet die Regel, die gegriffen hat, und erklärt, welche Anfrage sie ausgelöst hat. Die Entscheidung, was zu tun ist, bleibt bei uns, die Detektivarbeit nicht. Bei typischen Webserverfehlern wie 502 Bad Gateway oder vollen Festplatten arbeitet er genauso: Er liest mit journalctl und den Anwendungslogs, stellt eine Hypothese auf und belegt sie, bevor er etwas ändert.

Überwachung, die der Agent selbst baut

Ein großer Teil unserer Überwachung ist in Zusammenarbeit mit dem Agenten entstanden: kleine Prüfskripte, die alle paar Minuten per Cronjob einen Dienst Ende zu Ende testen und bei einem Fehler eine Nachricht aufs Handy schicken, etwa über einen Telegram-Bot. Der Agent schreibt das Skript, testet es mit absichtlich ausgelöstem Fehler, richtet den Cronjob ein und dokumentiert, wie man den Alarm stumm schaltet. Wie Sie so etwas grundsätzlich aufbauen, beschreibt der Beitrag Server-Monitoring einrichten.

Übersichten und Aufräumarbeiten

Welche Server laufen noch, obwohl der zugehörige Vertrag gekündigt ist? Welche Zusatzleistungen werden bezahlt, aber nicht mehr genutzt? Solche Fragen beantwortet der Agent, indem er Datenbanken und Schnittstellen nur lesend abfragt und das Ergebnis als Tabelle aufbereitet. Aufräumen darf er erst nach Freigabe, und vorher prüft er, ob die Maschine wirklich ungenutzt ist, zum Beispiel am Datenverkehr der letzten Tage.

Dokumentation, die von selbst mitwächst

Jede Änderung endet mit einem Eintrag im Änderungsprotokoll und, wenn nötig, einer Ergänzung im Betriebshandbuch. Das kostet den Agenten Sekunden und spart uns später Stunden, weil die Frage „Warum ist das eigentlich so?" eine schriftliche Antwort hat.

Die Vorteile, wenn die KI direkt am Server arbeitet

• Tempo: Der Agent liest in Sekunden, wofür ein Mensch Minuten braucht, und probiert eine Hypothese sofort aus, statt sie erst zu beschreiben.
• Gründlichkeit: Er liest die ganze Konfiguration samt eingebundener Dateien und die Logzeilen rund um den Fehler, nicht nur den Ausschnitt, den jemand für relevant hielt.
• Gleichbleibender Ablauf: Sicherung, Syntaxprüfung und Kontrolle laufen jedes Mal, auch am Freitagabend und auch bei der zwanzigsten kleinen Änderung.
• Dokumentation ohne Mehraufwand: Jede Änderung ist beschrieben, samt Grund, Sicherungsort und Rückweg.
• Automatisierung ohne Skriptstudium: Prüfskripte, Cronjobs und Berichte entstehen aus einer Beschreibung in normaler Sprache und werden vor dem Einsatz getestet.
• Lernen nebenbei: Der Agent erklärt, was er tut und warum. Wer mitliest, versteht seinen Server nach ein paar Wochen deutlich besser.

Drei Architekturen und welche wir nutzen

Es gibt drei bewährte Wege, einen Agenten mit einem Server zu verbinden. Sie unterscheiden sich darin, wo das Werkzeug läuft und wo die Zugangsdaten liegen.

Unsere Wahl: Agent auf dem Arbeitsplatz, Server per SSH

Wir arbeiten mit der ersten Variante. Der Agent läuft auf dem Arbeitsrechner, jeder Server hat einen Eintrag in der SSH-Konfiguration, und der Agent verbindet sich mit einem eigenen Schlüssel. Der wichtigste Grund: Wir betreuen viele Systeme, und genau so kann ein einziger Agent in einer Sitzung eine Ursache über mehrere Server hinweg verfolgen, etwa vom Webserver über die Datenbank bis zur Firewall. Außerdem liegen die Anmeldung beim KI-Anbieter und die Schlüssel an einem Ort, den wir ohnehin schützen. Wer nur einen Server hat und nachts automatische Berichte möchte, fährt mit der zweiten Variante gut. Mehr zu den Vor- und Nachteilen steht im Beitrag über AI Managed Server.

Anleitung: KI-Agent per SSH mit dem Server verbinden

Die folgenden sieben Schritte funktionieren mit Claude Code, Codex CLI und Gemini CLI gleichermaßen. Die Beispiele nutzen die Dokumentationsadresse 203.0.113.10 und den Benutzernamen deploy, ersetzen Sie beides durch Ihre Werte. Voraussetzung ist ein Server mit SSH-Schlüssel-Anmeldung, wie im Beitrag SSH absichern und Key-Login einrichten beschrieben.

Schritt 1: Einen eigenen SSH-Schlüssel nur für den Agenten erzeugen

Der Agent bekommt nie Ihren persönlichen Schlüssel, sondern einen eigenen. So können Sie ihm den Zugang jederzeit entziehen, ohne Ihren eigenen zu verlieren, und in den Logs ist erkennbar, welche Anmeldung vom Agenten kam.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 ist kurz, schnell und gilt als sicher. Der Kommentar ki-agent erscheint später in der authorized_keys des Servers und macht den Schlüssel auf einen Blick erkennbar.

Schritt 2: Den öffentlichen Schlüssel auf dem Server hinterlegen

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Wer den Zugang weiter eingrenzen will, ergänzt in der Datei ~/.ssh/authorized_keys auf dem Server Optionen vor dem Schlüssel. from= erlaubt die Anmeldung nur von einer bestimmten Adresse, no-agent-forwarding und no-port-forwarding verhindern, dass die Verbindung als Sprungbrett dient:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Meldet der Server danach Permission denied (publickey), hilft der Beitrag SSH Permission denied (publickey) beheben.

Schritt 3: Einen Host-Alias in der SSH-Konfiguration anlegen

Ein Alias sorgt dafür, dass der Agent nur einen kurzen Namen kennen muss und immer den richtigen Schlüssel benutzt:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

Danach genügt ssh web-prod "systemctl status nginx". IdentitiesOnly yes verhindert, dass SSH andere Schlüssel aus Ihrem Schlüsselbund durchprobiert. Für jeden weiteren Server legen Sie einen eigenen Block an, für Test- und Produktivsysteme am besten mit unterschiedlichen Namen wie web-test und web-prod, damit eine Verwechslung schon am Namen auffällt.

Schritt 4: Den Agenten installieren und anmelden

Claude Code, Codex CLI und Gemini CLI laufen auf Linux, macOS und Windows und werden mit einem Konto des Anbieters oder einem API-Schlüssel angemeldet. Die Installation und die Anmeldung ohne Browser sind in der Schritt-für-Schritt-Anleitung beschrieben. Für die Arbeitsplatz-Variante installieren Sie das Werkzeug auf Ihrem Rechner, nicht auf dem Server.

Schritt 5: Regeln festlegen, an die sich der Agent hält

Alle drei Werkzeuge lesen beim Start eine Regeldatei im Arbeitsverzeichnis: Claude Code die CLAUDE.md, Codex CLI die AGENTS.md, Gemini CLI die GEMINI.md. Dort steht, wie auf Ihren Servern gearbeitet wird. Ein erprobter Anfang:

# Regeln für die Arbeit auf Servern

- Vor jeder Änderung eine datierte Sicherung anlegen, außerhalb des Webverzeichnisses.
- Vor dem Einspielen die Syntax prüfen (nginx -t, php -l, apachectl configtest).
- Nach dem Einspielen Dienst, Log und Funktion prüfen und das Ergebnis melden.
- Passwörter, API-Schlüssel und Tokens nie ausgeben, nie in Dateien kopieren.
- Löschen, Datenbankänderungen und alles Unumkehrbare nur nach ausdrücklicher Freigabe.
- Dateien, die das Control Panel verwaltet, nicht direkt ändern.
- Testdateien nach dem Test wieder entfernen.

Die Regeln wachsen mit. Jedes Mal, wenn der Agent etwas anders macht, als Sie es wollen, gehört die Korrektur als Regel in diese Datei. Nach ein paar Wochen arbeitet er so, wie Sie selbst arbeiten würden.

Schritt 6: Freigaben und Allowlist einstellen

Standardmäßig fragen die Werkzeuge vor jedem Befehl, der etwas verändert. Das ist am Anfang richtig. Lesende Befehle, die Sie ständig bestätigen, können Sie freigeben. In Claude Code geschieht das in der Datei .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Alles, was nicht auf dieser Liste steht, braucht weiterhin Ihre Zustimmung. Schalter, die sämtliche Rückfragen abschalten, gehören höchstens auf eine Wegwerf-Testmaschine.

Schritt 7: Die erste Aufgabe: nur lesen

Beginnen Sie mit Aufgaben, die nichts verändern können, und beobachten Sie, wie der Agent vorgeht:

Prüfe auf web-prod die nginx-Fehler der letzten 24 Stunden und nenne die drei
häufigsten Ursachen mit je einem Beleg aus dem Log. Ändere nichts.

Erst wenn die Analysen stimmen, folgen kleine Änderungen, etwa eine neue Logrotation oder ein systemd-Service, und erst danach Deployments auf dem Produktivsystem.

So deployt der Agent: unser Ablauf für jede Änderung am Produktivsystem

Ein KI-Agent darf auf einem Produktivsystem nur nach einem festen Ablauf deployen, der eine Sicherung, einen vorbereiteten Rückweg und eine Prüfung vor und nach dem Einspielen enthält. Bei uns sieht dieser Ablauf so aus:

1. Ist-Stand prüfen. Die Datei auf dem Server wird mit dem letzten bekannten Stand verglichen. Hat sie inzwischen jemand anderes geändert, bricht der Agent ab und fragt nach, statt die fremde Änderung zu überschreiben.
2. Sicherung anlegen. Die betroffenen Dateien landen mit Datum in einem Sicherungsordner außerhalb des Webverzeichnisses. Eine Sicherung im Webverzeichnis wäre unter Umständen öffentlich abrufbar.
3. Rückweg vorbereiten. Ein kleines Skript, das den alten Stand mit einem einzigen Befehl zurückspielt, entsteht vor der Änderung, nicht erst im Notfall.
4. Syntax prüfen. Die neue Datei wird vor dem Einspielen geprüft, bei PHP mit php -l, bei nginx mit nginx -t. Ein Syntaxfehler erreicht das Produktivsystem so gar nicht erst.
5. Mit den richtigen Rechten einspielen. Eigentümer, Gruppe und Dateirechte werden vom alten Stand übernommen. Falsche Rechte sind nach Syntaxfehlern die häufigste Ursache für Ausfälle nach einem Update.
6. Ohne Nebenwirkungen testen. Getestet wird lesend, mit erfundenen Testdaten oder in einer abgeschotteten Umgebung, niemals mit echten Bestellungen oder echten Kundendaten.
7. Live prüfen. HTTP-Status, Fehlerlog und die geänderte Funktion werden nach dem Einspielen kontrolliert.
8. Dokumentieren. Änderungsprotokoll und Betriebshandbuch werden ergänzt, samt Ort der Sicherung und Befehl für den Rückweg.

Als Befehlsfolge, mit Platzhaltern statt echter Pfade, sieht das etwa so aus:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Warum der Rückweg vor der Änderung entsteht

Im Fehlerfall ist niemand in der besten Verfassung, einen sauberen Rückweg zu überlegen. Liegt das Skript schon bereit, ist die Rücknahme eine Sache von Sekunden, und der Agent kann sie auch selbst ausführen, wenn die Prüfung nach dem Einspielen fehlschlägt. Das ist der größte Unterschied zwischen einem Agenten, der „mal eben" etwas ändert, und einem, dem man ein Produktivsystem anvertraut.

Tests, die nichts kaputt machen können

Viele Funktionen lassen sich nicht testen, ohne dass etwas passiert: eine Bestellung, eine Zahlung, eine E-Mail. Hier helfen drei Techniken. Erstens Trockenläufe, die das Werkzeug selbst anbietet. Zweitens erfundene Kennungen, die garantiert nirgends existieren. Drittens eine abgeschottete Umgebung: Ein Prozess, der in einem eigenen Netz-Namensraum ohne Netzwerk läuft (unshare -n), kann weder eine externe Schnittstelle erreichen noch versehentlich etwas kaufen, sieht aber weiterhin die lokale Datenbank über den Unix-Socket. Nach dem Test werden alle Testdateien wieder entfernt.

Aktionen, die Geld kosten, brauchen eine Sperre

Wenn ein Ablauf etwas bestellt, abrechnet oder löscht, darf er nicht zweimal gleichzeitig laufen, auch nicht, wenn jemand doppelt klickt oder der Agent einen Befehl wiederholt. Die einfachste Lösung auf Linux ist flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "läuft bereits"

Bei Datenbankanwendungen erfüllt eine benannte Sperre (GET_LOCK in MySQL und MariaDB) denselben Zweck, bei Schnittstellen ein Idempotency-Key, dazu mehr bei der KernelHost API weiter unten.

Sicherheit: Zugang für den Agenten, ohne dass etwas durchsickert

Die Sorge, die wir am häufigsten hören, lautet: „Und was ist mit meinen Daten?" Die ehrliche Antwort: Alles, was der Agent liest, schickt er zur Verarbeitung an das Sprachmodell des Anbieters. Deshalb entscheiden Sie mit den folgenden Regeln, was er überhaupt zu sehen bekommt.

Geheimnisse gehören nicht in den Chat

Passwörter, API-Schlüssel und Tokens werden nie in eine Aufgabe geschrieben und nie vom Agenten ausgegeben. Skripte lesen sie aus Dateien mit Rechten 600, die der Agent nicht anzeigen muss, um das Skript zu benutzen. Landet trotzdem einmal ein Schlüssel im Chat, wird er sofort beim Anbieter gesperrt und neu erzeugt. Auch Bruchstücke gehören nicht in den Chat: Die ersten Zeichen eines Schlüssels helfen niemandem bei der Fehlersuche, verkürzen aber die Arbeit eines Angreifers.

Eigene Schlüssel, eigene Rechte, jederzeit widerrufbar

Jeder Agent bekommt einen eigenen SSH-Schlüssel, und jeder Schlüssel ist in der authorized_keys an seinem Kommentar erkennbar. Wer den Zugang entziehen will, löscht die eine Zeile. Wo es reicht, arbeitet der Agent mit einem eigenen Benutzer und einer sudo-Regel, die nur die nötigen Befehle erlaubt. Programmierschnittstellen bekommen eigene Schlüssel mit den kleinstmöglichen Rechten, für reine Auswertungen nur lesend.

Freigaben: was nie ohne Mensch passiert

Ohne ausdrückliche Zustimmung darf der Agent bei uns nicht löschen, nicht in Datenbanken schreiben, keine Firewall- oder Schutzregeln lockern, keine Maschinen stoppen und nichts bestellen. Die Werkzeuge unterstützen das: Claude Code hält eingreifende Aktionen an und lässt sich zusätzlich so einstellen, dass ein Sicherheitsfilter riskante Befehle erkennt und bis zur Freigabe blockiert. Aus unserem Alltag: Dieser Filter hat mehr als einmal eine Aktion angehalten, die fachlich richtig war, aber eben unumkehrbar. Sie lief erst, nachdem ein Mensch sie ausdrücklich freigegeben hatte. Genau so soll es sein.

Nachvollziehbarkeit: Protokoll, Änderungsliste, Sicherungen

Jede Sitzung hinterlässt Spuren, die ein Mensch lesen kann: die Sicherungen mit Datum, das Rückweg-Skript, den Eintrag im Änderungsprotokoll und die Anmeldungen im Systemlog. Wer /etc zusätzlich mit etckeeper in Git verwaltet, sieht jede Konfigurationsänderung als Diff. Was nicht nachvollziehbar ist, lässt sich auch nicht zurückdrehen. Die Grundlage bleibt eine funktionierende Backup-Strategie, denn ein Agent ersetzt keine Sicherung.

Welcher Server eignet sich für einen KI-Agenten?

Ein Server für KI-gestützte Verwaltung braucht vollen Root-Zugriff, SSH-Schlüssel-Anmeldung, ungehinderte ausgehende Verbindungen, einen dauerhaften DDoS-Schutz und idealerweise eine Programmierschnittstelle, über die sich Server automatisiert bestellen und steuern lassen. Eine GPU braucht er nicht, denn das Sprachmodell läuft beim Anbieter.

Warum KernelHost für KI-verwaltete Server

Grundsätzlich kann ein KI-Agent mit jedem Server arbeiten, auf dem er eine Shell bekommt. In der Praxis entscheidet aber das Umfeld darüber, wie viel Arbeit Sie ihm wirklich übergeben können. Auf einem KVM-Rootserver oder Dedicated Server von KernelHost gibt es keine eingeschränkten Konten, keine Hürden für die HTTPS-Verbindungen zu den KI-Anbietern und keine Vertragsbindung, die das Ausprobieren teuer macht. Der DDoS-Dauerschutz ist bei jedem Server ohne Aufpreis aktiv, und für rechenintensive Aufgaben gibt es Professional-Rootserver mit dedizierten Kernen. Abgerechnet wird PrePaid: kein Vertrag, keine Mindestlaufzeit, keine Einrichtungsgebühr. Wer zuerst probieren will, beginnt mit dem kostenlosen Testserver.

Die KernelHost API: Ihr Agent bestellt und steuert Server selbst

Der größte Hebel liegt eine Ebene über dem einzelnen Server. Über die KernelHost API kann ein Agent Produkte und Preise abfragen, Server bestellen, den Status seiner Dienste lesen, Server starten, stoppen und neu starten sowie Kündigungen auslösen und zurücknehmen. Damit wird aus „Richte mir einen Testserver ein" eine einzige Aufgabe: Der Agent bestellt die Maschine, wartet auf die Bereitstellung, verbindet sich per SSH, installiert die Anwendung und meldet die Adresse zurück.

Für den Einsatz durch Agenten ist die Schnittstelle bewusst vorsichtig gebaut. API-Schlüssel bekommen nur die Rechte, die sie brauchen, ein Schlüssel für Auswertungen kann gar nichts bestellen. Ein Idempotency-Key sorgt dafür, dass eine Bestellung, die der Agent nach einem Zeitüberschreitungsfehler wiederholt, nicht doppelt ausgeführt wird. Anfragen sind pro Schlüssel, pro Konto und pro Adresse begrenzt, sodass auch ein Agent in einer Endlosschleife keine Lawine auslöst. Und jeder Abruf von Zugangsdaten löst eine Benachrichtigung per E-Mail aus, damit Sie sehen, wann ein Agent Zugangsdaten gelesen hat.

Was kostet ein KI-verwalteter Server?

Es fallen zwei Posten an. Erstens der Server selbst: Für einen Agenten, der per SSH arbeitet, braucht er keine besondere Ausstattung, jeder Rootserver genügt, auf dem Ihre Anwendung ohnehin läuft. Läuft der Agent direkt auf dem Server, braucht das Werkzeug selbst nur wenige hundert Megabyte Arbeitsspeicher, ein Rootserver mit 2 vCPU und 4 GB RAM reicht, wenn sonst wenig darauf läuft. Zweitens das Sprachmodell: entweder ein Abo des Anbieters, das die Nutzung des Kommandozeilenwerkzeugs einschließt, oder ein API-Schlüssel mit Abrechnung nach Verbrauch. Bei täglicher intensiver Nutzung ist das Abo meist günstiger, für automatisierte Aufgaben ohne Menschen davor ist der API-Schlüssel der saubere Weg, weil er sich mit einem Monatsbudget deckeln lässt. Die aktuellen Serverpreise finden Sie auf der Seite Rootserver mieten.

Häufige Fehler und wie Sie sie vermeiden

• Der Agent arbeitet mit dem persönlichen Schlüssel des Administrators. Dann lässt sich sein Zugang nicht getrennt entziehen und in den Logs nicht unterscheiden. Lösung: eigener Schlüssel mit eigenem Kommentar.
• Alle Rückfragen sind abgeschaltet. Das spart am ersten Tag Klicks und kostet irgendwann einen Server. Lösung: Allowlist für lesende Befehle, Freigabe für alles Eingreifende.
• Keine Sicherung vor der Änderung. Lösung: Sicherung und Rückweg-Skript als feste Regel in der CLAUDE.md oder AGENTS.md.
• Sicherungen im Webverzeichnis. Eine Datei wie config.php.bak im Webroot kann öffentlich abrufbar sein, samt Datenbankpasswort. Lösung: Sicherungsordner außerhalb des Webverzeichnisses mit Rechten 700.
• Geheimnisse im Prompt. Lösung: Zugangsdaten nur in Dateien mit Rechten 600, die Skripte lesen, und bei einem Versehen sofort neu erzeugen.
• Doppelte Ausführung. Ein doppelter Klick oder eine wiederholte Anfrage bestellt zweimal. Lösung: Sperre mit flock oder Idempotency-Key.
• Vom Control Panel verwaltete Dateien direkt geändert. Das Panel überschreibt sie beim nächsten Update oder bricht daran. Lösung: Solche Dateien in den Regeln ausschließen und Änderungen über das Panel oder dessen Schnittstelle machen.
• Ausgaben ungeprüft übernommen. Ein Agent, der eine Ausgabe nicht versteht, rät. Lösung: Belege verlangen („zeig mir die Logzeile") und Ergebnisse live prüfen lassen.

Kurz zusammengefasst

• Eine KI mit dem Server zu verbinden heißt, einem Agenten wie Claude Code, Codex CLI oder Gemini CLI einen eigenen SSH-Schlüssel und klare Regeln zu geben.
• Der Agent liest Logs, spielt Änderungen ein, prüft das Ergebnis und dokumentiert es, eingreifende Schritte laufen nur mit Freigabe.
• Jedes Deployment folgt einem festen Ablauf: Ist-Stand prüfen, sichern, Rückweg vorbereiten, Syntax prüfen, einspielen, testen, live prüfen, dokumentieren.
• Geheimnisse gehören nie in den Chat, und Aktionen, die Geld kosten, brauchen eine Sperre gegen doppelte Ausführung.
• Der Server braucht Root-Zugriff, SSH-Schlüssel, freie ausgehende Verbindungen und DDoS-Schutz, aber keine GPU.
• KernelHost-Server erfüllen alle Anforderungen ab Werk, PrePaid ohne Vertragsbindung, und über die KernelHost API kann der Agent Server sogar selbst bestellen und steuern.