Суббота, 11 вечера. Я в гостях, телефон в кармане. Приходит алерт от Grafana: «память на сервере 92%». Раньше сценарий был такой: достать ноутбук (если взял), подключиться через SSH, вспомнить, какой контейнер жрёт память, попробовать docker stats, найти проблему, решить. Если ноутбука нет — открыть Termius на телефоне, набирать команды на экранной клавиатуре и молиться, чтобы не опечататься в rm -rf.

Сейчас я пишу в Telegram: «память 92%, разберись». Через минуту агент отвечает: контейнер с логами разросся до 3 ГБ, он уже почистил старые логи и рестартнул его, сейчас 54%. Я убираю телефон и возвращаюсь к разговору.

Это не фантазия и не демо. Это мой рабочий сетап последних недель. На VPS крутится OpenClaw — open-source AI-агент, который живёт в Docker, общается через Telegram и имеет полный доступ к серверу. Он может читать и редактировать файлы, выполнять команды, лезть в PostgreSQL, смотреть логи контейнеров и сам мониторить, что всё работает. По сути, у меня появился DevOps-напарник, который никогда не спит и всегда на связи.

Расскажу, как до этого дошло, как это устроено и какие реальные задачи я теперь решаю через Telegram вместо SSH.

Предыстория: 12 Docker-контейнеров и один человек

Я занимаюсь веб-разработкой, интеграциями и собственными SaaS-продуктами. На основном VPS крутится около дюжины проектов в Docker: клиентские сервисы, мои продукты, мониторинг, несколько ботов, базы данных. Всё это нужно поддерживать, обновлять, иногда дебажить в самое неудобное время.

Типичные ситуации, которые случаются регулярно:

  • Контейнер упал в 3 часа ночи, утром клиент пишет «у нас ничего не работает»

  • Нужно быстро глянуть, сколько записей в таблице или кто последний логинился

  • Nginx вернул 502, надо понять, какой upstream не отвечает

  • Правка одной строчки в конфиге, ради которой лень открывать SSH

Всё это мелочи, но они съедают время. И главное — они требуют полноценного доступа к терминалу. А я не всегда за ноутбуком.

Я пробовал разные решения: Portainer для управления Docker через веб, скрипты-алиасы, даже самописного Telegram-бота с захардкоженными командами. Всё это работало, но было негибко. Каждый новый сценарий — новый код. А мне нужен был инструмент, который понимает контекст и может решить задачу, которую я заранее не предусмотрел.

OpenClaw: AI-агент с доступом к серверу

OpenClaw — это open-source AI-агент, который разворачивается в Docker и работает через Telegram. Ключевое отличие от «просто GPT-бота» — у него есть инструменты. Он может выполнять shell-команды, работать с файлами, и делает это в контексте сервера, на котором живёт.

Но голый доступ к shell — это полдела. Настоящая магия начинается, когда ты пишешь кастомные скрипты-инструменты. У меня их сейчас полтора десятка — каждый заточен под конкретную задачу:

tools/
├── docker-status.sh        # Статус всех контейнеров
├── docker-logs.sh          # Логи конкретного контейнера
├── docker-restart.sh       # Перезапуск контейнера
├── project-restart.sh      # Перезапуск docker compose проекта
├── system-stats.sh         # RAM, CPU, диск, top по потреблению
├── db-discover.sh          # Авто-обнаружение всех БД и таблиц
├── db-query.sh             # SQL-запрос с авто-определением кредов
├── health-check.sh         # HTTP-проверка сайтов + авто-рестарт
├── nginx-errors.sh         # Последние ошибки Nginx
├── security-check.sh       # fail2ban, подозрительные процессы
├── youtrack-api.sh         # Управление задачами в YouTrack
├── n8n-workflows.sh        # Триггер n8n-автоматизаций
└── ...

Скрипты монтируются внутрь контейнера и доступны агенту по путям. В SOUL.md я описал, какой скрипт для чего, и агент сам выбирает нужный. Пишу «покажи логи auth-сервиса» — он вызывает docker-logs.sh. Пишу «сколько юзеров зарегалось за неделю» — он вызывает db-query.sh. Не нужно ничего объяснять — контекст описан один раз.

А ещё я описал ему свой контекст в markdown-файлах: кто я, какой стек, какие проекты запущены, карту контейнеров и баз данных. Агент читает это при каждой сессии и работает с учётом моей инфраструктуры.

