Keeping a Telegram bot online 24/7: polling, systemd, and a token that never touches your codeEinen Telegram-Bot rund um die Uhr online halten: Polling, systemd und ein Token, der nie deinen Code berührt

Why a laptop or a free tier isn't a bot hostWarum ein Laptop oder eine Free-Tier-Lösung kein Bot-Host ist

A laptop sleeps, reboots for updates, and goes offline the moment you close the lid or leave the house — none of which your bot's users notice until a message goes unanswered. A free-tier PaaS dyno or a serverless function is built to scale to zero when idle, which is exactly wrong for something that's supposed to hold a persistent polling loop against Telegram's API around the clock. A small Linux VPS you control has neither problem: it's a machine that's simply always on, running your process and nothing that decides to suspend it.Ein Laptop schläft, startet für Updates neu und geht offline, sobald du den Deckel zuklappst oder das Haus verlässt — nichts davon merken die Nutzer deines Bots, bis eine Nachricht unbeantwortet bleibt. Ein Free-Tier-PaaS-Dyno oder eine Serverless-Function ist darauf ausgelegt, im Leerlauf auf null herunterzuskalieren, was für etwas, das rund um die Uhr eine dauerhafte Polling-Schleife gegen Telegrams API halten soll, genau falsch ist. Ein kleiner Linux-VPS, den du selbst kontrollierst, hat keines dieser Probleme: Es ist eine Maschine, die einfach immer läuft, deinen Prozess ausführt und nichts, das sich entscheidet, ihn zu suspendieren.

Long polling versus webhooks, and why to start with pollingLong Polling versus Webhooks, und warum du mit Polling anfangen solltest

Telegram's Bot API gives you two ways to receive updates, and the difference matters a lot for a first deployment. Long polling means your bot calls getUpdates and holds the connection open until Telegram has something to send back, then immediately asks again — every connection your process makes is outbound. Webhooks mean you register a public HTTPS URL with Telegram and it pushes updates to you, which means something on your box has to accept an inbound connection on one of the ports Telegram allows for webhooks — 443, 80, 88, or 8443, with 443 behind a reverse proxy being the conventional choice.Telegrams Bot-API gibt dir zwei Wege, Updates zu empfangen, und der Unterschied ist für ein erstes Deployment sehr wichtig. Long Polling bedeutet, dass dein Bot getUpdates aufruft und die Verbindung offen hält, bis Telegram etwas zurückzuschicken hat, und dann sofort erneut fragt — jede Verbindung, die dein Prozess aufbaut, ist ausgehend. Webhooks bedeuten, dass du eine öffentliche HTTPS-URL bei Telegram registrierst und es Updates zu dir schickt, was heißt, dass etwas auf deiner Maschine eine eingehende Verbindung auf einem der Ports akzeptieren muss, die Telegram für Webhooks erlaubt — 443, 80, 88 oder 8443, wobei 443 hinter einem Reverse-Proxy die übliche Wahl ist.

That distinction decides how much networking you need to think about. Polling makes only outbound connections, so a NAT-style shared IPv4 is a non-issue and no port needs forwarding — the bot works identically whether your VPS has a dedicated address or not. Webhooks need a public HTTPS endpoint, which on NAT IPv4 means either a forwarded port sitting behind a reverse proxy like Caddy, or a dedicated IPv4 — available on request by e-mail, not as a self-service add-on. Whether 443 is among your forwarded ports depends on the plan, so check before you rely on it; NAT IPv4, ports and forwarding covers what a NAT plan does and doesn't give you.Diese Unterscheidung entscheidet, wie viel Netzwerk-Denken nötig ist. Polling baut nur ausgehende Verbindungen auf, sodass eine geteilte NAT-artige IPv4 kein Problem ist und kein Port weitergeleitet werden muss — der Bot funktioniert identisch, egal ob dein VPS eine dedizierte Adresse hat oder nicht. Webhooks brauchen einen öffentlichen HTTPS-Endpunkt, was bei NAT-IPv4 entweder einen weitergeleiteten Port hinter einem Reverse-Proxy wie Caddy bedeutet, oder eine dedizierte IPv4 — auf Anfrage per E-Mail verfügbar, nicht als Self-Service-Add-on. Ob 443 zu deinen weitergeleiteten Ports gehört, hängt vom Tarif ab, also prüfe das, bevor du dich darauf verlässt; NAT IPv4, Ports und Weiterleitung deckt ab, was ein NAT-Tarif gibt und was nicht.

