Пошаговый гайд: AI-агент, который чинит твой VPS из Telegram

Основная идея - ставим на VPS AI-агента, подключаем его к Telegram-боту и к LLM - и дальше можно мониторить и управлять сервером прямо из мессенджера. Написал «сайт лежит, разберись» - агент сам посмотрел логи, нашёл проблему, починил, отчитался. Без SSH, без ноутбука в три часа ночи.

Не магия - просто OpenClaw. Open-source фреймворк для персональных AI-агентов с 247 000+ звёзд на GitHub. Работает на твоём железе, подключается к любому мессенджеру, умеет выполнять shell-команды.

В этом гайде мы по шагам соберём такой стек:

VPS Ubuntu 24.04 - хост
Nginx - статический сайт (то, что будем «ломать» и «чинить»)
Ollama - прокси к облачной LLM (MiniMax M2.5, бесплатная, без GPU)
OpenClaw - сам AI-агент
Telegram-бот - интерфейс управления

Время на всё: ~30 минут. Поехали.

UPD: По мотивам статьи написал ansible-плейбук, который разворачивает весь стек одной командой.
https://github.com/MindPhaser34/openclaw_ollama_nginx

Что понадобится
Часть 1. Готовим сервер
Часть 2. Nginx - наш подопытный сервис
Часть 3. Ollama - мост к LLM
Часть 4. OpenClaw + Telegram
Часть 5. Выдаём права
Часть 6. Конфигурируем OpenClaw
Часть 7. Ломаем и чиним - тесты
Уборка после тестов
Что в итоге получилось

VPS: Ubuntu 24.04 LTS, 4GB RAM, 2 vCPU, 50GB+ диск
SSH-доступ с root или sudo
Telegram на телефоне
Стабильный интернет (облачная LLM + Telegram API)

Почему именно облачная модель, а не локальная? На 4GB RAM локальная LLM сожрёт всё и не оставит ресурсов ни Nginx, ни OpenClaw. Я буду использовать модель minimax-m2.5:cloud. Она работает на серверах MiniMax - на нашей VPS она будет потреблять около нуля. Бесплатная, поддерживает function calling (это критично для OpenClaw), контекстное окно ~200k+ токенов.

Как альтернативу, можно использовать deepseek-v4-pro:cloud - она значительно мощнее в агентных задачах (лидирует в Terminal-Bench, SWE-bench, MCPAtlas), поддерживает контекст 1M токенов и три режима reasoning. Подойдёт для сложных сценариев с множеством сервисов. Из минусов - склонна к многословности и быстрее расходует бесплатный лимит Ollama (49B active параметров против 10B у M2.5).

Также можно попробовать qwen3.5:cloud (256K контекст, мультимодальность) - золотая середина по интеллекту, но самая дорогая по output и не сильнее M2.5 в агентных задачах. К сожалению на момент написания статьи нет cloud варианта новой версии qwen3.6.

Если облако не вариант - можно поставить llama3.2:3b (~2.5GB RAM), либо qwen3.5:2b локально (~2.7GB RAM), но на бюджетной VPS будет тесно, лучше памяти взять побольше (6-8GB).

ssh root@YOUR_VPS_IP

sudo apt update && sudo apt dist-upgrade -y

sudo apt install -y curl git wget build-essential ufw fail2ban

Гонять всё от root - плохая идея. Делаем пользователя специально под OpenClaw:

sudo adduser openclaw sudo usermod -aG sudo openclaw

Задаём пароль, остальные поля можно пропустить.

sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp # SSH sudo ufw allow 80/tcp # Nginx sudo ufw limit 22/tcp # rate-limit на SSH от брутфорса sudo ufw enable

На вопрос отвечаем y. Проверяем:

sudo ufw status

su - openclaw

Дальше все команды выполняем от этого пользователя.

sudo apt install -y nginx

sudo systemctl enable nginx sudo systemctl start nginx

Заменяем дефолтную страницу Nginx на что-то своё. Это будет наш «сайт», который мы потом будем ломать и чинить:

