Quels plugins installer pour DeepSeek Harness ?

Quels plugins DeepSeek Harness valent la peine d’être installés

Les plugins DeepSeek Harness sont du code tiers qui s’exécute dans votre agent, avec les privilèges de celui-ci, sur une machine que vous payez. La liste communautaire couvre plus de vingt catégories et plus de mille entrées. Sur un serveur privé virtuel (VPS) loué, vous en avez besoin de cinq : dsh-budget pour plafonner les dépenses, dsh-permission-rules pour contrôler l’accès aux outils, dsh-defend pour détecter les injections et les secrets, dsh-memory pour les faits qui persistent au-delà d’une session, et dsh-web-lan-access seulement après avoir défini votre méthode d’authentification.

Le harness est dsh, le harness d’agent open source de DeepSeek, conçu pour que tout soit un plugin. Son propre README le présente comme une version de prévisualisation destinée aux développeurs et contient l’avertissement THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Ce seul fait détermine tous les choix ci-dessous. Épinglez les versions des éléments installés, prévoyez qu’une mise à niveau puisse les rendre incompatibles et gardez un ensemble assez réduit pour pouvoir en lire l’intégralité. Si le harness ne s’exécute pas encore, commencez par installer DeepSeek Harness sur un VPS, puis revenez ici. Si les éléments auxquels ces plugins se raccordent — la boucle de l’agent, ses outils et sa mémoire — restent flous, commencez par revoir les fondamentaux, car il est plus facile d’évaluer chaque choix une fois que vous savez ce que fait chaque couche.

Installation d’un plugin par dsh et emplacement de la configuration

dsh se construit à partir de plugins Cordis. Une instance en cours d’exécution est donc un arbre de plugins, et non un programme unique. Un profil est une composition nommée de ces plugins. Les deux templates sont web et headless. $DSH_HOME utilise ~/.dsh par défaut. Un profil se trouve dans $DSH_HOME/profiles/<name>/ et contient son propre package.json, un manifeste dsh.profile et un cordis.patch.yml.

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

Quatre formes de source sont prises en charge : un nom de package npm simple, un nom scoped comme @towzai/dsh-memory, une référence GitHub comme github:PerryLink/dsh-budget#main et un chemin local avec link: ou ./. Privilégiez la forme GitHub, car vous pouvez remplacer #main par un commit et récupérer exactement le même code le mois prochain.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

Les couches sont appliquées dans un ordre fixe : chaque bundle dans l’ordre indiqué par le profil, puis le cordis.patch.yml du profil, ensuite le cordis.patch.yml du compte utilisateur, puis tout overlay --patch. L’ordre est important, car une couche ultérieure peut reconfigurer ou supprimer ce qu’une couche précédente a défini. Si un plugin semble installé mais ne fait rien, ouvrez le cordis.patch.yml du profil et vérifiez deux éléments : son bloc d’insertion est présent et aucune couche ultérieure ne le désactive.

Au 17 août 2026, le package npm @deepseek-ai/dsh était en version 0.1.0-rc.7, tandis que les plugins ci-dessous étaient conçus pour la branche 0.1.0-rc. dsh-permission-rules et dsh-defend déclarent une compatibilité avec 0.1.0-rc.5 à 0.1.0-rc.6, dsh-budget déclare uniquement 0.1.0-rc.6, dsh-memory définit seulement des plages de versions peer commençant à ^0.1.0-rc.6, et dsh-web-lan-access ne déclare aucune version de dsh. Le 10 octobre 2026, le tag latest sur npm est 0.2.0-rc.2. L’écart est donc maintenant plus important qu’au moment où ces versions ont été épinglées. Cet écart est normal dans cet écosystème. C’est aussi la raison habituelle pour laquelle un plugin cesse de se charger : le harness évolue plus vite que les plugins qui l’entourent. Mettez à niveau le harness volontairement, puis testez les plugins un par un.

Lisez le code d’un plugin avant de lui faire confiance

