Meilleur VPS pour héberger un bot Telegram : polling, webhooks, IPv4 et coût mensuel

Le bot répond à tous les messages jusqu’à ce que le capot du portable se ferme. Ensuite, les utilisateurs n’obtiennent plus de réponse. Un petit VPS règle ce problème pour quelques dollars par mois. Le meilleur VPS pour un bot Telegram dépend de sa façon de recevoir les mises à jour : soit il les demande à Telegram, soit Telegram les lui envoie.

Ce choix détermine les ports et le certificat nécessaires, ainsi que le besoin d’une connectivité IPv4 publique.

La version courte

• Pour un seul bot sur un VPS, utilisez le long polling. Aucun domaine, certificat ni port ouvert n’est nécessaire.
• Les webhooks exigent HTTPS sur le port 443, 80, 88 ou 8443 et une adresse IPv4 publique. Telegram ne transmet pas les webhooks en IPv6.
• 512 MB of RAM is a workable start for one bot with no local database.
• Maintenez le bot en fonctionnement avec systemd, ou avec la politique de redémarrage de Docker si vous utilisez déjà des conteneurs.
• Choisissez selon l’IPv4 et la marge de RAM, pas uniquement selon le prix affiché.

Polling ou webhooks : le choix qui détermine les besoins du serveur

Un bot Telegram reçoit les mises à jour de deux façons. En long polling, il appelle getUpdates et Telegram garde la requête ouverte jusqu’à l’arrivée d’une mise à jour ou l’expiration du délai. Toutes les connexions partent donc de votre serveur. Avec un webhook, vous enregistrez une URL une fois avec setWebhook, puis Telegram y envoie chaque mise à jour par POST en HTTPS.

La colonne webhook suit les exigences de Telegram pour les webhooks.

Pour connaître la méthode utilisée par votre bot, interrogez la Bot API :

curl "https://api.telegram.org/bot<YOUR_TOKEN>/getWebhookInfo"

Si la réponse contient "url":"", aucun webhook n’est configuré et le bot peut utiliser le long polling. bot.start() de grammY utilise le long polling par défaut ; python-telegram-bot utilise run_polling() ou run_webhook().

Pour un bot seul sur son VPS, je choisirais le polling, ce qui est aussi le conseil par défaut de grammY. Les webhooks sont préférables si le serveur dispose déjà d’un proxy inverse (un serveur web qui transmet les requêtes HTTPS au bot), si plusieurs bots partagent un point d’entrée HTTPS ou sur une plateforme serverless. Dans ce cas, Caddy obtient et renouvelle le certificat sans tâche cron.

Une brève panne retarde les messages sans les perdre. Selon les règles de mise à jour de la Bot API, Telegram conserve les mises à jour jusqu’à 24 heures avant leur réception par le bot, quelle que soit la méthode, et réessaie les requêtes webhook ayant échoué avant d’abandonner.

Si le webhook utilise directement son port, limitez l’accès aux plages sources publiées par Telegram. Si un proxy inverse partage le port 443 avec d’autres sites, appliquez la restriction au seul chemin du webhook ou utilisez le jeton secret de Telegram sans bloquer tout le reste du trafic HTTPS. Le guide des webhooks indique deux plages sources et précise qu’elles peuvent changer. Avec UFW comme pare-feu de l’hôte :

sudo ufw allow 22/tcp    # keep SSH open before you enable the firewall

sudo ufw allow proto tcp from 149.154.160.0/20 to any port 443

sudo ufw allow proto tcp from 91.108.4.0/22 to any port 443

sudo ufw allow 80/tcp    # if your HTTPS setup uses HTTP validation or redirects HTTP to HTTPS

sudo ufw enable

Modifiez 443 si le webhook écoute sur 80, 88 ou 8443. Ces règles protègent un bot exécuté directement sur l’hôte. La documentation du pare-feu Docker indique qu’un port publié contourne UFW : un conteneur webhook démarré avec -p 443:443 reste donc accessible à tous. Définissez aussi un secret_token dans setWebhook. Telegram le renvoie dans l’en-tête X-Telegram-Bot-Api-Secret-Token de chaque requête, et votre gestionnaire rejette les requêtes qui ne le contiennent pas.