sudo tee /var/www/html/index.html > /dev/null << 'EOF' <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>OpenClaw Lab</title> <style> * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: 'Segoe UI', Arial, sans-serif; background: linear-gradient(135deg, #0f0c29, #302b63, #24243e); color: #ffffff; min-height: 100vh; display: flex; justify-content: center; align-items: center; } .container { text-align: center; padding: 40px; background: rgba(255, 255, 255, 0.05); border-radius: 16px; border: 1px solid rgba(255, 255, 255, 0.1); max-width: 600px; } h1 { font-size: 2.5em; margin-bottom: 10px; color: #e94560; } .status { display: inline-block; padding: 8px 20px; background: #00c853; border-radius: 20px; font-weight: bold; margin: 20px 0; } p { color: #ccc; line-height: 1.8; } .footer { margin-top: 30px; font-size: 0.85em; color: #666; } </style> </head> <body> <div class="container"> <h1>OpenClaw Lab Server</h1> <div class="status">Nginx is Running</div> <p>This static website is served by Nginx on Ubuntu 24.04.</p> <p>It is monitored and managed by an AI agent (OpenClaw) via Telegram.</p> <div class="footer"> Powered by OpenClaw + Ollama + MiniMax M2.5 </div> </div> </body> </html> EOF

curl -s -o /dev/null -w "HTTP Status: %{http_code}\\n" http://localhost

Должно быть HTTP Status: 200. Можно ещё открыть http://YOUR_VPS_IP в браузере - увидишь страницу с зелёным бейджем «Nginx is Running».

curl -fsSL https://ollama.com/install.sh | sh

ollama --version

Ollama автоматически ставится как systemd-сервис:

sudo systemctl enable ollama sudo systemctl status ollama

В выводе должно быть active (running).

Облачные модели (типа minimax-m2.5:cloud) требуют аутентификации. Нужен аккаунт на ollama.com - регистрация бесплатная.

ollama login

Следуем инструкциям. Если планируешь использовать только локальную модель - этот шаг можно пропустить. После того как авторизуете устройство в браузере появится такая вот довольная лама на авто =)

ollama run minimax-m2.5:cloud "What does the command 'systemctl status nginx' do?"

Если получил внятный ответ - всё работает: Ollama на месте, аутентификация прошла, модель отвечает.

Если Error: 401 Unauthorized - повтори ollama login.

**Важно:** модель minimax-m2.5:cloud работает на серверах MiniMax. На твою VPS ничего большого не скачивается. Промпты уходят по сети, ответы приходят обратно.

Запасной план - если облачная модель не заводится, то запускаем модель локально:

ollama pull llama3.2:3b ollama run llama3.2:3b "What does the command 'systemctl status nginx' do?"

Эта модель весит ~2.5GB и работает локально. Логин не нужен. Но на 4GB VPS будет тесновато.

Прежде чем ставить OpenClaw, нужен Telegram-бот:

Открываем Telegram, ищем @BotFather
Пишем /newbot
Вводим имя бота (например, My VPS Manager)
Вводим username (должен заканчиваться на bot, например myvps_manager_bot)
BotFather выдаёт токен вида 7123456789:AABb1-Dd2CcE3tToP_example_token
Сохраняем токен - он понадобится на следующем шаге

curl -fsSL https://openclaw.ai/install.sh | bash

Запустится мастер настройки (onboarding wizard). Тут есть нюансы - реальный процесс отличается от того, что можно ожидать. Вот что выбирать на каждом шаге:

Onboarding mode: QuickStart
Model/Auth Provider: Ollama
Ollama mode: Cloud Only
Ollama API key: (генерируем здесь и вставляем в терминале)
Default model: Enter model manually → ollama/minimax-m2.5:cloud (он удивится что её нет в каталоге, но при этом название модели оставит)
Select channel: Telegram (Bot API)
Bot Token: вставляем токен из шага 16
Search provider: Ollama Web Search (либо Skip for now)
Skills to install: Skip for now

Формат модели обязательно provider/model - то есть ollama/minimax-m2.5:cloud, а не просто minimax-m2.5:cloud.

После завершения перезагружаем shell:

source ~/.bashrc

Вот этот момент легко пропустить, а без него ничего не заработает(суть проблемы):

sudo loginctl enable-linger $(whoami) echo 'export XDG_RUNTIME_DIR=/run/user/$(id -u)' >> ~/.bashrc source ~/.bashrc

**Зачем это:**

XDG_RUNTIME_DIR - нужна для systemd user services на headless VPS. Без неё получишь ошибку "Failed to connect to bus: No medium found".

openclaw gateway install systemctl --user start openclaw-gateway.service systemctl --user enable openclaw-gateway.service