None of that makes webhooks wrong — at real scale they're less wasteful than a loop hammering getUpdates. But for one bot on one box, polling has no networking prerequisite at all, so this guide starts there and treats webhooks as a deliberate later upgrade, not the default.Nichts davon macht Webhooks falsch — bei echter Skalierung sind sie weniger verschwenderisch als eine Schleife, die getUpdates hämmert. Aber für einen Bot auf einer Maschine hat Polling überhaupt keine Netzwerk-Voraussetzung, deshalb fängt diese Anleitung dort an und behandelt Webhooks als ein bewusstes späteres Upgrade, nicht als Standard.

Step 1: a clean machine and a dedicated system userSchritt 1: eine saubere Maschine und ein dedizierter Systembenutzer

Deploy a small VPS running Ubuntu 24.04 LTS — the VPS for Discord and Telegram bots page describes exactly this shape of workload, and everything on it applies to Telegram — then do the ordinary hardening before the bot touches it: a non-root user with your SSH key, password authentication off, and a firewall that defaults to deny. connect to your VPS over SSH and secure your VPS cover both.Setze einen kleinen VPS mit Ubuntu 24.04 LTS auf — die Seite VPS für Discord- und Telegram-Bots beschreibt genau diese Art von Workload, und alles dort gilt auch für Telegram — und erledige dann die übliche Härtung, bevor der Bot sie berührt: einen Non-Root-User mit deinem SSH-Key, Passwort-Authentifizierung aus und eine Firewall, die standardmäßig blockiert. Über SSH mit deinem VPS verbinden und Sichere deinen VPS decken beides ab.

Run the bot as its own system user, not as yourself and never root. It only needs to read its own code and write to its own state directory — no reason to touch anything else on the box:Lass den Bot als eigenen Systembenutzer laufen, nicht als du selbst und niemals als Root. Er muss nur seinen eigenen Code lesen und in sein eigenes State-Verzeichnis schreiben — kein Grund, sonst irgendetwas auf der Maschine anzufassen:

sudo useradd --system --create-home --shell /usr/sbin/nologin botuser
sudo mkdir -p /opt/telegram-bot/state
sudo chown -R botuser:botuser /opt/telegram-bot

Deploy your code under /opt/telegram-bot, either with git clone or an rsync from your machine, so ownership stays consistent with what you just set.Lege deinen Code unter /opt/telegram-bot ab, entweder mit git clone oder einem rsync von deiner Maschine, damit die Besitzverhältnisse konsistent mit dem bleiben, was du gerade gesetzt hast.

Step 2: python-telegram-bot in a venv (or grammY, briefly)Schritt 2: python-telegram-bot in einem venv (oder kurz grammY)

For a Python bot, python-telegram-bot is the standard library for this, and it belongs in its own virtualenv rather than the system Python:Für einen Python-Bot ist python-telegram-bot die Standardbibliothek dafür, und sie gehört in ein eigenes Virtualenv statt in das System-Python:

sudo apt update
sudo apt install -y python3-venv
sudo -u botuser python3 -m venv /opt/telegram-bot/venv
sudo -u botuser /opt/telegram-bot/venv/bin/pip install "python-telegram-bot==21.*"

Pin the major version in requirements.txt too, and check the project's PyPI page for the current 21.x point release before you deploy — a bare pip install python-telegram-bot will happily hand you a breaking major upgrade later. A minimal bot's run_polling() call is the long-polling loop from the previous section, running with no extra networking setup.Pinne die Hauptversion auch in requirements.txt, und prüfe die PyPI-Seite des Projekts für das aktuelle 21.x-Patch-Release, bevor du deployst — ein nacktes pip install python-telegram-bot gibt dir später bereitwillig ein breaking Major-Upgrade. Der run_polling()-Aufruf eines minimalen Bots ist die Long-Polling-Schleife aus dem vorigen Abschnitt, die ohne zusätzliches Netzwerk-Setup läuft.

Writing the bot in Node instead, grammY is the equivalent framework — bot.start() defaults to long polling the same way, and everything here about the token, the system user, and the systemd unit applies unchanged; only ExecStart and the runtime differ.Schreibst du den Bot stattdessen in Node, ist grammY das äquivalente Framework — bot.start() setzt standardmäßig genauso auf Long Polling, und alles hier über den Token, den Systembenutzer und die systemd-Unit gilt unverändert; nur ExecStart und die Laufzeitumgebung unterscheiden sich.

Step 3: the bot token in an environment file, never in the codeSchritt 3: der Bot-Token in einer Environment-Datei, niemals im Code