Но давайте к конкретике. Вот реальные сценарии, ради которых всё затевалось.

Сценарий 1: «Что жрёт память?»

Пишу в Telegram:

Я: на сервере память за 90%, посмотри что случилось

Агент выполняет docker stats --no-stream, анализирует вывод, смотрит free -h:

Агент: Проблема в контейнере project-logs. Он занимает 2.8 ГБ RAM — скорее всего, накопились ротированные логи внутри контейнера. Остальные контейнеры в норме.

Могу:

  1. Почистить старые логи в контейнере и рестартнуть его

  2. Добавить mem_limit в docker-compose, чтобы это не повторялось

Что делаем?

Я: давай оба

Через минуту:

Агент: Готово. Почистил логи старше 7 дней, рестартнул контейнер. Добавил mem_limit: 512m в docker-compose. Текущее потребление RAM на сервере — 58%.

Раньше это заняло бы минут 15 в SSH: вспомнить синтаксис docker stats, найти проблемный контейнер, залезть внутрь, почистить, потом отредактировать docker-compose, потом docker compose up -d. Сейчас — два сообщения в Telegram.

Сценарий 2: быстрый SQL без pgAdmin

У меня несколько PostgreSQL-баз для разных проектов. Иногда нужно быстро проверить данные, не разворачивая pgAdmin или DBeaver.

Я: посмотри сколько пользователей зарегались за последнюю неделю в базе auth

Агент:

SELECT COUNT(*) as total, DATE(created_at) as day FROM users WHERE created_at > NOW() - INTERVAL '7 days' GROUP BY day ORDER BY day;

Результат:

total | day -------+------------ 12 | 2026-03-15 8 | 2026-03-16 23 | 2026-03-17 15 | 2026-03-18 19 | 2026-03-19 7 | 2026-03-20 11 | 2026-03-21

Итого 95 регистраций за неделю. Пик во вторник — 23.

Он знает, в каком контейнере база, знает название базы и её структуру (потому что я описал проекты в контексте). Мне не нужно указывать строку подключения — агент вызывает скрипт db-query.sh, который сам достаёт креды из переменных окружения контейнера и выполняет запрос. А если я не помню, в какой базе лежат нужные таблицы — есть db-discover.sh, который обходит все PostgreSQL-контейнеры на сервере и показывает список баз и таблиц в каждом.

Сценарий 3: сайт упал

Самый ценный кейс. Ночью приходит алерт, что один из сайтов не отвечает.

Я: mysite.ru не открывается, разберись

Агент проверяет цепочку: Nginx → upstream → Docker-контейнер. Это несколько команд: curl к домену, проверка логов Nginx, docker compose ps, логи контейнера.

Агент: Контейнер mysite-app упал 12 минут назад. Последние строки лога:

FATAL: password authentication failed for user "app" Error: connect ECONNREFUSED 127.0.0.1:5432

Похоже, PostgreSQL для этого проекта перезапускался, и контейнер приложения не смог переподключиться. Перезапускаю контейнер.

Агент: Перезапустил. Сайт отвечает, HTTP 200. Проверил — все страницы загружаются.

Весь цикл — обнаружение проблемы, диагностика, фикс, проверка — занял минуту. Без SSH, без ноутбука.

Сценарий 4: правка конфига

Нужно добавить новый домен в Nginx или поменять переменную в .env контейнера. Мелочь, но ради одной строчки открывать SSH не хочется.

Я: добавь CORS-origin https://newclient.com в .env контейнера myproject-api и рестартни его

Агент: Добавил ALLOWED_ORIGINS=...,https://newclient.com в .env. Перезапустил контейнер. Проверил — curl -I с Origin: https://newclient.com возвращает корректные CORS-заголовки.

Или пример с Nginx:

Я: создай nginx-конфиг для demo.myproject.com, проксируй на порт 3050 контейнера, SSL через certbot

Агент: Создал конфиг, проверил синтаксис nginx -t — ок. Запустил certbot для получения сертификата. Перезагрузил Nginx. Домен https://demo.myproject.com отвечает.

Это не конкретная заготовленная команда. Агент сам разбирается, куда положить файл, как его назвать, как сгенерировать сертификат. Потому что он понимает контекст сервера.

Сценарий 5: мониторинг на автопилоте

OpenClaw поддерживает heartbeat-режим, в котором агент периодически «просыпается» и проверяет состояние системы. Я написал для него скрипт health-check.sh, который обходит все мои сайты HTTP-запросами. Если какой-то возвращает 5xx или не отвечает — скрипт автоматически перезапускает контейнер и проверяет снова. Агенту остаётся только сообщить мне результат.

