Kör en Telegram-bot 24/7 på en VPS: aiogram, systemd, polling vs webhook

Du skrev en Telegram-bot med aiogram, testade den lokalt, och den fungerar. Nu måste den leva någonstans som inte somnar när du stänger laptopen. En liten VPS är det naturliga hemmet — men det finns ett gap mellan python bot.py i en SSH-session och en bot som faktiskt förblir uppe genom krascher, reboots, och din anslutning som tappar.

Detta är produktionsversionen: en virtualenv, token hållen utanför din kod, en systemd-tjänst som återuppväcker botten på egen hand, och ett klarögt svar på frågan alla till slut ställer — polling eller webhook?

Varför inte bara köra den på din laptop

En bot behöver en stadig utgående anslutning till Telegram. Din laptop somnar, startar om för uppdateringar, och hoppar mellan nätverk — var och en av dessa tappar botten, och användare stöter på en mur av tystnad. En VPS håller den anslutningen dygnet runt. Det är hela anledningen att flytta den från din maskin, och det är samma anledning som en Discord-bot hör hemma på en server också.

Om du bara vill ha den snabbast möjliga "få den online"-vägen med en minimal bot, täcker host-en-Telegram-bot-genomgången det. Detta stycke går ett steg djupare: aiogram, säker token-hantering, och att veta när man ska skala.

Botten, i en virtualenv

SSH:a in och håll botten isolerad i sin egen venv — installera inte paket system-wide, det gör uppgraderingar och cleanup en röra senare:

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

En minimal aiogram 3-bot som läser sin token från environment, inte från en hårdkodad sträng:

# 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())

Håll token utanför din kod

Klistra aldrig in BotFather-token i bot.py — en push till ett publikt repo och den är läckt. Sätt den i en root-läsbar env-fil istället:

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

En läckt token är en /revoke i BotFather från att vara fixad — men ett läckt något annat på en delad maskin är värre. En dedikerad VPS för botten är ärligt talat ett säkrare hem för token än din dagliga laptop: om den läcker, roterar du en token, inte hela din uppsättning.

Delen som håller den vid liv: systemd

Detta är vad som skiljer en bot som körs från en bot som förblir körande. Skapa tjänsten:

# /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

Kör det som en non-root-användare (botuser ovan), inte root — om botten någonsin komprometteras vill du ha den inramad. Sedan:

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

Restart=always med RestartSec=3 betyder att en krasch — en dålig uppdatering från Telegram, en ohanterad exception, en OOM — tar tillbaka botten på tre sekunder istället för att lämna den död tills du märker det. Titta på den live:

journalctl -u tgbot -f

Det är hela din logging-uppsättning. Inga loggfiler att rotera, ingen extra tooling — journald har det redan.

Uppdatera utan downtime-drama

När du ändrar koden eller bumpar aiogram:

cd ~/tgbot && source venv/bin/activate
pip install -U aiogram          # if upgrading the library
sudo systemctl restart tgbot
journalctl -u tgbot -n 30 --no-pager   # confirm it came back clean

Omstarten blippar botten en sekund eller två. För en polling-bot är det osynligt för användare — Telegram köar uppdateringar och levererar dem när botten återansluter.

Polling vs webhook — den ärliga versionen

Detta är beslutet folk övertänker. Här är den enkla versionen:

Polling (start_polling, vad koden ovan använder) har botten fråga Telegram "något nytt?" på en långlivad anslutning. Det behöver inget utom utgående internet — ingen domän, ingen TLS, inga öppna inkommande portar. Det körs fint bakom NAT. För den överväldigande majoriteten av bottar är detta korrekt och du bör stanna här.

Webhook har Telegram pusha uppdateringar till dig, vilket betyder att du måste exponera en publik HTTPS-endpoint. Det kräver en domän och en nåbar inkommande port — så antingen en dedikerad publik IP eller en reverse proxy framför. Mer setup, fler saker som går sönder. Utdelningen är lägre latens och mindre overhead i stor skala — tusentals samtidiga användare, tung uppdaterings-volym.

Den praktiska regeln: börja med polling på ett NAT-plan. Flytta till en webhook bara när du faktiskt vuxit ur polling — och om du gör det, är det då en dedikerad IP förtjänar sin plats, för du behöver den inkommande HTTPS-endpointen.

Vad det kostar att köra

En polling-bot är lätt. Den idlar på Telegrams long-poll och reagerar på meddelanden, så boxen väntar mestadels:

• $3 Nano (1 vCPU / 1 GB) — fin för de flesta bottar, även ganska pratsamma.
• $5 Micro (2 vCPU / 2 GB) — när botten håller en databas (SQLite/Postgres), hanterar media, eller betjänar många användare.
• Högre bara om botten själv gör riktigt arbete — bildbehandling, en lokal modell, tung per-meddelande-logik.

Registrering är e-post-only och du betalar i USDC eller USDT på Base eller Ethereum — inget kort, inget ID. Ett kort fungerar också, men on-rampen har ett minimum på ~$27, så för ett $3-plan är det smidigare att fylla på ett litet saldo en gång och låta renewals dra från det. Det är CPU-only, ett datacenter i Tyskland — en icke-fråga för en bot, värt att veta om du behövde en GPU eller en specifik region.

Den ärliga slutsatsen

En Telegram-bot är en av de billigaste sakerna du kan self-hosta: en $3-box, en systemd-unit, och polling ger dig en bot som är online genom krascher och reboots utan att du babysittar den. Sträck dig efter en webhook och ett större plan bara när skala faktiskt tvingar det — inte för att en tutorial sa åt dig att webhooks är "bättre." Skaffa den lilla boxen, håll token i en env-fil, låt systemd hantera uptimen, och — före allt annat — kör nya-VPS säkerhetschecklistan så att boxen själv är nedlåst.

Redo att hosta din? En Telegram-bot använder knappt resurser — Nano-planet ($3/mån) kör den 24/7 utan krångel.