Einen Telegram-Bot 24/7 auf einem VPS betreiben: aiogram, systemd, Polling vs Webhook

Du hast einen Telegram-Bot mit aiogram geschrieben, ihn lokal getestet, und er funktioniert. Jetzt muss er irgendwo leben, das nicht schläft, wenn du den Laptop schließt. Ein kleiner VPS ist das natürliche Zuhause — aber es gibt eine Lücke zwischen python bot.py in einer SSH-Sitzung und einem Bot, der tatsächlich durch Abstürze, Neustarts und das Wegfallen deiner Verbindung oben bleibt.

Das ist die Produktionsversion: ein virtualenv, der Token aus deinem Code herausgehalten, ein systemd-Dienst, der den Bot von selbst wiederbelebt, und eine klaräugige Antwort auf die Frage, die irgendwann jeder stellt — Polling oder Webhook?

Warum nicht einfach auf deinem Laptop betreiben

Ein Bot braucht eine stetige ausgehende Verbindung zu Telegram. Dein Laptop schläft, startet für Updates neu und springt zwischen Netzwerken — jedes davon lässt den Bot fallen, und Nutzer treffen auf eine Wand aus Stille. Ein VPS hält diese Verbindung rund um die Uhr. Das ist der ganze Grund, ihn von deiner Maschine wegzuziehen, und es ist derselbe Grund, warum auch ein Discord-Bot auf einen Server gehört.

Wenn du nur den schnellstmöglichen „bring es online“-Weg mit einem minimalen Bot willst, deckt die Telegram-Bot-hosten-Anleitung das ab. Dieses Stück geht eine Ebene tiefer: aiogram, sichere Token-Handhabung und zu wissen, wann zu skalieren ist.

Der Bot, in einem virtualenv

Logg dich per SSH ein und halte den Bot in seinem eigenen venv isoliert — installiere keine Pakete systemweit, das macht Upgrades und Aufräumen später zu einem Durcheinander:

sudo apt update && sudo apt install -y python3-venv
mkdir ~/tgbot && cd ~/tgbot
python3 -m venv venv && source venv/bin/activate
pip install -U aiogram

Ein minimaler aiogram-3-Bot, der seinen Token aus der Umgebung liest, nicht aus einem fest codierten String:

# bot.py
import asyncio, logging, os
from aiogram import Bot, Dispatcher
from aiogram.types import Message
from aiogram.filters import CommandStart

logging.basicConfig(level=logging.INFO)
dp = Dispatcher()

@dp.message(CommandStart())
async def start(m: Message):
    await m.answer("Alive and running on a VPS.")

async def main():
    bot = Bot(os.environ["BOT_TOKEN"])
    await dp.start_polling(bot)

if __name__ == "__main__":
    asyncio.run(main())

Halte den Token aus deinem Code

Füg den BotFather-Token nie in bot.py ein — ein Push in ein öffentliches Repo und er ist geleakt. Leg ihn stattdessen in eine root-lesbare Env-Datei:

sudo tee /etc/tgbot.env >/dev/null <<'EOF'
BOT_TOKEN=123456:your-token-from-botfather
EOF
sudo chmod 600 /etc/tgbot.env

Ein geleakter Token ist ein /revoke in BotFather davon entfernt, behoben zu sein — aber ein geleaktes irgendetwas anderes auf einer geteilten Maschine ist schlimmer. Ein dedizierter VPS für den Bot ist ehrlich gesagt ein sichereres Zuhause für den Token als dein Alltags-Laptop: wenn er leakt, rotierst du einen Token, nicht dein ganzes Setup.

Der Teil, der ihn am Leben hält: systemd

Das ist, was einen Bot, der läuft, von einem Bot trennt, der oben bleibt. Erstelle den Dienst:

# /etc/systemd/system/tgbot.service
[Unit]
Description=Telegram bot (aiogram)
After=network-online.target
Wants=network-online.target

[Service]
User=botuser
WorkingDirectory=/home/botuser/tgbot
EnvironmentFile=/etc/tgbot.env
ExecStart=/home/botuser/tgbot/venv/bin/python bot.py
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Betreibe ihn als Nicht-root-Benutzer (botuser oben), nicht als root — falls der Bot je kompromittiert wird, willst du ihn eingeschachtelt. Dann:

sudo systemctl daemon-reload
sudo systemctl enable --now tgbot

