VPS für einen Telegram-Bot auswählen und zuverlässig betreiben
Ein einfacher Bot braucht wenig Rechenleistung. Stabil wird er durch passende Reserven, kontrolliertes Deployment, sichere Secrets, Monitoring und getestete Backups. Deshalb sollte die Auswahl nicht allein bei CPU und RAM enden.
Ressourcen nach der Arbeitslast wählen
Die Zahl der Nutzer allein bestimmt die Last nicht. Ein Bot, der kurze Textbefehle beantwortet, ist leichtgewichtig. Bildverarbeitung, Dateidownloads, externe APIs, Hintergrundjobs oder eine große Datenbank verändern den Bedarf deutlich. Berücksichtigen Sie außerdem Betriebssystem, Container, Monitoring und die gleichzeitig laufenden Worker.
| Szenario | Sinnvoller Start | Wichtigster Engpass |
|---|---|---|
| Einfacher Bot mit Long Polling | 1 vCPU, 1 GB RAM, 15–20 GB SSD | Stabiler Prozess und Netz |
| Webhook und kleine Datenbank | 1–2 vCPU, 2 GB RAM, 20–30 GB NVMe | RAM, HTTPS, Datenbank |
| Mehrere Container und Queue | 2 vCPU, 4 GB RAM, NVMe | Speicher und Worker-Limits |
| Medienverarbeitung oder ML | ab 4 vCPU und 8 GB RAM | CPU, Speicherplatz, externer Storage |
Diese Werte sind Ausgangspunkte. Eine schlecht begrenzte Queue oder ein Speicherleck kann auch einen großen Server füllen. Eine detaillierte Kapazitätsplanung bietet der Ratgeber zu CPU und RAM.
Long Polling oder Webhook
Beim Long Polling fragt der Bot Telegram regelmäßig nach neuen Updates. Das ist einfach einzurichten und benötigt keine öffentlich erreichbare HTTPS-Adresse. Für kleine Projekte und Entwicklung ist es oft ausreichend. Es darf jedoch nur eine aktive Instanz dieselben Updates abrufen, sofern die Anwendung keine besondere Koordination vorsieht.
Beim Webhook sendet Telegram Updates an eine öffentliche HTTPS-URL. Das passt gut zu produktiven Diensten, erfordert aber Domain, gültiges TLS-Zertifikat, offenen Port und einen korrekt konfigurierten Reverse Proxy. Die Anwendung sollte Anfragen schnell bestätigen und längere Arbeit an eine Queue übergeben, damit Telegram nicht wegen Zeitüberschreitungen erneut zustellt.
Standort und Netzwerk testen
Der VPS braucht zuverlässige Routen zur Telegram API sowie zu Datenbanken und externen Diensten, die der Bot aufruft. Der geografisch nächste Standort ist nicht automatisch der beste. Testen Sie DNS-Auflösung, HTTPS-Verbindungen, Paketverlust und Antwortzeiten. Wenn Nutzer Dateien hoch- oder herunterladen, zählen zusätzlich Portgeschwindigkeit und monatliches Trafficvolumen.
- öffentliche IPv4 oder funktionierendes IPv6 für die geplante Architektur;
- stabile ausgehende HTTPS-Verbindungen zu benötigten APIs;
- klarer Trafficumfang und keine überraschende Drosselung;
- Konsole für den Zugang nach einer falschen Firewall-Regel;
- monatliche Laufzeit für den ersten Praxistest.
Deployment und automatischer Neustart
Der Bot darf nicht nur in einer interaktiven SSH-Sitzung laufen. Verwenden Sie systemd, einen Prozessmanager oder Container mit Restart-Policy. Der Dienst muss nach einem VPS-Neustart automatisch starten, Logs begrenzen und bei wiederholten Abstürzen eine Benachrichtigung auslösen. Legen Sie außerdem einen festen Release- und Rollback-Ablauf fest.
| Baustein | Aufgabe | Was zu prüfen ist |
|---|---|---|
| Prozessmanager | Start und Neustart | Start nach Reboot, begrenzte Neustartschleifen |
| Reverse Proxy | TLS und Webhook-Zugriff | Zertifikatserneuerung, nur nötige Ports |
| Datenbank | Zustand und Nutzerdaten | Indizes, Migrationen, konsistente Backups |
| Queue | Lange und wiederholbare Jobs | Retry-Limit, Dead-Letter-Queue, Idempotenz |
| Monitoring | Fehler früh erkennen | Externe Prüfung und erreichbare Alarme |
Timeouts und Wiederholungen müssen begrenzt sein. Exponential Backoff verhindert, dass ein gestörter externer Dienst eine Anfragenlawine auslöst. Bei erneut zugestellten Updates sollte die Geschäftslogik idempotent sein, damit Zahlungen, Nachrichten oder Datenbankeinträge nicht doppelt entstehen.
Token, Zugänge und Server schützen
Der Bot-Token gehört weder in den Quellcode noch in öffentliche Repositories oder Logs. Speichern Sie Secrets in geschützten Umgebungsvariablen oder einem Secret Store und geben Sie sie nur dem Dienstkonto. Nach einer vermuteten Offenlegung muss der Token sofort erneuert werden.
- SSH-Anmeldung mit Schlüsseln und ohne direkten Root-Login;
- Firewall mit ausschließlich benötigten Ports;
- regelmäßige Betriebssystem- und Paketupdates;
- separater Benutzer mit minimalen Rechten für den Bot;
- 2FA für Hostingkonto, Git-Plattform und DNS;
- Recovery-Codes und Schlüssel außerhalb des VPS aufbewahren.
Weitere Basisschritte stehen im Praxisleitfaden zur VPS-Sicherheit.
Daten und Backups wiederherstellbar halten
Sichern Sie Datenbank, Konfiguration und gegebenenfalls hochgeladene Dateien unabhängig vom VPS. Ein Snapshot allein genügt nicht: Er kann mit dem Konto verloren gehen und eine laufende Datenbank inkonsistent abbilden. Planen Sie anwendungsgerechte Dumps, verschlüsselte externe Ablage und eine begrenzte Aufbewahrungszeit.
Ein Backup gilt erst nach einem erfolgreichen Restore als geprüft. Stellen Sie regelmäßig eine Kopie in einer isolierten Umgebung wieder her und messen Sie, wie lange der Wiederanlauf dauert. Ausführliche Empfehlungen finden Sie unter VPS-Backups planen.
Welche Metriken wirklich helfen
- Antwortzeit, Fehlerrate und Zeit seit dem letzten erfolgreich verarbeiteten Update;
- CPU, verfügbare RAM-Menge, Swap und OOM-Ereignisse;
- freier Speicherplatz sowie I/O-Wartezeit;
- Queue-Länge, Alter des ältesten Jobs und Zahl fehlgeschlagener Jobs;
- Datenbankverbindungen, langsame Abfragen und Backup-Status;
- Ablaufdatum des TLS-Zertifikats und externe Webhook-Erreichbarkeit.
Ein Alarm sollte den verantwortlichen Menschen außerhalb des gestörten Servers erreichen. Ein lokales Dashboard hilft wenig, wenn der gesamte VPS offline ist.
Erst messen, dann skalieren
Steigt die Antwortzeit, vergleichen Sie den Zeitpunkt mit CPU, RAM, I/O, Datenbank und Queue. Mehr vCPU hilft nicht gegen eine fehlende Datenbankindexierung; mehr RAM behebt keine blockierte externe API. Optimieren Sie den belegten Engpass und vergrößern Sie erst danach gezielt den Tarif.
Für viele Bots reicht vertikale Skalierung. Mehrere Instanzen erfordern dagegen koordinierte Update-Verarbeitung, gemeinsam erreichbare Zustände und idempotente Jobs. Diese Architektur lohnt sich erst, wenn Last oder Verfügbarkeitsziel sie rechtfertigen.
Häufige Fragen
Reicht 1 GB RAM für einen Telegram-Bot?
Für einen einfachen Bot ohne schwere Verwaltungsoberfläche und große Datenbank oft ja. Mit PostgreSQL, Redis und mehreren Containern sind 2–4 GB ein sichererer Start.
Braucht ein Bot eine Domain?
Für Long Polling nein. Ein Webhook benötigt eine erreichbare HTTPS-Adresse; eine Domain vereinfacht Zertifikat und Serverwechsel.
Kann die Datenbank auf demselben VPS laufen?
Bei kleinen Projekten ist das üblich, sofern externe Backups vorhanden sind. Mit wachsender Last oder höheren Verfügbarkeitsanforderungen kann sie getrennt betrieben werden.