Déployer un agent IA sur VPS Hetzner : guide 2026

Pourquoi Hetzner revient sans cesse pour les agents auto-hébergés

Si vous traînez un peu dans le coin self-hosted de dev.to, Medium ou les groupes indie d'IA sur Telegram, vous avez remarqué le même schéma : quand quelqu'un demande où faire tourner un agent IA toujours allumé pour moins que le prix de deux cafés, la réponse plébiscitée est Hetzner Cloud. La communauté y revient pour deux raisons stables depuis des années : vraies performances CPU par euro et un Cloud Firewall propre que vous pouvez configurer avant même que le serveur démarre.

Ce guide s'adresse au lecteur qui a déjà décidé d'auto-héberger un agent IA (Hermes Agent, OpenClaw, une configuration n8n avec un nœud LLM, ou n'importe quoi d'autre qui appelle une API de modèle depuis un serveur persistant) et qui veut le faire sur Hetzner sans sauter les parties qui comptent à 3h du matin. Dimensionnement, durcissement, Docker Compose, un test Telegram et la liste honnête des choses qui finiront par casser.

Si vous hésitez encore sur le VPS pas cher à prendre, notre comparatif de VPS pas chers couvre l'ensemble du marché. Ce post suppose que Hetzner est déjà choisi.

Étape 1 : choisir le bon plan

Hetzner Cloud, à la mi-2026, scinde ses plans à vCPU partagés en trois lignes :

CX (Intel) - anciens vCPU Intel, en cours de retrait dans certaines régions
CPX (AMD EPYC) - le x86 standard actuel, meilleures performances mono-thread
CAX (ARM Ampere) - la ligne la moins chère, excellent rapport perf/euro

Pour un agent IA piloté par API (qui appelle OpenAI, Anthropic, OpenRouter ou votre propre Ollama et orchestre les outils localement) le plan à viser est le plus petit de l'une de ces lignes :

| Plan | vCPU | RAM | NVMe | Prix UE | Notes | |---|---|---|---|---|---| | CAX11 (ARM) | 2 | 4 Go | 40 Go | ~3,79 €/mois | Option viable la moins chère | | CX22 (Intel) | 2 | 4 Go | 40 Go | ~3,79 €/mois | En cours de retrait dans certaines régions | | CPX11 (AMD) | 2 | 2 Go | 40 Go | ~4,59 €/mois | Meilleur mono-thread x86 | | CPX21 (AMD) | 3 | 4 Go | 80 Go | ~7,55 €/mois | Marge pour un second agent ou un navigateur headless |

Les tarifs en région US sont un peu plus élevés (environ 4,59 à 4,99 USD pour l'équivalent CX22). Hetzner a ajusté ses prix le 15 juin 2026 - les nouvelles commandes paient le nouveau tarif, les serveurs existants gardent l'ancien tant qu'ils ne sont pas redimensionnés.

Recommandation : commencez par CAX11 ou CX22. Deux vCPU et 4 Go de RAM suffisent pour un agent unique, une passerelle Telegram, un petit reverse proxy et le démon Docker, avec de la marge pour une tâche navigateur headless occasionnelle. Si vous prévoyez plusieurs agents, du scraping avec Playwright ou des skills en batch la nuit, montez sur CPX21.

Si le runtime de votre agent ne publie pas encore d'image ARM, restez sur CX22 ou CPX11. La plupart des runtimes populaires (Hermes Agent, OpenClaw, n8n) publient déjà des images linux/arm64, donc la ligne CAX est généralement utilisable.

Étape 2 : provisionner et verrouiller le serveur avant tout SSH

C'est l'étape qu'on saute le plus souvent et qui mord ensuite. Hetzner offre deux firewalls (le Cloud Firewall en bordure et UFW sur l'hôte). Utilisez les deux. Le Cloud Firewall est à configurer avant le démarrage du serveur, pour qu'il n'accepte pas un seul paquet sur un port que vous ne voulez pas ouvrir.

Dans la Console Hetzner, créez un Cloud Firewall avec ces règles entrantes :

