Solutions · Agents de code

Un VPS pour OpenHands

OpenHands est un agent de code autonome : donnez-lui un dépôt et une tâche, et il modifie, exécute, teste et ouvre des pull requests tout seul, avec le modèle de votre choix derrière une clé API. Son propre README indique que la manière la plus puissante de l’utiliser est sur un serveur dans le cloud, et son propre avertissement précise que l’agent a un accès complet à la machine sur laquelle il tourne. Les deux mènent à la même réponse : une machine qui n’est l’ordinateur portable de personne. Le guide serveur du projet juge 2 vCPU et 4 GB largement suffisants pour un utilisateur ; BD-8 à $12.90 par mois lui offre le double, pour moins cher que les machines 4 GB ailleurs.

Déployer BD-8 Comparer toutes les offres

Ce qu’il lui faut

Logiciels issus de la documentation, tailles indiquées avec leur source

Les logiciels et la configuration de sécurité proviennent de la documentation du projet lui-même. Lorsque le projet ne publie aucun chiffre matériel, les tailles indiquent de qui elles viennent.

D’après le README, SELF_HOSTING.md et la documentation d’OpenHands

« 2 vCPU / 4 GB RAM is plenty for a single user » (guide VM du projet : 2 vCPU et 4 GB de RAM suffisent largement pour un seul utilisateur). La documentation demande « un processeur moderne et au minimum 4GB de RAM ».
Installation : Node.js 24 ou plus récent et uv, puis npx @openhands/agent-canvas --public. Une seule commande démarre le serveur d’agents, le backend d’automatisation et l’application web derrière un ingress sur 127.0.0.1:8000.
Définissez LOCAL_BACKEND_API_KEY avant le premier démarrage : en mode public, chaque appel API doit la porter et l’application web la demande avant toute chose. Fermez tout sauf SSH sur le pare-feu d’abord ; le guide demande de le faire avant que l’agent ne s’exécute.
Une clé API d’un fournisseur de modèles : la documentation indique qu’OpenHands en a besoin pour la plupart des modèles. Docker est facultatif et ne sert que si vous voulez isoler chaque conversation dans son propre conteneur. Pas de GPU, sauf si vous hébergez le modèle vous-même.

Tailles (le chiffre du projet, puis le nôtre)

Dimensionnement par usage
Charge de travail	vCPU	RAM
Un utilisateur, modèles hébergés, agent sur l’hôte (officiel)Le chiffre du guide lui-même. Le serveur d’agents tourne directement sur la machine : la machine est le bac à sable.	2	4 GB
Un ou deux utilisateurs, un bac à sable Docker par conversationLe nôtre. Chaque conversation a son conteneur ; installations de dépendances, compilations et suites de tests s’y exécutent.	4	8 GB
Le serveur d’agents partagé d’une équipe, plusieurs agents à la foisLe nôtre. Des agents en parallèle sur des dépôts en parallèle, chacun compilant quelque chose.	8	24 GB

Les offres adaptées

5 machines, prix en temps réel

Machine adaptée la moins chère en premier. Prix du jour, par mois, issus du catalogue.

BD-8$12.90/mois
4 vCPU · 8 GB · 100 GB de disque · 32 TB
Le moins cher avec de la marge pour compiler et tester. 4 vCPU, 8 GB, 100 GB et 32 TB de transfert, pour moins cher que les machines 4 GB ailleurs. Le double du chiffre du guide ; les suites de tests sentent la différence de cœurs.
Déployer
U2-4-40$14.90/mois
2 vCPU · 4 GB · 40 GB de disque · Unmetered
Exactement le chiffre du guide, Unmetered, Istanbul. 2 vCPU / 4 GB / 40 GB. Un utilisateur, modèles hébergés, agent sur l’hôte. Trafic non décompté pour les clonages et les installations de paquets.
Déployer
BD-24$31.90/mois
8 vCPU · 24 GB · 300 GB de disque · 32 TB
8 vCPU / 24 GB pour le serveur d’agents d’une équipe. Plusieurs agents à la fois, bacs à sable Docker, backend d’automatisation planifié.
Déployer
C2-4-80$37.90/mois
2 vCPU · 4 GB · 80 GB de disque · 3 TB
Le chiffre du guide, dans des dizaines de villes. 2 vCPU / 4 GB / 80 GB. À choisir pour la ville ; une conversation à la fois.
Déployer
C4-8-160$75.90/mois
4 vCPU · 8 GB · 160 GB de disque · 3 TB
4 vCPU / 8 GB / 160 GB, dans des dizaines de villes. La taille confortable, avec du disque pour de nombreux checkouts et images Docker.
Déployer

