DeepSeek Harness sicher auf einem VPS betreiben

Was das DeepSeek Harness ist

Das DeepSeek Harness (dsh) ist eine Node.js-Agent-Laufzeitumgebung, die Sie auf einem VPS (virtual private server) ausführen können. Sicher ist der Betrieb, wenn sie an 127.0.0.1 gebunden ist und Ihr Browser über einen SSH-Tunnel (secure shell) darauf zugreift. Die Laufzeitumgebung stellt auf Port 3080 eine Weboberfläche (user interface) bereit, statt ausschließlich in einem Terminal zu laufen. Der Webserver verlangt selbst kein Passwort. Ein veröffentlichter Port 3080 stellt daher jedem, der ihn findet, einen Agenten bereit, der Ihre Dateien liest und Befehle unter Ihrem Linux-Benutzer ausführt.

DeepSeek hat die Software am 13. August 2026 unter der MIT-Lizenz als npm-Paket @deepseek-ai/dsh veröffentlicht. Das Projekt bezeichnet sich selbst als Entwicklervorschau und weist darauf hin, dass inkompatible Änderungen zu erwarten sind. Jede unten angegebene Versionsnummer entspricht dem Stand von August 2026. Prüfen Sie daher das Repository, bevor Sie die Angaben auf einem wichtigen System verwenden.

Ein Gedanke zieht sich durch das gesamte Design: Alles ist ein Plugin. Der Modelladapter, die Tool-Registry, das Sitzungsprotokoll, die Sandbox, der Scheduler und die Agentenschleife selbst sind Plugins, die in einen gemeinsamen Kontext geladen werden. Jedes dieser Plugins kann ersetzt werden. Es gibt keinen privilegierten Kern, den Plugins lediglich erweitern. Das macht den Harness einen Versuch wert. Gleichzeitig liegt genau darin das einzige echte Risiko. Ob dieser Kompromiss sinnvoll ist, hängt davon ab, womit Sie ihn vergleichen. Der Vergleich mit Claude Code und Omnigent stellt das Plugin-für-alles-Design zwei anderen Ansätzen gegenüber: bei der Modellkopplung, der Lizenz und dem Umfang des VPS, den jeder Ansatz benötigt.

Ein Harness ist kein Modell

Das Harness führt die Agentenschleife aus. Die Verarbeitung findet in einem Modell an anderer Stelle statt. Daher funktioniert nichts, bis Sie entweder einen API-Schlüssel (application programming interface) oder die Adresse eines von Ihnen selbst betriebenen Modellendpunkts hinterlegen. Alles in diesem Beitrag betrifft die Harness-Konfiguration und nicht das Modellverhalten. Sie sollten die Grenze zwischen beiden klären, bevor Sie einen Nachmittag damit verbringen, herauszufinden, auf welcher Seite ein Problem entstanden ist.

Sie konfigurieren dies in der Benutzeroberfläche unter Settings und anschließend unter Models. Der Katalog enthält fertige Karten für die großen API-Anbieter (DeepSeek, OpenAI, Anthropic), in die Sie einen Schlüssel einfügen. Die interessante Option ist „Add a custom provider“. Sie benötigt eine Provider-ID, einen Anzeigenamen, eine Basis-URL, ein API-Protokoll und ein Zugangsdatenobjekt. Sie verwendet das OpenAI-kompatible Protokoll. Daher funktioniert jeder Gateway oder lokale Server, der dieses Protokoll implementiert. Benutzerdefinierte Provider können außerdem den OpenAI-kompatiblen GET /models-Endpunkt abfragen, um die Modellliste automatisch auszufüllen.

So verbinden Sie das Harness mit einem Modell auf demselben VPS. Ollama stellt unter http://127.0.0.1:11434/v1/ eine OpenAI-kompatible API bereit. Im Feld für den API-Schlüssel muss ein beliebiger String stehen, üblicherweise ollama. Das Feld ist erforderlich, wird anschließend aber ignoriert. Ob ein Modell, das klein genug für Ihren VPS ist, einen Agenten ausreichend gut steuern kann, ist die schwierigere Frage. Der Unterschied zwischen Ollama und vLLM als lokalem Modellserver bestimmt, wie viel RAM die Antwort benötigt.