Проверяем:

openclaw status

Должен показать "Gateway: ... reachable", "Gateway service: ... running" и Telegram channel Enabled/State: ON.

На ошибки не обращаем внимание, дальше их разберем.

openclaw doctor

Проверит версию Node.js, подключение к Ollama, доступность модели, конфигурацию gateway.

Ещё один момент, на котором многие застревают. OpenClaw не будет отвечать на сообщения, пока ты явно не авторизуешь свой Telegram-аккаунт.

Пишем /start своему боту в Telegram
Бот ответит с user ID и pairing code (пример):
Your Telegram user id: 1234567890
Pairing code: ZD34WE69
Ask the bot owner to approve with:
openclaw pairing approve telegram ZD34WE69
На VPS выполняем:
openclaw pairing approve telegram ZD34WE69
Пишем боту ещё раз - теперь он должен ответить.

У OpenClaw есть веб-дашборд. Чтобы открыть его безопасно через SSH-туннель:

ssh -N -L 18789:127.0.0.1:18789 openclaw@YOUR_VPS_IP

Затем в браузере:

http://localhost:18789/#token=YOUR_GATEWAY_TOKEN

Токен можно найти так:

cat ~/.openclaw/openclaw.json | grep '"token"'

Дашборд работает только через localhost - не через публичный IP.

Через дашборд можно уcтановить дополнительные навыки (skills).

По умолчанию OpenClaw работает от пользователя openclaw и не может управлять системными сервисами. Нужно дать sudo-доступ, но по принципу минимальных привилегий.

sudo visudo -f /etc/sudoers.d/openclaw

Для лабораторной среды (быстро, но небезопасно):

openclaw ALL=(ALL) NOPASSWD: ALL

Для продакшена (только Nginx-команды):

openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl start nginx openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop nginx openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload nginx openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status nginx openclaw ALL=(ALL) NOPASSWD: /usr/sbin/nginx -t openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl -u nginx*

sudo -l -U openclaw

Должен показать список разрешённых команд. Теперь можно написать боту в Telegram «can you stop nginx?» - и он выполнит.

В ранней версии OpenClaw использовался единый "системный промпт" в качестве инструкций для агента - как себя вести, какие команды использовать, чего не делать. Сейчас OpenClaw использует систему из набора нескольких markdown-файлов, находящихся в ls -la ~/.openclaw/workspace/

IDENTITY.md - Визитка - Имя агента, «существо» (AI/робот/призрак), эмодзи, аватар. Чисто косметика - влияет на то, как агент представляется
SOUL.md - Системный промпт - Главный файл. Характер, принципы поведения, стиль общения, границы дозволенного. По сути - «конституция» агента
TOOLS.md - Шпаргалка по инфраструктуре - Описание окружения: какие серверы, хосты, устройства, SSH-алиасы, пути. Отделён от SOUL, чтобы можно было менять инфру не трогая поведение
USER.md - Досье на хозяина - Имя, таймзона, предпочтения, контекст проектов. Агент обновляет сам по мере общения - «учится» о тебе
HEARTBEAT.md - Crontab - Периодические задачи. Если файл пустой - heartbeat отключён. Если написать задачи - агент выполняет их по расписанию и пишет в Telegram только если что-то не так
BOOTSTRAP.md - Скрипт первого запуска - Инструкции, которые агент выполняет один раз при первом старте сессии
AGENTS.md - Мультиагентный конфиг - Описание нескольких агентов с разными ролями (например, один следит за Docker, другой за безопасностью). Для продвинутого использования

Для нашей статьи минимально нужны три: SOUL.md (что делать и чего не делать), TOOLS.md (какое окружение) и HEARTBEAT.md (автоматические проверки). Остальные - по желанию. Их можно заполнять на русском языке, при условии что ИИ модель поддерживает русский и понимает его. В нашем случае:

MiniMax M2.5:cloud - русский понимает, но обучена преимущественно на английском и китайском. На русском может терять точность в выполнении инструкций, особенно в сложных цепочках команд.
Qwen3.5:cloud - аналогично, русский не в приоритете.

Мой совет: инструкции (SOUL.md, TOOLS.md) писать на английском - это рабочие команды для модели, точность важнее. А USER.md и IDENTITY.md - можно на русском, там нет критичной логики.

Приведу пример файлов, можно изменить по своему усмотрению.