Restart=always mit RestartSec=3 bedeutet, dass ein Absturz — ein schlechtes Update von Telegram, eine unbehandelte Ausnahme, ein OOM — den Bot in drei Sekunden zurückbringt, statt ihn tot zu lassen, bis du es bemerkst. Sieh ihm live zu:

journalctl -u tgbot -f

Das ist dein ganzes Logging-Setup. Keine Log-Dateien zu rotieren, kein zusätzliches Tooling — journald hat es bereits.

Aktualisieren ohne Ausfall-Drama

Wenn du den Code änderst oder aiogram hochziehst:

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # falls die Bibliothek aktualisiert wird
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # bestätige, dass er sauber zurückkam

Der Neustart lässt den Bot für ein, zwei Sekunden blinken. Für einen Polling-Bot ist das für Nutzer unsichtbar — Telegram stellt Updates in eine Warteschlange und liefert sie, sobald der Bot sich neu verbindet.

Polling vs Webhook — die ehrliche Version

Das ist die Entscheidung, die Leute überdenken. Hier ist die einfache Version:

Polling (start_polling, was der Code oben nutzt) lässt den Bot Telegram auf einer langlebigen Verbindung fragen „irgendetwas Neues?“. Es braucht nichts als ausgehendes Internet — keine Domain, kein TLS, keine offenen eingehenden Ports. Es läuft gut hinter NAT. Für die überwältigende Mehrheit der Bots ist das richtig und du solltest hier aufhören.

Webhook lässt Telegram Updates zu dir pushen, was bedeutet, dass du einen öffentlichen HTTPS-Endpunkt offenlegen musst. Das erfordert eine Domain und einen erreichbaren eingehenden Port — also entweder eine dedizierte öffentliche IP oder einen Reverse-Proxy davor. Mehr Einrichtung, mehr Dinge, die kaputtgehen. Der Gewinn ist niedrigere Latenz und weniger Overhead im großen Maßstab — Tausende gleichzeitiger Nutzer, schweres Update-Volumen.

Die praktische Regel: beginne mit Polling auf einem NAT-Plan. Wechsle nur zu einem Webhook, wenn du Polling tatsächlich entwachsen bist — und wenn du es tust, dann verdient eine dedizierte IP ihren Platz, weil du diesen eingehenden HTTPS-Endpunkt brauchst.

Was der Betrieb kostet

Ein Polling-Bot ist leicht. Er ruht auf Telegrams Long-Poll und reagiert auf Nachrichten, also wartet die Maschine meist:

• 3-$-Nano (1 vCPU / 1 GB) — gut für die meisten Bots, sogar recht gesprächige.
• 5-$-Micro (2 vCPU / 2 GB) — wenn der Bot eine Datenbank hält (SQLite/Postgres), Medien handhabt oder viele Nutzer bedient.
• Höher nur, wenn der Bot selbst echte Arbeit macht — Bildverarbeitung, ein lokales Modell, schwere Pro-Nachricht-Logik.

Die Registrierung ist nur E-Mail und du zahlst in USDC oder USDT auf Base oder Ethereum — keine Karte, kein Ausweis. Eine Karte funktioniert auch, aber die Auffahrt hat ein ~27-$-Minimum, also ist es für einen 3-$-Plan reibungsloser, einmal ein kleines Guthaben aufzuladen und Verlängerungen daraus ziehen zu lassen. Es ist reine CPU, ein Rechenzentrum in Deutschland — kein Thema für einen Bot, gut zu wissen, wenn du eine GPU oder eine bestimmte Region brauchtest.

Das ehrliche Fazit

Ein Telegram-Bot ist eines der günstigsten Dinge, die du selbst hosten kannst: eine 3-$-Maschine, eine systemd-Unit und Polling geben dir einen Bot, der durch Abstürze und Neustarts online ist, ohne dass du ihn babysittest. Greif zu einem Webhook und einem größeren Plan nur, wenn der Maßstab es tatsächlich erzwingt — nicht weil ein Tutorial dir sagte, Webhooks seien „besser“. Hol die kleine Maschine, halte den Token in einer Env-Datei, lass systemd die Verfügbarkeit handhaben, und — vor allem anderen — führe die Neuer-VPS-Sicherheits-Checkliste aus, damit die Maschine selbst abgeriegelt ist.

Bereit, deinen zu hosten? Ein Telegram-Bot nutzt kaum Ressourcen — der Nano-Plan (3 $/Mon.) betreibt ihn 24/7 ohne Aufhebens.