Maintenir le bot en fonctionnement : systemd ou Docker

Faire fonctionner un bot Telegram 24 h/24 implique de le relancer après les plantages et les redémarrages. Sur un VPS, systemd s’en charge, ou Docker si le bot est distribué sous forme d’image.

Une unité systemd est un court fichier de configuration qui indique au système d’initialisation comment lancer et relancer un programme. Créez /etc/systemd/system/telegram-bot.service :

[Unit]
Description=Telegram bot
After=network-online.target
Wants=network-online.target

[Service]
User=bot
WorkingDirectory=/opt/bot
EnvironmentFile=/opt/bot/.env
ExecStart=/opt/bot/venv/bin/python bot.py
# Node: ExecStart=/usr/bin/node bot.js
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Placez le jeton dans un fichier .env du dossier du projet sous la forme BOT_TOKEN=..., puis lisez-le avec os.environ["BOT_TOKEN"] (Node : process.env.BOT_TOKEN) pour le garder hors du code. Copiez ensuite le projet au bon endroit et lancez-le :

sudo mkdir -p /opt/bot

sudo cp -r ~/your-bot/. /opt/bot/        # your project, after git clone or scp from your machine; include .env and requirements.txt

sudo apt install -y python3-venv         # Debian/Ubuntu

sudo useradd --system --no-create-home bot

sudo chown -R bot:bot /opt/bot

sudo -u bot python3 -m venv /opt/bot/venv

sudo -u bot /opt/bot/venv/bin/pip install -r /opt/bot/requirements.txt

# Node: skip the venv and pip commands above, then run:

cd /opt/bot && sudo -u bot npm ci

sudo chmod 600 /opt/bot/.env

sudo systemctl daemon-reload

sudo systemctl enable --now telegram-bot

systemctl status telegram-bot    # look for: Active: active (running)

sudo journalctl -u telegram-bot -f    # follow the bot's logs

Restart=always relance le bot après une sortie normale ou un plantage ; on-failure ignore les sorties normales, selon le manuel systemd.service. RestartSec=5 espace les tentatives, et WantedBy=multi-user.target avec enable lance le bot au démarrage. S’il redémarre en boucle, sudo journalctl -u telegram-bot -n 50 affiche la trace d’erreur. Vérifiez d’abord si BOT_TOKEN manque.

L’équivalent Docker tient en une option :

docker run -d --name telegram-bot --restart unless-stopped --env-file .env your-bot-image

docker logs -f telegram-bot

Dans Compose, la ligne est restart: unless-stopped. La documentation des politiques de redémarrage Docker précise que le conteneur repart après sa sortie ou le redémarrage du démon, mais pas après un arrêt volontaire. Cela couvre les redémarrages de la machine si Docker démarre lui-même au boot, ce qui est le cas par défaut sur Debian et Ubuntu. Ailleurs, exécutez sudo systemctl enable docker.service.

Ma règle : un script sur une petite machine utilise systemd, sans démon supplémentaire en mémoire. Si vous créez déjà des images ou exécutez d’autres conteneurs, utilisez Docker en tenant compte de la RAM consommée par son démon.

Aucun des deux outils ne vous signale que le bot est arrêté. Un moniteur push Uptime Kuma sur un second serveur peut le faire. Le bot appelle périodiquement l’URL du moniteur et Uptime Kuma vous alerte sur Telegram lorsque les appels cessent.

Les limites de l’hébergement gratuit et des serveurs à domicile

Render met en veille un service web gratuit après 15 minutes sans trafic entrant et sa documentation sur l’offre gratuite annonce environ une minute pour le réveil. Un bot en polling ne reçoit pas de trafic entrant : il est donc arrêté. Un bot webhook est réveillé par le POST de Telegram, avec un démarrage à froid après une période calme. La viabilité de l’hébergement gratuit dépend donc de la méthode du bot.

Le guide de grammY cite les plateformes serverless comme adaptées aux webhooks, tandis que le long polling nécessite une machine fonctionnant en permanence. Fly.io facture à l’usage et exige une carte bancaire enregistrée.