SOUL.md

## Role You are a server administrator for a single VPS running Nginx as a systemd service. Your job: diagnose problems, fix what you can, report clearly. ## Diagnostic Workflow When the user reports an issue or asks you to check something, always follow this order: 1. Test the website: curl -s -o /dev/null -w "%{http_code}" http://localhost 2. Check service status: sudo systemctl status nginx 3. Test config syntax: sudo nginx -t 4. Read recent logs: sudo journalctl -u nginx --no-pager -n 50 5. Check host resources: free -h df -h ## Fixing Issues Nginx stopped: sudo systemctl start nginx Nginx failed (config error): sudo nginx -t Read /etc/nginx/nginx.conf, find the broken line, fix it sudo nginx -t (verify fix) sudo systemctl restart nginx Nginx running but not responding: sudo systemctl restart nginx ## After Every Fix 1. curl -s -o /dev/null -w "%{http_code}" http://localhost 2. sudo systemctl status nginx 3. Report: what broke → what you did → current state ## Health Report Format When asked for a health check, include: - Nginx: status, uptime, config test result - Website: HTTP status code - CPU: load average - Memory: used / total - Disk: usage on / and /var - System uptime ## Communication - Be specific: service status, error lines from logs, exit codes - If unsure about root cause - say so, suggest next steps - No filler phrases - Explain so a beginner can understand - Respond in the same language the user writes in ## Hard Rules - NEVER run destructive commands (see TOOLS.md) - NEVER delete nginx config without backing it up first - NEVER modify SSH, firewall, or sudoers config - NEVER guess - if you need more info, ask - Always verify your fix before reporting success

TOOLS.md

## Host - OS: Ubuntu 24.04 LTS - Resources: 2 vCPU, 4GB RAM - Hostname: arthost ## Services - Nginx: systemd service, serves static site on port 80 - Config: /etc/nginx/nginx.conf - Web root: /var/www/html/ - Logs: journalctl -u nginx ## Available Commands (sudo, no password) - systemctl start/stop/restart/reload/status nginx - nginx -t - journalctl -u nginx * ## System Monitoring (no sudo needed) - free -h - df -h - uptime - top -bn1 - curl http://localhost ## Prohibited Commands - rm -rf, dd, mkfs (destructive) - Never edit /etc/ssh/sshd_config - Never modify firewall rules (ufw) - Never touch /etc/sudoers

IDENTITY.md

- **Name:** HostBot - **Creature:** AI server engineer and system administrator - **Vibe:** Calm, precise, no fluff. Like a good on-call SRE. - **Emoji:** 🔧

USER.md

Name: Artem Timezone: Europe/Moscow Notes: DevOps engineer. Prefers short answers with actual commands, not theory. Speaks Russian and English.

HEARTBEAT.md

Every 6 hours: - sudo systemctl status nginx - curl -s -o /dev/null -w "%{http_code}" http://localhost - free -h - df -h Alert the user ONLY if: - Nginx is not active (running) - HTTP status is not 200 - Memory usage > 85% - Disk usage > 85% If everything is OK - stay silent.

Ломаем через SSH:

sudo systemctl stop nginx

Проверяем, что сломалось:

curl http://localhost # curl: (7) Failed to connect to localhost port 80: Connection refused

Теперь пишем боту в Telegram что-то типа:

The website seems to be down. Can you check and fix it?

Что агент делает за кулисами:

curl http://localhost → Connection refused
sudo systemctl status nginx → inactive (dead)
sudo systemctl start nginx → Success
curl http://localhost → HTTP 200 OK
Отвечает: «Nginx был остановлен. Я его перезапустил, сайт работает (HTTP 200).»

Этот интереснее - тут простой рестарт не поможет.

Ломаем:

sudo bash -c 'echo "THIS_IS_BROKEN;" >> /etc/nginx/nginx.conf' sudo systemctl restart nginx

Рестарт упадёт, потому что конфиг теперь невалидный. Проверяем:

sudo nginx -t # nginx: [emerg] unknown directive "THIS_IS_BROKEN" in /etc/nginx/nginx.conf:XX

Пишем боту, что-то типа:

The website is not loading. Something might be wrong with the server. Please investigate and fix it.

Что агент делает:

