Как выбрать VPS для Telegram-бота
Небольшому боту не нужен дорогой сервер, но ему нужны стабильная сеть, автоматический перезапуск и резервная копия данных. Подбираем конфигурацию с запасом, который действительно пригодится.
Минимальные ресурсы зависят от нагрузки
| Сценарий | Стартовая конфигурация | Когда увеличивать |
|---|---|---|
| Простой бот без БД | 1 vCPU, 1 ГБ RAM, 10–20 ГБ SSD | При росте одновременных обработчиков |
| Бот + PostgreSQL/Redis | 2 vCPU, 2–4 ГБ RAM, NVMe | При очередях и нехватке кэша |
| Медиа или ML-задачи | 2–4 vCPU, от 4 ГБ RAM | По измерениям CPU, RAM и диска |
Оставьте 20–30% RAM свободными для системы и обновлений. Для базы данных важнее стабильный NVMe и достаточная память, чем большой диск. Не храните загруженные файлы бесконечно: переносите их в объектное хранилище или удаляйте по расписанию.
Long polling или webhook
Long polling проще запустить и не требует входящего HTTPS-соединения. Webhook удобен при масштабировании, но нужен домен, TLS-сертификат и доступный порт. В обоих случаях критичнее стабильность маршрута до API Telegram, чем гигабитный порт.
Проверьте, что провайдер не ограничивает нужные исходящие соединения, а выбранная локация имеет устойчивый маршрут. Начните с помесячного тарифа и протестируйте задержки на реальном боте.
Как выбрать локацию и сеть
Бот общается одновременно с API Telegram, внешними сервисами и вашей базой. Локация должна иметь стабильный маршрут ко всем критичным точкам. Географическая близость к владельцу не всегда важна: пользователь отправляет сообщение через инфраструктуру Telegram, а задержка может возникнуть на запросе к стороннему API.
Попросите тестовый IP, проверьте маршрут в разное время и сначала запустите копию бота без переключения основного трафика. Гигабитный порт обычно не нужен текстовому боту, но для загрузки и обработки медиа важны и скорость, и месячный лимит. Условия больших объёмов разобраны в статье о трафике VPS.
Как развернуть без ручных перезапусков
- Создайте отдельного пользователя без постоянной работы от root.
- Храните токен и пароли в переменных окружения, а не в репозитории.
- Запускайте приложение через systemd или Docker с политикой перезапуска.
- Закройте лишние порты, включите SSH-ключи и автоматические обновления безопасности.
- Настройте логирование с ротацией, чтобы логи не заполнили диск.
Не сохраняйте секреты в образ контейнера или открытый файл конфигурации. Ограничьте права токена базы, меняйте скомпрометированные ключи и разделяйте тестовую и рабочую среды. Если используете webhook, автоматически обновляйте TLS-сертификат и следите за сроком его действия.
База данных, очередь и файлы
Для маленького бота SQLite может быть достаточна, если работает один процесс и запись невелика. При параллельных обработчиках, отчётах и росте данных удобнее PostgreSQL. Redis полезен для очереди и кэша, но не должен быть единственной копией важных данных без настроенного сохранения.
| Компонент | Основной риск | Что контролировать |
|---|---|---|
| Процесс бота | Остановка после ошибки или обновления | Автоперезапуск, health check, число ошибок |
| База данных | Потеря или рост задержки | Дампы, размер, медленные запросы, соединения |
| Очередь | Накопление задач | Длину и возраст старейшей задачи |
| Медиафайлы | Заполнение диска | Квоту, срок хранения и очистку |
| Внешний API | Лимиты и временная недоступность | Таймауты, повторы с задержкой, число отказов |
Не выполняйте долгую операцию прямо внутри обработчика сообщения. Поставьте задачу в очередь, сообщите пользователю о начале обработки и ограничьте число повторов. Это защищает бота от цепочки дублей при временной ошибке внешнего сервиса.
Мониторинг и резервные копии
Минимальный мониторинг должен сообщать, что процесс остановился, накопилась очередь или заканчивается диск. Для базы данных делайте отдельные ежедневные дампы и периодически проверяйте восстановление. Снимок всего VPS полезен, но не заменяет переносимую копию данных.
Добавьте внешний мониторинг: если сервер целиком недоступен, локальный процесс не сможет отправить уведомление. Следите за CPU, RAM, swap, свободным диском, числом ошибок, временем обработки и длиной очереди. Порог выбирайте по обычному поведению бота, а не по случайному универсальному значению.
План восстановления должен отвечать на три вопроса: где лежит последняя независимая копия, кто имеет доступ и сколько времени занимает запуск на чистом VPS. Один раз пройдите этот сценарий до аварии. Подробный порядок описан в руководстве по резервному копированию VPS.
Когда увеличивать сервер
- CPU долго загружен и очередь растёт именно из-за вычислений;
- памяти не хватает, появляется swap или процессы завершаются;
- база замедляется после оптимизации запросов и индексов;
- диск регулярно заполняется несмотря на очистку логов и файлов;
- несколько процессов действительно могут использовать дополнительные ядра.
Масштабирование не исправляет бесконечный повтор запросов, утечку памяти или отсутствующий индекс. Сначала найдите узкое место по метрикам, затем меняйте только ограничивающий ресурс.
Проверка перед запуском
- токен бота и пароли не находятся в репозитории и логах;
- процесс автоматически запускается после перезагрузки VPS;
- ошибки внешних API имеют таймаут и ограниченное число повторов;
- дамп базы сохраняется вне сервера и успешно восстанавливается;
- диск, очередь и доступность контролируются внешним мониторингом;
- у владельца есть инструкция для выпуска и отката новой версии.
Перед переключением пользователей проведите тест с отдельным ботом или тестовым окружением. Имитируйте временную недоступность базы и внешнего API, перезагрузите сервер и убедитесь, что обработка продолжилась без дублей. Такой тест полезнее покупки ресурсов «с запасом».
Частые вопросы
Хватит ли 1 ГБ RAM для Telegram-бота?
Для простого бота без тяжёлой панели и большой базы — часто да. Для PostgreSQL, Redis и нескольких контейнеров безопаснее начать с 2–4 ГБ и наблюдать за памятью.
Нужен ли домен?
Для long polling — нет. Для webhook нужен доступный HTTPS-адрес; домен упрощает сертификат и перенос между серверами.
Можно ли держать базу на том же VPS?
Для небольшого проекта это нормально при регулярных внешних копиях. При росте нагрузки и требований к доступности базу можно вынести отдельно.
Для точного расчёта откройте таблицу CPU и RAM для разных задач.