Offres adaptées, avec prix en temps réel
Offre	vCPU	RAM	Disque	Transfert	Prix	Déployer
BD-8Le moins cher avec de la marge pour compiler et tester4 vCPU, 8 GB, 100 GB et 32 TB de transfert, pour moins cher que les machines 4 GB ailleurs. Le double du chiffre du guide ; les suites de tests sentent la différence de cœurs.	4	8 GB	100 GB	32 TB	$12.90/mois	Déployer
U2-4-40Exactement le chiffre du guide, Unmetered, Istanbul2 vCPU / 4 GB / 40 GB. Un utilisateur, modèles hébergés, agent sur l’hôte. Trafic non décompté pour les clonages et les installations de paquets.	2	4 GB	40 GB	Unmetered	$14.90/mois	Déployer
BD-248 vCPU / 24 GB pour le serveur d’agents d’une équipePlusieurs agents à la fois, bacs à sable Docker, backend d’automatisation planifié.	8	24 GB	300 GB	32 TB	$31.90/mois	Déployer
C2-4-80Le chiffre du guide, dans des dizaines de villes2 vCPU / 4 GB / 80 GB. À choisir pour la ville ; une conversation à la fois.	2	4 GB	80 GB	3 TB	$37.90/mois	Déployer
C4-8-1604 vCPU / 8 GB / 160 GB, dans des dizaines de villesLa taille confortable, avec du disque pour de nombreux checkouts et images Docker.	4	8 GB	160 GB	3 TB	$75.90/mois	Déployer

Il n’existe pas encore de préréglage de démarrage pour OpenHands : l’installation consiste en cinq étapes ci-dessous, saisies par vous, dans l’ordre donné par le guide du projet. D’abord le pare-feu, ensuite la clé, puis l’agent.

L’installation

Cinq étapes, dans l’ordre donné par le guide d’OpenHands

Le guide est explicite : le pare-feu passe avant le premier démarrage, car le serveur d’agents a les pleins pouvoirs sur la machine et seuls le pare-feu et la clé le séparent d’un inconnu.

D’abord le pare-feu. ufw allow OpenSSH && ufw --force enable Rien en entrée sauf SSH. L’ingress (8000), le serveur d’agents (18000), le backend d’automatisation (18001) et le serveur statique (3001) ne doivent pas être accessibles de l’extérieur ; le guide le dit en ces termes.
Node.js 24 et uv. apt-get install -y curl git curl -fsSL https://deb.nodesource.com/setup_24.x | bash - && apt-get install -y nodejs curl -LsSf https://astral.sh/uv/install.sh | sh uv exécute le serveur d’agents ; le guide l’installe avec le programme d’installation en une ligne d’astral.sh.
Générez la clé, démarrez en mode public. export LOCAL_BACKEND_API_KEY=$(openssl rand -base64 32); echo $LOCAL_BACKEND_API_KEY npx @openhands/agent-canvas --public Copiez la clé en lieu sûr avant de continuer ; en mode public, l’application web vous la demandera. Pour un fonctionnement durable, l’unité systemd du guide dans /etc/systemd/system/agent-canvas.service avec Environment=LOCAL_BACKEND_API_KEY=…, puis systemctl enable --now agent-canvas.
Accédez-y en SSH, ajoutez le modèle. ssh -N -L 8000:127.0.0.1:8000 root@your-server puis http://127.0.0.1:8000, collez la clé, puis Settings : choisissez le fournisseur de LLM et le modèle, et collez la clé API de ce fournisseur. Lancez une conversation sur un dépôt.
En option, un domaine. Pointez un enregistrement A vers le serveur, ouvrez 80 et 443, apt-get install -y nginx certbot python3-certbot-nginx, et ajoutez le bloc nginx du guide qui fait proxy vers 127.0.0.1:8000 avec les en-têtes WebSocket ; certbot --nginx -d canvas.example.com --redirect obtient le certificat. Si 443 doit être ouvert à tous, le guide précise que la clé est votre principale défense : gardez-la longue et secrète.

En toute franchise

Ce que nous achèterions vraiment