BotFather hands you a token that is, functionally, your bot's password — anyone with it can send messages as your bot and read what it receives. It does not belong hardcoded in bot.py, in a .env committed by accident, or in a config file every user on the box can read. It belongs in a root-owned EnvironmentFile:BotFather gibt dir einen Token, der funktional das Passwort deines Bots ist — wer ihn hat, kann Nachrichten als dein Bot senden und lesen, was er empfängt. Er gehört nicht fest in bot.py verdrahtet, nicht in eine aus Versehen committete .env, und nicht in eine Config-Datei, die jeder Nutzer auf der Maschine lesen kann. Er gehört in eine root-eigene EnvironmentFile:

sudo mkdir -p /etc/telegram-bot
sudo touch /etc/telegram-bot/env
sudo chown root:root /etc/telegram-bot/env
sudo chmod 600 /etc/telegram-bot/env

TELEGRAM_BOT_TOKEN=your-token-here

Read it in your bot with os.environ["TELEGRAM_BOT_TOKEN"], not a string literal. This works even though the process ends up running as botuser: systemd, running as root, reads EnvironmentFile before dropping privileges, then hands the resulting variables to your already-starting process — the file itself never needs to be readable by botuser, so chmod 600 owned by root is correct as a permanent setting, not a temporary one to loosen later. Add the file's path to .gitignore before you write the token into it, and if a token ever reaches a repo — public or private — treat it as burned and get a fresh one from BotFather with /revoke.Lies ihn in deinem Bot mit os.environ["TELEGRAM_BOT_TOKEN"], nicht als String-Literal. Das funktioniert, obwohl der Prozess am Ende als botuser läuft: systemd liest, während es als root läuft, EnvironmentFile, bevor es Privilegien abgibt, und übergibt die resultierenden Variablen dann an deinen bereits startenden Prozess — die Datei selbst muss nie für botuser lesbar sein, weshalb chmod 600 im Besitz von root eine dauerhafte Einstellung ist und keine vorübergehende, die du später lockerst. Füge den Pfad der Datei zu .gitignore hinzu, bevor du den Token hineinschreibst, und falls ein Token jemals in ein Repo gelangt — öffentlich oder privat —, behandle ihn als verbrannt und hol dir bei BotFather mit /revoke einen neuen.

Step 4: a systemd unit with a real restart policySchritt 4: eine systemd-Unit mit einer echten Restart-Policy

A bot started in a terminal or a tmux session dies the moment that session does — a disconnect, a reboot, an out-of-memory kill. A systemd unit survives all three and restarts the process without you doing anything:Ein Bot, der in einem Terminal oder einer tmux-Sitzung gestartet wurde, stirbt in dem Moment, in dem diese Sitzung stirbt — eine Trennung, ein Neustart, ein Out-of-Memory-Kill. Eine systemd-Unit übersteht alle drei und startet den Prozess neu, ohne dass du etwas tun musst:

[Unit]
Description=telegram-bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=300
StartLimitBurst=5

[Service]
Type=simple
User=botuser
Group=botuser
WorkingDirectory=/opt/telegram-bot
EnvironmentFile=/etc/telegram-bot/env
ExecStart=/opt/telegram-bot/venv/bin/python /opt/telegram-bot/bot.py
Restart=always
RestartSec=5
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/opt/telegram-bot/state
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Restart=always is the right choice here, unlike a bot that needs a deliberate, clean-exit kill switch — a Telegram bot with no such mechanism should simply come back regardless of why it stopped. RestartSec=5 gives Telegram's API a moment to recover if the exit was caused by a transient network blip, and StartLimitBurst=5 within StartLimitIntervalSec=300 stops a genuine crash loop from restarting forever and hammering getUpdates into a rate limit.Restart=always ist hier die richtige Wahl, anders als bei einem Bot, der einen bewussten Clean-Exit-Killswitch braucht — ein Telegram-Bot ohne einen solchen Mechanismus sollte einfach zurückkommen, egal warum er gestoppt ist. RestartSec=5 gibt Telegrams API einen Moment, sich zu erholen, falls der Exit durch einen vorübergehenden Netzwerk-Hänger verursacht wurde, und StartLimitBurst=5 innerhalb von StartLimitIntervalSec=300 verhindert, dass eine echte Crash-Loop endlos neu startet und getUpdates in ein Rate-Limit hämmert.

Save that block as /etc/systemd/system/telegram-bot.service (for example sudoedit /etc/systemd/system/telegram-bot.service), then enable it, but don't start it until the environment file from Step 3 actually exists — systemd refuses to start a service whose EnvironmentFile is missing:Speichere diesen Block als /etc/systemd/system/telegram-bot.service (zum Beispiel mit sudoedit /etc/systemd/system/telegram-bot.service), aktiviere ihn dann, aber starte ihn nicht, bevor die Environment-Datei aus Schritt 3 tatsächlich existiert — systemd weigert sich, einen Dienst zu starten, dessen EnvironmentFile fehlt:

sudo systemctl daemon-reload
sudo systemctl enable telegram-bot.service
sudo systemctl start telegram-bot.service
sudo systemctl status telegram-bot.service

The systemd.service manual documents every directive here if you want the precise semantics rather than my summary.Das systemd.service-Manual dokumentiert jede Direktive hier, falls du die genaue Semantik statt meiner Zusammenfassung willst.

Step 5: logs with journalctlSchritt 5: Logs mit journalctl

Because the unit's ExecStart writes to stdout and stderr, journald captures everything without a separate log file to manage:Weil das ExecStart der Unit nach stdout und stderr schreibt, erfasst journald alles, ohne dass eine separate Logdatei verwaltet werden muss:

journalctl -u telegram-bot.service -f

That gives a live tail while testing a change. For what happened overnight:Das gibt dir einen Live-Tail, während du eine Änderung testest. Für das, was über Nacht passiert ist:

journalctl -u telegram-bot.service --since "1 hour ago"

journalctl caps and rotates its own storage by default, so there's no unbounded log file quietly filling the disk the way logging to a plain file can.journalctl begrenzt und rotiert seinen eigenen Speicher standardmäßig, sodass es keine unbegrenzte Logdatei gibt, die die Festplatte still und leise füllt, wie es beim Loggen in eine einfache Datei passieren kann.

Honest sizing: what a Telegram bot actually costsEhrliche Größeneinschätzung: was ein Telegram-Bot tatsächlich kostet

A Python bot holding one long-polling connection and handling text messages typically idles in the tens of MiB resident — commonly under 60 MiB once python-telegram-bot's event loop and your handlers are warmed up. The 1 GiB Starter tier covers that with room to spare for the OS itself. Disk is similarly light: the venv, your code, and rotated logs fit comfortably inside a few hundred MB, well under the Starter's 25 GB.Ein Python-Bot, der eine Long-Polling-Verbindung hält und Textnachrichten verarbeitet, liegt im Leerlauf typischerweise bei ein paar Dutzend MiB resident — üblicherweise unter 60 MiB, sobald die Event-Loop von python-telegram-bot und deine Handler warmgelaufen sind. Der 1-GiB-Starter-Tarif deckt das mit Reserve für das Betriebssystem selbst ab. Die Festplatte ist ähnlich genügsam: Das venv, dein Code und rotierte Logs passen bequem in ein paar hundert MB, weit unter den 25 GB des Starters.

What actually pushes you up a tier is not the bot's core loop — it's what the bot does. Downloading and re-encoding photos or video, running any kind of image or speech model locally, or keeping a growing SQLite or Postgres database of user state alongside the bot all add real memory and CPU that the baseline number above doesn't include. If your bot is "read a message, look something up, reply," Starter is the right machine indefinitely; if it starts touching media or a database, size up before it starts swapping, not after.Was dich tatsächlich eine Stufe hochtreibt, ist nicht die Kernschleife des Bots — es ist, was der Bot tut. Fotos oder Videos herunterzuladen und neu zu kodieren, irgendein Bild- oder Sprachmodell lokal laufen zu lassen, oder neben dem Bot eine wachsende SQLite- oder Postgres-Datenbank mit Nutzerzustand zu führen — all das addiert echten Speicher- und CPU-Verbrauch, den die Basiszahl oben nicht einschließt. Wenn dein Bot „eine Nachricht lesen, etwas nachschlagen, antworten“ macht, ist Starter auf unbestimmte Zeit die richtige Maschine; fängt er an, Medien oder eine Datenbank anzufassen, stufe hoch, bevor er anfängt zu swappen, nicht danach.

Unattended security updatesUnbeaufsichtigte Sicherheitsupdates

A bot host you don't log into every day still needs its OS patched, and the standard way to get that without babysitting it is unattended-upgrades:Ein Bot-Host, in den du dich nicht jeden Tag einloggst, braucht trotzdem gepatchte Systeme, und der Standardweg, das ohne Babysitting zu erreichen, ist unattended-upgrades:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

That installs security updates automatically on the schedule Ubuntu ships by default; it does not reboot the machine unless you separately opt into Unattended-Upgrade::Automatic-Reboot, worth enabling once you've confirmed the systemd unit reliably comes back up after a restart — that's what enable in Step 4 was for.Das installiert Sicherheitsupdates automatisch nach dem Zeitplan, den Ubuntu standardmäßig mitbringt; es startet die Maschine nicht neu, außer du aktivierst separat Unattended-Upgrade::Automatic-Reboot — lohnt sich, sobald du bestätigt hast, dass die systemd-Unit nach einem Neustart zuverlässig wieder hochkommt — dafür war das enable in Schritt 4 da.