Un plugin dsh n’est pas isolé du harness. Il est chargé dans le même arbre Cordis et dans le même processus, avec le même utilisateur du système d’exploitation, les mêmes identifiants de modèle et le même répertoire de travail. En installer un revient davantage à exécuter le script de quelqu’un d’autre avec sudo qu’à ajouter une extension de navigateur. C’est la même question de confiance que celle soulevée par les plugins Claude Code, et la réponse est la même : lisez le code ou ne l’installez pas.

Voici quatre points à vérifier, dans cet ordre :

• Les points d’extension utilisés. tools/pre-execute signifie que le plugin voit chaque appel d’outil et peut le bloquer. agent/pre-step signifie qu’il voit vos messages. webServer.tapIndex signifie qu’il réécrit la page servie à votre navigateur. Un plugin qui n’utilise aucun de ces points peut faire très peu de choses ; un plugin qui les utilise tous constitue votre frontière de sécurité.
• La présence de communications réseau. Recherchez fetch, http et tout hostname codé en dur dans le code source. Un compteur de coûts qui envoie des données à son éditeur transmet votre profil d’utilisation à un tiers.
• L’accès aux identifiants. Tout ce qui accède à credentials.* ou à une clé de fournisseur doit avoir une raison clairement indiquée dans le README.
• La licence et la date du dernier commit. Un plugin sans licence, qui n’a pas été modifié depuis des mois dans un écosystème qui évolue chaque semaine, constitue un risque.

Installez ensuite le plugin à partir d’un commit plutôt que d’une branche, puis lisez le bloc d’insertion que l’installateur a écrit dans cordis.patch.yml. Ce bloc indique l’identifiant du plugin et la configuration qu’il a enregistrée. C’est la description la plus concise et la plus fiable de ce que vous venez d’ajouter. Lorsque le harness le permet, gardez les clés de fournisseur hors de portée du plugin, comme indiqué dans la conservation des secrets hors des agents IA.

dsh-budget : comment empêcher un agent de dépenser toute la nuit ?

Un agent s’exécute sans surveillance sur un VPS. C’est précisément l’intérêt de l’y installer, mais c’est aussi le risque. dsh-budget comptabilise les tokens et le coût estimé par modèle, par session et par jour, puis applique des plafonds à ces totaux.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

Ses valeurs par défaut sont généreuses : 10 USD par session, 50 par jour et 500 par mois. Elles conviennent à une équipe financée. Sur un serveur personnel, elles sont assez élevées pour qu’une boucle qui s’emballe se termine avant que le plafond ne s’applique. Réduisez-les donc dès le premier jour.

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

La colonne suggérée constitue un point de départ pour un opérateur sur une machine, et non une valeur publiée. Augmentez-la lorsqu’un mois réel d’utilisation vous le justifie. Un plafond mensuel de 40 USD associé à un plafond de session de 2 échoue rapidement et de manière visible. C’est ce que vous voulez tant que vous évaluez l’appétit de l’outil.

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

Le paramètre qui modifie le comportement de la machine est overLimit. Sa valeur par défaut est alert : le plugin affiche un avertissement, mais continue les dépenses. Par défaut, ce plugin sert donc de tableau de bord. Définissez-le sur block pour que le harness refuse tout nouvel appel au modèle lorsqu’un plafond est atteint. Ainsi, un job lancé pendant la nuit s’arrête au lieu de continuer à facturer jusqu’au matin. degrade est le troisième mode : il bloque l’appel et indique un modèle moins coûteux issu de la map degradation. Ce mode convient lorsqu’un job doit se terminer, mais n’a pas besoin de votre meilleur modèle. warnRatio vaut 0.8 par défaut. Vous êtes donc averti à 80 pour cent du plafond.

