Чому Telegram-бот вимикається разом із ноутбуком і як запустити його 24/7

Сценарій знайомий багатьом, хто пише першого Telegram-бота: запустили python bot.py або node bot.js, відправили /start — відповідь приходить одразу. Потім закрили термінал, ноутбук заснув або зник домашній інтернет, і бот раптом замовк. З боку це схоже на проблему Telegram, хоча зазвичай Telegram тут ні до чого.

Telegram не виконує код вашого бота. Він надає Bot API, а Python-, Node.js- чи інший процес працює на вашому комп’ютері. Для режиму 24/7 цей процес потрібно перенести в середовище, яке постійно доступне в мережі, а потім налаштувати його так, щоб він не залежав від відкритого SSH-сеансу, відновлювався після збою та запускався після перезавантаження системи.

Чому бот працює на ноутбуці, але зникає після його вимкнення

Telegram-бот перестає відповідати після вимкнення ноутбука, тому що саме на цьому комп’ютері виконується його код. BotFather реєструє бота та видає токен, Telegram Bot API передає запити, але команди /start, робота з базою, звернення до сторонніх API та інша прикладна логіка виконуються вашою програмою.

Поки активний процес python bot.py, усе добре. Закрили термінал — процес може завершитися. Ноутбук перейшов у сон — виконання зупинилося. Пропав Wi-Fi — програма може залишатися запущеною, але зв’язку з Telegram уже немає. Необроблений виняток у коді дає ще один варіант тієї самої картини: у чаті бот є, але відповідати нікому.

Тут корисно не змішувати три різні речі: доступність самого Telegram, реєстрацію бота через BotFather і фактичну роботу процесу з кодом. Перші дві можуть бути в порядку, коли третя вже давно зупинилася.

На Linux швидку перевірку можна почати з pgrep -af python або пошуку конкретного Node.js-процесу. Ще краще — перевіряти не всі процеси Python поспіль, а конкретний systemd-сервіс, контейнер або процес у PM2. На Windows для локального тесту підійде Диспетчер завдань. Після цього дивляться лог і відправляють тестову команду боту.

Що змінюється, коли бот переноситься з ноутбука на сервер

Копіювання файлів на сервер нічого не запускає автоматично. Спочатку потрібно відтворити середовище, у якому працює проєкт: потрібну версію Python або Node.js, залежності, змінні середовища, доступ до бази даних і зовнішніх API.

Для Python зазвичай перевіряють python --version, створюють окреме середовище через python -m venv venv і встановлюють залежності з requirements.txt. Для Node.js починають із node --version та npm install. Якщо бот використовує розклад, варто одразу перевірити часовий пояс системи.

Коли локально все працює, а на сервері програма падає відразу після старту, причина часто банальна: інша версія бібліотеки, відсутній пакет, неправильний шлях до файла, не переданий токен, немає прав на каталог або недоступна база даних.

Нормальна послідовність проста: зайти по SSH, перейти в каталог проєкту, активувати середовище, запустити бота вручну і надіслати тестове повідомлення. Лише коли цей сценарій стабільно працює, є сенс налаштовувати systemd, PM2 чи Docker. Менеджер процесів уміє перезапустити програму, але не виправляє помилки в ній.

Polling чи webhook: як бот отримуватиме повідомлення

Для невеликого Telegram-бота polling часто цілком достатньо і після переходу на постійний сервер. За polling програма сама звертається до Telegram і забирає нові updates. За webhook напрямок інший: Telegram надсилає HTTP-запит на вказаний вами HTTPS endpoint.

Параметр	Polling	Webhook
Початкове налаштування	Простіше	Більше компонентів
Публічний HTTPS endpoint	Не потрібен	Потрібен
Reverse proxy	Зазвичай не потрібен	Часто використовується
Невеликий окремий бот	Часто зручний варіант	Залежить від архітектури
Вхідні HTTP-запити	Не потрібні для отримання updates	Є основою схеми

Коли достатньо polling

Polling добре підходить боту, який обробляє команди, звертається до API або працює з невеликою базою й не має власної публічної вебчастини. Піднімати окремий HTTPS endpoint лише заради Telegram у такому сценарії не потрібно. Відкривати вхідний порт на сервері для самого polling теж не потрібно.

Коли має сенс webhook

Webhook логічно використовувати, коли застосунок уже має вебчастину, HTTPS і reverse proxy або коли така схема природно вписується в його архітектуру. Для перевірки стану webhook корисний метод getWebhookInfo: через нього можна побачити налаштовану адресу та помилки доставки updates.

Не треба тягнути webhook у проєкт лише заради слова production. Він не стає автоматично «професійнішим», а polling — «тестовим». Важливіше, щоб обрана схема була простою для підтримки й відповідала реальній архітектурі застосунку.

Чому недостатньо просто запустити python bot.py через SSH

Постійний Telegram-бот варто запускати через системний сервіс або менеджер процесів, а не залишати прив’язаним до інтерактивного SSH-сеансу. Якщо бот працює лише доти, доки ви підключені до сервера, це все ще ручний запуск, а не нормальний режим 24/7.