Un Raspberry Pi ou un vieux PC peut faire tourner un bot en polling tant que la machine, le courant et la connexion fonctionnent. Les webhooks à domicile exigent aussi une adresse publique et une redirection de port. Pour un bot amateur, ces deux solutions gratuites peuvent suffire.

Un VPS convient aux deux méthodes pour un prix mensuel fixe.

Cinq fournisseurs de VPS comparés pour un bot Telegram

Le tableau compare cinq offres payantes d’entrée de gamme pour héberger un bot Telegram, aux prix mensuels annoncés en octobre 2026, hors taxes. Les promotions sont indiquées le cas échéant.

L’offre IPv6 seule de Vultr n’a pas d’IPv4, et le prix de Hetzner n’inclut pas l’adresse IPv4. Sans celle-ci, aucun des deux ne peut recevoir de webhook.

Un bot en polling peut fonctionner uniquement en IPv6, car api.telegram.org possède une adresse IPv6. Tous les autres services contactés doivent aussi en avoir une : registres de paquets, hébergeur Git et API utilisées. Vérifiez chaque hôte avant de choisir :

dig +short AAAA api.telegram.org

dig +short AAAA github.com

dig +short AAAA pypi.org    # repeat for every host your bot or its installs reach

Une réponse vide signifie que cet hôte n’a pas d’adresse IPv6.

512 Mo suffisent-ils pour un bot Telegram ?

Je commencerais avec 512 Mo pour un bot sans base de données locale. La documentation de python-telegram-bot n’indique aucune exigence de mémoire. Tout dépend des autres composants présents sur la machine : le système d’exploitation, le démon Docker s’il est utilisé et toute base de données locale. Mesurez l’utilisation.

free -m                   # "available" is your headroom; the Swap row shows swap use

ps -o rss,cmd -p "$(systemctl show -p MainPID --value telegram-bot)"   # bot's resident memory, in KB

docker stats --no-stream  # per-container memory, if the bot runs in Docker

journalctl -k | grep -i "out of memory"   # kernel OOM kills

Une interruption OOM survient lorsque le noyau tue un processus pour libérer de la RAM. systemd relance le bot : cette ligne de journal peut donc être votre seule preuve. Passez à 1 Go si des arrêts OOM apparaissent, si le swap est utilisé en permanence ou avant d’ajouter une base locale ou un second bot.

Lequel choisir

Pour un bot, je prendrais une offre de 512 Mo avec IPv4 publique incluse. Le choix dépend ensuite du prix, de la marge de ressources et de la localisation des utilisateurs.

• Prix mensuel actuel le plus bas : Cloudzy à 2,48 $ pendant sa promotion de 50 %, avec IPv4 et IPv6 incluses.
• Prix actuel le plus bas avec IPv4 : Cloudzy à 2,48 $ pendant la promotion. L’IPv4 dédiée et l’IPv6 sont incluses.
• 1 GB of headroom for Docker or a small database: Linode, from $5 a month.
• Plusieurs bots ou une base, utilisateurs en Europe : Hetzner offre le plus de ressources par euro de ce tableau lorsque l’offre est disponible (elle était affichée comme indisponible en octobre 2026). Ajoutez le coût de l’IPv4 pour les webhooks.
• Davantage de disque et de transfert avec 512 Mo : Cloudzy. Parmi ces offres de 512 Mo, elle propose le plus de stockage (20 Go NVMe contre 10) et de transfert (1 To contre environ 500 Go), IPv4 et IPv6 incluses. Au prix promotionnel actuel, Cloudzy coûte aussi moins cher que les autres offres de base comparées.

Au prix promotionnel actuel, Cloudzy associe le prix mensuel le plus bas de cette comparaison à davantage de stockage et de transfert que les autres offres de 512 Mo. Son offre de 512 Mo est facturée à l’heure et bénéficie d’une garantie de remboursement de 14 jours : vous pouvez tester le bot quelques jours avant de vous engager. Choisissez la région la plus proche des utilisateurs, déployez un VPS Linux Cloudzy et ajoutez l’unité systemd ci-dessus.

Foire aux questions