Deux limites doivent être connues. Le coût est calculé à partir d’une table de prix intégrée, fusionnée avec les prix que vous fournissez. Le mainteneur précise que les prix intégrés peuvent évoluer. prices est vide par défaut. Dans le commit épinglé 461d478, defaultPrice, la valeur de repli pour un modèle absent des deux tables est de 1.0 USD par million de tokens d’entrée et de 3.0 par million de tokens de sortie. Dans la version actuelle de main, vérifiée le 10 octobre 2026, cette valeur est par défaut égale à zéro et le modèle apparaît sans prix. Saisissez les valeurs réelles de vos modèles. Sinon, le tableau de bord ne sera qu’une estimation présentée comme une mesure. Deuxième limite : avec 461d478, le plugin agrège les données dans le processus en cours à partir du flux d’événements de la session. Les totaux sont donc réinitialisés lorsque le harness redémarre. Une boucle de crash, ou un superviseur qui redémarre dsh, réinitialise aussi un plafond quotidien. La version actuelle de main conserve par défaut les compteurs journaliers et mensuels (persistence.enabled: true, avec un snapshot toutes les 10 secondes) et les restaure au démarrage. Dans cette version, un redémarrage n’efface donc plus un plafond quotidien ou mensuel, à condition que le harness fournisse le domaine de stockage. Sans ce domaine, l’agrégation reste limitée au processus. main cible également la branche de harness 0.2. Déplacer le commit épinglé implique donc de déplacer aussi le harness. Dans tous les cas, considérez dsh-budget comme une protection contre vos propres jobs et définissez une limite de dépense sur le compte du fournisseur comme plafond réel. C’est l’argument plus général présenté dans contrôler le coût d’un agent IA sur un VPS.

Au quotidien, utilisez /budget pour la vue d’ensemble, /budget models pour le détail par modèle et /budget unblock <scope> pour lever un blocage après avoir décidé de poursuivre.

règles de permission de dsh : quels appels d’outils ne doivent jamais être exécutés ?

dsh-permission-rules place des règles déclaratives dans le workflow tools/pre-execute, afin qu’une règle soit évaluée avant l’exécution d’un outil. Trois actions sont disponibles. allow laisse passer l’appel, deny le bloque et renvoie une raison que le modèle peut lire, et ask l’achemine vers le mécanisme officiel d’approbation.

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

Les règles se trouvent dans .dsh/rules.yaml, relatif au répertoire de travail de la session, avec un emplacement global fallbackPath et un emplacement searchUp facultatif pour remonter vers la racine du système de fichiers. La correspondance couvre les globs de noms d’outils, les globs de clés et de valeurs de paramètres, les globs de chemins relatifs à l’espace de travail, les sélecteurs d’agents tels que main ou subagent, ainsi que les cibles réseau.

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

L’évaluation s’arrête à la première correspondance. Ainsi, un allow général placé en haut annule silencieusement toutes les règles plus précises qui le suivent. Écrivez d’abord les refus, puis les règles permissives. Le glob de nom d’outil couvre mcp__*. C’est ainsi que vous contrôlez les outils fournis par un serveur de model context protocol (MCP), plutôt que par le harness lui-même. Cela devient important dès que vous exécutez des serveurs MCP sur un VPS.

Il faut prévoir un comportement particulier : ask nécessite un répondant. Dans un profil headless, personne ne surveille nécessairement la session. Un ask sans réponse n’attend pas que quelqu’un intervienne : en l’absence de répondant configuré, la chaîne d’approbation du harness échoue par défaut et l’appel est refusé. Sur une machine sans surveillance, une règle ask se comporte donc comme un deny que vous n’auriez pas écrit intentionnellement. Utilisez deny pour tout ce que vous n’approuveriez jamais, conservez ask pour le profil que vous surveillez directement et, si vous voulez que les approbations fonctionnent sans surveillance, prévoyez un véritable chemin de réponse. C’est le sujet de la validation des actions des agents IA par approbation.

dsh-defend : qu’en est-il de l’injection de prompt et des secrets divulgués ?

dsh-defend effectue des scans à trois étapes : les messages entrants sur agent/pre-step, les arguments des outils sur tools/pre-execute, avec une protection contre les suppressions destructrices, et les résultats des outils sur tools/post-execute. Ce dernier point est le plus intéressant, car c’est là que le contenu récupéré depuis une page web est contrôlé avant que le modèle n’agisse dessus.

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

