Exécuter OpenCode sur un VPS

Ce qu'est OpenCode, et ce que vous mettez en place

OpenCode est un agent de codage IA open source conçu pour le terminal. Vous le lancez à l'intérieur d'un répertoire de projet, et il lit votre code, propose des changements, modifie des fichiers et exécute des commandes, le tout depuis une interface utilisateur en mode texte (TUI). Il est sous licence MIT, il se connecte à plus de 75 fournisseurs de modèles, et avec environ 165 000 étoiles GitHub à la mi-2026, c'est l'agent de codage open source le plus étoilé qui existe. Pour exécuter OpenCode sur un VPS, vous l'installez sous un utilisateur dédié non privilégié, vous placez la clé API de votre modèle dans un fichier privé, et vous le démarrez dans tmux afin que la session survive à la coupure de votre connexion. Ce guide fait exactement cela, dans cet ordre.

Une remarque sur les noms évite la confusion. Le dépôt canonique est anomalyco/opencode, maintenu par l'équipe Anomaly (auparavant connue sous le nom de SST), et le projet se trouvait autrefois à sst/opencode. Un dépôt plus ancien et sans rapport nommé opencode-ai/opencode existe aussi sur GitHub, alors vérifiez que vous lisez la documentation du bon projet. Le site officiel est opencode.ai.

Pourquoi exécuter OpenCode sur un VPS

Une session d'agent de codage est longue. OpenCode peut passer de nombreuses minutes à travailler sur une refactorisation ou une suite de tests, et s'il tourne sur votre ordinateur portable, un capot rabattu ou une connexion Wi-Fi coupée interrompt la session en pleine tâche. Sur un VPS dans tmux, l'agent continue de travailler après votre déconnexion, et vous vous reconnectez plus tard pour lire ce qu'il a fait. C'est le même schéma que l'exécution de Claude Code sur un VPS avec tmux, et c'est le plus grand gain de confort du déplacement d'un agent hors de votre ordinateur portable.

La deuxième raison est l'emplacement. Un VPS est proche du code que vous déployez : le dépôt, les outils de build, la base de données de test et souvent l'environnement de préproduction y vivent déjà ou juste à côté. Un agent qui modifie du code et exécute les tests fonctionne mieux sur la machine où ces tests s'exécutent réellement. Et comme la machine est un serveur que vous contrôlez, vous pouvez donner à l'agent un environnement confiné à dessein, ce que fait la section suivante.

Si vous êtes encore en train de choisir un outil, l'exécution d'un agent IA de codage sur un VPS compare le champ plus large, y compris Aider et Goose.

Donnez à OpenCode son propre utilisateur

Voici le point de départ honnête : un agent de codage modifie des fichiers et exécute des commandes. C'est son travail, et c'est aussi le risque. OpenCode exécutera des builds, des tests et toutes les commandes shell que la tâche semble nécessiter, et le jugement du modèle est bon mais pas parfait. Le compte sous lequel l'agent s'exécute est le plafond de ce qu'une mauvaise commande peut atteindre, alors ne l'exécutez pas en tant que root, et ne l'exécutez pas en tant que le même utilisateur qui administre le serveur.

Contrairement à un agent d'arrière-plan, OpenCode est interactif, donc son utilisateur a besoin d'un vrai shell et d'un répertoire personnel :

sudo useradd --create-home --shell /bin/bash opencode
sudo -iu opencode

Gardez les projets sur lesquels vous voulez qu'il travaille sous /home/opencode, clonés par cet utilisateur. Ne donnez aucun droit sudo au compte. Si l'agent exécute une commande destructrice, il ne peut détruire que ce que possède ce seul compte, ce qui suit le même raisonnement que l'exécution de services sous un utilisateur non privilégié. Travaillez aussi à l'intérieur d'un dépôt git, car un dépôt transforme toute mauvaise modification en un git revert plutôt qu'en une perte.

Installez OpenCode

Le projet documente deux installations. Le script d'installation est le plus rapide, et l'exécuter en tant qu'utilisateur opencode garde tout à l'intérieur du répertoire personnel de cet utilisateur :

curl -fsSL https://opencode.ai/install | bash

L'habitude habituelle du curl | bash s'applique ici comme partout : sur un serveur qui vous tient à cœur, téléchargez d'abord le script, lisez-le, puis exécutez-le. Après l'installation, démarrez un nouveau shell pour que le changement de PATH effectué par l'installateur prenne effet, puis vérifiez que le binaire répond :

