OpenClaw требует стабильного процесса, долговечного состояния для сессий и токенов и одного HTTPS-URL, до которого провайдеры чатов дотягиваются webhook’ами. В 2026 году чаще всего встречаются два контура: Fly.io — машина с прикреплённым томом и управляемым TLS — и обычный Linux VPS с systemd, reverse proxy и каталогом данных на диске. Ниже — сравнение по тем осям, где ломается прод: где лежит состояние, как ведёт себя публичный URL при выкатах, как Slack или Telegram повторяют запросы к шлюзу и как подключить health checks так, чтобы рестарты не «съедали» уже сопряжённые каналы. Практика по сохранению сессий на VPS разобрана отдельно: 2026: OpenClaw и WhatsApp на Linux VPS в облаке: сопряжение по QR, сохранение сессии и несколько каналов.
Матрица решений в одном экране
Fly уместен, когда платформа должна вести rolling deploy, anycast и продление сертификатов без тяжёлого Ansible. VPS — когда нужны фиксированные исходящие IP, произвольные модули ядра, соседство с другими агентами на одном хосте или граница соответствия, которую вы контролируете целиком. Для сценариев с несколькими мессенджерами и правами ботов см. 2026: OpenClaw — Telegram и Discord: двухканальное подключение на практике.
| Измерение | Fly.io (machines) | Linux VPS (systemd + proxy) |
|---|---|---|
| Постоянное состояние | Подключите том и смонтируйте его туда, где OpenClaw хранит конфиг и сессии; без тома рестарты эфемерны. | Выделенный каталог на диске (часто под /var/lib или Docker volume); миграции — через снимки ФС. |
| Публичный HTTPS | TLS на стороне Fly proxy; внутренние порты согласуйте с fly.toml. |
Caddy или Nginx на хосте; DNS, ACME и stapling на вашей стороне. |
| Webhook callback | Стабильное имя на приложение; следите за порядком выката, чтобы процесс слушал до того, как Slack пометит URL нездоровым. | Та же дисциплина URL; проще повесить WAF или allowlist по IP, если вендор публикует диапазоны. |
| Health checks | HTTP-пробы на лёгкий /healthz; при провале машина заменяется. |
systemd Restart=on-failure и при желании внешний мониторинг; не проверяйте пути, требующие живой авторизации канала. |
Постоянство: тома против bind mount
На Fly объявите том в том же регионе, что и машина, и смонтируйте его на путь, который entrypoint контейнера использует для учётных данных, метаданных каналов и локального кэша. Горизонтальное масштабирование нескольких машин без общего хранилища разветвит состояние; для OpenClaw почти всегда нужен один экземпляр-писатель, пока в документации явно не описана многонодовая семантика. На VPS держите один bind-mounted каталог с владельцем не root и бэкапами, достаточно согласованными для хранилищ в духе SQLite.
Вход, webhook и давление повторов
Провайдеры доставляют события с ретраями и жёсткими SLA по задержке. Шлюз должен отвечать быстро, по возможности проверять подпись на периметре и ставить тяжёлую работу в очередь, а не выполнять её внутри HTTP-обработчика. На Fly убедитесь, что таймауты upstream короче клиентского таймаута вендора, иначе накопятся дубликаты, похожие на «баги повтора». За Nginx или Caddy логируйте статус upstream отдельно от ошибок TLS, чтобы продление сертификата не выглядело как 500 приложения.
Health checks, переживающие выкаты
Отдавайте дешёвый GET, который проверяет разбор конфигурации и возможность записи на смонтированный том, а не живые вызовы к API каналов на каждую пробу. Добавьте синтетику «можно поставить задачу в очередь» в стек наблюдаемости. На Fly подберите интервалы так, чтобы кратковременный CPU steal соседей не вызывал замену здоровых машин. В systemd не злоупотребляйте Type=notify, если бинарь не шлёт sd_notify; лучше опираться на коды выхода и лимиты бэкоффа, чем на шторм рестартов.
Логи на томе состояния ротируйте или шипьте наружу: если в health попадает только stdout, а файлы под каталогом данных растут до заполнения диска, «зелёный» health долго будет врать. На dual-stack проверьте, IPv4 или IPv6 использует клиент пробы, чтобы не получить зелёный loopback при мёртвом слушателе по AAAA.
1. curl -v https://ваш-хост/healthz # TLS и маршрутизация 2. ls -la $OPENCLAW_STATE_DIR # том смонтирован? 3. journalctl -u openclaw -b # или fly logs --app … 4. сверить webhook secret с UI провайдера # тихие 401/403
FAQ: типовые сбои
В: Slack после каждого деплоя помечает Events URL как плохой. О: поднимайте слушатель до переключения трафика; путь запроса должен совпадать между превью и продом; секрет подписи в UI должен совпадать с переменными среды рантайма.
В: сессии пропали за ночь. О: почти всегда несмонтированный том или запись состояния в слой образа. Проверяйте mount внутри запущенной задачи, а не только в Dockerfile.
В: health зелёный, пользователи видят таймауты. О: проба, скорее всего, бьёт в localhost, а webhook идёт на перегруженный TLS-фронт. Добавьте внешнюю синтетику или монитор снаружи VPC.
В: на Fly после scale появилось несколько машин. О: без лидер-выборов не масштабируйте горизонтально, пока нет общего хранилища или одной очереди-писателя; иначе дубли webhook разгонят одни и те же автоматизации.
Рядом с Linux-шлюзом — спокойный macOS-узел
Fly и VPS отлично подходят для OpenClaw на периметре, но командам всё равно нужен тихий долгоживущий macOS для Xcode, подписи и нативных инструментов. Облачный Mac mini M4 даёт те же Unix-привычки, что и на VPS, при простое порядка 4 Вт, низкой частоте падений macOS и встроенной защите Gatekeeper и SIP — удобно держать рядом с Linux-краем, который обслуживает webhook.
Единая память Apple Silicon и предсказуемый стек Homebrew снижают когнитивную нагрузку: те же SSH-ключи и скрипты, что на сервере, без «второй операционной реальности» вроде тяжёлого Windows-десктопа для сопутствующих задач.
Если хотите macOS-ёмкость на том же уровне надёжности, что и описанный периметр, облачный Mac mini M4 от VPSSpark — практичный следующий шаг — ознакомьтесь с тарифами и оставьте ботов и сборки на железе, рассчитанном на круглосуточную работу.