Déployer un agent IA sur un Droplet DigitalOcean (2026)

Pourquoi tout le monde finit sur DigitalOcean pour héberger un agent IA

Quand vous décidez d'auto-héberger un agent IA, vous tombez tôt ou tard sur le même trio : Hetzner, AWS EC2 ou DigitalOcean. Chacun attire un public. Hetzner attire l'optimiseur de coûts européen. AWS attire les équipes "dans ma boîte on est déjà dessus". DigitalOcean attire l'indie SaaS qui veut une machine Ubuntu propre, un joli panneau de contrôle, une image 1-Click Docker officielle et une documentation qui ne présume pas de votre équipe.

Une autre raison explique la présence disproportionnée de DigitalOcean dans ce créneau : la DigitalOcean Community publie un catalogue croissant de tutoriels sur les agents IA et d'images 1-Click au Marketplace (Docker Agent, Ollama, bases pensées pour les agents) qui raccourcissent la première heure d'installation. Si votre runtime d'agent est déjà livré comme conteneur, la moitié de la bataille "mettre un agent en ligne" est déjà gagnée.

Ce guide s'adresse à celles et ceux qui ont choisi DigitalOcean et veulent monter un agent auto-hébergé (Hermes Agent, un workflow n8n avec un nœud LLM, un proxy OpenAI Assistants, tout ce qui appelle une API modèle depuis un serveur toujours allumé) sans sauter ce qui compte à 3 h du matin. Dimensionnement, hardening, Docker Compose, un test Telegram et la liste honnête de ce qui va casser.

Si vous hésitez encore sur le fournisseur, notre guide Hetzner et le comparatif des VPS pas chers couvrent le reste. Ce post part du principe que vous avez choisi DigitalOcean.

Étape 1 : choisir le bon Droplet

La gamme de CPU partagés de DigitalOcean en 2026 se décline en trois groupes visibles à la création d'un Droplet :

Regular Intel - les vCPU partagés classiques, les plus anciens et lents par dollar
Premium Intel / Premium AMD - puces plus récentes, single-thread plus rapide
Basic AMD (facturation à la seconde) - le sweet spot actuel pour les petits services

Pour un agent piloté par API (qui appelle OpenAI, Anthropic, OpenRouter ou votre propre Ollama et orchestre les tool calls localement), l'inférence tourne côté fournisseur. Le Droplet ne fait tourner que le processus de l'agent, une passerelle Telegram et le daemon Docker : vous n'avez pas besoin de beaucoup de CPU. La contrainte, c'est la RAM.

Plan	vCPU	RAM	NVMe	Prix	Verdict
s-1vcpu-512mb-10gb	1	512 Mo	10 Go	4 $/mois	Trop juste, OOM au premier chargement d'une skill
s-1vcpu-1gb	1	1 Go	25 Go	6 $/mois	Convient à un agent minimal en appels API
s-1vcpu-2gb	1	2 Go	50 Go	12 $/mois	Convient à un agent, aucune marge pour un second service
s-2vcpu-4gb-amd	2	4 Go	80 Go	28 $/mois	Choix recommandé : agent + mémoire + Playwright + reverse proxy
s-2vcpu-4gb (Intel)	2	4 Go	80 Go	24 $/mois	Mêmes specs, CPU plus ancienne

DigitalOcean est passée à la facturation à la seconde (60 s minimum) le 1er janvier 2026 : un Droplet monté pour tester et détruit le même après-midi coûte des centimes, pas un mois. Chaque Droplet inclut un quota de trafic (1 To sur le tier 6 $, 4 To sur le tier 24-28 $), largement suffisant pour un agent qui relaye surtout des messages de chat.

Recommandation : commencez sur s-2vcpu-4gb-amd. Deux vCPU et 4 Go de RAM laissent de la marge pour l'agent, un petit polling IMAP, une skill à navigateur headless et un reverse proxy, sans mauvaise surprise OOM la première fois que le backend mémoire écrit un lot sur disque. Si votre unique charge est un agent de chat contre un modèle cloud, le tier 6 $ (s-1vcpu-1gb) suffit vraiment.

Sautez le tier 4 $ dès qu'il faut faire tourner Docker plus un volume mémoire plus une passerelle Telegram. Il franchira le seuil OOM en une semaine.

Étape 2 : verrouillez le Droplet avant tout SSH

C'est l'étape que l'on saute et qui fait mal ensuite. DigitalOcean fournit un Cloud Firewall au niveau de l'hyperviseur, avant même que les paquets n'atteignent la VM. Configurez-le avant le démarrage du Droplet pour que la machine n'accepte jamais un paquet sur un port que vous n'aviez pas prévu d'ouvrir.

