Хостинг для Telegram-бота: где разместить и как выбрать

Бот на Python отвечает в тестах, вы заливаете его на обычный виртуальный хостинг, а через час он замолкает: хостер убил «зависший» процесс, потому что shared-тариф не рассчитан на программу, работающую круглосуточно. Это самый частый провал при первом деплое Telegram-бота, и упирается он не в код, а в тип хостинга.

Разберём по первоисточникам, что именно нужно боту (постоянно живой процесс или публичный HTTPS-эндпоинт), почему shared-хостинг обычно не годится, сколько стоит VPS на примере Timeweb и где «бесплатные» варианты превращаются в ловушку с засыпанием и лимитами.

Что вообще нужно Telegram-боту от хостинга

Telegram отдаёт сообщения боту одним из двух взаимоисключающих способов. Первый — long polling: бот сам в цикле дёргает метод getUpdates и спрашивает сервер, есть ли что-то новое. Второй — webhook: через setWebhook вы регистрируете URL, и Telegram сам шлёт на него POST-запрос при каждом обновлении. В документации это сказано прямо: пока настроен исходящий webhook, получать апдейты через getUpdates уже нельзя. Оба режима включить одновременно не получится.

Практический вывод один. Polling — это pull: нужен процесс, который живёт постоянно и не «засыпает», иначе бот перестаёт опрашивать сервер. Webhook — это push: нужен публичный HTTPS-адрес, готовый в любой момент принять запрос. От выбранного режима напрямую зависит, какой хостинг подойдёт, а какой окажется бесполезным.

Polling или webhook: как выбор диктует требования

Webhook строже к инфраструктуре. Он обязательно требует шифрования: по документации webhook требует SSL/TLS независимо от порта, и поддерживается только TLS версии 1.2 и выше. Портов ровно четыре: 443, 80, 88 и 8443, остальные Telegram не примет. Для «настоящего» доверенного сертификата нужен домен; можно обойтись самоподписанным сертификатом, но тогда придётся указать IP как CN и загрузить публичный сертификат параметром certificate. Итог: webhook-боту в любом случае нужен внешне доступный адрес (домен или белый IP) плюс валидный HTTPS.

Polling проще на старте: домен и сертификат не нужны, боту достаточно машины с исходящим интернетом и процессом, который не гасят. Отсюда критерий выбора. Один-два бота с умеренным трафиком — берите polling, разворачивается за минуты. Много ботов на сервере или высокая нагрузка, где важна мгновенная доставка, — переходите на webhook. И в том, и в другом случае обычный shared-хостинг оказывается узким местом.

Почему shared-хостинг обычно не тянет бота

От виртуального хостинга под Telegram-бота стоит отказываться сразу, и об этом говорит даже собственный гайд Timeweb: «от shared-хостингов для телеграм-бота лучше сразу отказаться». Причина техническая. На shared-тарифе нельзя держать собственный постоянно работающий процесс и ставить произвольное ПО: своё окружение Python или Node, Docker, базу вроде PostgreSQL или Redis рядом с ботом. А боту нужно именно это.

Стандартное решение — VPS или VDS с root-доступом. Он даёт стабильное подключение, выделенный IP и не требует обязательного домена для polling-бота. Чтобы процесс не умирал после сбоя или перезагрузки, его запускают под менеджером процессов. Тот же гайд Timeweb предлагает PM2, командой вида pm2 start main.py --interpreter=python3; на практике для той же задачи используют systemd или supervisor. Подробнее про сам формат аренды и тарификацию — в разборе аренды виртуального сервера.

Сколько стоит VPS: Timeweb как пример

Возьмём для ориентира облачные VPS Timeweb линейки Cloud MSK. Цены ниже — с учётом скидки 10% при оплате за год:

Для одиночного бота хватает младшего тарифа: 2 ГБ RAM с запасом покрывают polling-процесс на Python или Node и небольшую базу рядом. В тариф входят NVMe-диски, публичный IP, канал 1000 Мбит/с, KVM-виртуализация и снапшоты; из образов доступны Ubuntu, Debian, CentOS, AlmaLinux, Astra и Windows, есть загрузка своих ISO и поддержка Docker, PostgreSQL и Redis — всё, что нужно и polling-, и webhook-боту. Доступен почасовой биллинг: сервер можно арендовать хоть на час, при смене тарифа цена пересчитывается. Детальный разбор провайдера — в обзоре Timeweb.

Важная оговорка про цифры. По сети гуляют цены «VPS от 169–188 ₽/мес» и обещания тестового периода на 10 дней, но на самой странице timeweb.com минимум — 693 ₽ за кастом и 882 ₽ за именной тариф, а тестовый период там не заявлен. Более дешёвые ценники относятся к другому бренду, timeweb.cloud, а не к timeweb.com, поэтому ориентируйтесь на прайс площадки, где реально будете платить.