Les valeurs par défaut sont prudentes plutôt que strictes : detection.injectionAction, detection.jailbreakAction et detection.secretAction valent tous ask, tandis que detection.secretBlockCritical vaut true. Un secret critique est donc bloqué quels que soient les autres paramètres. Sur une machine sans supervision, définissez sur block les actions qui vous intéressent, car ask sans personne à qui demander confirmation ne constitue pas une décision.

La conception de l’audit est bien pensée. Les événements defend/detection enregistrent l’identifiant de la règle, la famille, la catégorie, la gravité, la décision et les informations du scan, mais jamais le texte détecté. Les secrets sont enregistrés uniquement par type. L’activation du journal d’audit ne crée donc pas une deuxième copie de l’identifiant que vous essayiez de protéger.

Il faut bien comprendre ce que cela apporte. La détection repose sur des règles, et le README indique clairement que des formulations inédites et des attaques en plusieurs étapes peuvent lui échapper. Elle réduit la fréquence des attaques évidentes. Elle ne permet pas d’utiliser sans risque un agent avec du contenu non fiable. Conservez donc les règles de permission qui s’appliquent en dessous.

dsh-memory : que mémorise l’agent pour demain ?

Deux plugins différents portent le nom dsh-memory. Il est donc utile de le savoir avant de saisir une commande d’installation. Installez-le en indiquant explicitement la source afin d’obtenir celui que vous avez consulté.

Sur un petit serveur, je choisirais la version SQLite. Elle s’enregistre sous le nom memory, conserve un fichier unique dans $DSH_HOME/memory/memory.db, partagé entre les profils, et expose memory_write, memory_search et memory_forget. La recherche s’effectue par mots-clés dans le texte et les tags enregistrés. Il n’y a ni service d’embedding, ni clé d’API, ni processus supplémentaire.

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

La configuration à modifier est limitée : path pour le fichier de base de données, promptRecentCount (valeur par défaut : 10) pour le nombre de mémoires non épinglées à injecter, et promptMaxChars (valeur par défaut : 2000) pour le budget de rendu. Elle s’appuie sur node:sqlite, que Node 22 et 24 signalent encore comme expérimental. Une mise à niveau de Node doit donc être testée, et non considérée comme sûre par défaut.

Voici ce que la mémoire change réellement sur la machine : les mémoires injectées sont ajoutées au system prompt à chaque tour. promptMaxChars définit une limite pour la section rendue, et non une taille fixe. Mais une fois cette limite remplie par vos mémoires, un budget de 2000 caractères ajoute quelques centaines de tokens d’entrée à chaque requête, indéfiniment. Cela apparaît réellement sur votre facture. C’est pourquoi dsh-budget doit être installé sur le serveur avant dsh-memory. Maintenez promptMaxChars à une valeur faible et nettoyez les entrées avec memory_forget au lieu de laisser le fichier grossir.

L’autre version stocke les mémoires dans un fichier YAML et utilise une recherche par embeddings avec injection automatique dans le prompt. Elle s’installe avec dsh plugin --profile web add github:towzai/dsh-memory. Sa recherche par embeddings nécessite une instance ollama locale et un modèle d’embedding, qwen3-embedding:0.6b par défaut, remplaçable avec DSH_MEMORY_EMBED_MODEL. Sans ollama, elle revient à une recherche par mots-clés. Le rappel sémantique est meilleur que le rappel par mots-clés. En contrepartie, vous ajoutez un deuxième service et un ensemble de poids de modèle résidents sur le même serveur. Sur une petite offre, cette mémoire est prélevée sur les ressources que vous avez louées pour exécuter vos tâches. Choisissez cette version si vous disposez de RAM supplémentaire. Le compromis général entre la qualité du rappel et le coût en ressources résidentes est présenté dans mémoire locale pour les agents.

dsh-web-lan-access : l’interface web doit-elle écouter au-delà de loopback ?

npx @deepseek-ai/dsh web sert l’interface sur 127.0.0.1:3080. Les navigateurs n’exposent crypto.randomUUID() que dans un contexte sécurisé. Le chargement de cette même page en HTTP simple depuis une autre machine échoue donc. dsh-web-lan-access corrige ce problème en utilisant webServer.tapIndex pour injecter un petit polyfill. Il modifie aussi l’adresse d’écoute du serveur et la définit sur 0.0.0.0.

