Bester VPS für Telegram-Bots: Polling, Webhooks, IPv4 und monatliche Kosten

Der Bot beantwortet jede Nachricht, bis der Laptop zugeklappt wird. Dann bleiben die Antworten aus. Ein kleiner VPS löst das für wenige Dollar monatlich. Welcher VPS passt, hängt davon ab, wie der Bot Updates erhält: Er fragt Telegram danach oder Telegram sendet sie ihm.

Das entscheidet über Ports, Zertifikat und die Notwendigkeit einer öffentlichen IPv4-Verbindung.

Die Kurzfassung

• Für einen Bot auf einem VPS eignet sich Long Polling. Domain, Zertifikat und offener Port sind nicht nötig.
• Webhooks benötigen HTTPS auf Port 443, 80, 88 oder 8443 sowie eine öffentliche IPv4-Adresse. Telegram liefert Webhooks nicht über IPv6 aus.
• 512 MB of RAM is a workable start for one bot with no local database.
• Halten Sie den Bot mit systemd am Laufen oder nutzen Sie Dockers Neustartrichtlinie, wenn Sie bereits Container einsetzen.
• Wählen Sie nach IPv4 und RAM-Reserve, nicht allein nach Listenpreis.

Polling oder Webhooks: Diese Wahl bestimmt die Serveranforderungen

Ein Telegram-Bot erhält Updates auf zwei Wegen. Beim Long Polling ruft er getUpdates auf. Telegram hält die Anfrage bis zu einem Update oder Timeout offen; alle Verbindungen gehen vom Server aus. Für Webhooks registrieren Sie einmal eine URL mit setWebhook, an die Telegram jedes Update per HTTPS-POST sendet.

Die Webhook-Spalte folgt Telegrams Webhook-Anforderungen.

Fragen Sie die Bot API ab, um die Methode Ihres Bots zu prüfen:

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

Enthält die Antwort "url":"", ist kein Webhook eingerichtet und der Bot kann Long Polling nutzen. grammYs bot.start() nutzt standardmäßig Long Polling; python-telegram-bot verwendet run_polling() oder run_webhook().

Für einen Bot auf einem eigenen VPS würde ich Polling wählen, entsprechend grammYs Standardempfehlung. Webhooks passen besser, wenn bereits ein Reverse Proxy läuft (ein Webserver, der HTTPS-Anfragen an den Bot weiterleitet), mehrere Bots einen HTTPS-Endpunkt teilen oder eine Serverless-Plattform genutzt wird. Dafür beschafft und erneuert Caddy das Zertifikat ohne Cronjob.

Ein kurzer Ausfall verzögert Nachrichten, ohne sie zu verlieren. Laut den Update-Regeln der Bot API speichert Telegram Updates bei beiden Verfahren bis zum Empfang durch den Bot höchstens 24 Stunden und wiederholt fehlgeschlagene Webhook-Anfragen, bevor es aufgibt.

Belegt der Webhook seinen Port direkt, beschränken Sie ihn auf Telegrams veröffentlichte Quellnetze. Teilt ein Reverse Proxy Port 443 mit anderen Websites, beschränken Sie nur den Webhook-Pfad oder verwenden Sie Telegrams geheimes Token, statt sämtlichen anderen HTTPS-Verkehr zu blockieren. Der Webhook-Leitfaden nennt zwei Quellnetze und warnt vor möglichen Änderungen. Mit UFW als Host-Firewall:

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

Ändern Sie 443, wenn der Webhook auf 80, 88 oder 8443 lauscht. Diese Regeln schützen einen direkt auf dem Host laufenden Bot. Dockers Firewall-Dokumentation erklärt, dass veröffentlichte Ports UFW umgehen; ein mit -p 443:443 gestarteter Webhook-Container bleibt daher allgemein erreichbar. Setzen Sie außerdem secret_token in setWebhook. Telegram sendet es im Header X-Telegram-Bot-Api-Secret-Token jeder Anfrage. Ihr Handler weist Anfragen ohne Token zurück.

Den Bot am Laufen halten: systemd oder Docker

Ein Bot im Dauerbetrieb muss nach Abstürzen und Neustarts wieder starten. Auf einem VPS erledigt das systemd oder Docker, wenn der Bot als Image ausgeliefert wird.

Eine systemd-Unit ist eine kurze Konfigurationsdatei, die dem Init-System Start und Neustart eines Programms vorgibt. Erstellen Sie /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

Speichern Sie das Token als BOT_TOKEN=... in einer .env-Datei im Projektordner und lesen Sie es mit os.environ["BOT_TOKEN"] (Node: process.env.BOT_TOKEN), damit es nicht im Code steht. Kopieren Sie danach das Projekt an seinen Platz und starten Sie es:

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 startet den Bot nach regulärem Ende und Abstürzen neu; on-failure überspringt reguläre Beendigungen laut systemd.service-Handbuch. RestartSec=5 schafft Abstand zwischen Versuchen. WantedBy=multi-user.target plus enable startet den Bot beim Booten. Bei Neustartschleifen zeigt sudo journalctl -u telegram-bot -n 50 den Fehlerverlauf. Prüfen Sie zuerst, ob BOT_TOKEN fehlt.

Bei Docker genügt eine Option:

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

docker logs -f telegram-bot

In Compose lautet die Zeile restart: unless-stopped. Laut Dockers Dokumentation zu Neustartrichtlinien startet der Container nach seinem Ende oder einem Daemon-Neustart erneut, nicht aber nach manuellem Stoppen. Das deckt Systemneustarts ab, wenn Docker beim Booten startet, wie standardmäßig unter Debian und Ubuntu. Andernfalls führen Sie sudo systemctl enable docker.service aus.

