Najlepszy VPS dla bota Telegram: polling, webhooki, IPv4 i koszt miesięczny

Bot odpowiada na każdą wiadomość, dopóki nie zamkniesz laptopa. Potem użytkownicy nie dostają odpowiedzi. Mały VPS rozwiązuje to za kilka dolarów miesięcznie. Najlepszy VPS dla bota Telegram zależy od sposobu odbierania aktualizacji: albo bot prosi o nie Telegram, albo Telegram wysyła je do bota.

Ten wybór określa potrzebne porty i certyfikat oraz to, czy wymagane jest publiczne połączenie IPv4.

Krótka wersja

• Dla jednego bota na VPS wybierz long polling. Nie wymaga domeny, certyfikatu ani otwartego portu.
• Webhooki wymagają HTTPS na porcie 443, 80, 88 lub 8443 oraz publicznego adresu IPv4. Telegram nie dostarcza webhooków przez IPv6.
• 512 MB of RAM is a workable start for one bot with no local database.
• Utrzymuj bota w działaniu za pomocą systemd lub zasad restartowania Dockera, jeśli już wdrażasz kontenery.
• Wybieraj dostawcę według dostępności IPv4 i zapasu RAM, nie tylko ceny katalogowej.

Polling czy webhooki: wybór określający wymagania serwera

Bot Telegram odbiera aktualizacje na jeden z dwóch sposobów. Przy long pollingu wywołuje getUpdates, a Telegram utrzymuje żądanie otwarte do nadejścia aktualizacji lub upływu limitu czasu. Każde połączenie rozpoczyna się więc na Twoim serwerze. Przy webhooku jednorazowo rejestrujesz URL za pomocą setWebhook, a Telegram wysyła pod ten adres każdą aktualizację żądaniem POST przez HTTPS.

Kolumna webhooków jest zgodna z wymaganiami Telegrama dotyczącymi webhooków.

Aby sprawdzić, z jakiej metody korzysta bot, zapytaj Bot API:

curl "https://api.telegram.org/bot<YOUR_TOKEN>/getWebhookInfo"

Jeśli odpowiedź zawiera "url":"", webhook nie jest skonfigurowany i bot może korzystać z long pollingu. Funkcja bot.start() w grammY domyślnie używa long pollingu; python-telegram-bot korzysta z run_polling() lub run_webhook().

Dla jednego bota na własnym VPS wybrałbym polling, co jest też domyślnym zaleceniem grammY. Webhooki wygrywają, gdy serwer ma już odwrotne proxy (serwer WWW przekazujący żądania HTTPS do bota), gdy kilka botów współdzieli jeden punkt końcowy HTTPS lub na platformie serverless. W takim przypadku Caddy pobiera i odnawia certyfikat bez zadania cron.

Krótka awaria opóźnia wiadomości, ale ich nie gubi. Zgodnie z zasadami aktualizacji Bot API Telegram przechowuje aktualizacje do 24 godzin, aż bot je odbierze, przy obu metodach, oraz ponawia nieudane żądania webhooków, zanim zrezygnuje.

Jeśli webhook bezpośrednio używa swojego portu, ogranicz go do zakresów źródłowych opublikowanych przez Telegram. Jeśli port 443 współdzieli odwrotne proxy obsługujące inne witryny, zastosuj ograniczenie tylko do ścieżki webhooka albo użyj tajnego tokena Telegrama zamiast blokować cały pozostały ruch HTTPS. Przewodnik po webhookach podaje dwa zakresy źródłowe i ostrzega, że mogą się zmienić. Z UFW jako zaporą hosta:

sudo ufw allow 22/tcp    # keep SSH open before you enable the firewall

sudo ufw allow proto tcp from 149.154.160.0/20 to any port 443

sudo ufw allow proto tcp from 91.108.4.0/22 to any port 443

sudo ufw allow 80/tcp    # if your HTTPS setup uses HTTP validation or redirects HTTP to HTTPS

sudo ufw enable

Zmień 443, jeśli webhook nasłuchuje na 80, 88 lub 8443. Te reguły chronią bota działającego bezpośrednio na hoście. Dokumentacja zapory Dockera podaje, że opublikowany port omija UFW, więc kontener webhooka uruchomiony z -p 443:443 pozostaje dostępny dla wszystkich. Ustaw też secret_token w setWebhook. Telegram przesyła go w nagłówku X-Telegram-Bot-Api-Secret-Token każdego żądania, a kod obsługi odrzuca żądania bez niego.