Вот что делает heartbeat при каждом срабатывании:

  1. health-check.sh — HTTP-проверка всех сайтов. Если упал — авто-рестарт контейнера. Если после рестарта не починился — пишет мне СРОЧНО.

  2. docker-status.sh — проверяет контейнеры. Если что-то в unhealthy или exited — перезапускает и сообщает.

  3. system-stats.sh — RAM, CPU, диск. Если RAM меньше 500 МБ свободных или диск забит на 90% — сообщает.

  4. Всё ок — молчит (HEARTBEAT_OK).

В HEARTBEAT.md я прописал правила: ночью без срочности не писать, но CRITICAL по сайтам — писать ВСЕГДА, даже в 3 часа ночи. Не повторять уже сообщённое — починил, отчитался один раз и всё.

Результат: я могу проснуться утром и увидеть:

Агент: Ночью в 02:47 сайт project.ru вернул 502. Автоматически перезапустил контейнер — сейчас HTTP 200, всё работает. Причина падения — OOM kill, контейнер превысил лимит памяти.

Агент: Диск /dev/sda1 заполнен на 87%. Основная причина — Docker-образы и билд-кэш занимают 14 ГБ. Могу запустить docker system prune для очистки неиспользуемых образов и кэша. Ориентировочно освободится ~8 ГБ. Сделать?

Я: да

Агент: Готово. Освободил 9.2 ГБ. Текущее использование диска — 61%.

Это существенно отличается от обычных систем алертинга. Grafana/Prometheus скажут «плохо». OpenClaw скажет «плохо, потому что вот это, и я уже починил». Разница между пожарной сигнализацией и пожарным.

Сценарий 6: «Кто-то ломится на сервер?»

У меня есть скрипт security-check.sh, который агент может запустить по моей просьбе или в рамках heartbeat. Он проверяет fail2ban, смотрит заблокированные IP за последние сутки, находит подозрительные процессы с высоким CPU (привет, майнеры) и считает 4xx/5xx ошибки в Nginx за последний час.

Я: проверь безопасность

Агент: fail2ban активен. За последние 24 часа заблокировано 7 IP (SSH bruteforce). Подозрительных процессов нет. В Nginx за последний час: 12 ошибок 404 (нормально), 0 ошибок 5xx. Всё чисто.

Одна команда вместо четырёх разных утилит.

Сценарий 7: управление задачами из Telegram

Проекты ведутся в YouTrack. Я написал обёртку youtrack-api.sh над REST API и дал агенту доступ. Теперь можно прямо из Telegram:

Я: создай задачу в проекте SA: «Добавить rate limiting на эндпоинт регистрации»

Агент: Создал задачу SA-47: «Добавить rate limiting на эндпоинт регистрации». Назначить на кого-то?

Я: на меня, приоритет high

Агент: Готово. SA-47 назначена на тебя, приоритет High.

Также можно посмотреть открытые задачи по проекту, сменить статус, назначить на другого человека. Всё через Telegram, без открытия YouTrack в браузере.

Как это устроено технически

OpenClaw — Docker-образ, который поднимается через docker compose. Из конфигов — один JSON для настройки поведения агента и пара markdown-файлов для контекста.

Ключевые настройки:

Модель. Указываете любую модель через OpenRouter (или напрямую OpenAI API). Можно основную и фолбэки — если основная модель зарейтлимичена, агент переключится на запасную автоматически.

Telegram-канал. Бот создаётся через @BotFather. В конфиге указываешь свой Telegram ID в whitelist — никто другой с агентом общаться не сможет. В групповых чатах агент реагирует только на упоминания.

Сессии. Контекст разговора живёт, пока ты не замолчишь на несколько часов. Можно утром написать «помоги с nginx-конфигом», через час уточнить «а добавь туда ещё rate limiting» — агент помнит, о каком конфиге речь.

SOUL.md — файл, где описываешь поведение агента. И тут самое важное — не общие фразы вроде «будь полезным», а конкретные правила. У меня, например:

  • Чтение файлов, просмотр логов, SELECT-запросы — делай без вопросов. Не спрашивай разрешения на чтение.

  • DELETE/UPDATE запросы и изменения в коде — спроси подтверждение.

  • Когда просят «покажи файл с hero-секцией» — не проси путь. Сам найди через grep -rl, прочитай и покажи.

  • Когда просят данные из БД — не проси креды. Используй db-discover.sh для обнаружения и db-query.sh для запросов.

