# Как отвязать своего бота от включённого ноутбука

Закрыл крышку ноутбука - и бот замолчал. Разбираю, что переносить на сервер кроме кода, что ломается при переезде и кто перезапустит сервис после падения.

URL: https://posts.danashkin.ru/guides/otvyazat-bota-ot-vklyuchennogo-noutbuka
Обновлено: 2026-08-22

---

## Коротко

**Главное**

- Пока твой бот или сервис запускается на личном ноутбуке, это не продукт, а демонстрация: закрыл крышку - и всё встало.
- Переезд состоит из четырёх частей: код, секреты, данные и тот, кто перезапустит упавшее. Забывают обычно последние две.
- Самая частая ошибка непрограммиста - перенести только код. Продукт стартует, падает через час и молча лежит, пока кто-нибудь не заметит.
- Автозапуск после перезагрузки сервера настраивается один раз и снимает большую часть аварий: сервер перезагрузился ночью, сервис поднялся сам.
- Наружу выставляем ровно один вход, а всё остальное держим закрытым. Особенно там, где ходят чужие персональные данные.

## Почему «работает у меня на ноутбуке» - это не продукт?

**Главное**

Личный компьютер выключается, засыпает, теряет сеть и перезагружается ради обновлений. Любой сервис, живущий на нём, наследует все эти состояния. Пользователь при этом видит не «ноутбук закрыт», а «ваш сервис не работает».

Типичная история непрограммиста, который собрал что-то полезное: бот отвечает, отчёт собирается, напоминания приходят. Всё честно работает, пока ноутбук открыт и подключён к сети.

Дальше начинается быт. Ты уехал, крышка закрылась, машина ушла в сон. Обновление системы перезагрузило компьютер, и терминал с запущенным сервисом закрылся. Ты подключился к чужому вайфаю, и внешний сервис перестал достукиваться.

Для тебя это мелочи, для пользователя - отказ. Причём тихий: никто не пришлёт уведомление о том, что бот умер.

Похожий путь я проходил на собственном боте, который стал пультом управления делами: пока он жил на ноутбуке, им пользовался только я. Как он устроен, разбирал в [материале про этот кейс](/guides/telegram-bot-pult-upravleniya-biznesom-keys).

Есть и вторая причина, менее приятная. Сервис на личном ноутбуке невозможно передать. Ни коллеге, ни подрядчику, ни клиенту. Он существует только вместе с твоим компьютером.

## Четыре части переезда

**Главное**

Четыре разных вещи: код, секреты, данные и присмотр. Код переносится проще всего, секреты требуют отдельного места хранения, данным нужна резервная копия, а присмотр - это правило автозапуска и способ узнать, что сервис лежит.

| Что переносим | Где живёт после переезда | Что будет, если забыть |
|---|---|---|
| Код продукта | папка на сервере или образ приложения | сервис просто не запустится |
| Секреты: токены, ключи, пароли | отдельный файл на сервере с закрытым доступом | либо не запустится, либо утекут ключи |
| Данные: база, файлы пользователей | база на сервере плюс резервная копия | потеряешь всё при первой аварии |
| Присмотр: автозапуск и оповещение | настройка сервера и алерт в мессенджер | сервис упадёт и будет лежать сутками |

На обучениях я показываю эту таблицу целиком, потому что первые два пункта делают все, третий часть, а четвёртый почти никто. Отсюда классическая ситуация «месяц назад всё работало, а сейчас, оказывается, не работает уже две недели».

**Секреты не едут вместе с кодом**

Токены и ключи не должны лежать в тех же файлах, что и код, и тем более уезжать в облачное хранилище кода. На сервере им место в отдельном файле с закрытыми правами доступа. Это пять минут работы и единственная защита от того, что твой ключ найдут по поиску.

## Три варианта размещения

**Главное**

Для непрограммиста реалистичны три пути: арендованный сервер, платформа с автоматическим развёртыванием и бессерверный запуск по расписанию. Выбор зависит не от бюджета, а от того, должен ли сервис работать постоянно или включаться по событию.

**Арендованный сервер.** Обычная виртуальная машина за небольшие деньги в месяц. Ты полностью управляешь тем, что на ней происходит. Подходит для ботов, которые должны быть на связи круглосуточно, и для всего, где важно, чтобы данные лежали в известной юрисдикции.

