VPS für einen Telegram-Bot: was der Bot braucht und wie Sie den Tarif wählen

Die Suche nach einem „VPS für einen Bot“ endet meist beim günstigsten Tarif, und in der Hälfte der Fälle ist das auch richtig. Die Probleme zeigen sich später: Eine Massennachricht liefert 429-Fehler, der Bot kann ein vom Nutzer gesendetes Video nicht herunterladen, der Webhook kommt nach dem Umzug auf einen neuen Server nicht mehr an, oder Nachrichten gehen während eines nächtlichen Ausfalls verloren. Fast alles davon liegt an der Funktionsweise der Bot API, nicht an fehlenden Kernen. Im Folgenden: wie Sie die Last Ihres Bots abschätzen, welche Telegram-Regeln die Anforderungen an den Server festlegen und was Sie in einem Tarif vor der Bezahlung prüfen sollten.

Was ein Bot tatsächlich verbraucht

Der Bot selbst ist ein kleiner Prozess, der Updates von Telegram empfängt und Antworten sendet. Die Ressourcen fließen in alles drumherum.

• Netzwerk und Latenz. Jede Aktion des Bots ist eine HTTPS-Anfrage an api.telegram.org. Für einen Menü-Bot zählt eine stabile Verbindung mehr als die Bandbreite: Der Traffic liegt bei einigen Megabyte pro Tag.
• Datenbank. Bei einigen hundert Nutzern reicht SQLite. Sobald Tausende Nutzer, Bestellungen, Statistiken und gleichzeitige Anfragen dazukommen, brauchen Sie PostgreSQL oder MySQL, also Hunderte Megabyte Arbeitsspeicher und eine schnelle Festplatte.
• Queues und Hintergrundaufgaben. Massennachrichten, geplante Erinnerungen, Zahlungsabwicklung über externe Dienste. Meist ist das Redis plus ein separater Worker-Prozess.
• Dateien. Videokonvertierung, Bildgenerierung und PDF-Berichte belasten CPU und Festplatte stärker als alles andere zusammen.
• Externe APIs. Ein Bot, der Anfragen per API an ein KI-Modell weiterleitet, belastet den Server kaum: Er wartet nur auf die Antwort. Ein Bot mit lokalem Modell ist ein Fall für einen leistungsstarken Server oder eine GPU.

Schätzen Sie nicht, „wie schwer der Bot ist“, sondern wie viele solcher Komponenten er hat und welche davon ständig laufen.

Bot-API-Limits, die den Server betreffen

Telegram hat Limits, die sich durch keine Serverleistung aufheben lassen. Kennen Sie sie vor der Tarifwahl, damit Sie nicht für Ressourcen bezahlen, die der Bot gar nicht nutzen kann.

• Sendegeschwindigkeit. Telegram rät davon ab, mehr als eine Nachricht pro Sekunde an einen einzelnen Chat, mehr als 20 Nachrichten pro Minute an eine Gruppe und Massennachrichten schneller als etwa 30 Nachrichten pro Sekunde zu senden. Darüber liefert die Bot API den Fehler 429 mit dem Parameter retry_after. Eine Massennachricht an 10.000 Nutzer dauert auf jedem Server mehrere Minuten, Sie brauchen also eine Queue mit Ratenbegrenzung, keine zusätzlichen Kerne.
• Dateigröße. Über die Standard-Bot-API lädt ein Bot Dateien bis 20 MB herunter und bis 50 MB hoch. Für mehr betreiben Sie einen eigenen Bot-API-Server (das Open-Source-Projekt telegram-bot-api): Er hebt das Download-Limit auf und erlaubt Uploads bis 2000 MB. Dieser Server legt Dateien auf der Festplatte ab und braucht daher Reserven bei Speicherplatz und Arbeitsspeicher.
• Aufbewahrung von Updates. Solange der Bot nicht läuft, speichert Telegram eingehende Updates, allerdings höchstens 24 Stunden. Ein Tag Ausfall ohne Monitoring, und ein Teil der Nutzernachrichten ist endgültig verloren.

Anforderungen des Webhooks an den Server

Die Grundregeln für Webhooks, HTTPS und die Ports 443, 80, 88 oder 8443, finden Sie auf der Seite VPS für einen Telegram-Bot. Einige weitere Anforderungen fallen meist erst nach dem Serverkauf auf.

• Nur IPv4. Telegram stellt Webhooks ausschließlich an IPv4-Adressen zu; IPv6 wird nicht unterstützt. Die günstigsten Tarife ohne eigene IPv4 funktionieren für Webhooks nicht: Ihnen bleibt dann Long Polling oder eine kostenpflichtige IPv4.
• TLS 1.2 und neuer. Alte SSL-Versionen sowie TLS 1.0/1.1 werden abgelehnt. Das Zertifikat muss zur Domain passen; ein selbstsigniertes Zertifikat funktioniert, wenn Sie es beim Aufruf von setWebhook hochladen.
• Absenderadressen. Anfragen kommen aus den Subnetzen 149.154.160.0/20 und 91.108.4.0/22. Sie können den Webhook-Port in der Firewall nur für diese öffnen.
• Geheimer Header. Mit dem Parameter secret_token von setWebhook fügt Telegram jeder Anfrage den Header X-Telegram-Bot-Api-Secret-Token hinzu. Prüfen Sie ihn in Ihrer Anwendung, um gefälschte Anfragen zu verwerfen.
• Parallele Verbindungen. Standardmäßig hält Telegram bis zu 40 gleichzeitige Verbindungen zum Webhook (einstellbar von 1 bis 100). Ist der Handler langsam, stauen sich die Anfragen, übergeben Sie aufwendige Arbeit also an eine Queue und antworten Sie Telegram sofort.