Jak utrzymać bota w działaniu: systemd czy Docker

Działanie bota Telegram przez całą dobę wymaga ponownego uruchamiania po awariach i restartach serwera. Na VPS zajmuje się tym systemd albo Docker, jeśli bot jest dostarczany jako obraz.

Jednostka systemd to krótki plik konfiguracyjny informujący system inicjalizacji, jak uruchamiać i restartować program. Utwórz /etc/systemd/system/telegram-bot.service:

[Unit]
Description=Telegram bot
After=network-online.target
Wants=network-online.target

[Service]
User=bot
WorkingDirectory=/opt/bot
EnvironmentFile=/opt/bot/.env
ExecStart=/opt/bot/venv/bin/python bot.py
# Node: ExecStart=/usr/bin/node bot.js
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Umieść token w pliku .env w folderze projektu jako BOT_TOKEN=... i odczytuj go przez os.environ["BOT_TOKEN"] (Node: process.env.BOT_TOKEN), aby nie był zapisany w kodzie. Następnie skopiuj projekt we właściwe miejsce i uruchom go:

sudo mkdir -p /opt/bot

sudo cp -r ~/your-bot/. /opt/bot/        # your project, after git clone or scp from your machine; include .env and requirements.txt

sudo apt install -y python3-venv         # Debian/Ubuntu

sudo useradd --system --no-create-home bot

sudo chown -R bot:bot /opt/bot

sudo -u bot python3 -m venv /opt/bot/venv

sudo -u bot /opt/bot/venv/bin/pip install -r /opt/bot/requirements.txt

# Node: skip the venv and pip commands above, then run:

cd /opt/bot && sudo -u bot npm ci

sudo chmod 600 /opt/bot/.env

sudo systemctl daemon-reload

sudo systemctl enable --now telegram-bot

systemctl status telegram-bot    # look for: Active: active (running)

sudo journalctl -u telegram-bot -f    # follow the bot's logs

Restart=always restartuje bota po poprawnym zakończeniu i po awarii; on-failure pomija poprawne zakończenia, zgodnie z podręcznikiem systemd.service. RestartSec=5 zapewnia odstęp między próbami, a WantedBy=multi-user.target wraz z enable uruchamia bota przy starcie systemu. Jeśli bot ciągle się restartuje, sudo journalctl -u telegram-bot -n 50 pokaże ślad błędu. Najpierw sprawdź, czy nie brakuje BOT_TOKEN.

Odpowiednik w Dockerze to jedna flaga:

docker run -d --name telegram-bot --restart unless-stopped --env-file .env your-bot-image

docker logs -f telegram-bot

W Compose jest to wiersz restart: unless-stopped. Dokumentacja zasad restartowania Dockera mówi, że kontener wraca po zakończeniu działania lub restarcie demona, ale nie po ręcznym zatrzymaniu. Obejmuje to restarty serwera, jeśli sam Docker uruchamia się przy starcie systemu, co robi domyślnie w Debianie i Ubuntu. W innych systemach uruchom sudo systemctl enable docker.service.

Moja zasada: jeden skrypt na małym serwerze dostaje systemd, bez dodatkowego demona w pamięci. Jeśli już budujesz obrazy lub uruchamiasz inne kontenery, użyj Dockera i uwzględnij zużycie RAM przez jego demona.

Żadne z tych narzędzi nie informuje o awarii bota. Może to zrobić monitor push Uptime Kuma na drugim serwerze. Bot cyklicznie wywołuje URL monitora, a Uptime Kuma wysyła alert w Telegramie, gdy wywołania ustaną.

Gdzie darmowy hosting i serwery domowe zawodzą

Render usypia darmową usługę WWW po 15 minutach bez ruchu przychodzącego, a dokumentacja darmowej oferty Rendera określa czas wybudzenia na około minutę. Bot z pollingiem nie odbiera ruchu przychodzącego, więc zostaje zatrzymany. Bota z webhookiem wybudza POST Telegrama, co po okresie ciszy oznacza zimny start. To, czy darmowy hosting sprawdzi się dla bota Telegram, zależy więc od jego metody.

Przewodnik grammY wymienia platformy serverless jako odpowiednie dla webhooków, podczas gdy long polling potrzebuje maszyny działającej przez całą dobę. Fly.io rozlicza za użycie i wymaga zapisanej karty płatniczej.