Именно эти правила превращают агента из «умного, но бесполезного» в реально работающего ассистента. Без них он будет на каждый чих переспрашивать: «Хотите, чтобы я прочитал этот файл? Какой пароль от базы данных?» — и весь смысл теряется.

USER.md — файл с контекстом о тебе и твоих проектах. Какой стек, карта контейнеров и баз данных, какой проект в какой папке. Агент использует это, чтобы не задавать лишних вопросов. Ты пишешь «глянь логи auth-сервиса» — он знает, какой контейнер ты имеешь в виду.

Память. OpenClaw ведёт дневные логи (memory/YYYY-MM-DD.md) и долговременную память (MEMORY.md). Если вчера ты обсуждал с ним баг в конкретном сервисе, сегодня он помнит контекст. Это не магия — агент при старте сессии читает последние записи. Но эффект впечатляет: ощущение, что ассистент в курсе происходящего, а не начинает с чистого листа каждый раз.

Heartbeat — периодическая проверка. Настраиваешь интервал и правила: ночью без срочности не писать, критичные падения сайтов сообщать ВСЕГДА, не повторять уже сообщённые проблемы. В HEARTBEAT.md — конкретный чеклист: какие скрипты запустить, в каком порядке, на что обратить внимание.

Что я понял за несколько недель

SSH с телефона — это насилие над собой. Неважно, Termius это или JuiceSSH. Набирать docker compose -f /path/to/docker-compose.yml logs --tail 100 container-name на экранной клавиатуре — мучение. Написать «покажи последние логи auth-сервиса» — нормально.

80% моих SSH-сессий — это одна-две команды. Посмотреть статус, глянуть логи, рестартнуть контейнер, проверить свободное место. Для этого не нужен терминал. Нужен агент, который поймёт задачу на человеческом языке.

Агент ошибается. Не часто, но бывает. Иногда неправильно интерпретирует задачу, иногда предлагает неоптимальное решение. Поэтому для критичных операций я прошу его сначала показать, что он собирается делать, а потом подтверждаю. Базовая гигиена — как code review, только через Telegram.

Контекст решает. Самая большая разница между «спросить ChatGPT как почистить Docker» и «попросить агента почистить Docker» — в том, что агент видит реальное состояние сервера. Он не предполагает, а знает: сколько места занято, какие контейнеры запущены, какие образы не используются. Его ответ — не generic совет из Stack Overflow, а конкретное действие в конкретном контексте.

Для одиночек-девопсов это убийственная штука. Если у вас несколько серверов с Docker и вы единственный, кто за них отвечает — AI-агент с доступом к серверу экономит часы в неделю. Особенно на рутине: логи, перезапуски, мелкие правки конфигов, диагностика.

Про безопасность

Очевидный вопрос: «ты дал AI полный доступ к серверу, не страшно?»

Честно — первые дни было непривычно. Но давайте разберём объективно.

Доступ к боту ограничен whitelist-ом по Telegram ID. Если кто-то напишет боту — он проигнорирует. Агент работает в Docker-контейнере, а не под root хоста. API-ключ и токен бота хранятся в .env с правами 600.

Главный риск — не взлом, а ошибка агента. Он может неправильно понять задачу и сделать что-то не то. Поэтому я разделил операции на два уровня прямо в SOUL.md: чтение (логи, файлы, SELECT-запросы) — без подтверждения, изменения (DELETE, UPDATE, редактирование кода, удаление контейнеров) — только после approve. Агент следует этим правилам и сам спрашивает перед деструктивными действиями.

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

Кому это подойдёт

Если у вас один VPS с парой сайтов на shared хостинге — это overkill. Не нужно.

Если у вас несколько серверов, десятки Docker-контейнеров, и вы часто лезете в SSH чтобы «просто проверить» — попробуйте. Разворачивается за 10 минут. Нужен VPS с Docker, API-ключ OpenAI/Claude/OpenRouter и Telegram-бот от @BotFather.

Проект open-source, образ на GitHub Container Registry: ghcr.io/openclaw/openclaw.

Если есть вопросы по настройке или по конкретным сценариям — спрашивайте в комментариях. Могу рассказать подробнее про heartbeat, про настройку контекста или про то, как агент работает с несколькими Docker Compose-проектами на одном сервере.