TCP 22 uniquement depuis votre IP (ou un petit CIDR si vous avez une plage fixe de bureau)
TCP 80 depuis 0.0.0.0/0, ::/0 (seulement si vous lancez un reverse proxy sur cette machine)
TCP 443 depuis 0.0.0.0/0, ::/0 (seulement si vous avez besoin de HTTPS pour des webhooks ou une UI web)
ICMP depuis 0.0.0.0/0, ::/0 (pour que ping fonctionne en monitoring)

Sortie : laissez le "tout autoriser" par défaut - l'agent doit pouvoir joindre l'API du modèle.

Créez maintenant le serveur, attachez le firewall et choisissez Ubuntu 24.04 LTS. Dans le panneau des clés SSH, ajoutez la clé publique de votre poste. N'autorisez pas la connexion par mot de passe.

Panneau de contrôle sombre photoréaliste avec une icône de bouclier réseau verte lumineuse, illustrant une protection par firewall cloud

Une fois le serveur démarré, connectez-vous en SSH en tant que root et faites immédiatement quatre choses :

# 1. Mises à jour
apt update && apt upgrade -y && apt install -y ufw fail2ban unattended-upgrades

# 2. Créer un utilisateur non-root
adduser --disabled-password --gecos "" agent
usermod -aG sudo agent
mkdir -p /home/agent/.ssh && cp ~/.ssh/authorized_keys /home/agent/.ssh/
chown -R agent:agent /home/agent/.ssh && chmod 600 /home/agent/.ssh/authorized_keys

# 3. Verrouiller SSH
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

# 4. Firewall hôte (UFW), redondant avec le Cloud Firewall mais filet de sécurité utile
ufw default deny incoming && ufw default allow outgoing
ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp
ufw --force enable

Puis activez les mises à jour de sécurité automatiques et fail2ban avec ses réglages par défaut :

dpkg-reconfigure -plow unattended-upgrades   # répondez Yes
systemctl enable --now fail2ban

Par défaut, fail2ban bannit les IPs après 5 tentatives SSH échouées en 10 minutes. Le Cloud Firewall en jette déjà la plupart en bordure, mais fail2ban attrape ce qui passe (un collègue, un runner de CI mal configuré, vous).

Déconnectez-vous de root, reconnectez-vous en tant que agent et continuez depuis là.

Étape 3 : installer Docker

Docker est la façon la plus propre de faire tourner un agent IA sur un VPS en 2026. L'agent reste isolé, les dépendances ne polluent pas l'hôte et les mises à jour tiennent en un pull && up.

# En tant qu'utilisateur agent, avec sudo
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker agent
newgrp docker
docker run --rm hello-world

Si hello-world s'affiche, Docker est prêt.

Étape 4 : déployer l'agent avec Docker Compose

Créez ~/agent/docker-compose.yml sur le serveur. L'exemple ci-dessous est pour Hermes Agent, mais la structure est identique pour OpenClaw, Open WebUI + un fournisseur LLM, ou tout autre runtime d'agent conteneurisé.

services:
  agent:
    image: ghcr.io/your-runtime/agent:latest
    container_name: agent
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./data:/data
      - ./skills:/skills
      - ./memory:/memory
    ports:
      - "127.0.0.1:8080:8080"   # UI web liée à localhost uniquement

Puis créez ~/agent/.env :

# Fournisseur de modèle (BYOK - bring your own key)
OPENAI_API_KEY=sk-...
# Ou l'un de :
# ANTHROPIC_API_KEY=...
# OPENROUTER_API_KEY=...

# Passerelle de messagerie
TELEGRAM_BOT_TOKEN=...
TELEGRAM_ALLOWED_USERS=12345678   # votre ID utilisateur Telegram

# Persistance
DATA_DIR=/data
MEMORY_DIR=/memory

chmod 600 .env pour que les autres utilisateurs de la machine ne puissent pas lire vos clés, puis lancez :

docker compose up -d
docker compose logs -f agent

La politique restart: unless-stopped est ce qui maintient l'agent en vie entre les redémarrages. Si vous préférez une installation native plutôt que Docker, l'équivalent est une unité systemd avec Restart=always et WantedBy=multi-user.target.

Étape 5 : brancher Telegram et tester

Si vous êtes parti sur Telegram comme surface de messagerie (la majorité des self-hosters, parce que la Bot API est gratuite et instantanée), la boucle de test est courte :