Dans la console DigitalOcean, allez dans Networking > Firewalls > Create Firewall. Règles entrantes :

SSH (TCP 22) depuis My IP uniquement (ou un petit CIDR si vous avez une IP fixe de bureau)
HTTP (TCP 80) depuis All IPv4, All IPv6 (uniquement si vous exposez un reverse proxy)
HTTPS (TCP 443) depuis All IPv4, All IPv6 (uniquement pour des webhooks HTTPS ou une UI web)
ICMP depuis All IPv4, All IPv6 (pour que les pings de monitoring fonctionnent)

Sortant : gardez les valeurs par défaut - l'agent doit joindre l'API modèle. Attachez ce firewall au Droplet dès la création. Ne créez pas le Droplet d'abord pour lui greffer le firewall ensuite.

Pour un setup plus solide, fermez totalement le port 22 à Internet et rejoignez la machine via Tailscale. DigitalOcean propose une 1-Click Tailscale et la documentation Tailscale couvre le workflow "fermer le port 22 pour de bon". Le Cloud Firewall jette les tentatives SSH au bord du réseau : elles n'atteignent même pas fail2ban ni vos logs.

À la création du Droplet, choisissez Ubuntu 24.04 LTS, collez votre clé publique SSH, attachez le firewall et cliquez Create. Une fois le Droplet en ligne, connectez-vous en SSH en root et faites immédiatement quatre choses :

# 1. Mise à 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 un bon filet
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 :

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

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