**Платформа с автоматическим развёртыванием.** Ты подключаешь хранилище кода, платформа сама собирает и запускает приложение при каждом обновлении. Удобно для сайтов и веб-сервисов, дороже в мелочах, зато почти без администрирования.

**Запуск по расписанию.** Если сервис не должен работать постоянно, а обязан просыпаться раз в час или раз в сутки, отдельная машина не нужна: достаточно запланированной задачи, которая выполняет скрипт и засыпает.

| Вариант | Кому подходит | Что требует от тебя |
|---|---|---|
| Свой сервер | боты, круглосуточные сервисы, чувствительные данные | базовые команды и настройка автозапуска |
| Платформа развёртывания | сайты, веб-приложения, прототипы для людей | подключить репозиторий и переменные |
| Задача по расписанию | отчёты, рассылки, сборы данных | описать расписание и хранить результат |

Про то, где вообще проходит граница между «поиграться» и «отдать людям», подробно писал в материале про то, [что доезжает до продакшена](/guides/vibecoding-v-prodakshene-realnye-proekty).

## Что ломается при переезде?

**Главное**

Три вещи почти всегда: пути к файлам, часовой пояс сервера и доступы к внешним сервисам. Все три выясняются в первый час и лечатся быстро, если знать заранее, куда смотреть.

**Пути к файлам.** На твоём компьютере файл лежал на рабочем столе, на сервере такого места нет вовсе. Всё, что сервис читает и пишет, должно жить внутри его папки, а не «где-то рядом».

**Время.** Сервер почти всегда живёт по всемирному времени, а ты думаешь по своему. Классическая авария: отчёт, который должен уходить в девять утра, приходит в полночь. Правило простое: договорись с собой, в каком поясе считает сервис, и запиши это в его настройках.

**Доступы.** Ключ, который работал с твоего домашнего адреса, может не работать с адреса сервера: часть сервисов ограничивает доступ по стране или требует подтверждения нового устройства. Проверять это надо до переезда, а не в момент запуска.

К этому добавляется четвёртая, менее очевидная вещь: на сервере нет твоего окружения. Программы, которые ты когда-то поставил себе и забыл, там придётся ставить заново. Поэтому переезд лучше делать не копированием файлов, а сборкой с нуля по описанию - тогда список нужного становится явным.

## Кто перезапустит сервис, когда он упадёт?

**Главное**

Перезапуск должен быть автоматическим: правило «упал - подними» и автостарт после перезагрузки сервера. Плюс оповещение в мессенджер, иначе о падении узнаешь от пользователя, а не от системы.

На своём боте-расшифровщике я сформулировал это правило так: сервис обязан подниматься сам после любого падения и после перезагрузки машины, без моего участия.

Настраивается это один раз:

1. **Включи автоматический перезапуск**

   Стандартная настройка запуска: если процесс завершился, поднять заново. Одна строчка в конфигурации.

2. **Включи автостарт при загрузке сервера**

   Сервер иногда перезагружается: обновления, сбои у хостера. После перезагрузки сервис должен подняться сам.

3. **Ограничь аппетит**

   Задай потолок памяти. Тогда при пике умрёт один сервис, а не всё, что живёт на машине.

4. **Сделай проверку живости**

   Простой скрипт или запрос, который отвечает «я жив». По нему видно состояние без захода на сервер.

5. **Настрой оповещение**

   Сообщение в мессенджер при падении и при недоступности. Это заменяет ежедневную ручную проверку.

Отдельно скажу про разделение. Если сервисов несколько, полезно держать их отдельными процессами: тяжёлый компонент, который долго стартует, и лёгкий, который часто обновляется. Тогда обновление одного не роняет второй.

## Что нельзя выставлять наружу?

**Главное**

Наружу открывается ровно один вход, нужный пользователям. Служебные порты, базы данных и внутренние сервисы остаются закрытыми. Отдельная осторожность нужна там, где сервис обрабатывает персональные данные людей.

Самая частая дыра у самодельных сервисов - открытый порт базы данных или служебного компонента. Открыли для удобства отладки, забыли закрыть, и через неделю в базе появились чужие записи.

Правила, которых достаточно на старте:

1. **Наружу только то, что нужно пользователю.** Остальное слушает только внутреннюю сеть.
2. **Доступ к серверу по ключу**, а не по паролю.
3. **Шифрование для всего, что открыто наружу.** Бесплатные сертификаты выдаются автоматически, отговорок нет.
4. **Резервная копия базы по расписанию** и проверка, что она восстанавливается.
5. **Отдельное решение по персональным данным.** Если сервис обрабатывает данные людей, требования закона распространяются и на твой маленький бот тоже. Разбирал это в материале про [деплой прототипа и 152-ФЗ](/guides/prototip-gotov-chto-dalshe-deploy-152fz).

**Про голосовые и переписку**

Если сервис работает с голосовыми сообщениями, перепиской или документами сотрудников, это уже чужие персональные данные. Такой сервис не публикуют наружу вовсе: он должен быть доступен только тем, кому положено, и по списку.

## Переезд по шагам

**Главное**

Порядок один и тот же независимо от того, что переносишь: сначала описание запуска, потом сервер и секреты, потом данные, потом автозапуск и оповещения. В конце обязательная проверка выключением своего компьютера.

1. **Попроси агента описать, что нужно для запуска.** Список программ, версий, файлов и переменных. Это же станет инструкцией для сервера.
2. **Арендуй сервер и подготовь его.** Обновления, пользователь, доступ по ключу, закрытая сеть.
3. **Перенеси код и секреты раздельно.** Код через хранилище кода, секреты руками в закрытый файл.
4. **Перенеси данные и настрой резервную копию.** До первого запуска, а не после.
5. **Запусти и проверь по своему сценарию.** Не «стартовало без ошибок», а «прошёл путь пользователя целиком».
6. **Включи автозапуск и оповещения.**
7. **Выключи свой компьютер и проверь ещё раз.** Это финальный экзамен: если что-то работало через твою машину, вскроется здесь.

Последний шаг звучит смешно, но именно он ловит самые обидные зависимости вроде «сервис ходил в файл, который лежит у меня в облачной папке».

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

**Главное**

Что спрашивают чаще всего: сколько это стоит, нужен ли админ, можно ли обойтись без сервера и что делать, если сервис нужен только на рабочее время.

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

**Сколько стоит держать такой сервис?**

Небольшой сервер под бота стоит как пара чашек кофе в месяц. Дороже обычно обходится не сервер, а обращения к платным моделям, если сервис к ним ходит.

**Нужен ли системный администратор?**

Для одного сервиса - нет. Настройка делается один раз вместе с агентом, дальше поддержка сводится к обновлениям и реакции на оповещения.

**Можно ли вообще без сервера?**

Если задача периодическая, да: запланированная задача выполнит скрипт и завершится. Постоянно работающему боту сервер всё же нужен.

**Сервис нужен только в рабочее время. Выключать на ночь?**

Не стоит: экономия копеечная, а риск не проснуться утром реальный. Проще оставить работающим и ограничить расход на стороне платных вызовов.

## Главный вывод

**Главное**

Отвязка от личного компьютера - это граница между поделкой и продуктом. Технически она проходится за вечер, но требует четырёх вещей сразу: кода, секретов, данных и присмотра. Без последнего пункта сервис живёт до первой аварии.

Соберу в одну мысль. Пока продукт запускается только у тебя, он не существует для остальных. Как только он живёт на сервере и поднимается сам, им можно пользоваться, его можно передать и на нём можно строить дальше.

Хорошая новость: [вайбкодинг](/concepts/vibecoding) дошёл до того, что весь переезд делается вместе с агентом по шагам, и от тебя требуется понимать смысл шагов, а не помнить команды.

Самый простой тест: закрой ноутбук на час и посмотри, что перестало работать. Этот список и есть твой план переезда.

### Источники

- [Docker - официальная документация: автоматический перезапуск контейнеров и автостарт после перезагрузки](https://docs.docker.com/engine/containers/start-containers-automatically/)
- [systemd - система управления службами, которая поднимает сервисы при старте машины](https://systemd.io/)
- [Telegram Bot API - официальная документация по ботам](https://core.telegram.org/bots/api)
- [Let's Encrypt - бесплатные сертификаты для шифрования соединения](https://letsencrypt.org/ru/)
- [Федеральный закон № 152-ФЗ «О персональных данных» - текст на КонсультантПлюс](https://www.consultant.ru/document/cons_doc_LAW_61801/)
- [PostgreSQL - документация о резервном копировании базы данных](https://www.postgresql.org/docs/current/backup.html)