Lisez son avertissement avant de l’installer. Dans le commit cité ici, e27e909, le README indiquait que la liaison sur 0.0.0.0 rendait l’agent accessible sans authentification à toute personne présente sur le même réseau local (LAN), et, sur un serveur doté d’une adresse IP publique, à l’ensemble d’Internet. Une courte liste de méthodes sensibles (settings.*, credentials.*, llm.discoverModels) restait liée à loopback et renvoyait 403 pour les origines distantes. Cela a changé. Les builds actuels de harness, vérifiés le 10 octobre 2026, authentifient le navigateur : le launch token présent dans l’URL affichée est échangé contre un cookie de session signé, exigé par toutes les routes et tous les flux de l’API Host. Le README actuel du plugin décrit trustedHosts comme une barrière Origin/Host, et non comme un mécanisme d’identité. Il indique que la liaison sur 0.0.0.0 expose la surface d’authentification sur chaque interface accessible. Il active désormais aussi les paramètres adossés à Host pour une page distante authentifiée. Dans les builds actuels, un navigateur distant avec une session ouverte peut donc également accéder aux paramètres Host. Le risque a changé, mais il n’a pas disparu : toute personne pouvant atteindre le port peut sonder la connexion, l’URL affichée constitue elle-même un identifiant d’accès et, en HTTP simple, ce token circule en clair sur le réseau.

La plupart du temps, ce plugin est inutile. Transférez plutôt le port avec SSH.

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

Ouvrez ensuite http://127.0.0.1:3080 dans votre navigateur local. Le harness continue d’écouter uniquement sur loopback. Rien n’est donc exposé. Comme les navigateurs considèrent 127.0.0.1 comme une origine sécurisée, crypto.randomUUID() est disponible et aucun polyfill n’est nécessaire. Une commande, aucun plugin et aucune nouvelle surface d’attaque.

N’installez le plugin que si un forwarding ne suffit pas, par exemple lorsqu’un téléphone connecté au même réseau doit accéder à l’interface. Dans ce cas, liez-le à une interface réseau privée, conservez une règle de firewall qui autorise uniquement cette interface et indiquez les noms que vous utiliserez sous trustedHosts dans l’entrée web-runtime. Pour un véritable accès multi-utilisateur, dsh-passwords ajoute des permissions par sous-utilisateur, des quotas horaires de tokens et des quotas quotidiens de durée pour chaque sous-utilisateur, des certificats TLS (transport layer security) automatiques via Let's Encrypt et un journal d’audit chiffré. Évaluez-le comme une plateforme plutôt que comme un plugin : il utilise les ports 80 et 443, fournit son propre installateur et la procédure rapide documentée transmet directement un script shell du réseau à bash. Préférez npm install -g dsh-passwords, puis dsh-passwords install, afin que le code soit stocké sur le disque et puisse être lu avant son exécution.

Comment supprimer proprement un plugin

La désinstallation se fait en deux étapes, mais la seconde est souvent oubliée.

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list ne doit plus l’afficher. Ouvrez ensuite $DSH_HOME/profiles/web/cordis.patch.yml et supprimez tout bloc d’insertion restant qui mentionne ce plugin, car c’est cette entrée qui le charge dans l’arborescence. Redémarrez le harness pour reconstruire l’arborescence ; un plugin déjà chargé reste chargé jusqu’à cette opération. Enfin, n’oubliez pas que les données persistent au-delà du code. $DSH_HOME/memory/memory.db et .dsh/rules.yaml restent présents après la désinstallation. Supprimez-les vous-même si la suppression des données était l’objectif.

Ce que j’ai consulté, et à quel moment

Chaque référence ici correspond à un commit, pas à une branche, car main contiendra un code différent lorsque vous lirez ceci. J’ai tout consulté le 17 août 2026, et le harness lui-même était en version 0.1.0-rc.7 sur npm ce jour-là. J’ai revérifié les valeurs par défaut et le comportement décrits plus haut à partir des sources primaires le 10 octobre 2026, lorsque le tag latest sur npm était 0.2.0-rc.2.