opencode --version

Si vous préférez un gestionnaire de paquets et que Node.js est déjà sur la machine, la voie npm installe le même outil à l'échelle du système, ce qui place le binaire opencode sur le PATH pour chaque utilisateur :

sudo npm install -g opencode-ai

Dans les deux cas, la vérification est la même : opencode --version affiche un numéro de version. Un command not found après l'installation par script signifie que le shell actuel n'a pas encore lu le PATH mis à jour, alors déconnectez-vous et reconnectez-vous en tant qu'utilisateur opencode.

Placez la clé API dans un fichier privé

OpenCode a besoin d'une clé pour le fournisseur de modèle que vous utilisez, et cette clé peut dépenser votre argent, alors traitez-la comme un mot de passe. Créez un fichier que seul l'utilisateur opencode peut lire, avec le mode 600, et gardez la clé là plutôt que de la taper dans des commandes où elle atterrirait dans l'historique de votre shell :

install -m 600 /dev/null ~/opencode.env
nano ~/opencode.env

Placez-y la variable de votre fournisseur, par exemple ANTHROPIC_API_KEY=... ou l'équivalent pour votre fournisseur, car OpenCode récupère les variables d'environnement standard des fournisseurs. Chargez le fichier dans votre shell avant de démarrer l'agent :

set -a; source ~/opencode.env; set +a

OpenCode propose aussi une alternative interactive : la commande /connect à l'intérieur du TUI vous guide pour ajouter un fournisseur et enregistre l'identifiant dans ~/.local/share/opencode/auth.json dans le répertoire personnel de l'utilisateur. Si vous utilisez cette voie, confirmez que le fichier est privé avec chmod 600 ~/.local/share/opencode/auth.json. Les deux voies gardent la clé hors de vos lignes de commande ; choisissez-en une et restez cohérent.

Démarrez OpenCode dans tmux

tmux est ce qui rend la configuration du VPS payante, car une session tmux continue de tourner quand votre connexion SSH se termine. Démarrez-en une, entrez dans votre projet, et lancez l'agent :

tmux new -s opencode
cd ~/my-project
opencode

Vous devriez voir le TUI s'ouvrir avec une invite en bas et le nom de votre projet dans l'interface. Donnez-lui une tâche en langage clair, et il commence à lire des fichiers et à proposer des changements. Quand vous voulez partir, détachez-vous avec Ctrl-b puis d, et l'agent continue de travailler avec votre ordinateur portable fermé. Reconnectez-vous plus tard avec :

tmux attach -t opencode

La session, la conversation et toute tâche en cours sont exactement là où vous les avez laissées. Cela survit à vos déconnexions, mais pas à un redémarrage du serveur, donc après un redémarrage vous démarrez une nouvelle session tmux de la même manière.

Pointez-le vers un modèle

OpenCode est agnostique au fournisseur. Il utilise l'AI SDK et le catalogue Models.dev pour prendre en charge plus de 75 fournisseurs, donc le même outil fonctionne avec Anthropic, OpenAI, Google et des dizaines d'autres, y compris des serveurs locaux. La voie rapide est la commande /connect à l'intérieur du TUI, qui liste les fournisseurs et gère l'identifiant. Pour une configuration que vous pouvez versionner et reproduire, placez un opencode.json à la racine du projet et définissez le modèle sous la forme provider/model-id :

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-20250514"
}

Un modèle local fonctionne via le même fichier, car tout serveur compatible OpenAI peut être déclaré comme fournisseur. Si vous servez un modèle avec Ollama sur le même VPS, la configuration pointe vers son API locale, et le nom du modèle est celui que ollama list affiche sur votre machine :

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://127.0.0.1:11434/v1" },
      "models": { "your-model-name": { "name": "Local coding model" } }
    }
  }
}

Une habitude intégrée vaut la peine d'être adoptée dès le premier jour. OpenCode fournit deux agents entre lesquels vous basculez avec la touche Tab : Build, l'agent par défaut avec un accès complet, et Plan, qui désactive la capacité d'apporter des changements. Commencez une nouvelle tâche en Plan, laissez-le lire le code et proposer une approche, et ne basculez vers Build que lorsque vous êtes d'accord avec le plan. Sur un serveur, un premier passage en lecture seule est une assurance bon marché.