curl http://localhost → Connection refused
sudo systemctl status nginx → failed
sudo journalctl -u nginx -n 50 → ошибка конфига в логах
sudo nginx -t → Syntax error на строке XX
Читает /etc/nginx/nginx.conf, находит THIS_IS_BROKEN;
Удаляет битую строку
sudo nginx -t → Syntax is OK
sudo systemctl restart nginx → Success
curl http://localhost → HTTP 200
Отвечает: «Nginx упал из-за невалидной директивы THIS_IS_BROKEN в nginx.conf. Удалил битую строку, проверил конфиг, перезапустил. Сайт работает.»

Агент не просто перезапустил сервис - он прочитал логи, нашёл root cause, исправил конфиг, проверил и отчитался. Из одного сообщения в Telegram.

Необязательно ждать, пока что-то сломается. Пишем боту:

Give me a full health report of the server.

Ожидаемый ответ:

Server Health Report: - CPU: 2 vCPU, load average 0.12 - Memory: 1.2GB used / 4GB total (30%) - Disk: 8GB used / 50GB total (16%) - Nginx: active (running), uptime 2 hours - Website: HTTP 200 (responding normally) - Uptime: 3 days, 7 hours Everything looks healthy!

К слову, на моём тестовом стенде nginx и прочие микросервисы развёрнуты через docker compose - вот какой отчёт он мне присылает:

Проверяем, что конфиг Nginx чистый:

sudo nginx -t

Если показывает ошибки - восстанавливаем:

sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf 2>/dev/null || sudo apt install --reinstall -y nginx sudo systemctl restart nginx

Полностью рабочий стек:

Ubuntu 24.04 VPS - инфраструктура
Nginx - веб-сервер на порту 80
Ollama → MiniMax M2.5 cloud - LLM без нагрузки на VPS
OpenClaw - AI-агент
Telegram-бот - пульт управления

Вся тяжёлая AI-работа происходит в облаке (MiniMax), а на VPS крутится только лёгкий агент + веб-сервер. Поэтому и хватает 4GB RAM.

Если сломается Nginx, агент сам через некоторое время напишет в Telegram и сам всё починит - без единого SSH-подключения.

OpenClaw - не замена мониторингу. Grafana никуда не девается. Это другой слой: можно написать «что с сервером?» и получить не уведомление, а конкретный ответ с диагностикой. Для домашнего лаба или пары VPS - уже работает. Для продакшена с чем-то критичным - пока рано.

Идею взял из статьи "AI-Powered VPS Manager with OpenClaw, Ollama & Telegram".

Если понравилось и хочешь не пропустить следующие материалы - подпишись на канал Art Of Chain. Там про Web3, blockchain, AI и пр.

#openclaw #ai #manual #devops #ollama #telegram #telegrambot

Пошаговый гайд: AI-агент, который чинит твой VPS из Telegram

Содержание:

Что понадобится

Часть 1. Готовим сервер

Шаг 1. Подключаемся к VPS

Шаг 2. Обновляем систему

Шаг 3. Ставим базовые пакеты

Шаг 4. Создаём отдельного пользователя

Шаг 5. Настраиваем firewall

Шаг 6. Переключаемся на нового пользователя

Часть 2. Nginx - наш подопытный сервис

Шаг 7. Устанавливаем Nginx

Шаг 8. Включаем автозапуск

Шаг 9. Кладём простую HTML-страницу

Шаг 10. Проверяем

Часть 3. Ollama - мост к LLM

Шаг 11. Устанавливаем Ollama

Шаг 12. Проверяем

Шаг 13. Убеждаемся, что сервис работает

Шаг 14. Логинимся в Ollama

Шаг 15. Тестируем модель

Часть 4. OpenClaw + Telegram

Шаг 16. Создаём Telegram-бота

Шаг 17. Устанавливаем OpenClaw

Шаг 18. Настраиваем переменные окружения

Шаг 19. Запускаем Gateway

Шаг 20. Диагностика

Шаг 21. Одобряем Telegram-pairing

Шаг 22. Дашборд (опционально)

Часть 5. Выдаём права

Шаг 23. Sudoers

Шаг 24. Проверяем

Часть 6. Конфигурируем OpenClaw

Шаг 25. Настраиваем файлы

Часть 7. Ломаем и чиним - тесты

Тест 1. Останавливаем Nginx (простой кейс)

Тест 2. Ломаем конфиг Nginx (средний кейс)

Тест 3. Health-check

Уборка после тестов

Что в итоге получилось