Solange ein Webhook gesetzt ist, können Sie keine Updates mit getUpdates abrufen. Beim Umzug auf einen neuen Server starten Sie den Bot zuerst dort und leiten erst dann den Webhook auf die neue Adresse um; den Parameter drop_pending_updates verwenden Sie nur, wenn Sie die wartenden Updates wirklich nicht brauchen.

Welcher Tarif für welchen Bot

Richtwerte für einen Linux-Server mit einem Bot in Python, Node.js oder Go. Die Angaben enthalten Reserven für System, Logs und Updates.

Für die ersten beiden Profile siehe VPS mit 1 GB und VPS mit 2 GB. Laufen die Bots in Containern, brauchen Sie KVM-Virtualisierung, siehe VPS für Docker. Eine Datenbank mit Tausenden Nutzern profitiert spürbar von NVMe, siehe VPS für Datenbanken.

Was Sie im Tarif prüfen sollten

• Eine eigene IPv4 ist für Webhooks Pflicht und erleichtert die Arbeit mit externen APIs.
• Art der Kerne. Für einen Menü-Bot genügen geteilte Kerne. Für Medienkonvertierung und geplante Massennachrichten, die mit den Spitzenzeiten der Nachbarn zusammenfallen, sind dedizierte Kerne stabiler.
• Stundenweise Abrechnung. Praktisch, um den Bot vor einer längeren Zahlungsperiode unter realer Last zu testen, ohne einen Testserver für den ganzen Monat zu bezahlen, siehe VPS mit stundenweiser Abrechnung.
• Snapshots und Backups. Die Nutzerdatenbank des Bots ist das Wertvollste auf dem Server. Prüfen Sie, ob Backups inklusive sind oder extra kosten.
• Standort. Für einen Bot zählt eine stabile Route zu Telegram und zu externen APIs mehr als der Ping zu den Nutzern. Speichert der Bot personenbezogene Daten, prüfen Sie die für Ihre Nutzer geltenden Regeln zum Speicherort der Daten, etwa die DSGVO in der EU.

Wie Sie Netzwerk und Festplatte verschiedener Hoster vor der Bezahlung vergleichen, erklärt Ping und Geschwindigkeit eines VPS vor dem Kauf testen.

Zuverlässigkeit: damit der Bot keine Nachrichten verliert

Ein Neustart nach einem Absturz über systemd oder Docker ist das Minimum. Das reicht nicht, wenn der Bot Geld einbringt.

• Externes Monitoring. Prüfen Sie alle paar Minuten, ob der Bot antwortet: Die Methode getWebhookInfo zeigt die Anzahl wartender Updates und den letzten Zustellfehler. Eine wachsende Warteschlange bedeutet, dass der Bot hängt, obwohl der Prozess formal noch läuft.
• Datenbank-Backups außerhalb des Servers. Ein täglicher Dump in einen separaten Speicher. Ein Snapshot beim selben Hoster hilft nicht, wenn das Problem beim Konto oder im Rechenzentrum liegt.
• Systemupdates. Automatische Sicherheitsupdates und Neustarts in einem nächtlichen Zeitfenster, wenn der Bot die wenigsten Nutzer hat.
• Log-Rotation. Ein Bot mit ausführlichen Logs kann eine kleine Festplatte innerhalb weniger Monate füllen, und dann kann die Datenbank nicht mehr schreiben.

Token und Serverzugang

Das Bot-Token gibt die volle Kontrolle über den Bot: Damit kann jeder eingehende Nachrichten lesen und im Namen des Bots schreiben. Bewahren Sie es in Umgebungsvariablen oder in einer Datei auf, die nur der Benutzer des Bots lesen kann, niemals im Repository. Starten Sie den Bot unter einem eigenen Benutzer ohne Root-Rechte. Melden Sie sich am Server mit SSH-Schlüsseln an und deaktivieren Sie die Passwortanmeldung. Könnte das Token in falsche Hände geraten sein, widerrufen Sie es in @BotFather mit dem Befehl /revoke und erstellen Sie ein neues.

Nimmt der Bot Zahlungen an, bewahren Sie die Zahlungsschlüssel getrennt vom Token auf und protokollieren Sie keine vollständigen Anfragen des Zahlungsanbieters.

Wenn ein VPS nicht mehr reicht

Ein einzelner Server bewältigt einen Bot mit Zehntausenden Nutzern, wenn aufwendige Aufgaben über eine Queue laufen. Teilen Sie auf, wenn sich Datenbank und Worker gegenseitig behindern: Die Datenbank zieht auf einen eigenen Server mit NVMe um, die Medien-Worker auf einen Server mit mehr Kernen. Allgemeine Grundsätze zur Wahl von CPU, Arbeitsspeicher und Festplatte finden Sie unter VPS auswählen. Für Bots in anderen Messengern gibt es eigene Auswahlen, etwa VPS für einen Discord-Bot.