Étape 3 : installer Docker (ou utiliser l'image 1-Click)

Vous avez deux voies.

Voie A : installer Docker sur Ubuntu vierge. Standard, une seule ligne, marche partout :

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker agent
newgrp docker
docker run --rm hello-world

Voie B : utiliser l'image Docker du Marketplace DigitalOcean. Depuis la page de création, choisissez Marketplace > Docker (Ubuntu 24.04 avec Docker préinstallé). Vous sautez l'installation et vous partez d'un setup déjà configuré. Même résultat, une commande de moins.

Si votre runtime publie une image 1-Click officielle sur DigitalOcean (Docker Agent, Ollama et une liste qui s'allonge le font), vous pouvez aller plus loin et utiliser directement cette image, puis composer uniquement votre fichier d'env et vos volumes.

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

Créez ~/agent/docker-compose.yml. L'exemple est générique ; remplacez la référence d'image par le runtime que vous utilisez.

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 bindée sur localhost uniquement

Puis ~/agent/.env :

# Fournisseur de modèle (BYOK - apportez votre clé)
OPENAI_API_KEY=sk-...
# ou ANTHROPIC_API_KEY / OPENROUTER_API_KEY

# Passerelle messagerie
TELEGRAM_BOT_TOKEN=...
TELEGRAM_ALLOWED_USERS=12345678

# 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 on lance :

docker compose up -d
docker compose logs -f agent

restart: unless-stopped, c'est ce qui garde l'agent vivant à travers les redémarrages du Droplet (DigitalOcean en fait de temps en temps pour maintenance).

Attacher un Volume persistant

Le disque racine du Droplet suffit au conteneur, mais l'état de l'agent (mémoire, skills, historique de conversations) mérite un Volume DigitalOcean à part. Il survit à la destruction du Droplet, prend ses propres snapshots et peut être réattaché à un nouveau Droplet en cas de redimensionnement.

Dans la console : Volumes > Create > 10 Go > attach to your Droplet. Puis sur la machine :

sudo mkdir -p /mnt/agent-state
sudo mount -o discard,defaults,noatime /dev/sda /mnt/agent-state
echo '/dev/sda /mnt/agent-state ext4 defaults,nofail,discard 0 0' | sudo tee -a /etc/fstab
sudo chown agent:agent /mnt/agent-state

Faites pointer les volumes ./data, ./skills, ./memory de docker-compose.yml vers des sous-dossiers de /mnt/agent-state. Un Volume de 10 Go coûte environ 1 $/mois.

Étape 5 : brancher Telegram et tester

Si Telegram est votre canal (la plupart des auto-hébergeurs finissent là car la Bot API est gratuite et instantanée), la boucle de test est courte :

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

Vous devriez avoir une réponse en quelques secondes. Sinon, docker compose logs -f agent pointe directement le problème : token manquant, mauvais ID utilisateur autorisé ou fournisseur qui renvoie 401.

Pour un tour plus détaillé côté Telegram (groupes, sujets, mode voix, dépannage), lisez comment monter un agent IA sur Telegram.

Étape 6 : backups et monitoring

Deux habitudes peu chères qui se rentabilisent à la première panne :

DigitalOcean Backups ou Snapshots. Les Backups sont hebdomadaires et automatiques avec quatre semaines de rétention, facturés 20 % du prix du Droplet. Les Snapshots sont manuels, facturés au Go / mois (environ 0,05 $/Go/mois). Au minimum, taguez un snapshot "before-update" avant chaque docker compose pull.
Un ping d'uptime. BetterStack, UptimeRobot ou l'Uptime maison de DigitalOcean. Frappez https://votre-domaine/health (ou un check TCP) toutes les 5 minutes. La première fois que le long-polling Telegram tombe à 3 h du matin, vous le saurez avant le déjeuner, pas au déjeuner.

Pour l'état de l'agent sur le Volume, un cron d'une ligne qui tare /mnt/agent-state en /var/backups/agent-$(date +%F).tar.gz, plus un rsync vers DigitalOcean Spaces (compatible S3, offre d'entrée à 5 $/mois), suffit. Spaces conserve les tarballs au prix de l'object storage, bien en dessous de "j'attache un second Droplet".

Étape 7 : mises à jour

Une fois par semaine, snapshot frais à l'appui :

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

Généralement moins d'une minute. Si la nouvelle image casse quelque chose, restaurez le snapshot depuis la console. Le seul état perdu, c'est ce qui a été écrit entre le snapshot et maintenant, et il vit dans le Volume mémoire.

Ce qui casse tôt ou tard

Une liste honnête, indépendante du fournisseur, éprouvée :

Le long-polling Telegram tombe pendant les micro-coupures réseau. La plupart des runtimes se reconnectent ; sinon, c'est le ping d'uptime qui prévient.
docker compose pull :latest embarque un changement de config incompatible. Épinglez les tags d'image à des versions précises en production.
Le fournisseur de modèle vous rate-limite et l'agent devient muet sans erreur claire. Loguez le statut HTTP côté client fournisseur.
Le disque racine se remplit parce qu'une skill écrit dans /tmp sans rotation. du -sh /* et docker system df doivent être en mémoire musculaire. C'est exactement pour cela que l'état persistant vit sur un Volume.
Vous oubliez une règle de firewall en ajoutant un service. Cloud Firewall et UFW ont tous les deux besoin du nouveau port, sinon vous passez 20 minutes à déboguer un "connection refused" du mauvais côté.

Rien de cela n'est propre à DigitalOcean. C'est la taxe de tout gérer soi-même.

Contrôle du coût réel

Ordre de grandeur mensuel pour une petite production sur DigitalOcean, mi-2026 :

Droplet (s-2vcpu-4gb-amd) : 28 $
Volume 10 Go : 1 $
Weekly Backups : environ 5,60 $
Spaces (backup off-site, 250 Go / 1 To de transfert) : 5 $
Ping d'uptime : 0 $ (offre gratuite)

Total : environ 40 $/mois pour un hôte d'agent IA correctement sauvegardé, surveillé et isolé sur DigitalOcean. Chez Hetzner la même forme se rapproche des 8-10 $/mois (régions UE, CPU comparable, 20 To de transfert inclus), et sur AWS EC2 les mêmes specs grimpent à 60-80 $/mois une fois EBS et l'egress ajoutés. DigitalOcean se situe au milieu, au prix du soin, des docs, des images 1-Click et du fait de ne pas avoir à penser aux paliers de facturation.

Quand la calculette du VPS ne tient plus

Si les étapes ci-dessus vous parlent, c'est exactement pour ce workflow que DigitalOcean est fait. Panneau propre, images en un clic, écosystème plein de tutoriels "comment faire tourner X".

Si elles sonnent comme une taxe sur votre week-end, la comparaison change. Un hébergement géré échange un petit forfait mensuel et un dimanche après-midi contre un setup qui inclut déjà la passerelle Telegram, BYOK contre votre fournisseur de modèle, une mémoire persistante, des snapshots et le "ça reste en ligne pendant que vous dormez". Notre guide hébergement vs self-hosting déroule la comparaison, y compris ce que vaut votre temps.

Commencez avec Hermify si vous voulez la voie gérée : un Hermes Agent sur une infrastructure de production en une minute environ, sans Cloud Firewall à configurer ni Volume à attacher. Si vous préférez le faire vous-même sur DigitalOcean, ce guide devrait vous y mener.