In die Benutzeroberfläche eingegebene Schlüssel können nur geschrieben, nicht gelesen werden. Das Harness speichert sie in $DSH_HOME/.credentials.yaml und hinterlegt in settings.yaml nur eine Referenz auf die Zugangsdaten. $DSH_HOME verwendet standardmäßig ~/.dsh. Behandeln Sie diese Datei wie eine Passwortdatei, denn genau das ist sie: Jeder, der sie lesen kann, kann Ihr API-Budget verbrauchen. Wenn Sie diese Dateien direkt bearbeiten möchten, statt durch Settings zu navigieren, zeigt die Anleitung zu dsh-Konfigurationsdateien, Schlüsseln und Modellendpunkten, welche Funktion jeder Schlüssel hat und welche Daten Ihr System in den einzelnen Modi verlassen.

Voraussetzungen für die Installation

• ein VPS mit Ubuntu 24.04 oder einem anderen aktuellen Linux-System und SSH-Zugriff
• Node.js 22.19 oder neuer aus der 22.x-Reihe oder Node.js 24 oder höher, da das Projekt gegen diese Versionen erstellt und getestet wird
• ein normales Benutzerkonto, nicht root, da der Agent Shell-Befehle mit den Berechtigungen des Benutzers ausführt, der den Prozess gestartet hat
• pnpm im PATH, wenn Sie Plugins installieren möchten, da der Plugin-Befehl dieses Programm als Unterprozess aufruft
• Port 3080 in Ihrer Firewall und in der separaten Netzwerk-Firewall Ihres Providers geschlossen

Das Ubuntu-eigene nodejs-Paket ist älter als für die Harness-Umgebung erforderlich. Installieren Sie Node daher über NodeSource oder nvm, statt apt install nodejs zu verwenden. Wenn der VPS frisch eingerichtet ist, lohnt es sich, SSH zuerst abzusichern, da der Tunnel, von dem Sie gleich abhängig sind, nur so zuverlässig ist wie der dahinterliegende SSH-Server.

DeepSeek Harness auf einem VPS installieren und auf eine Version festlegen

node --version
npx @deepseek-ai/dsh@0.1.0-rc.6 web

npx lädt das Paket herunter und führt dessen dsh-Binärdatei aus. web ist ein Alias für --profile web. Damit wird die Browseranwendung gestartet, und der Prozess gibt die Adresse aus, auf der er Verbindungen entgegennimmt. Der Standardwert ist http://127.0.0.1:3080. Diese Zahlen sind eine verbindliche Festlegung und kein rein kosmetischer Standardwert. Warum dsh eine Loopback-Adresse ausgibt erklärt, welche Anfragen das Harness beantwortet und welche nicht, bevor Sie es von Ihrem Laptop aus suchen.

Legen Sie die Version fest. npx @deepseek-ai/dsh web löst bei jeder Ausführung auf, worauf das Tag latest zu diesem Zeitpunkt zeigt. Das Projekt hat bereits mehrere Release Candidates veröffentlicht und kündigt inkompatible Änderungen an. 0.1.0-rc.6 bezeichnet den Stand, auf den latest am 13. August 2026 zeigte. Mit einer festgelegten Version verhält sich der eingerichtete Server auch im nächsten Monat gleich. Ein Upgrade wird dadurch zu einer bewussten Entscheidung und nicht zu einem Fehler, den Sie erst nachträglich feststellen. Wenn ein festgelegter Befehl trotzdem den falschen Build startet oder die Installation vollständig verweigert, erklärt die üblichen Installations- und Versionsfehler von dsh, wie Sie den npx-Cache leeren und prüfen, welches npm mit Node ausgeliefert wird.

Für den täglichen Betrieb installieren Sie das Programm einmal, statt es bei jedem Start erneut aufzulösen.

npm install -g @deepseek-ai/dsh@0.1.0-rc.6
dsh --profile web --help

Die zweite Zeile sollten Sie ausführen, weil der Launcher und die Webanwendung getrennte Optionssätze verwenden. dsh --help zeigt die eigenen Optionen des Launchers. dsh --profile web --help zeigt die von der Webanwendung akzeptierten Optionen. Dort finden Sie --port, --host und die wiederholbare Option --trusted-host.

