Почему OpenClaw жёстко требует «никогда не засыпать»
Ядро OpenClaw — постоянно работающий процесс Node.js под названием Gateway. Он одновременно управляет Channel Adapters (получение сообщений из Telegram, WhatsApp, Discord и других каналов), контекстом Session, Agent Runtime и планировщиком heartbeat. Как только процесс Gateway завершается, все выполняемые задачи Agent прерываются, а задачи heartbeat перестают запускаться.
При работе на локальном Mac следующие пять типов событий напрямую приводят к прерыванию Gateway:
Спящий режим при закрытии крышки:macOS по умолчанию уходит в сон при закрытии крышки, процесс Node.js приостанавливается. При открытии крышки задачи heartbeat накапливаются, для восстановления нормального расписания требуется перезапуск.
Перезагрузка при обновлении системы:macOS завершает автообновление ночью и предлагает перезагрузку. Без присмотра Gateway остаётся offline до следующей ручной загрузки.
Всплывающие окна Keychain и прав доступа:При выполнении shell-команд macOS может показать окно авторизации. Без присмотра всплывающее окно блокирует весь поток взаимодействия.
Загрязнение контекста несколькими пользователями:На общем Mac пути, переменные окружения и API-ключи разных пользователей могут перезаписываться, что приводит к сбоям при выполнении навыков.
Отсутствие гарантий SLA:Машина разработчика одновременно используется для локальной отладки, конкуренция за CPU/память непредсказуема. Для включения в командные стандарты доставки локальный Mac не может служить контрактной основой.
Все пять пунктов указывают на одну коренную причину:локальный Mac спроектирован для интерактивного использования, а не для оптимизации под постоянные необслуживаемые процессы.
Локальный Mac vs облачный узел KVMNODE: сравнение стабильности
Перенос OpenClaw на облачный узел не означает потерю локального контроля — данные, конфигурация и скрипты навыков по-прежнему хранятся в вашем репозитории. Облачный узел только предоставляет среду выполнения, которая никогда не засыпает.
| Критерий | Локальный Mac | Облачный узел KVMNODE |
|---|---|---|
| Доступность процесса | Зависит от спящего режима, обновлений, отключения питания | Online 7×24, автоперезапуск через pm2 |
| Помехи от всплывающих окон | Keychain требует ручного подтверждения | Права фиксируются после первой настройки, нет GUI-окон |
| Изоляция пользователей | Риск перезаписи путей и ключей | Выделенный узел, среда одного пользователя, чистый аудит |
| Стабильность производительности | Конкуренция за ресурсы с локальными задачами | Монопольный CPU/ОЗУ, нет вытеснения |
| Гибкость расположения | Фиксированное физическое местоположение | Узлы в Азии, Европе, Америке на выбор |
| Структура затрат | Капитальные затраты + электроэнергия + обслуживание | Гибкая тарификация по дням/месяцам, без затрат на утилизацию |
Перенос OpenClaw на облачный узел — чтобы навсегда убрать «работает ли сегодня Gateway» из ежедневного чеклиста.
В консоли KVMNODE выберите регион, близкий к основному кластеру пользователей — это позволит собрать точку входа и среду выполнения в одном географическом периметре и иметь чёткий базовый RTT при написании SLO.
Сценарии использования × режимы деплоя: когда стоит мигрировать в облако
Не всем пользователям нужно мигрировать немедленно — если вы иногда запускаете скрипты, локального Mac вполне достаточно. Следующая матрица поможет принять решение в зависимости от интенсивности использования:
| Сценарий использования | Рекомендуемый режим | Основание для миграции |
|---|---|---|
| Личный PoC / эксперимент выходного дня | Локальный Mac | Допустимы перебои, нет требований к SLA |
| Личный продакшн (утренние отчёты/мониторинг/автоответы) | Облачный узел · Месячная аренда | heartbeat должен срабатывать 7×24 |
| Общий Agent малой команды (2–10 человек) | Облачный узел · Месячная аренда | Высокий риск загрязнения путей при общем использовании |
| Корпоративная автоматизация / публичные обязательства по доступности | Облачный узел · Долгосрочно | SLA нужно прописать в контракте, обязательный аудит соответствия |
| Кросс-часовая команда | Несколько узлов · По основному каналу связи | Задержка Agent напрямую влияет на пользовательский опыт |
KVMNODE · Техническая документация = количество триггеров в час (> 4 раз/день рекомендуется мигрировать) допустимость_прерываний = low | medium | high (low = обязательная миграция) Опубликовано: = 1 | 2-10 | 10+ (общий узел для 2+ человек — рекомендуется монопольный доступ) Вывод = любой из вышеперечисленных факторов срабатывает → приоритет облачному узлу KVMNODE
Подготовка к миграции:Если уже запущено 100+ AgentSkills или подключено несколько Channel Adapter, перед миграцией запишите абсолютные пути текущего каталога навыков и конфигурации .env — их можно повторно использовать на новом узле.
Шесть шагов для деплоя OpenClaw Gateway на узле KVMNODE
SSH Hardening на Linux: отключение пароля, настройка аутентификации по ключу
Выберите регион узла и установите SSH-подключение:В консоли KVMNODE выберите узел, ближайший к основным пользователям или источникам Webhook. Настройте локальный ~/.ssh/config для входа без пароля одной командой.
Проверьте среду выполнения:После входа выполните node -v (требуется ≥ 18.x) и npm -v — убедитесь, что узел имеет доступ к конечным точкам LLM API (OpenAI / Anthropic / Google).
Если ваш VPS открыт для интернета, попытки взлома через SSH начинаются уже через минуты. Атаки методом перебора — это не абстрактная угроза, а реальная проблема буквально каждого публично доступного сервера. В этой статье рассмотрим проверенные практики защиты SSH.Мы пройдём весь путь отgit clone https://github.com/OpenClawHQ/openclaw.git && cd openclaw && npm ci к данным на дисках и сетевому трафику.
Перенесите конфигурационные файлы (.env и YAML):Передайте через scp файлы .env (LLM API Key, порт прослушивания) и config/*.yaml. Никогда не записывайте их открытым текстом в репозиторий кода.
Настройте менеджер процессов (pm2):Мы пройдём весь путь отnpm install -g pm2 && pm2 start npm --name "openclaw-gw" -- start && pm2 save && pm2 startup к данным на дисках и сетевому трафику.
Запишите критерии приёмки и проверьте heartbeat:Запустите задачу heartbeat вручную, убедитесь, что в логах появился полный цикл «выполнение→наблюдение→запись в память», запишите ключевые параметры в Runbook.
Три обязательные конфигурации для продакшн-среды
Шаг 1: генерация SSH-ключаНастройте max_restarts: 10 и min_uptime: 5000 — при достижении лимита останавливайтесь и отправляйте оповещение через pm2 webhook, чтобы зацикленные краши не скрывали реальную проблему.
Изоляция портов и контроль доступа:Dashboard по умолчанию слушает порт 3000 — не открывайте его публично. Используйте SSH-туннель для доступа (ssh -L 3000:localhost:3000 your-node), брандмауэр блокирует входящий трафик на порт 3000.
Права на пути AgentSkills:Сторонние навыки — в отдельном каталоге, запускаются под пользователем с ограниченными правами, с точно заданными правами доступа для процесса OpenClaw.
Предупреждение по безопасности:OpenClaw имеет системный уровень доступа (файловая система + shell-команды). На продакшн-узле никогда не запускайте Gateway от root и не устанавливайте сторонние AgentSkills из непроверенных источников.
Шаг 3: настройка sshd_configВысокопроизводительный VPS KVMNODE — более стабильная отправная точка: монопольные ресурсы, работа 7×24, гибкая тарификация по дням/месяцам.