Meine Regel: Ein einzelnes Skript auf einem kleinen Server bekommt systemd, ohne zusätzlichen Daemon im RAM. Wer bereits Images baut oder andere Container betreibt, kann Docker nutzen und dessen RAM-Verbrauch einplanen.

Keines der Werkzeuge meldet einen ausgefallenen Bot. Ein Push-Monitor von Uptime Kuma auf einem zweiten Server kann das. Der Bot ruft dessen URL regelmäßig auf; bleiben die Aufrufe aus, warnt Uptime Kuma über Telegram.

Wo kostenloses Hosting und Heimserver an Grenzen stoßen

Render pausiert kostenlose Webdienste nach 15 Minuten ohne eingehenden Verkehr; laut Renders Dokumentation zum Gratisangebot dauert das Aufwecken etwa eine Minute. Ein Polling-Bot empfängt keinen eingehenden Verkehr und wird gestoppt. Einen Webhook-Bot weckt Telegrams POST nach Ruhephasen mit einem Kaltstart. Ob kostenloses Hosting passt, hängt also vom Verfahren ab.

grammYs Leitfaden nennt Serverless-Plattformen als geeignet für Webhooks. Long Polling benötigt dagegen eine ständig laufende Maschine. Fly.io rechnet nach Nutzung ab und verlangt eine hinterlegte Zahlungskarte.

Ein Raspberry Pi oder alter PC kann einen Polling-Bot betreiben, solange Maschine, Strom und Verbindung funktionieren. Webhooks zu Hause benötigen zusätzlich eine öffentliche Adresse und Portweiterleitung. Für einen Hobby-Bot kann beides kostenlos ausreichen.

Ein VPS eignet sich für beide Verfahren zu einem festen Monatspreis.

Fünf VPS-Anbieter für Telegram-Bots im Vergleich

Die Tabelle vergleicht fünf kostenpflichtige Einstiegstarife für Telegram-Bots zu den beworbenen Monatspreisen vor Steuern (Stand: Oktober 2026). Aktionspreise sind entsprechend gekennzeichnet.

Vultrs reiner IPv6-Tarif hat keine IPv4; bei Hetzner ist sie nicht im Preis enthalten. Ohne IPv4 können beide keine Webhooks empfangen.

Polling ist rein über IPv6 möglich, weil api.telegram.org eine IPv6-Adresse hat. Alle weiteren Ziele benötigen ebenfalls eine: Paketregister, Git-Host und jede verwendete API. Prüfen Sie jeden Host vor der Auswahl:

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

Eine leere Antwort bedeutet, dass dieser Host keine IPv6-Adresse hat.

Reichen 512 MB für einen Telegram-Bot?

Ich würde einen Bot ohne lokale Datenbank mit 512 MB starten. Die Dokumentation von python-telegram-bot nennt keinen Speicherbedarf. Entscheidend sind die Mitnutzer: Betriebssystem, gegebenenfalls Docker-Daemon und lokale Datenbank. Messen Sie den Verbrauch.

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

Bei einem OOM-Kill beendet der Kernel einen Prozess, um RAM freizugeben. systemd startet den Bot neu; der Logeintrag kann der einzige Hinweis sein. Wechseln Sie auf 1 GB, sobald OOM-Kills auftreten, Swap dauerhaft genutzt wird oder bevor Sie eine lokale Datenbank oder einen zweiten Bot hinzufügen.

Welchen Anbieter wählen?

Für einen Bot würde ich 512 MB mit öffentlicher IPv4 inklusive wählen. Danach entscheiden Preis, Ressourcenreserve und Nutzerstandort.

• Aktuell niedrigster Monatspreis: Cloudzy mit 2,48 $ während der 50-%-Aktion, inklusive IPv4 und IPv6.
• Aktuell niedrigster Preis mit IPv4: Cloudzy mit 2,48 $ im Aktionszeitraum. Dedizierte IPv4 und IPv6 sind enthalten.
• 1 GB of headroom for Docker or a small database: Linode, from $5 a month.
• Mehrere Bots oder eine Datenbank, Nutzer in Europa: Hetzner bietet in dieser Tabelle die meisten Ressourcen pro Euro, sofern der Tarif verfügbar ist (im Oktober 2026 war er als nicht verfügbar gelistet). Für Webhooks kommt die IPv4-Gebühr hinzu.
• Mehr Speicher und Transfer bei 512 MB: Cloudzy. Unter den 512-MB-Tarifen bietet es am meisten Speicher (20 GB NVMe statt 10) und Transfer (1 TB statt etwa 500 GB), inklusive IPv4 und IPv6. Der aktuelle Aktionspreis liegt außerdem unter den anderen verglichenen Einstiegstarifen.

Zum aktuellen Aktionspreis verbindet Cloudzy den niedrigsten Monatspreis in diesem Vergleich mit mehr Speicher und Transfer als die anderen 512-MB-Tarife. Der 512-MB-Tarif von Cloudzy wird stündlich abgerechnet und bietet eine 14-tägige Geld-zurück-Garantie, sodass Sie den Bot einige Tage darauf betreiben können, bevor Sie sich festlegen. Wählen Sie den Standort nahe Ihren Nutzern, stellen Sie einen Cloudzy Linux VPS bereit und übernehmen Sie die systemd-Unit von oben.

Häufig gestellte Fragen