Якщо власної постійно ввімкненої машини немає, для такого запуску можна використовувати VPS, хмарне середовище або сервер для Telegram-бота. Конкретний варіант другорядний: процесу потрібні постійно доступна операційна система, стабільна мережа та достатні ресурси для його задач.

systemd для постійного сервісу

Для Python-бота на Linux типовим вибором залишається systemd. У service-файлі задають робочий каталог, команду запуску, користувача та політику відновлення після збою. Наприклад, Restart=on-failure дозволяє сервісу стартувати повторно після аварійного завершення. Поточний стан зручно перевіряти через systemctl status bot.service.

PM2 для Node.js

У Node.js-проєктах часто використовують PM2. Він тримає процес під контролем, показує його стан і логи та може відновлювати список застосунків після перезавантаження. Для щоденної роботи достатньо знати хоча б pm2 status і pm2 logs.

Docker із політикою перезапуску

Якщо бот уже контейнеризований, його життєвим циклом може керувати Docker. Тут важливо не лише запустити контейнер, а й задати політику перезапуску, наприклад restart: unless-stopped у Compose-конфігурації. Стан видно через docker ps, а причину збою — через docker logs.

nohup, screen і tmux зручні для тестів або ручних запусків, але постійним процесом краще керувати через сервіс чи менеджер процесів. SSH має бути способом адміністрування бота, а не умовою його роботи.

Що має статися після помилки або перезавантаження сервера

Автоматичний перезапуск після падіння і запуск після reboot — не одне й те саме. Програма може успішно відновлюватися після exception, але так і не стартувати після перезавантаження самого сервера, якщо сервіс не доданий до автозапуску.

Причини аварійного завершення бувають різними: необроблена помилка в коді, OOM, проблема з мережею, недоступний зовнішній API. У такому випадку systemd, PM2 або Docker можуть підняти процес повторно. Але після reboot має спрацювати ще й механізм системного старту.

Для systemd перевіряють systemctl is-enabled bot.service. У PM2 потрібно налаштувати запуск разом із системою і зберегти список процесів. У Docker — переконатися, що контейнер має відповідну restart policy.

Перевіряти це краще не «на віру». Спочатку контрольовано завершіть процес і подивіться, чи повернув його менеджер. Потім зробіть планове перезавантаження сервера та перевірте бота без ручного старту по SSH. Поки такий тест не пройдено, автозапуск фактично не перевірений.

Де зберігати Bot Token, паролі та API-ключі

Bot Token краще передавати через змінну середовища або конфігурацію поза репозиторієм, а не записувати прямо у вихідний код. Конструкція на кшталт BOT_TOKEN = "123456:secret" зручна для першого локального тесту, але швидко стає проблемою, коли проєкт потрапляє в Git або передається іншому розробнику.

.env і змінні середовища

Поширена схема — зберігати значення у файлі .env, а в коді читати BOT_TOKEN зі змінної середовища. Сам файл .env додають до .gitignore. На сервері секрети також можна передати через конфігурацію systemd, PM2 або механізм секретів контейнерного середовища.

Файл конфігурації може містити BOT_TOKEN=..., API_KEY=... і DB_PASSWORD=..., але ці значення не повинні потрапляти в логи, stack trace, скриншоти чи публічний репозиторій. Для файлів із секретами варто перевірити й права доступу.

Що робити, якщо токен потрапив у Git

Якщо справжній Bot Token уже опинився у відкритому репозиторії, видалити його з останньої версії файла недостатньо. Значення могло залишитися в історії Git або бути скопійованим раніше. Такий токен краще вважати скомпрометованим, перевипустити через BotFather і після цього оновити конфігурацію на сервері.

.env допомагає лише тоді, коли сам .env не потрапляє в репозиторій.

Бот мовчить: де шукати причину замість випадкових перезапусків

Якщо Telegram-бот раптово перестав відповідати, спочатку перевіряють стан процесу та останні записи в логах, а не перезавантажують увесь сервер. Один симптом «бот мовчить» може означати що завгодно: падіння процесу, неправильний токен, недоступну БД, помилку стороннього API, нестачу пам’яті або заповнений диск.

Для systemd почніть із systemctl status bot.service та journalctl -u bot.service --since "30 minutes ago". Для PM2 підійдуть pm2 status і pm2 logs, для Docker — docker ps та docker logs --tail 100 container_name.

Якщо сервіс піднімається, через кілька секунд падає і знову стартує, проблема вже не в автозапуску. Треба шукати першу помилку в логах, а не радіти тому, що менеджер процесів сумлінно запускає несправний код знову й знову.

Бот не відповідає: порядок перевірки

1. Переконатися, що процес або контейнер справді запущений.
2. Перевірити, чи немає циклічних перезапусків.
3. Подивитися останні записи в логах перед збоєм.
4. Перевірити змінні середовища, токен і конфігурацію сервера.
5. Переконатися, що машина має вихід у мережу та може звертатися до Telegram API.
6. Перевірити базу й сторонні API. Коди 401, 403, 429 та 5xx підказують різні напрямки пошуку.
7. Подивитися пам’ять через free -h і вільне місце через df -h.
8. Для webhook перевірити доступність endpoint та HTTP status.
9. Після виправлення надіслати тестове повідомлення й переконатися, що воно обробляється.