Raspberry Pi lub stary komputer może uruchamiać bota z pollingiem, dopóki działają maszyna, zasilanie i połączenie. Webhooki z domu wymagają też publicznego adresu i przekierowania portów. Dla hobbystycznego bota obie darmowe możliwości mogą wystarczyć.

VPS obsługuje obie metody za stałą miesięczną cenę.

Porównanie pięciu dostawców VPS dla bota Telegram

Tabela porównuje pięć płatnych planów podstawowych do hostingu botów Telegram według reklamowanych miesięcznych cen, aktualnych na październik 2026 r., przed opodatkowaniem. Ceny promocyjne oznaczono tam, gdzie obowiązują.

Plan Vultra tylko z IPv6 nie ma IPv4, a cena Hetznera nie obejmuje adresu IPv4. Bez niego żaden z nich nie może odbierać webhooków.

Bot z pollingiem może działać tylko po IPv6, ponieważ api.telegram.org ma adres IPv6. Muszą go mieć również wszystkie inne cele połączeń, w tym rejestry pakietów, hosting Git i każde wywoływane API. Sprawdź każdy host przed wyborem:

dig +short AAAA api.telegram.org

dig +short AAAA github.com

dig +short AAAA pypi.org    # repeat for every host your bot or its installs reach

Pusta odpowiedź oznacza, że host nie ma adresu IPv6.

Czy 512 MB wystarczy dla bota Telegram?

Zacząłbym od 512 MB dla jednego bota bez lokalnej bazy danych. Dokumentacja python-telegram-bot nie podaje wymagań pamięciowych. Decyduje to, co współdzieli serwer: system operacyjny, ewentualny demon Dockera i lokalna baza danych. Zmierz zużycie.

free -m                   # "available" is your headroom; the Swap row shows swap use

ps -o rss,cmd -p "$(systemctl show -p MainPID --value telegram-bot)"   # bot's resident memory, in KB

docker stats --no-stream  # per-container memory, if the bot runs in Docker

journalctl -k | grep -i "out of memory"   # kernel OOM kills

Zakończenie procesu z powodu braku pamięci (OOM) oznacza, że jądro zamyka proces, aby zwolnić RAM. systemd restartuje bota, więc ten wpis w logu może być jedynym dowodem. Przejdź na 1 GB, gdy wystąpią zakończenia OOM, swap jest stale używany lub przed dodaniem lokalnej bazy danych albo drugiego bota.

Który wybrać

Dla jednego bota wybrałbym plan 512 MB z publicznym IPv4 w cenie. Wybór dostawcy zależy wtedy od ceny, zapasu zasobów i lokalizacji użytkowników.

• Najniższa obecna cena miesięczna: Cloudzy za 2,48 USD w promocji 50%, z IPv4 i IPv6 w cenie.
• Najniższa obecna cena z IPv4: Cloudzy za 2,48 USD w promocji. Dedykowany IPv4 i IPv6 są w cenie.
• 1 GB of headroom for Docker or a small database: Linode, from $5 a month.
• Kilka botów lub baza danych, użytkownicy w Europie: Hetzner, najwięcej zasobów za euro w tej tabeli, o ile plan jest dostępny (w październiku 2026 r. figurował jako niedostępny). Dla webhooków dolicz opłatę za IPv4.
• Więcej dysku i transferu przy 512 MB: Cloudzy. Spośród planów 512 MB oferuje najwięcej przestrzeni (20 GB NVMe wobec 10) i transferu (1 TB wobec około 500 GB), z IPv4 i IPv6 w cenie. Przy obecnej cenie promocyjnej Cloudzy jest też tańsze od pozostałych planów podstawowych w tym porównaniu.

Przy obecnej cenie promocyjnej Cloudzy łączy najniższą cenę miesięczną w tym porównaniu z większą przestrzenią dyskową i transferem niż pozostałe plany 512 MB. Plan Cloudzy 512 MB jest rozliczany godzinowo i ma 14-dniową gwarancję zwrotu pieniędzy, więc możesz uruchomić na nim bota na kilka dni, zanim podejmiesz decyzję. Wybierz lokalizację najbliższą użytkownikom, wdroż Linux VPS od Cloudzy i dodaj opisaną wyżej jednostkę systemd.

Często zadawane pytania