Prüfen Sie jetzt, auf welcher Adresse der Prozess Verbindungen entgegennimmt.

ss -tlnp | grep 3080

In der Spalte für die lokale Adresse sollte 127.0.0.1:3080 stehen. Wenn dort 0.0.0.0:3080 steht, ist die Benutzeroberfläche aus dem Internet erreichbar. Beenden Sie den Prozess, bevor Sie etwas anderes tun.

Warum Sie Port 3080 niemals veröffentlichen dürfen

Der Webserver verfügt über keine Authentifizierungsschicht. Seine Konfiguration legt einen Listen-Host und einen Listen-Port fest. Das ist die gesamte Angriffsfläche. Die Zugriffskontrolle für Bereitstellungen außerhalb des Loopback-Interfaces erfolgt über eine separate Einstellung für vertrauenswürdige Hosts. Dabei handelt es sich nicht um eine Anmeldemaske.

Betrachten Sie nun, was hinter diesem Port läuft. Der Agent bearbeitet Dateien im Arbeitsbereich und führt Shell-Befehle aus. Ihre Provider-Anmeldedaten liegen daneben auf der Festplatte. Ein offener Port 3080 ist daher eine Remote-Shell mit einer Chat-Oberfläche. Sie läuft unter dem Benutzerkonto, das sie gestartet hat, und verwendet Ihren API-Schlüssel. Dafür ist kein Exploit erforderlich. Angreifer benötigen nur die Portnummer. Scanner finden offene Ports innerhalb weniger Stunden, nachdem ein Host online gegangen ist.

Die CLI (Command Line Interface) bestätigt diese Einschätzung. Ab 0.1.0-rc.6 unterstützt sie --host 0.0.0.0 absichtlich nicht und beendet sich stattdessen mit einem Usage-Fehler, ohne zu starten. Diese Verweigerung ist eine Sicherheitsfunktion. Suchen Sie daher nicht nach einem Patch, der sie entfernt.

Zwei weitere Bereitstellungsvarianten sind sinnvoll, wenn ein Tunnel für Sie nicht infrage kommt. Binden Sie den Rechner in ein privates Overlay-Netzwerk ein. Dann besitzt er nur eine Adresse, die ausschließlich Ihre eigenen Geräte erreichen können. Genau das ermöglicht ein selbst gehosteter Headscale-Control-Server. Oder schalten Sie einen Reverse Proxy davor, der die Anfrage authentifiziert, bevor sie Port 3080 erreicht. Dafür kann beispielsweise ein Authentik-Single-Sign-On-Server Forward Auth übernehmen. Ein Reverse Proxy ohne Authentifizierung davor ist keine Sicherheitskontrolle. Es ist nur eine längere URL.

Weboberfläche über einen SSH-Tunnel erreichen

Führen Sie diesen Befehl auf Ihrem Laptop aus, nicht auf dem Server.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

-L öffnet Port 3080 auf Ihrem Laptop und leitet alle Verbindungen, die dort eingehen, durch die verschlüsselte SSH-Sitzung weiter. Der Teil 127.0.0.1:3080 wird auf dem Server aufgelöst. Die Verbindung erreicht den Harness daher über Loopback, genau so, als würden Sie direkt an der Maschine sitzen. -N gibt an, dass keine entfernte Shell gestartet werden soll, weil Sie nur die Weiterleitung benötigen.

Öffnen Sie anschließend http://127.0.0.1:3080 in Ihrem lokalen Browser. Wenn Port 3080 auf Ihrem Laptop bereits belegt ist, ändern Sie die Zahl auf der linken Seite: ssh -N -L 3180:127.0.0.1:3080 you@your-server. Rufen Sie anschließend http://127.0.0.1:3180 auf. Die Zahl auf der linken Seite ist lokal. Die Zahl auf der rechten Seite gehört zum Server. Daher wird nur die linke Zahl geändert.

Speichern Sie den Befehl in ~/.ssh/config. Dann müssen Sie ihn nicht erneut eingeben.

Host dsh
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  LocalForward 3080 127.0.0.1:3080

Danach startet ssh -N dsh den Tunnel. Wenn der Browser meldet, dass die Verbindung abgelehnt wurde, ist der Tunnel normalerweise aktiv, aber auf der entfernten Seite lauscht kein Dienst. SSH leitet den Port unabhängig davon weiter, ob der Harness läuft. Prüfen Sie den Server mit dem oben genannten Befehl ss.

