Polling или webhook — кое да използвам?

Започни с polling. Работи от всяка машина с изходящ интернет — без домейн, без отворени портове, без TLS — и е предостатъчен за повечето ботове. Превключи към webhook само когато работиш на скала (хиляди потребители) или се нуждаеш от възможно най-ниската латентност; webhook се нуждае от публичен HTTPS endpoint, което значи домейн и достъпен входящ порт (dedicated IP или reverse proxy), така че е повече движещи се части. За 95% от ботовете polling на малък VPS е правилният отговор.

Нужен ли ми е dedicated IP или домейн за Telegram бот?

Не за polling — ботът прави само изходящи повиквания към Telegram, така че NAT план с port-forwarded SSH е достатъчен. Нужен ти е публичен HTTPS endpoint (домейн + входящ порт, т.е. dedicated IP или reverse proxy) само ако превключиш към webhook режим. Повечето ботове никога не се нуждаят от него.

Какъв размер VPS се нуждае aiogram бот?

Най-малкият. Polling бот основно чака long-poll-а на Telegram, така че 1 vCPU / 1 GB (Nano за $3) се справя с повечето ботове комфортно. Увеличавай само когато самият бот върши тежката работа — база данни, обработка на медия или локален модел — което те бута към 2 GB ($5) или повече.

Как да държа бота работещ, след като изляза?

Пусни го като systemd услуга с Restart=always. Стартиран в терминала ти, той умира, когато SSH се затвори; под systemd преживява изход, рестартира при срив и се връща след рестарт. Това е линията между демонстрация и нещо, на което можеш да разчиташ.

Пусни Telegram бот 24/7 на VPS: aiogram, systemd, polling срещу webhook

Написа Telegram бот с aiogram, тества го локално, и работи. Сега трябва да живее някъде, което не заспива, когато затвориш лаптопа. Малък VPS е естественият дом — но има пролука между python bot.py в SSH сесия и бот, който реално стои включен през сривове, рестарти и падането на връзката ти.

Това е production версията: virtualenv, токенът държан извън кода ти, systemd услуга, която възкресява бота сама, и ясноок отговор на въпроса, който всеки в крайна сметка пита — polling или webhook?

Защо да не го пуснеш просто на лаптопа си

Бот се нуждае от стабилна изходяща връзка към Telegram. Лаптопът ти заспива, рестартира за ъпдейти и скача между мрежи — всяко от тези пуска бота, а потребителите удрят стена от тишина. VPS държи тази връзка денонощно. Това е цялата причина да го преместиш от машината си, и е същата причина Discord бот да принадлежи на сървър също.

Ако просто искаш най-бързия възможен път „вкарай го онлайн“ с минимален бот, ръководството за хостване на Telegram бот покрива това. Този текст отива ниво по-дълбоко: aiogram, безопасно боравене с токен и знаене кога да мащабираш.

Ботът, в virtualenv

Влез по SSH и дръж бота изолиран в собствен venv — не инсталирай пакети системно, това прави ъпдейтите и почистването бъркотия по-късно:

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

Минимален aiogram 3 бот, който чете токена си от environment-а, не от твърдо кодиран низ:

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

Дръж токена извън кода си

Никога не постваш BotFather токена в bot.py — един push към публичен repo и е изтекъл. Сложи го в root-четим env файл вместо това:

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

Изтекъл токен е на един /revoke в BotFather от поправка — но изтекло каквото и да е друго на споделена машина е по-лошо. Dedicated VPS за бота е честно по-безопасен дом за токена от ежедневния ти лаптоп: ако изтече, ротираш един токен, не цялата си настройка.

Частта, която го държи жив: systemd

Това е, което разделя бот, който работи, от бот, който стои работещ. Създай услугата:

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

Пусни го като non-root потребител (botuser по-горе), не root — ако ботът бъде компрометиран, го искаш ограничен. После:

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

Restart=always с RestartSec=3 значи, че срив — лош ъпдейт от Telegram, необработено изключение, OOM — връща бота за три секунди, вместо да го остави мъртъв, докато забележиш. Гледай го на живо:

journalctl -u tgbot -f

Това е цялата ти настройка за логване. Няма log файлове за ротиране, няма допълнителен инструментариум — journald вече го има.

Ъпдейтване без драма с downtime

Когато сменяш кода или вдигаш 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

Рестартът примигва бота за секунда-две. За polling бот това е невидимо за потребителите — Telegram опашква ъпдейтите и ги доставя, щом ботът се пресвърже.

Polling срещу webhook — честната версия

Това е решението, което хората премислят прекалено. Ето простата версия:

Polling (start_polling, което кодът по-горе използва) кара бота да пита Telegram „нещо ново?“ на дълготрайна връзка. Не се нуждае от нищо освен изходящ интернет — без домейн, без TLS, без отворени входящи портове. Работи добре зад NAT. За преобладаващото мнозинство ботове това е правилно и трябва да спреш тук.

Webhook кара Telegram да бута ъпдейти към теб, което значи, че трябва да изложиш публичен HTTPS endpoint. Това изисква домейн и достъпен входящ порт — така че или dedicated публичен IP, или reverse proxy отпред. Повече настройка, повече неща, които се чупят. Отплатата е по-ниска латентност и по-малко overhead на голяма скала — хиляди едновременни потребители, тежък обем ъпдейти.

Практичното правило: започни с polling на NAT план. Премести се към webhook само когато реално си надраснал polling — и ако го направиш, тогава dedicated IP си заслужава мястото, защото се нуждаеш от този входящ HTTPS endpoint.

Колко струва да го пуснеш

Polling бот е лек. Той стои бездеен на long-poll-а на Telegram и реагира на съобщения, така че машината основно чака:

Nano за $3 (1 vCPU / 1 GB) — наред за повечето ботове, дори доста бъбриви.
Micro за $5 (2 vCPU / 2 GB) — когато ботът държи база данни (SQLite/Postgres), обработва медия или обслужва много потребители.
По-високо само ако самият бот върши реална работа — обработка на изображения, локален модел, тежка логика на съобщение.

Регистрацията е само с имейл и плащаш в USDC или USDT на Base или Ethereum — без карта, без документ. Карта също работи, но on-ramp-ът има минимум ~$27, така че за план за $3 е по-гладко еднократно да заредиш малък баланс и да оставиш подновяванията да черпят от него. Само CPU е, един датацентър в Германия — незначителен въпрос за бот, струва си да знаеш, ако си се нуждаел от GPU или конкретен регион.

Честното заключение

Telegram бот е едно от най-евтините неща, които можеш да хостваш сам: машина за $3, systemd unit, и polling ти дава бот, който е онлайн през сривове и рестарти, без ти да го бавачиш. Посегни към webhook и по-голям план само когато скалата реално го наложи — не защото туториал ти е казал, че webhook-овете са „по-добри“. Вземи малката машина, дръж токена в env файл, остави systemd да се грижи за времето на работа, и — преди всичко друго — пусни checklist за сигурност на нов VPS, така че самата машина да е заключена.

Готов да хостваш своя? Telegram бот едва използва ресурси — Nano планът ($3/месец) го пуска 24/7 без суетня.