A small state directory, backed up if the bot keeps anythingEin kleines State-Verzeichnis, gesichert, falls der Bot etwas behält

If your bot only replies to commands and holds no state between restarts, there's nothing to back up beyond the code itself, which lives in git. If it remembers anything — a SQLite file of user preferences, a small queue, a per-chat setting — keep that in the state directory created in Step 1 and nowhere else, so backing it up is one path instead of a search:Wenn dein Bot nur auf Befehle antwortet und zwischen Neustarts keinen Zustand hält, gibt es außer dem Code selbst, der in git lebt, nichts zu sichern. Wenn er sich irgendetwas merkt — eine SQLite-Datei mit Nutzereinstellungen, eine kleine Queue, eine Pro-Chat-Einstellung —, halte das im in Schritt 1 angelegten state-Verzeichnis und nirgendwo sonst, damit das Sichern ein einzelner Pfad ist statt einer Suche:

sudo mkdir -p /root/backups
sudo tar czf /root/backups/telegram-bot-$(date +%F).tar.gz \
  -C / opt/telegram-bot/state etc/telegram-bot/env etc/systemd/system/telegram-bot.service

A tarball on the same disk it was made from is not a backup, it's a file that disappears with the disk — copy it off with rsync or scp on a schedule, and treat that off-box copy as the one you rely on. back up your VPS covers what's included by default if you'd rather not run this yourself.Ein Tarball auf derselben Festplatte, von der er erstellt wurde, ist kein Backup, sondern eine Datei, die mit der Festplatte verschwindet — kopiere ihn planmäßig mit rsync oder scp herunter, und verlass dich auf diese Kopie außerhalb der Maschine, nicht auf den Tarball selbst. Backup deines VPS deckt ab, was standardmäßig enthalten ist, falls du das lieber nicht selbst machen willst.

On overnight.hostBei overnight.host

Full disclosure: this is what we sell. A single Telegram bot idles in a few dozen MiB, so a 1 GiB Starter runs it with room to spare; size up only once the bot processes media or keeps a growing local database.Zur vollen Transparenz: Das ist, was wir verkaufen. Ein einzelner Telegram-Bot liegt im Leerlauf bei ein paar Dutzend MiB, sodass ein 1-GiB-Starter ihn mit Reserve betreibt; skaliere erst hoch, sobald der Bot Medien verarbeitet oder eine wachsende lokale Datenbank führt.

Linux KVM VPS — EUR 4.99 to EUR 59.99 a month, on our own single-tenant bare metal in Dallas, TX and Charlotte, NC. Full hardware virtualisation (KVM), your own kernel, full root. Six tiers, vps-starter to vps-ultra. Starter is 1 vCPU, 1 GiB RAM, 25 GB disk.Linux-KVM-VPS — 4,99 bis 59,99 EUR im Monat, auf unserer eigenen Single-Tenant-Bare-Metal-Hardware in Dallas, TX und Charlotte, NC. Vollständige Hardware-Virtualisierung (KVM), eigener Kernel, volles Root. Sechs Tarife, vps-starter bis vps-ultra. Starter hat 1 vCPU, 1 GiB RAM, 25 GB Speicher.

You order in the shop, pay by card (Stripe) or SEPA bank transfer, and your login details are e-mailed to you once the service is set up. Support is e-mail, run by one person, with no guaranteed response time. All prices are final totals under the German small-business rule (§19 UStG); no VAT is added or shown.Du bestellst im Shop, zahlst per Karte (Stripe) oder SEPA-Überweisung, und deine Zugangsdaten werden dir per E-Mail zugeschickt, sobald der Dienst eingerichtet ist. Support läuft per E-Mail, von einer einzelnen Person betrieben, ohne garantierte Reaktionszeit. Alle Preise sind Endpreise. Gemäß § 19 UStG wird keine Umsatzsteuer ausgewiesen.

Order vps-starter → · Linux KVM VPS overviewvps-starter bestellen → · Übersicht Linux-KVM-VPS

Written by the person who runs overnight.host: a small, honest hosting company on dedicated bare metal — Linux VPS, game servers, web hosting. Live status at up.overnight.host.Geschrieben von der Person, die overnight.host betreibt: ein kleines, ehrliches Hosting-Unternehmen auf dedizierter Bare-Metal-Hardware — Linux-VPS, Gameserver, Webhosting. Live-Status unter up.overnight.host.