Die Harness-Ausführung nach dem Abmelden fortsetzen

Ein npx-Befehl wird zusammen mit Ihrer Shell beendet. Ein systemd-Benutzerdienst läuft weiter und startet die Harness-Ausführung nach einem Absturz oder Reboot erneut. Die Unit ist hier bewusst minimal gehalten. Wenn die Harness-Ausführung unter einem eigenen, gesperrten Konto laufen soll, die Version innerhalb der Unit festgelegt werden soll und durchsuchbare Logs benötigt werden, wird das in der vollständigen headless-systemd-Konfiguration für dsh ausführlich beschrieben.

loginctl enable-linger $USER
mkdir -p ~/.config/systemd/user
command -v dsh

enable-linger ist erforderlich, weil Benutzerdienste normalerweise beendet werden, sobald Ihre letzte Sitzung endet. Ohne diese Einstellung wird die Harness-Ausführung beendet, sobald Sie den Tunnel schließen. Übernehmen Sie den von command -v dsh ausgegebenen absoluten Pfad in die Unit, da systemd nicht den PATH durchsucht, den Ihre Login-Shell erstellt.

[Unit]
Description=DeepSeek Harness web UI
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/projects/site
ExecStart=/usr/local/bin/dsh web
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

WorkingDirectory ist nicht nur eine Formalität. Der Prozess dsh verwendet sein Aufrufverzeichnis als standardmäßigen Speicherort im Dateisystem. Wird der Dienst im falschen Verzeichnis gestartet, erhält der Agent den falschen standardmäßigen Arbeitsbereich. Den Arbeitsbereich können Sie weiterhin in der Benutzeroberfläche auswählen.

systemctl --user daemon-reload
systemctl --user enable --now dsh
systemctl --user status dsh

Eine Unit, die den Start verweigert, verwendet fast immer einen falschen ExecStart-Pfad oder eine Node-Version, die die Binärdatei ablehnt. journalctl --user -u dsh -n 50 gibt an, welcher Fall vorliegt. Dasselbe Muster eignet sich für den dauerhaften Betrieb eines beliebigen Coding-Agenten auf einem VPS. Die Fehlerursachen sind identisch.

Was ein Plugin tun darf

Ein Plugin ist ein Modul, das Dienste, typisierte Ereignisse und umkehrbare Effekte zu einem gemeinsamen Kontext beiträgt. Die Erweiterungspunkte sollten Sie besonders genau lesen:

