Самостоятельно разместить OpenClaw-подобный воркфлоу кажется просто: арендовать VPS, установить агента, направить его в репозиторий. Проблемы у команд начинаются вокруг этого цикла — секреты, ветки, логи, лимиты расходов и путь восстановления, когда длинная задача зависает в середине миграции.
Это операционная модель, которую мы рекомендуем пользователям OpenClaw, которым нужен больший контроль без заявления, что Office Claws является нативным рантаймом OpenClaw. Office Claws управляет локальным состоянием desktop-приложения и VPS-раннерами для агентов на базе Codex. Если ваша нагрузка OpenClaw в основном связана с репозиториями, это дает полезную self-hosted форму: ключи остаются локально, каждая задача получает изолированный раннер, а каждое изменение попадает в проверяемую ветку.
Что должно означать «OpenClaw Self Hosted»
Самое безопасное определение — не «скопировать hosted-сервис на один сервер». Это разделение control plane.
| Слой | Где держать | Почему это важно |
|---|---|---|
| Управление с desktop | Локальная машина | API-токены, SSH-ключи, подтверждения и намерение оператора остаются рядом с разработчиком |
| Выполнение агента | VPS-раннер | Долгие задачи переживают сон ноутбука и нестабильный Wi-Fi |
| Изменения репозитория | Ветка на задачу | Review, CI и rollback остаются обычными |
| Сетевой доступ | Приватная mesh-сеть | SSH не открыт напрямую в интернет |
| Биллинг | Подписка + небольшой VPS | Расходы предсказуемы, а каждый idle-retry не становится API-сюрпризом |
Эта модель отличается от запуска самого OpenClaw. Мы не утверждаем, что Office Claws импортирует расширения, память или браузерные автоматизации OpenClaw. Мы описываем self-hosted workflow для пользователей OpenClaw, которым в основном нужна автономная работа с кодом на устойчивых машинах. Сравнение OpenClaw vs Codex лучше подходит, чтобы решить, приемлем ли такой обмен.
Референсная архитектура
Надежный self-hosted setup состоит из четырех частей:
- Office Claws на desktop для provisioning, подтверждений, статуса и локального управления ключами.
- Один VPS на активный раннер в Contabo, DigitalOcean, Hetzner или у провайдера, которому вы уже доверяете.
- Tailscale или аналогичная приватная mesh-сеть, чтобы раннеры не открывали SSH в интернет.
- Codex CLI внутри раннера для repo-shaped пути выполнения, который многим пользователям OpenClaw нужен после изменения подписки или стоимости.
Главная привычка: одна задача, один раннер, одна ветка. Не позволяйте трем агентам делить один checkout только потому, что это кажется эффективным. Так дешевый self-hosted эксперимент превращается в загадочные diff и перезаписанные результаты тестов. Гайд по OpenClaw desktop manager объясняет, почему UI так явно показывает состояние раннера: если вы не видите, какой агент владеет каким репозиторием, операционного слоя еще нет.
Чеклист настройки
Начните с малого. Одного раннера достаточно, чтобы проверить цикл.
# target shape, not a magic installer
1. create a VPS from a known snapshot
2. join it to your private mesh
3. authenticate Codex CLI on the runner
4. clone one repo into one task workspace
5. create a branch before the agent edits files
6. run tests and push the branch
7. destroy or reset the runner when the task is doneДля пользователей Office Claws приложение берет на себя provisioning и слой статуса; права репозитория, правила review в GitHub и аккаунт модели остаются вашей ответственностью. Self-hosted план стоит $4.99/мес за desktop/VPS управление, а managed-раннер — $14.99/мес, если вы хотите меньше владеть сервером. Держите эти цифры отдельно от подписки модели и счета за VPS.
Перед тем как дать раннеру реальную работу, проверьте скучные средства контроля:
- Ограниченный GitHub-токен: только доступ к репозиторию, без admin-токена на всю организацию.
- Без общего
.env-хаоса: передавайте только секреты, нужные задаче. - Лимит расходов: задайте его у VPS-провайдера и, если возможно, в workflow аккаунта модели.
- CI-gate: никаких прямых deploy из ветки агента.
- Путь сброса: snapshot или rebuild должны быть быстрее отладки испорченного раннера.
Это те же меры, которые мы рекомендуем в OpenClaw security best practices. Self-hosting убирает одну поверхность поставщика, но добавляет ответственность; он не делает работу агентов безопасной магически.
Режимы отказа, под которые стоит проектировать
Большинство проблем self-hosted агентов предсказуемы. Спроектируйте защиту до первого ночного запуска.
| Режим отказа | Симптом | Защита |
|---|---|---|
| Конфликты общего workspace | Два агента меняют одни файлы | Один раннер и ветка на задачу |
| Открытый публичный SSH | Случайные попытки входа в логах | Только приватная mesh-сеть; публичный SSH закрыт |
| Слишком широкие секреты | Агент может читать посторонние credentials | Env на задачу и scoped-токены |
| Тихое зависание | Job останавливается после prompt или упавшего теста | Status checks, логи и явное восстановление |
| Дрейф расходов | Лишние раннеры живут все выходные | Лимиты расходов и cleanup раннеров |
Слой статуса важнее, чем кажется. Терминальный мультиплексор может держать сессию живой, но не отвечает на вопросы оператора: кто владеет этой задачей, какую ветку она запушила, прошли ли тесты и можно ли удалить машину? Поэтому наши OpenClaw-материалы снова указывают на Office Claws для пользователей OpenClaw, а не делают вид, что голого VPS достаточно.
Рекомендация
Если ваша работа в OpenClaw в основном про код, сначала self-host операционный слой, а не всё подряд. Держите подтверждения и credentials локально. Запускайте агентов на приватных VPS-раннерах. Используйте Codex-backed выполнение там, где оно подходит. Каждый результат проводите через GitHub и CI как ветку любого коллеги.
Если ваша работа в OpenClaw зависит от нативных расширений, браузерных автоматизаций или platform-specific flow, не втискивайте ее в этот шаблон. Оставьте OpenClaw для этих задач и используйте Office Claws для repo-shaped работы, которой выгодны более дешевые долговечные раннеры.
Лучший self-hosted setup намеренно скучный: одна задача, один раннер, одна ветка, один review-gate. В этом и смысл. Автономному coding гораздо легче доверять, когда инфраструктура отказывается быть слишком умной.