Revérifiez ces références avant de copier une commande. Dans un écosystème en developer preview, un numéro de version associé à une date est le seul qui ait une signification.

FAQ

Quels plugins DeepSeek Harness dois-je installer en premier sur un VPS ?

Installez dsh-budget et dsh-permission-rules avant toute autre chose. Un budget avec overLimit: block empêche une exécution sans surveillance de se poursuivre toute la nuit, et un fichier .dsh/rules.yaml bloque un appel d’outil que vous n’auriez jamais approuvé. Ajoutez dsh-defend dès que l’agent lit des informations sur le Web public, et dsh-memory lorsque vous constatez que vous collez le même contexte dans chaque session. Ignorez les thèmes et les indicateurs d’état : ils ajoutent du code exécuté avec les privilèges de l’agent sans modifier le comportement de la machine.

Les plugins dsh sont-ils isolés du harness ?

Non. Un plugin se charge dans le même arbre Cordis que le harness, au sein du même processus, avec le même utilisateur du système d’exploitation, les mêmes identifiants de modèle et le même arbre de travail. Un plugin qui intercepte tools/pre-execute voit chaque appel d’outil et peut le bloquer ; un plugin qui intercepte agent/pre-step voit vos messages. Lisez donc le code source, vérifiez la licence et la date du dernier commit, puis installez le plugin en vous basant sur un commit plutôt que sur une branche afin que le code ne puisse pas changer à votre insu.

dsh-budget arrête-t-il réellement l’agent ou se contente-t-il de m’avertir ?

Cela dépend de overLimit. La valeur par défaut est alert : un avertissement s’affiche à warnRatio, mais les dépenses continuent. block refuse les appels supplémentaires au modèle une fois le plafond atteint, et /budget unblock <scope> le lève lorsque vous choisissez de continuer. degrade bloque l’exécution et indique un modèle moins cher provenant de la map degradation. Une limite est à connaître : dans le commit épinglé 461d478, les totaux sont cumulés dans le processus en cours. Le redémarrage du harness les réinitialise donc, et une boucle de redémarrage permettrait de contourner une limite quotidienne. La version actuelle main conserve par défaut les compteurs journaliers et mensuels après les redémarrages. Dans tous les cas, définissez une limite de dépenses sur le compte du fournisseur : c’est le véritable plafond.

Comment supprimer complètement un plugin dsh ?

Exécutez dsh plugin --profile web remove <package-name>, confirmez avec dsh plugin --profile web list, puis ouvrez $DSH_HOME/profiles/web/cordis.patch.yml et supprimez tout bloc d’insertion restant pour ce plugin, car cette entrée est ce qui le charge. Redémarrez le harness afin de reconstruire l’arborescence des plugins. Les données écrites par le plugin restent sur le disque : $DSH_HOME/memory/memory.db et .dsh/rules.yaml persistent toutes deux après la désinstallation, jusqu’à ce que vous les supprimiez vous-même.

Est-il sûr d’exposer l’interface web de dsh sur le réseau ?

Pas de manière autonome. dsh web écoute sur 127.0.0.1:3080, et dsh-web-lan-access modifie cette liaison pour utiliser 0.0.0.0. Au commit cité ici, son README indiquait que cela rendait l’agent accessible sans authentification à toute personne présente sur le même réseau, seuls settings.*, credentials.* et llm.discoverModels étant liés à la loopback. Les builds actuels du harness, vérifiés le 10 octobre 2026, authentifient la session du navigateur avec le launch token présent dans l’URL affichée et un cookie de session signé. Cependant, l’interface de connexion est alors exposée sur toutes les interfaces, et une URL HTTP simple transmet ce token en clair. Utilisez un port forwarding SSH, ssh -N -L 3080:127.0.0.1:3080 you@your-server, ou placez le port derrière une interface réseau privée et une règle de firewall. Maintenez TLS devant tout service accessible depuis l’extérieur.