• einen Model-Provider auf ctx.llm registrieren
• dem Modell zugeordnete Tools auf ctx.tools hinzufügen
• das Shell-Backend hinter ctx.shell bereitstellen
• Dateisystemzugriff oder Richtlinien hinter ctx.fs bereitstellen
• menschliche Befehle auf ctx.commands registrieren
• Hintergrundaufgaben über ctx.jobs ausführen
• gestartete Prozesse mit einem ctx.sandbox-Backend umschließen
• Anfragen und Tool-Aufrufe über die Ereignisse agent/* und tools/* abfangen
• den dauerhaft gespeicherten Sitzungsstatus erweitern
• die Benutzeroberfläche über ctx.agents steuern

Lesen Sie diese Liste aus der Perspektive eines Angreifers. Ein Plugin kann die Dateisystem- und Shell-Schicht bereitstellen und sich zwischen jeden Tool-Aufruf des Modells schalten. Zwischen einem Plugin und diesen Schnittstellen gibt es kein Berechtigungsdialogfeld, weil ein Plugin gewöhnlicher Node-Code ist, der im selben Prozess wie alle anderen Komponenten geladen wird. Ein Plugin zu installieren bedeutet, den Code eines Fremden mit den Berechtigungen Ihres Agenten auszuführen. Die Berechtigungen Ihres Agenten entsprechen den Berechtigungen Ihres Unix-Benutzers.

Dies ist dieselbe Vertrauensentscheidung wie beim Einbinden eines MCP-Servers in einen Agenten auf einem VPS, wobei MCP für Model Context Protocol steht. Deshalb beginnt auch der sichere Betrieb eines Coding-Agenten auf einem VPS mit dem Benutzerkonto, unter dem er ausgeführt wird, und nicht mit dem Modell. Aus demselben Grund haben npm-Angriffe auf die Lieferkette solche Auswirkungen auf Server: Der Installationsschritt führt zum Einbruch, und es wird keine Rückfrage angezeigt.

Woher Plugins kommen

Plugins befinden sich in Profilen. Ein Profil ist eine benannte Zusammenstellung unter $DSH_HOME. Standardmäßig ist das ~/.dsh. In jedem Profilverzeichnis liegen die externen Plugins, die dort installiert sind. Die CLI leitet Ihre Argumente direkt an pnpm weiter und verwendet dabei das Profilverzeichnis als Arbeitsverzeichnis.

dsh plugin --profile web add github:deepseek-harness/turtle-ui
dsh plugin --profile web remove turtle-ui

Da die Argumente unverändert an pnpm übergeben werden, verhalten sich add, remove, update und why wie in jedem pnpm-Projekt. Ein Plugin kann ein npm-Paket oder eine GitHub-Referenz sein. pnpm muss sich zuerst im PATH befinden. Unter Node 22 und höher stellt corepack enable pnpm es dort bereit.

Die Suche erfolgt über ein GitHub-Topic. Plugin-Autoren fügen ihrem Repository das Topic dsh-plugin hinzu. Über dieses Topic finden Sie vorhandene Plugins. Ein Topic ist eine Bezeichnung, die ein Autor auf sein eigenes Repository anwendet. Es wird von niemandem geprüft oder signiert. Die Topic-Seite sortiert nach Sternen. Diese messen die Popularität, nicht die Sicherheit.

Vier Gewohnheiten halten den Aufwand überschaubar. Lesen Sie den Quellcode vor der Installation, da die meisten Plugins klein genug sind, um sie in zehn Minuten zu prüfen. Fixieren Sie die exakte Version oder den Commit, statt einem Branch zu folgen. Führen Sie den Harness unter einem Benutzer aus, dem keine anderen Ressourcen gehören, und auf einem VPS, den Sie bei Bedarf neu aufsetzen würden. Geben Sie dem Agenten einen eigenen API-Schlüssel mit einem eigenen Ausgabenlimit. Verwenden Sie dafür nicht den Schlüssel Ihrer Produktionsdienste. Wenn Sie ein Plugin prüfen und wissen möchten, welche Dateien das Risiko enthalten, beschreibt die Anleitung zur Prüfung eines dsh-Plugins das Manifest, den Einstiegspunkt und die Erweiterungspunkte, die ein Plugin registriert.

Wenn Sie Designs vor der Festlegung vergleichen möchten, löst der Omnigent-Multi-Agent-Harness dasselbe Problem mit einer anderen Struktur. Sobald Plugins ins Spiel kommen, werden die jeweiligen Kompromisse offensichtlich. Wenn Sie schließlich zwei oder drei davon auf demselben Server betreiben, statt sich für einen zu entscheiden, erspart ein zentraler Self-Hosted-API-Zugang für alle Harnesses jeweils einen Tunnel pro Port. Dafür kommt ein weiterer Dienst hinzu, der von Anfang an an loopback gebunden und mit einem sicheren Passwort versehen werden muss.

Was zuerst fehlschlägt

Node ist zu alt. Das Projekt benötigt Node 22.19 oder eine neuere Version der 22.x-Reihe beziehungsweise Node 24 oder höher. Diese Versionen werden auch in der CI getestet. Eine ältere Laufzeitumgebung schlägt beim Start fehl, weil der Code Syntax und APIs verwendet, die dort nicht verfügbar sind. Führen Sie zuerst node --version aus.

Port 3080 ist bereits belegt. Möglicherweise verwendet ihn ein zweites Harness, ein veralteter Prozess oder eine andere Anwendung. Ermitteln Sie den Prozess mit ss -tlnp | grep 3080. Beenden Sie ihn oder starten Sie das Harness an einem anderen Port mit dsh web --port 3180. --port gehört zur Webanwendung und wird daher nach web ausgeführt.

Der Browser kann über den Tunnel keine Verbindung herstellen. Prüfen Sie, ob Sie 127.0.0.1 und nicht die öffentliche Adresse des Servers aufgerufen haben. Der weitergeleitete Port ist nur auf Ihrem Laptop verfügbar. Prüfen Sie anschließend, ob das Harness auf dem Server Verbindungen annimmt. SSH richtet die Weiterleitung unabhängig davon ein, ob am entfernten Ende ein Dienst antwortet.

dsh plugin schlägt sofort fehl. Der Befehl ist ein Wrapper um pnpm. Eine fehlende pnpm-Binärdatei beendet ihn daher, bevor die Plugin-Verarbeitung beginnt.

Der Agent kann Ihr Projekt nicht sehen. Der Workspace entspricht standardmäßig dem Verzeichnis, in dem der Prozess gestartet wurde. Wenn WorkingDirectory einer Unit auf Ihr Home-Verzeichnis zeigt, erhält der Agent daher Ihr Home-Verzeichnis. Wählen Sie den Workspace in der Benutzeroberfläche aus oder korrigieren Sie die Unit und laden Sie sie neu.

FAQ

Ist es sicher, die Weboberfläche von DeepSeek Harness auf Port 3080 bereitzustellen?

Nein. Der Webserver hat keine eigene Anmeldung. Der dahinter ausgeführte Agent bearbeitet Dateien und führt Shell-Befehle mit den Rechten des Benutzers aus, der den Prozess gestartet hat. Ihr Provider-API-Schlüssel liegt ebenfalls auf derselben Festplatte. Lassen Sie den Listener auf 127.0.0.1 gebunden und greifen Sie über einen SSH-Tunnel darauf zu. Ein privates Overlay-Netzwerk oder ein Reverse Proxy, der jede Anfrage authentifiziert, bevor sie den Port erreicht, funktioniert ebenfalls. Ab Version 0.1.0-rc.6 verweigert die CLI --host 0.0.0.0 und beendet sich mit einem Usage-Fehler. Das zeigt, wie die Autoren diese Vorgehensweise einschätzen.

Benötige ich einen DeepSeek-API-Schlüssel, oder kann ich ein lokales Modell verwenden?

Beides ist möglich, weil das Harness eine Laufzeitumgebung und kein Modell ist. Öffnen Sie Settings und danach Models. Dort können Sie einen Schlüssel in das Feld eines Catalog-Provider-Eintrags einfügen. Alternativ wählen Sie "Add a custom provider" und geben eine Base-URL an, die das OpenAI-kompatible Protokoll unterstützt. Ein lokaler Ollama-Server antwortet unter http://127.0.0.1:11434/v1/ und akzeptiert im Feld für den API-Schlüssel beliebige Zeichenfolgen. Die Schlüssel werden in $DSH_HOME/.credentials.yaml gespeichert. Standardmäßig ist dies ~/.dsh/.credentials.yaml.

Welche Berechtigungen erhält ein DeepSeek-Harness-Plugin tatsächlich?

Die Berechtigungen des Kontos, unter dem das Harness ausgeführt wird. Ein Plugin besteht aus Node-Code und wird in denselben Prozess geladen. Die Erweiterungspunkte umfassen das Shell-Backend, die Dateisystemschicht, die Tool-Registrierung und die Events, die jeden Tool-Aufruf umschließen. Ein Plugin wird von diesen Schnittstellen nicht isoliert, sofern es die Sandbox nicht selbst bereitstellt. Lesen Sie vor der Installation den Quellcode. Führen Sie das Harness unter einem Benutzer aus, der keine wichtigen Daten besitzt.

Welche Version sollte ich installieren, und funktioniert sie dauerhaft?

Installieren Sie eine exakt angegebene Version, zum Beispiel npx @deepseek-ai/dsh@0.1.0-rc.6 web. Auf diese Version verwies der Tag latest am 13. August 2026. Das Projekt bezeichnet sich als Developer Preview und weist darauf hin, dass inkompatible Änderungen zu erwarten sind. Ein Befehl ohne feste Versionsangabe kann sich daher von einem Tag zum nächsten anders verhalten. Prüfen Sie das Repository vor einem Upgrade. Rechnen Sie damit, dass sich Konfigurationsschlüssel und Plugin-Schnittstellen ändern, solange die Versionsnummer mit 0 beginnt.