Parlez à @BotFather sur Telegram, lancez /newbot, enregistrez le token dans .env.
Parlez à @userinfobot pour récupérer votre ID numérique Telegram et mettez-le dans TELEGRAM_ALLOWED_USERS.
docker compose restart agent.
Ouvrez votre nouveau bot dans Telegram et envoyez "bonjour".

Vous devriez voir une réponse en quelques secondes. Sinon, docker compose logs -f agent pointe presque toujours directement le problème (token manquant, mauvais ID utilisateur, fournisseur de modèle renvoyant 401).

Pour un parcours bien plus approfondi du côté Telegram (groupes, sujets, mode voix, dépannage), voyez comment construire un agent IA sur Telegram.

Gros plan photoréaliste d'un smartphone affichant une bulle de chat en thème sombre avec un accent vert

Étape 6 : sauvegardes et monitoring (la partie que tout le monde saute)

Deux choses peu coûteuses qui se rentabilisent dès qu'un truc casse :

Snapshots Hetzner : dans la Console, activez un snapshot quotidien du serveur. Environ 0,012 €/Go/mois, soit autour de 0,50 €/mois pour un disque de 40 Go. Tagguez-en un "before-update" avant chaque docker compose pull.
Un ping d'uptime : gratuit avec BetterStack ou UptimeRobot. Faites-le frapper https://votre-domaine/health (ou un check TCP) toutes les 5 minutes. La première fois que la passerelle Telegram tombera à 3h du matin, vous le saurez avant le déjeuner et pas pendant.

Pour l'état de l'agent lui-même (fichiers de mémoire, skills, historique), mettez un cron d'une ligne qui empaquette le volume monté dans /var/backups/agent-$(date +%F).tar.gz et fait tourner les vieilles copies. Rsync hebdomadaire vers un autre VPS bon marché, un bucket compatible S3 ou votre poste.

Étape 7 : mises à jour

Une fois par semaine, avec le snapshot déjà pris :

cd ~/agent
docker compose pull
docker compose up -d
docker image prune -f

L'ensemble prend en général moins d'une minute. Si la nouvelle image casse, restaurez le snapshot depuis la Console Hetzner - tout ce que vous perdez, ce sont les conversations entre le snapshot et maintenant, qui vivent dans le volume mémoire de l'agent.

Ce qui finit par casser

Une liste courte et honnête :

Coupures du long-polling Telegram lors de longs hoquets réseau. La plupart des runtimes se reconnectent seuls, mais sinon, le ping d'uptime est ce qui prévient.
docker compose pull apporte un changement de config incompatible. Épinglez le tag de l'image sur une version précise en production plutôt que :latest.
Le fournisseur de modèle vous rate-limit et l'agent arrête de répondre sans erreur évidente. Loggez systématiquement le statut HTTP du fournisseur et privilégiez ceux qui exposent un tableau d'usage.
Un disque se remplit parce qu'une skill écrit dans /tmp sans rotation. du -sh /* et docker system df doivent faire partie de votre mémoire musculaire de debug.
Vous oubliez la règle de firewall en ajoutant un second service. Les deux firewalls (Cloud + UFW) ont besoin du nouveau port, sinon vous passez 20 minutes à débuguer un "connection refused" depuis la bonne adresse.

Aucun de ces points n'est propre à Hetzner. C'est la taxe de tout faire tourner vous-même.

Quand le calcul VPS cesse de tenir

Si vous lisez ceci et que les étapes ci-dessus vous paraissent intéressantes - parfait, c'est exactement le workflow pour lequel Hetzner est bon. Pas cher, rapide, transparent.

Si elles vous paraissent une taxe sur un week-end, la comparaison change. L'hébergement managé échange 4 €/mois et un dimanche après-midi contre une configuration qui inclut déjà la passerelle Telegram, le BYOK chez votre fournisseur, les volumes de mémoire persistante, les snapshots et "ça reste juste en l'air". Notre guide hébergement vs self-hosting fait tous les calculs, y compris ce que vaut votre temps.

Lancez-vous avec Hermify si vous voulez la voie managée - un agent sur infrastructure de production en moins de 30 minutes, sans Cloud Firewall à configurer ni fail2ban à régler. Si vous préférez le faire vous-même sur Hetzner, ce guide devrait vous y mener.