У polling є ще одна характерна пастка. Якщо одночасно запустити два екземпляри одного бота, що використовують getUpdates, вони можуть конфліктувати між собою; типовий симптом — відповідь Telegram із кодом 409 Conflict. Під час міграції варто перевірити, чи не залишився старий процес на ноутбуці або попередньому сервері.

«Бот не працює» — це симптом, а не діагноз. Спочатку лог, потім restart. Інакше легко прибрати прояв проблеми, але так і не зрозуміти, чому вона виникла.

Скільки ресурсів потрібно боту і коли на сервері можна тримати кілька

Простому Telegram-боту зазвичай потрібно небагато ресурсів. Навантаження визначає не сам Telegram, а код, який запускається після отримання повідомлення. Бот із десятком команд і невеликою базою та бот, який обробляє відео чи запускає браузерну автоматизацію, — зовсім різні серверні задачі.

Для невеликого Python- або Node.js-бота без важких локальних обчислень стартовою точкою часто може бути 1 vCPU та приблизно 512 МБ–1 ГБ RAM. Це не гарантія й не універсальний тариф. Споживання залежить від бібліотек, версії середовища, бази даних, Docker та інших процесів на машині.

Ресурси починають швидко рости, якщо бот обробляє фото й відео, генерує документи, запускає headless-браузер, локальні ML/AI-моделі, великі черги задач або важку базу на тому самому сервері.

Після запуску краще дивитися на фактичні показники: free -h, top, htop, docker stats, load average, swap, частоту перезапусків і час відповіді. Ресурси підбирають під роботу бота, а не під слово Telegram.

Кілька невеликих ботів цілком можуть працювати на одній машині. Зручніше, коли кожен має окремий service, процес або контейнер, власні секрети та окремо читабельні логи. Якщо використовуються локальні HTTP-порти, вони не повинні перетинатися. І, звісно, на сервері має залишатися запас пам’яті, щоб один процес не почав витісняти інші.

Що ще потрібно для роботи 24/7: логи, моніторинг і резервні копії

Автоматичний restart ще не означає надійну роботу. Процес може падати й підніматися десятки разів, а власник помітить проблему лише після повідомлення користувача. Робота 24/7 — це не просто запущений процес, а можливість вчасно побачити збій, знайти причину й відновити сервіс.

Що саме варто моніторити

Для невеликого проєкту не обов’язково будувати складну систему спостереження. Мінімум — знати, чи активний процес, чи не почав він часто перезапускатися, скільки залишилося RAM і місця на диску. Для webhook можна контролювати доступність HTTP endpoint, а для складнішого застосунку додати власну перевірку стану.

Логи мають містити час події, зрозумілий рівень помилки та контекст, якого достатньо для діагностики. Bot Token, API-ключі, паролі та зайві персональні дані туди потрапляти не повинні. Якщо лог постійно росте, потрібна ротація — через journald, logrotate або інший механізм відповідно до схеми запуску.

Що резервувати

Сам процес відновити нескладно — набагато цінніші дані та конфігурація. У резервні копії можуть входити база, завантажені користувачами файли, створені ботом документи, service-файли, Compose-конфігурація та список залежностей. Код краще зберігати в нормальному Git-репозиторії, а не покладатися на єдину копію на сервері.

Секрети резервують окремо й безпечно. Хороша перевірка всієї схеми звучить так: чи зможете ви взяти чисту машину, повернути код, конфігурацію та дані й запустити бота без здогадок про те, «що там колись було налаштовано»?

Перевірка Telegram-бота перед переходом у 24/7

• Код запускається на сервері вручну без помилок.
• Встановлені потрібні версії Python або Node.js та всі залежності.
• Bot Token і API-ключі не записані прямо в репозиторії.
• Polling або webhook обрані під архітектуру проєкту.
• Процес запускається через systemd, PM2, Docker або інший менеджер процесів.
• Бот продовжує працювати після закриття SSH.
• Налаштований запуск після reboot.
• Налаштований перезапуск після аварійного завершення.
• Відомо, де дивитися логи застосунку та системи.
• Перевірені RAM, CPU і вільне місце на диску.
• Є спосіб помітити, що бот зупинився або потрапив у цикл перезапусків.
• Визначено, які дані й конфігурацію потрібно резервувати.
• Якщо ботів кілька, їхні процеси, секрети та логи розділені.

Перенесення Telegram-бота з ноутбука в режим 24/7 — не одна магічна команда. Спочатку потрібен стабільний ручний запуск, потім керування процесом, відновлення після збою, старт після reboot, безпечне зберігання секретів, логи й базовий моніторинг. Коли ці частини перевірені окремо, бот перестає залежати від того, відкритий у вас термінал чи вже давно закритий ноутбук.