Le guide indique que 2 vCPU et 4 GB suffisent largement pour un utilisateur. Prenez la machine 8 GB qui coûte moins que les machines 4 GB et laissez l’agent compiler.

Pour l’agent de code d’une personne

BD-8 · $12.90/mois

4 vCPU, 8 GB et 100 GB pour $12.90 : le serveur de l'agent, quelques dépôts clonés, leurs arbres de dépendances et une suite de tests qui s'exécute sous vos yeux, avec de la mémoire en réserve si vous activez les sandboxes Docker. Le modèle est ailleurs, derrière une clé API : cette machine n'a donc jamais besoin de GPU, et la facture qui compte est celle du fournisseur. C2-4-80 à $37.90 correspond exactement au chiffre du guide, dans des dizaines de villes, si la ville compte davantage que le nombre de cœurs.

Déployer BD-8 C2-4-80 dans des dizaines de villes

Questions

Les questions posées avant l’achat.

De combien de RAM OpenHands a-t-il besoin ?

Le guide VM du projet indique que 2 vCPU et 4 GB de RAM suffisent largement pour un seul utilisateur, et sa documentation recommande un processeur récent et au moins 4 GB. Cela couvre le serveur d’agents, le backend d’automatisation et l’application web avec des modèles hébergés. Ce que fait ensuite l’agent (cloner des dépôts, installer des dépendances, lancer compilations et tests) est un travail de développeur ordinaire qui demande des ressources de développeur ordinaires ; c’est pourquoi la machine la moins chère de cette page a 4 cœurs et 8 GB plutôt que le strict minimum.

Pourquoi l'exécuter sur un serveur plutôt que sur mon ordinateur portable ?

Deux raisons, tirées du README lui-même. Il indique que la manière la plus puissante d’exécuter OpenHands est sur un serveur dans le cloud, pour que les agents continuent de tourner quand votre portable est fermé et puissent être déclenchés depuis Slack, GitHub ou un webhook. Et il avertit que le serveur d’agents tourne directement sur la machine avec un accès complet au système de fichiers, au shell et au réseau. Une machine qui ne contient que l’agent et les dépôts sur lesquels il travaille est la manière honnête de lui donner cet accès.

Faut-il une clé API, ou peut-il utiliser un modèle local ?

Sa documentation indique qu’OpenHands nécessite une clé API pour accéder à la plupart des modèles de langage, et liste les fournisseurs hébergés qu’elle recommande. Un modèle local via Ollama ou un serveur similaire est pris en charge, mais la documentation ajoute qu’un travail d’agent efficace avec des modèles locaux exige du matériel performant et des modèles entraînés à suivre des instructions. En pratique : un modèle hébergé et une clé API sur cette machine, et si vous voulez un modèle local, un serveur de modèles distinct, dimensionné d’après la page Ollama ou la gamme GPU.

Que font --public et LOCAL_BACKEND_API_KEY ?

Sans --public, l'application injecte sa clé de session dans la page web par commodité, ce que le README qualifie de dangereux pour un déploiement accessible publiquement. Avec --public, la clé n'est pas dans la page : toute personne qui ouvre l'application web doit d'abord coller LOCAL_BACKEND_API_KEY, et chaque appel à l'API doit la transmettre. L'ordre indiqué par le guide est : pare-feu, puis clé, puis démarrage, et il génère la clé avec openssl rand -base64 32.

Ai-je besoin de Docker ?

Pas pour l’installation par défaut, qui exécute le serveur d’agents sur l’hôte avec Node 24 et uv. Docker sert aux modes isolés : exécuter toute la pile depuis l’image du projet, ou donner à chaque conversation son propre conteneur pour que plusieurs agents travaillent en même temps sans partager de système de fichiers. Le README précise que le bac à sable isole l’exécution des conversations, pas l’application entière. Si vous le souhaitez, installez Docker et prévoyez la ligne 8 GB ou plus.

Quels ports sont concernés ?

Tout écoute sur le loopback : le proxy d’ingress sur 127.0.0.1:8000 achemine vers le serveur statique sur 3001, le serveur d’agents sur 18000 et le backend d’automatisation sur 18001. Vous accédez à 8000 par un tunnel SSH, ou via nginx sur 443 si vous ajoutez un domaine. Aucun de ces quatre ports ne doit être ouvert sur le pare-feu ; le guide les cite par leur numéro comme ceux qui ne doivent pas être accessibles de l’extérieur.

Poursuivre la lecture