Faire tourner un agent IA 24/7 sur un VPS.
Hors de votre ordinateur portable, sur du métal qui ne dort jamais.
Pour faire tourner un agent IA 24/7 sur un VPS, il vous faut quatre choses, aucune d’elles n’étant sophistiquée : une machine qui reste debout, un superviseur qui la redémarre, des secrets qui n’entrent jamais dans l’image, et un plafond de dépense — plus un hébergeur qui n’exige pas votre identité.
- 01
La plupart des agents ne sont qu’une glue liée aux I/O autour d’une API de modèle hébergée. L’inférence ne se fait pas sur votre machine, donc la machine reste petite : 2 vCPU et 4 GB suffisent à faire tourner un agent à boucle unique.
- 02
La disponibilité est un problème de superviseur, pas de matériel. Une unit systemd ou une politique de redémarrage Docker — activée, et testée avec un vrai redémarrage — c’est tout ce qu’il faut.
- 03
Les deux choses qui font vraiment mal : un secret figé dans une couche d’image, et un agent sans plafond de dépense qui boucle toute la nuit contre une API facturée à l’usage.
Pourquoi votre ordinateur portable n’est pas un déploiement. Quatre modes de défaillance, tous aussi ennuyeux les uns que les autres.
Un agent qui fonctionne sur votre machine est un agent qui marche, pas un agent déployé. L’écart tient à quatre problèmes peu glorieux, dont aucun ne concerne le prompt engineering.
La veille. Fermez le capot et le processus est suspendu. La gestion de l’alimentation bride le travail en arrière-plan bien avant que le capot ne se ferme, ce qui produit la pire version de cette panne : un agent qui tourne, mais en retard et de façon imprévisible.
Le renouvellement d’IP. Une connexion à domicile ou dans un café vous attribue une nouvelle adresse à chaque reconnexion. Tout ce qui est limité par IP, tout webhook nécessitant un callback stable, toute allowlist que vous avez enregistrée se casse par intermittence.
Les redémarrages. Les mises à jour du système d’exploitation redémarrent la machine selon leur propre calendrier. À moins que l’agent ne soit enregistré auprès d’un gestionnaire de services, la machine revient sur un bureau, pas sur une boucle en cours d’exécution. La plupart des gens s’en rendent compte une semaine plus tard.
Le déménagement. Vous voyagez, vous changez de machine, vous réinstallez. Tout ce qui ne vit que dans l’historique de votre shell n’est pas reproductible — un agent configuré un après-midi de mars n’a tout simplement aucune procédure de déploiement.
Un serveur règle ces quatre problèmes et rien d’autre — ni la justesse, ni le coût, ni la sécurité. Il vous donne un environnement d’exécution dont les pannes sont les vôtres à corriger. Méfiez-vous de quiconque vous le vend comme davantage.
Dimensionner la machine. Quel palier de VPS pour quelle forme d’agent.
Le réflexe est de surdimensionner, parce que l’intelligence artificielle a l’air lourde. Ce n’est pas le cas, tant que le modèle tourne sur le matériel de quelqu’un d’autre : un agent qui appelle une API hébergée passe son temps à attendre des I/O réseau. Une troisième forme — faire tourner le modèle lui-même — sort du cadre ici ; cette charge de travail veut un GPU bien plus qu’une machine virtuelle.
Forme un — la boucle unique. Un seul processus, une boucle de polling ou planifiée, une API de modèle hébergée, un état dans SQLite. C’est le cas de la plupart des agents indépendants et des bots de surveillance, et c’est réellement léger.
Forme deux — la petite pile. L’agent plus Postgres, une file d’attente adossée à Redis, un worker et un vector store. La mémoire devient désormais la contrainte limitante — un modèle d’embedding chargé dans le processus réclame un gigaoctet ou deux à lui seul.
Face au catalogue : Sentinel (NB-V1 — 2 vCPU, 4 GB RAM, 120 GB NVMe, 1 Gbps, bande passante illimitée, $3.90/month) couvre la forme un très largement. Garrison (NB-V2 — 4 vCPU, 8 GB, 240 GB, $7.90/month) est le plancher honnête pour la forme deux dès que Postgres et une file d’attente entrent en jeu. Ravelin (NB-V3 — 8 vCPU, 16 GB, 480 GB, 2.5 Gbps, $16.90/month) convient à plusieurs agents partageant une même machine. L’inférence locale relève du matériel dédié.
La facturation se fait au mois, avec une remise sur les engagements plus longs — 10% à trois mois, 20% à six, 30% à douze. Si votre agent est un client de trading exclusivement Windows plutôt qu’un processus Python, les paliers de bureau à distance existent pour ce cas.
Le chemin de déploiement — faire tourner un agent IA sur un VPS en environ quinze minutes.
Provisionnez la machine avec Ubuntu 24.04 LTS ou Debian 13 — tous deux proposés à la commande, avec Ubuntu 22.04, Debian 12, AlmaLinux 9 et Rocky Linux 9. Vous obtenez des identifiants root ; la première chose à en faire est d’arrêter de les utiliser. Si l’authentification par clé SSH est un territoire inconnu, lisez d’abord le guide de durcissement lié plus bas.
1 — Créer un utilisateur de service. adduser --system --group --home /srv/agent agent. L’agent ne doit pas tourner en root et ne doit pas posséder de shell interactif. Une commande maintenant, et le rayon de dégâts reste réduit plus tard si un outil qu’il appelle se retourne contre lui.
2 — Faire arriver le code sur la machine. git clone dans /srv/agent, ou rsync si vous préférez ne pas laisser de clé de déploiement sur le serveur. Figez les dépendances : un lockfile fait toute la différence entre un redéploiement qui se reproduit fidèlement et un autre qui vous surprend.
3 — Construire l’environnement. python3 -m venv /srv/agent/.venv, puis installez depuis le lockfile avec le pip de ce virtualenv. Ou bien installez uv et laissez-le gérer à la fois l’interpréteur et le lockfile. Les deux approches conviennent ; les mélanger, non.
4 — L’exécuter une fois à la main. sudo -u agent /srv/agent/.venv/bin/python -m agent --once. Ne sautez pas cette étape pour passer directement à une unit de service. Neuf échecs sur dix, ici, tiennent à une variable d’environnement manquante ou à un chemin relatif à votre ordinateur portable, et les deux se lisent plus clairement dans un terminal que dans journald.
5 — Le confier à un superviseur. C’est l’objet du chapitre suivant. C’est ce qui transforme un script que vous avez lancé en un service dont la machine est propriétaire. Si la séquence a pris nettement plus de quinze minutes, la cause est presque toujours une dépendance implicite à votre machine de développement — un binaire global, un identifiant dans votre profil de shell, un chemin situé hors du dépôt.
Le maintenir en vie 24/7. systemd, Docker, et le piège de la boucle de plantage.
Un processus que vous avez lancé depuis une session SSH meurt quand la session se termine, et ne revient pas après un redémarrage. La supervision n’est pas optionnelle, et vous avez deux options raisonnables.
systemd, pour un processus unique. Une unit dans /etc/systemd/system/agent.service avec User=agent, WorkingDirectory=/srv/agent, ExecStart pointant vers l’interpréteur du virtualenv, Restart=always et RestartSec=5. Puis systemctl daemon-reload, puis systemctl enable --now agent. C’est l’enable qui survit à un redémarrage ; démarrer sans activer est la façon la plus courante de perdre un agent trois semaines plus tard.
Docker, pour un ensemble de choses. Quand l’agent a des processus frères — une base de données, une file d’attente, un navigateur headless — décrivez-les dans un seul fichier Compose avec restart: unless-stopped sur chaque service. unless-stopped diffère d’always sur un point qui compte : un conteneur que vous avez délibérément arrêté reste arrêté même après un redémarrage du daemon.
Le piège de la boucle de plantage. systemd limite le débit des redémarrages par défaut. Plantez assez souvent dans l’intervalle et l’unit passe à l’état failed et arrête d’essayer — un agent qui semble être mort silencieusement alors que le fichier unit affiche pourtant Restart=always. Réglez StartLimitIntervalSec=0 pour réessayer indéfiniment, et augmentez RestartSec pour qu’un agent cassé ne fasse pas tourner un cœur à plein régime toute la nuit.
Être vivant n’est pas être en bonne santé. Une boucle bloquée sur une lecture de socket pendant neuf heures est un processus en cours d’exécution selon tout ce que systemd peut mesurer. Exposez un signal de vie : un watchdog avec WatchdogSec, un HEALTHCHECK Docker, ou un fichier horodaté que l’agent touche à chaque cycle, avec un timer qui alerte quand il devient périmé.
Les secrets. Le fichier d’environnement qui ne doit jamais atteindre l’image.
Un agent détient un matériel plus dangereux qu’une application web. Une clé d’API de modèle est un instrument de dépense ; une clé de trading en est une avec effet de levier ; une clé de wallet, ce sont les fonds eux-mêmes. Et contrairement à une application web, un agent agit sur du texte qu’il n’a pas écrit, ce qui rend ténue la frontière entre l’agent qui détient une clé et un attaquant qui la détiendrait.
Les garder hors de l’image. Les valeurs ENV et ARG d’un Dockerfile sont écrites dans les couches de l’image et lisibles avec docker history par quiconque obtient l’image. Utilisez env_file: dans Compose, ou EnvironmentFile= dans l’unit systemd, et gardez le fichier en dehors du contexte de build.
Les garder hors du dépôt. .gitignore et .dockerignore dès le premier commit, pas le cinquantième. Une clé qui a un jour été commitée est compromise même après la réécriture du commit, car l’objet survit dans les clones et les forks. Faites-la tourner (rotation) plutôt que de réécrire l’historique.
Restreindre ce que le fichier peut atteindre. Faites appartenir le fichier d’environnement à l’utilisateur du service et réglez le mode 600. Combiné à un utilisateur de service non-root, une dépendance compromise ailleurs sur la machine ne peut pas simplement lire vos clés sur le disque.
Restreindre la portée de chaque clé chez l’émetteur. Une clé par agent, avec les permissions les plus restreintes que le fournisseur propose — lecture seule là où la lecture suffit, retrait désactivé sur les clés d’exchange, allowlist IP limitée au serveur. Une IP stable est un avantage discret de quitter un ordinateur portable : l’allowlisting devient enfin possible. Si plusieurs personnes ont besoin des mêmes identifiants, placez-les derrière le coffre auto-hébergé du guide compagnon.
La planification. Boucles, timers et le fuseau horaire qui vous mord.
« Tourner en continu » recouvre trois architectures différentes, et choisir la mauvaise est une source fréquente de travail dupliqué et d’exécutions manquées.
La boucle résidente. Un seul processus longue durée qui dort entre les cycles. C’est le plus simple à appréhender, et le bon choix par défaut. Sa faiblesse est l’état : tout ce qui est en mémoire est perdu au redémarrage, donc tout ce qui doit survivre à un plantage doit se trouver dans SQLite ou Postgres, pas dans une variable.
L’exécution planifiée. Un processus qui démarre, effectue une unité de travail et se termine. Un timer systemd avec OnCalendar est le meilleur outil ici, surtout grâce à Persistent=true : après une interruption, un timer persistant déclenche l’exécution qu’il a manquée, alors que cron la saute simplement.
La file d’attente. Un producteur met des tâches en file, des workers les consomment. C’est ce qu’il vous faut dès que les tâches arrivent plus vite qu’elles ne se terminent. Cela vous donne aussi les réessais, la gestion des dead-letters et un plafond de concurrence.
Deux règles quel que soit votre choix. Rendez chaque tâche idempotente — un superviseur qui redémarre après un plantage va réessayer des tâches, et une tâche réessayée ne doit pas publier ou commander en double. Et laissez l’horloge du serveur en UTC, en ne convertissant qu’aux frontières : un planning qui glisse d’une heure deux fois par an est un bug fastidieux à trouver.
Donner des outils à l’agent. Un serveur d’outils sur la même machine.
Un agent sans outils n’est qu’une boucle de discussion. Ce sont les outils qui lui permettent de lire un dépôt, d’interroger une base de données, de passer une commande ou d’ouvrir un ticket — et une fois que l’agent vit sur un serveur, eux aussi le devraient.
Le Model Context Protocol est devenu la façon courante d’exposer ces outils, et un serveur que vous faites tourner en privé est facile à placer à côté de l’agent : même machine, même interface privée, aucune exposition publique nécessaire. Les guides compagnons couvrent cela en détail — héberger un serveur MCP distant parcourt TLS, le transport streamable-HTTP, OAuth et la carte d’agent, tandis que l’angle hébergement sans KYC couvre la même pile côté identité.
Le lier à localhost d’abord. Si le seul consommateur est l’agent sur la même machine, le serveur d’outils n’a aucune raison d’occuper un port public. Liez-le à l’adresse de loopback et faites l’impasse sur le certificat. Ne l’exposez publiquement que lorsqu’une seconde machine en a besoin — et alors il lui faut TLS et l’authentification, pas l’un des deux seulement.
Donner aux outils le moins d’autorité qui fonctionne. L’agent décide quel outil appeler en se basant sur du texte, et une partie de ce texte vient de l’extérieur. L’injection de prompt n’est pas hypothétique pour un agent qui lit des pages web ou des boîtes de réception : c’est le cas attendu. Un outil qui ne peut que lire ne peut pas être convaincu d’écrire. Là où un outil doit écrire, exigez une confirmation humaine sur les chemins destructeurs.
Si vous construisez des outils pour les agents d’autres personnes plutôt que pour le vôtre, l’API machine et la surface orientée agents documentent comment cette plateforme expose le provisioning directement à un agent.
Observabilité et coût. Quoi journaliser, et le kill-switch en cas d’emballement.
Deux modes de défaillance dominent les déploiements réels d’agents, et aucun des deux n’est un plantage. Le premier est l’agent qui tourne parfaitement et ne produit rien d’utile. Le second est l’agent qui tourne parfaitement et produit une facture d’API à quatre chiffres du jour au lendemain.
Journaliser la forme, pas le contenu. Horodatage, id de tâche, nombre d’étapes, noms des outils invoqués, totaux de tokens, durée, résultat. Cela répond à toutes les questions opérationnelles que vous poserez réellement. Les prompts et completions complets sont une transcription de tout ce qu’on a jamais demandé à l’agent de faire, en clair, sur un disque situé dans le bâtiment de quelqu’un d’autre.
Plafonner la rétention. journald continue de grossir tant que vous ne lui dites pas d’arrêter. SystemMaxUse et MaxRetentionSec dans journald.conf plafonnent à la fois la taille et l’ancienneté. Un agent bavard remplit sinon un disque en quelques semaines, et un disque plein échoue de façons bien plus difficiles à lire qu’un plantage propre.
Trois couches de contrôle de la dépense. Chez le fournisseur, un plafond strict sur la clé API — la seule limite qu’aucun bug de votre code ne peut contourner, et celle que tout le monde saute. Dans l’agent, un compteur de tokens par exécution avec un seuil d’interruption. Autour de l’agent, un nombre d’étapes maximal et un timeout en temps réel, pour qu’un modèle qui discute avec lui-même s’arrête après vingt itérations plutôt que quatre mille.
Construire le kill-switch avant d’en avoir besoin. Une seule commande qui arrête tout : systemctl stop agent, ou docker compose down. Assurez-vous qu’elle n’exige pas un ordinateur portable avec une clé spécifique dessus. La différence entre une mauvaise nuit et un mauvais mois tient à ce qu’arrêter un emballement prenne dix secondes ou une heure.
Le plancher identitaire. Ce que l’hébergeur sait — et ce dont il ne peut pas vous protéger.
Un agent est un processus longue durée doté d’identifiants, agissant en votre nom depuis une adresse stable, en continu. Cela rend la trace de la location plus révélatrice que pour un site statique : il fait des choses qui vous sont attribuables, chaque heure, pendant des mois.
Le plancher, ici, c’est une adresse e-mail et un mot de passe pour s’inscrire, un paiement parmi huit actifs — Bitcoin, Ethereum, Tether sur deux chaînes, Monero, Litecoin, TRON et Solana — et aucun document d’identité à aucune étape. Les datacenters se trouvent dans quatre régimes constitutionnels nordiques : Stockholm, Helsinki, Oslo et Reykjavík. La doctrine d’exploitation précise ce qui est conservé ; la page réseau couvre le routage.
Vient maintenant la limite, qui compte plus que l’argument commercial. Un hébergeur qui ne demande aucune identité supprime la trace de la location. Il ne touche pas à la couche d’inférence : votre agent s’authentifie auprès d’un fournisseur de modèle avec une clé rattachée à un compte, depuis une IP stable, à chaque appel. Si ce compte est à votre nom légal — et pour la plupart des gens, c’est le cas — l’identité y est établie, quel que soit celui qui loue le métal. La couche hébergement supprime un maillon : un vrai, et un seul.
Ce qui suit n’a rien de glorieux. Compartimentez : un agent, un serveur, une clé, un wallet. Durcissez la machine dès le premier jour plutôt que le trentième — la checklist de la première heure est une heure bien investie sur une machine qui tourne sans surveillance pendant des mois. Si l’agent doit atteindre un réseau privé, terminez-le sur le serveur avec un tunnel plutôt que d’exposer des services — le guide du tunnel couvre la configuration. Et payez en crypto depuis un wallet qui n’est pas celui d’où trade votre agent.
Rien de tout cela n’est exotique, et rien de tout cela n’est une garantie. C’est la discipline ordinaire qui consiste à faire tourner quelque chose qui agit en votre nom pendant que vous dormez — ce qui est tout ce que « fonctionnement continu » signifie. Le reste du cluster se trouve sur l’index des guides.
Questions, réponses.
Sept questions que se posent les développeurs avant de sortir un agent de localhost — et pendant le premier mois qui suit.
De quel VPS ai-je besoin pour faire tourner un agent IA 24/7 ?
Moins qu’on ne le pense, car l’inférence s’exécute sur le matériel du fournisseur, pas sur le vôtre. Un agent qui appelle une API de modèle hébergée et fait tourner une boucle de polling est un processus lié aux I/O : le palier Sentinel (2 vCPU, 4 GB RAM, 120 GB NVMe, $3.90/month) convient très bien. Passez à Garrison (4 vCPU, 8 GB, $7.90/month) dès que vous ajoutez Postgres, une file d’attente et un modèle d’embedding local.
Faut-il utiliser systemd ou Docker pour maintenir l’agent actif ?
Les deux fonctionnent ; ce sont les modes de défaillance qui diffèrent. Une unit systemd avec Restart=always est le chemin le plus court pour un processus unique et vous donne journald, les limites de ressources et l’ordonnancement au démarrage gratuitement. Docker avec restart: unless-stopped est préférable quand l’agent a des processus frères, car Compose décrit l’ensemble en un seul fichier. Ce qui compte le plus, c’est de réellement l’activer (enable), et de tester un redémarrage avant de passer à autre chose.
Pourquoi mon agent arrête-t-il de redémarrer après quelques plantages ?
Parce que systemd limite le débit des redémarrages. StartLimitBurst et StartLimitIntervalSec autorisent un petit nombre de redémarrages sur une courte fenêtre ; dépassez-les et l’unit passe à l’état failed et y reste, ce qui ressemble exactement à une mort silencieuse. Soit vous corrigez le plantage sous-jacent — la bonne réponse — soit vous réglez StartLimitIntervalSec=0 pour désactiver le limiteur, et RestartSec=10 pour qu’un agent en boucle de plantage ne brûle pas un cœur entier à réessayer.
Où placer les clés d’API ?
Dans un fichier que l’image du conteneur ne voit jamais. Conservez un fichier d’environnement en dehors du contexte de build, référencé par EnvironmentFile= dans l’unit systemd ou env_file: dans Compose, appartenant à l’utilisateur du service avec le mode 600. N’utilisez jamais ENV ou ARG dans un Dockerfile pour un secret : ces valeurs sont figées dans les couches de l’image et lisibles avec docker history. Ajoutez le fichier à .gitignore et .dockerignore avant le premier commit.
Comment empêcher un agent de dépenser tout mon budget API en une nuit ?
Trois couches, et vous voulez les trois. Chez le fournisseur : un plafond de dépense strict sur la clé API, la seule limite qu’aucun bug de votre code ne peut contourner. Dans l’agent : comptez les tokens ou les appels par exécution et interrompez au-delà d’un seuil. Autour de l’agent : un plafond d’étapes par tâche et un timeout en temps réel. Aucun hébergeur ne peut faire cela à votre place — un VPS est de la capacité louée, pas un garde-fou budgétaire sur l’API de quelqu’un d’autre.
Que ne faut-il jamais écrire dans les journaux de l’agent ?
Les prompts et les completions complets, les arguments bruts des outils, les clés API, le matériel de wallet et tout ce qu’un utilisateur a tapé. Journalisez plutôt la forme de l’exécution : horodatage, id de tâche, nombre d’étapes, noms des outils, totaux de tokens, durée, résultat. Un journal d’agent verbeux est une transcription de tout ce qu’on a jamais demandé à l’agent de faire, en clair, sur un disque que vous ne contrôlez pas physiquement.
Un hébergeur sans KYC rend-il mon agent anonyme ?
Non, et il vaut la peine d’être précis. Une inscription sans pièce d’identité et un paiement en crypto signifient que l’hébergeur n’a aucune identité légale à rattacher au serveur. Cela ne change rien au fournisseur de modèle : votre agent s’authentifie auprès de cette API avec une clé rattachée à un compte, depuis une IP de serveur stable, à chaque appel. La couche hébergement supprime un maillon de la chaîne — la trace de la location — et c’est tout ce qu’elle supprime.
Louez un VPS sans KYC, payez en crypto, sortez l’agent de votre ordinateur portable dès ce soir.
Sentinel — 2 vCPU, 4 GB RAM, 120 GB NVMe, bande passante illimitée, $3.90/month — porte un agent à boucle unique avec de la marge pour son serveur d’outils à côté. Une adresse e-mail et un mot de passe pour s’inscrire ; aucun document à aucune étape.
Dernière révision · 2026-08-24 · Références · Pages de manuel systemd.service, systemd.timer et journald.conf, documentation Docker restart-policy et Compose, spécification du Model Context Protocol, catalogue NordBastion · Fréquence · annuellement
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Docker Compose, PostgreSQL, des webhooks qui fonctionnent — une automatisation qui vous appartient.
Ollama sur CPU, sans GPU — ce qui tient dans 4, 8, 16 ou 32 Go.