Le rayon d'impact, honnêtement

Un agent de codage n'est pas passif, alors dites clairement ce que cette configuration contient et ne contient pas. Elle contient bien les dommages aux fichiers : l'utilisateur opencode possède son propre répertoire personnel et rien d'autre, donc les modifications et les suppressions s'arrêtent à cette frontière. Elle contient bien l'exposition des identifiants : la clé vit dans un seul fichier avec le mode 600, dans un seul compte. Elle ne contient pas ce que le compte peut légitimement faire, donc si le répertoire du projet détient des identifiants de déploiement de production, l'agent peut les utiliser ; gardez-les entièrement hors du compte de l'agent.

Contrairement à un agent passerelle comme OpenClaw, OpenCode est un programme de terminal interactif, pas un démon. Il n'ouvre aucun port d'écoute et n'a aucun service de longue durée, donc il n'y a aucune unité systemd à écrire et aucun port à protéger par pare-feu pour l'agent lui-même. Le confinement est le compte utilisateur et le répertoire du projet, ce qui explique pourquoi la première section de ce guide est celle qui compte le plus.

La machine autour a toujours besoin des soins standard, car un VPS de codage reste un serveur public : SSH par clé uniquement avec la connexion root désactivée, comme dans le durcissement de SSH sur un VPS, un pare-feu par refus par défaut, et des mises à jour régulières. Et passez en revue ce que l'agent produit. Lisez ses diffs avant de les pousser, de la même manière que vous liriez une pull request d'un nouveau contributeur, car c'est vous qui déployez le résultat.

Enfin, gardez l'outil lui-même à jour. OpenCode publie souvent, et les mises à jour apportent des correctifs qui comptent pour un programme qui exécute des commandes sur votre serveur. La mise à jour utilise la même voie que celle par laquelle vous avez installé : réexécutez le script d'installation en tant qu'utilisateur opencode, ou exécutez sudo npm update -g opencode-ai si vous avez installé via npm, puis confirmez la nouvelle version avec opencode --version. Une minute de maintenance de temps en temps coûte moins cher que déboguer un comportement qu'un build vieux de plusieurs mois a déjà corrigé.

FAQ

OpenCode peut-il utiliser un modèle local au lieu d'une API payante ?

Oui. OpenCode traite tout serveur compatible OpenAI comme un fournisseur, donc un modèle servi par Ollama sur le même VPS fonctionne : déclarez le fournisseur dans opencode.json avec le baseURL local et le nom du modèle qu'Ollama rapporte. Le hic, c'est le matériel, car un modèle assez bon pour un vrai travail de codage a besoin de beaucoup de mémoire, alors dimensionnez le serveur pour le modèle avant de le télécharger.

Comment garder OpenCode en cours d'exécution après avoir fermé mon ordinateur portable ?

Exécutez-le dans tmux sur le VPS. Démarrez l'agent dans une session nommée avec tmux new -s opencode, détachez-vous avec Ctrl-b puis d, et la session continue de tourner sur le serveur après la fin de votre connexion SSH. Reconnectez-vous à tout moment avec tmux attach -t opencode et la conversation ainsi que toute tâche en cours sont toujours là. Un redémarrage du serveur met fin à la session, alors démarrez-en une nouvelle après un redémarrage.

Est-il sûr de laisser OpenCode exécuter des commandes sur mon VPS ?

C'est gérable si vous le confinez. Donnez à OpenCode un utilisateur dédié non privilégié sans sudo, gardez ses projets dans git pour que chaque modification soit réversible, stockez la clé API dans un fichier avec le mode 600, et utilisez son agent Plan pour un premier passage en lecture seule avant de laisser l'agent Build changer quoi que ce soit. L'agent ne peut alors endommager que ce que possède son propre compte, et le reste du serveur reste hors de portée.

Quelle est la différence entre OpenCode et Claude Code ?

OpenCode est open source (MIT) et agnostique au fournisseur, se connectant à plus de 75 fournisseurs de modèles, y compris locaux, via une seule interface. Claude Code est l'agent de terminal propre à Anthropic, construit autour des modèles d'Anthropic. Si vous voulez un seul outil pour de nombreux fournisseurs, ou une pile entièrement auto-hébergée avec un modèle local, OpenCode est le bon choix ; les deux fonctionnent bien sur un VPS dans tmux avec la même configuration d'utilisateur non privilégié.