VPS für einen Telegram-Bot mieten

Viel weniger, als meist verkauft wird. Ein Bot ist ein langlebiger Prozess, der fast die ganze Zeit wartet: Ein zustandsloser Befehls-Bot liegt bei etwa 60 MB, einer mit ORM, Scheduler und Cache eher bei 150 MB. Nachdem das Betriebssystem seine rund 300 MB belegt hat, bietet eine Maschine mit 1 GB noch Platz für 4 schwere oder 12 leichte Bots. Die Zahl der NUTZER spielt kaum eine Rolle, weil Telegram Updates einzeln an Ihren Prozess liefert, nicht eine Verbindung pro Nutzer. Was die Antwort ändert, ist Zustand, den Sie selbst im Speicher halten: ein großer Cache, eine In-Process-Datenbank, ein Modell.

Zum Start Long Polling, Webhooks, wenn es darauf ankommt. Bei Long Polling baut Ihr Bot eine ausgehende Verbindung zu Telegram auf und wartet: Er braucht keine Domain, kein Zertifikat und keinen offenen Port, funktioniert also hinter NAT und ist der schnellste Weg, etwas zum Laufen zu bringen. Bei einem Webhook verbindet sich Telegram mit IHNEN, daher braucht er eine öffentliche Adresse, ein gültiges TLS-Zertifikat und einen zum Internet offenen Port; im Gegenzug entfällt die Polling-Schleife vollständig und er skaliert besser, wenn der Bot wirklich ausgelastet ist. Beides läuft problemlos auf der kleinsten Maschine hier. Der ehrliche Grund zu wechseln ist Last oder Latenz, nicht Mode.

Das sind Telegrams eigene Grenzen, nicht unsere: Ein Bot, der die öffentliche Bot API nutzt, kann Dateien bis 20 MB herunterladen und bis 50 MB hochladen. Ein eigener Bot-API-Server hebt das auf 2 GB an und sorgt vor allem dafür, dass die Dateien auf dem Speicherplatz Ihres Servers landen, statt über Telegram zu laufen. Das ist die eine Änderung, die wirklich bestimmt, welche Maschine Sie brauchen: Plötzlich zählen Speicherplatz und Traffic, und deshalb steht in der Tabelle oben BD-8 bei dieser Zeile und nicht bei den anderen.

Ein Text-Bot nie. Ein Medien-Bot möglicherweise, und dreißig Sekunden Rechnen lohnen sich: durchschnittliche Dateigröße × Nachrichten pro Tag × 30. Fünfzigtausend Sprachnachrichten am Tag à 3 MB ergeben etwa 4.3 TB im Monat, mehr als das Inklusivvolumen der meisten günstigen Tarife und weit unter den 32 TB bei BD-8, oder der Linie Unmetered, bei der sich die Frage nicht stellt. Beide Richtungen zählen: Eine Datei, die Ihr Bot empfängt, und eine, die er sendet, sind beide Traffic.

Eine systemd-Unit, keine screen-Sitzung. Schreiben Sie eine kleine Service-Datei mit Restart=always, aktivieren Sie sie, und der Bot startet nach einem Absturz und nach einem Neustart wieder, ohne dass Sie dafür wach sein müssen. Das ist der häufigste Grund, warum ein Bot auf einem VPS „ausfällt“, und es ist kein Hosting-Problem: Ein von Hand gestarteter Prozess endet mit der SSH-Sitzung, die ihn gestartet hat. Docker mit einer Restart-Policy erledigt dasselbe, wenn Sie es lieber so verpacken.

Ja, und die meisten sollten das tun. Jeder ist ein eigener Prozess mit eigener systemd-Unit und eigenem Token; sie teilen sich die Maschine, auf Wunsch die Datenbank, und sonst nichts. Die Rechnung in der Tabelle beantwortet genau diese Frage: Eine Maschine mit 4 GB trägt 25 anspruchsvolle Bots, bevor der Arbeitsspeicher zur Grenze wird. Nutzen Sie getrennte Ports und getrennte Benutzer, wenn die Bots für verschiedene Personen sind.

Überall, wo Ihre Nutzer hinkommen und Ihre Latenz zu Telegram vernünftig ist: Der Bot kommuniziert mit der Infrastruktur von Telegram, nicht direkt mit Ihren Nutzern, daher zählt die übliche Regel „nah an Ihrem Publikum“ hier weniger als bei einer Website. Wenn der Bot denselben Nutzern auch ein Web-Dashboard oder eine API bereitstellt, wählen Sie die Region danach. Wenn Sie unsicher sind, stellen Sie stundenweise in zwei Regionen bereit, messen Sie und löschen Sie die schlechtere: Bei $0.0113 pro Stunde ist das ein günstiges Experiment.