Бесплатные варианты и где они ломаются

Бесплатно разместить бота технически можно, но почти каждая площадка ставит подножку именно там, где боту нужна непрерывность. PythonAnywhere разрешает постоянно работающую задачу (Always-on task), которая и держит polling-бота, только на платных аккаунтах — в справке прямо сказано, что это заработает лишь на платных тарифах. На бесплатном аккаунте держать бота в polling не выйдет.

У Render свой набор ограничений на free-тарифе: бесплатный веб-сервис засыпает после 15 минут без входящего трафика, холодный старт около минуты, лимит 750 instance-часов на воркспейс в месяц, бесплатная база удаляется через 30 дней, а сам сервис может перезапуститься в любой момент. Для webhook-бота это не потеря сообщений, а задержка на «пробуждение»: пока сервис минуту просыпается, он не отдаёт Telegram успешный ответ. По документации Bot API при ответе с HTTP-статусом не из диапазона 2XY Telegram повторяет доставку, а неполученные апдейты хранит на сервере до 24 часов — значит гарантированной потери нет, но обработчик должен быть идемпотентным: из-за повторов один и тот же апдейт может прийти несколько раз, поэтому дедуплицируйте его по update_id. Паттерн у всех бесплатных тарифов одинаковый — спят при простое, ограничены по часам и ресурсам, без гарантии аптайма, поэтому годятся под тест и пет-проект, но не под боевого бота. Шире сравнить площадки — в подборке про бесплатный хостинг.

Serverless: альтернатива, а не замена VPS

Облачные функции — отдельный сценарий, который хорошо ложится на webhook-бота: функция вызывается на каждый апдейт, а платите вы не «только за вызовы», а за вызовы плюс ресурсы выполнения (память×время) и исходящий трафик — но не за круглосуточно арендованный сервер. У Yandex Cloud Functions есть ежемесячный бесплатный грант: первый 1 000 000 вызовов, 10 ГБ×час выполнения и 100 ГБ исходящего трафика не тарифицируются, дальше идёт 18,97 ₽ за миллион вызовов плюс 6,48 ₽ за ГБ×час, а использование триггеров не тарифицируется вовсе. Для типичного бота с умеренным трафиком это чаще всего укладывается в бесплатный лимит.

У serverless есть и минусы: он рассчитан под webhook и почти не подходит под постоянный polling. Экземпляры функции тоже приостанавливаются после простоя (у Yandex Cloud Functions это прямо описано в жизненном цикле экземпляра), отсюда возможные холодные старты; гарантированно убрать их можно только на подготовленных (provisioned) экземплярах, но у них тарифицируется и простой. Добавьте привязку к экосистеме провайдера. Поэтому облачные функции — альтернатива для webhook-сценария, а не замена VPS, где вы полностью управляете окружением.

Пошагово: как поднять бота на VPS

1. Определитесь с режимом: polling для одного простого бота, webhook — если нужен домен, SSL и мгновенная доставка.
2. Возьмите VPS с root-доступом (для одиночного бота хватает 2 ГБ RAM), выберите ОС из образов провайдера.
3. Поставьте окружение (Python или Node), при необходимости Docker и базу, залейте код бота.
4. Запустите процесс под менеджером — PM2, systemd или supervisor, чтобы бот сам перезапускался после сбоя и перезагрузки.
5. Для webhook привяжите домен (или белый IP с самоподписанным сертификатом), настройте HTTPS на порту 443/80/88/8443 и вызовите setWebhook.
6. Проверьте автозапуск, логи и мониторинг, чтобы падение процесса не осталось незамеченным.

VPS с root-доступом — это ваша ответственность за безопасность, поэтому перед боевым запуском пройдитесь по базовому чеклисту:

• Токен — в секреты. Храните токен бота в переменных окружения или менеджере секретов, а не в коде и не в репозитории: попав в git, он утекает вместе с исходниками, и бота смогут угнать.
• Не работайте под root. Заведите отдельного непривилегированного пользователя и запускайте бота под ним — так ошибка или взлом не дадут полного контроля над сервером.
• Файрвол. Включите ufw (или аналог) и оставьте открытыми только нужные порты — для webhook это HTTPS-порт, всё лишнее закройте.
• Обновления и бэкапы. Регулярно ставьте обновления ОС и пакетов и настройте резервное копирование кода, конфигов и базы.
• Проверяйте источник webhook. Задайте secret_token при вызове setWebhook и на каждом запросе сверяйте заголовок X-Telegram-Bot-Api-Secret-Token — так вы убедитесь, что запрос пришёл от Telegram, а не подделан сторонним отправителем, знающим ваш URL.

Частые вопросы