Как запустить KiroCrew на VPS: настройка и автозапуск

Почему стоит размещать KiroCrew на VPS, а не на ноутбуке

Самостоятельный хостинг KiroCrew оправдан только на машине, которая работает круглосуточно, поэтому VPS подходит для этого лучше, чем ноутбук. KiroCrew хранит историю сессий, семантическую память, запланированные задачи и очередь подтверждений на диске, перезагружая эти данные при каждом запуске процесса. Это не принесет пользы, если процесс не запущен в 03:00, когда должна выполниться запланированная задача, а закрытый ноутбук не будет её выполнять.

KiroCrew — это рабочее пространство для агентов с открытым исходным кодом от команды Kiro, распространяемое по лицензии Apache 2.0, первые публичные релизы которого появились в начале августа 2026 года. Один процесс, называемый gateway, управляет состоянием и предоставляет веб-панель управления на порту 5476. Доступ к этому шлюзу осуществляется через панель управления, kirocrew CLI или через чат-каналы, такие как Slack. Шлюз — это единственный компонент, который вы размещаете самостоятельно, поэтому данное руководство посвящено обеспечению его работоспособности, защите от доступа из публичного интернета и возможности восстановления после неудачного обновления.

Две вещи, которые нужно знать перед началом. KiroCrew управляет kiro-cli, что требует однократного входа в систему с учетной записью Kiro, а инференс агента оплачивается согласно тарифному плану Kiro, поэтому по состоянию на август 2026 года это не является полностью автономной установкой. Проекту также всего несколько недель. Исходите из того, что вам может потребоваться откат системы, и устанавливайте его так, чтобы это было возможно. Если вы ранее не запускали агентов на сервере, в статье запуск агента для программирования на VPS описаны базовые правила, на которых строится данное руководство.

Что требуется KiroCrew и где хранятся данные состояния

Для нативной установки требуется Python 3.10 или новее (проект рекомендует 3.12), Node.js 18 или новее, если вы собираете панель управления из исходного кода, а также kiro-cli, который при первом запуске устанавливается и настраивается автоматически. При установке в контейнере ничего из этого на хосте не требуется. Нужен только Docker. Это основная причина предпочесть данный способ.

Состояние хранится в ~/.kiro/crew, а переменная окружения KIROCREW_HOME позволяет перенести его в другое место. Что находится внутри:

• config.json: настройки шлюза и учетные данные каналов чата.
• .env: секреты.
• workspace/memory/: настройки, заметки по проекту и история чатов.
• memory.db и memory_index.db: семантический и полнотекстовый индексы.
• models/: модель эмбеддингов, загружаемая при первом запуске.
• gateway.log и security_events.jsonl: журнал выполнения и журнал событий безопасности.

Этот каталог и есть сама установка. Скопируйте его на новый VPS, и вы перенесете своего агента. Именно поэтому раздел о резервном копировании ниже важнее раздела об установке.

Планируйте ресурсы исходя из объема диска, а не оперативной памяти. Шлюз — это процесс на Python; нагрузку на систему создает то, что запускает агент: сборка или набор тестов. Каталог состояния растет вместе с историей чатов, а модель эмбеддингов загружается при первом запуске, поэтому через несколько недель оцените объем на своей машине с помощью du -sh ~/.kiro/crew, вместо того чтобы доверять цифрам, опубликованным в первый месяц жизни проекта.

Какой из трех путей установки выбрать

Проект публикует три варианта. Однострочный установщик загружает wheel и добавляет kirocrew в ваш PATH:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

Он принимает флаг канала и флаг версии:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.3

Контейнерный образ публикуется по адресу ghcr.io/kirodotdev/kirocrew для linux/amd64 и linux/arm64 под каждым тегом. Сборка из исходного кода — это git clone плюс make build; она предназначена для тех, кто вносит изменения в код, а не для тех, кто его запускает.

Используйте контейнер. Нативная установка размещает пакеты Python, Node и kiro-cli на том же хосте, где работают другие ваши сервисы, поэтому неудачное обновление заставит вас исправлять всё вручную. Контейнер хранит среду выполнения в одном образе, а состояние — в одном томе, что делает откат простым изменением тега и перезапуском.

Закрепляйте образ за конкретным тегом релиза, а не за stable

В собственном примере проекта используется тег stable:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

stable — это динамический тег. Он всегда указывает на последний стабильный релиз, поэтому при следующем обновлении версия может измениться без вашего участия, а сам тег не сохраняет информацию о том, какая именно версия была установлена. Теги версий неизменяемы, поэтому используйте их для фиксации. Последний релиз на 6 августа 2026 года — 0.1.3, опубликованный 5 августа 2026 года. Также существует тег nightly, что для такого молодого проекта означает, что код менялся сегодня утром.

Напишите /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.1.3
    container_name: kirocrew
    restart: unless-stopped
    ports:
      - "127.0.0.1:5476:5476"
    volumes:
      - kirocrew-home:/home/kirocrew

volumes:
  kirocrew-home:

Запустите его, а затем проверьте эндпоинт проверки работоспособности (health endpoint), который образ также использует для собственного HEALTHCHECK:

cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/health

docker compose ps должен сообщить, что контейнер исправен (healthy), в течение минуты или около того, а /api/health отвечает без токена (как и /api/live с /api/ready, что и делает их пригодными для использования в качестве проб). Если состояние остается starting, прочитайте docker logs kirocrew, прежде чем что-либо менять. При первом запуске скачивается модель эмбеддингов, поэтому при медленном соединении первый запуск может занять много времени.

Поддержание работы с помощью systemd

restart: unless-stopped возвращает контейнер в рабочее состояние после сбоя или перезагрузки, при условии, что сам Docker запускается при старте системы. Unit-файл делает эту зависимость явной и позволяет одной командой остановить весь стек перед выполнением резервного копирования. В Запуск стека Docker Compose при загрузке описан общий шаблон. Вот вариант KiroCrew в /etc/systemd/system/kirocrew.service:

[Unit]
Description=KiroCrew gateway
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/kirocrew
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrew

systemctl status kirocrew должен содержать active (exited), что является корректным состоянием для данного юнита. Type=oneshot с RemainAfterExit=yes необходимы здесь, так как docker compose up -d завершается сразу после запуска контейнера: systemd отслеживает факт работы стека, а не процесс в foreground. Если написать Type=simple, systemd зафиксирует немедленное завершение команды, пометит сервис как неактивный и либо прекратит попытки, либо уйдет в цикл перезапуска в зависимости от настройки Restart=. Для нативной установки проект предоставляет собственный эквивалент — kirocrew service install, который записывает /etc/systemd/system/kirocrew.service и запускает шлюз от имени вашего пользователя. Не запускайте оба юнита одновременно. Более подробная информация по этой теме приведена в systemd сервисы и таймеры на VPS.

Первый запуск: вход в систему и получение токена панели управления

Контейнер запускает шлюз, но среда выполнения агента еще не авторизована. Выполните вход внутри контейнера:

docker exec -it kirocrew kiro-cli login

Команда выведет код устройства и URL, который нужно открыть в вашем браузере. Затем создайте токен панели управления:

docker exec kirocrew kirocrew token --ttl 2h

URL панели управления — http://localhost:5476/?token=<the token>. Срок действия токенов ограничен: сессии по умолчанию длятся один час, а максимально допустимое значение согласно документации составляет двадцать часов. Если панель управления загружается пустой или сразу перенаправляет вас обратно на страницу входа, это обычно означает, что срок действия токена истек — создайте новый. Никогда не отправляйте токен в тикеты или сообщения чатов, так как любой, у кого есть этот токен, получает полный доступ к вашему агенту.

Доступ к панели управления через SSH без публикации порта 5476

Еще раз обратите внимание на адрес привязки в примере проекта: -p 127.0.0.1:5476:5476. Внутри контейнера шлюз слушает 0.0.0.0, так как он должен быть доступен через проброс портов, но само сопоставление публикует сервис только на loopback-интерфейсе хоста. Удалите префикс 127.0.0.1:, и шлюз окажется доступен из публичного интернета любому, кто просканирует этот порт. Правило брандмауэра вас не спасет: Docker публикует порты, записывая правила DNAT, которые обрабатываются до фильтрации ufw, поэтому ufw deny 5476 никак не влияет на опубликованный порт. В Docker ports bypassing ufw подробно описан этот механизм.

Вместо этого перенаправьте порт через SSH со своего ноутбука:

ssh -N -L 5476:127.0.0.1:5476 you@your-server.example.com

Оставьте этот процесс запущенным и откройте http://localhost:5476/?token=<the token> локально. Чтобы автоматизировать перенаправление при каждом подключении, добавьте его в ~/.ssh/config:

Host your-server.example.com
    LocalForward 5476 127.0.0.1:5476

Если порт 5476 уже занят на вашем ноутбуке, измените только левое число: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, затем перейдите по адресу http://localhost:45476/?token=....

Ожидаемое задокументированное поведение при работе через туннель: шлюз считывает перенаправленные запросы как удаленные, поэтому эндпоинты для записи конфигурации и отображения секретов в панели управления отклоняют их. Если настройки не сохраняются через SSH, это особенность, а не ошибка. Редактируйте конфигурацию непосредственно на хосте:

docker cp kirocrew:/home/kirocrew/.kiro/crew/config.json .
# edit config.json here
docker cp config.json kirocrew:/home/kirocrew/.kiro/crew/config.json
docker exec -u 0 kirocrew chown kirocrew:kirocrew /home/kirocrew/.kiro/crew/config.json
docker restart kirocrew

Для доступа с телефона проект рекомендует использовать tailscale serve от Tailscale, что позволяет держать панель управления внутри вашей собственной tailnet, а не на публичном доменном имени. Отдавайте предпочтение этому способу, а не публичному reverse proxy. Токен передается в URL, а URL записывается в каждый access log на пути следования запроса.

Ограничьте радиус поражения агента

При первом запуске контейнер проверяет поддержку песочницы, и результат этой проверки определяет, сможет ли агент выполнять какие-либо действия. Если изоляция пространств имен (namespaces) доступна, подпроцессы агента запускаются изолированно. Если она недоступна, а параметр KIROCREW_ALLOW_UNSANDBOXED=1 не задан, выполнение команд блокируется, чтобы избежать работы без ограничений. Если шлюз выглядит работоспособным, но все задачи зависают, причина обычно именно в этом. Решение сохраняется в docker logs kirocrew после первого запуска. Проект также предоставляет профиль seccomp (secure computing mode), который можно применить:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o /opt/kirocrew/kirocrew-seccomp.json

    security_opt:
      - seccomp:./kirocrew-seccomp.json

Если вы все же устанавливаете KIROCREW_ALLOW_UNSANDBOXED=1, четко осознавайте последствия: теперь контейнер является единственным барьером между агентом и вашим сервером. Предупреждение проекта стоит привести полностью. Не монтируйте пути хоста, которые вы не доверили бы напрямую агенту. На практике это исключает Docker socket, любые bind-монтирования / и любые директории, содержащие данные других сервисов.

Остальное — это общие правила для любого агента, которому разрешено выполнять команды. Ограничьте его учетные данные одним репозиторием или одним бакетом, который ему необходим; никогда не используйте персональный токен с правами на весь аккаунт. Запускайте его от имени выделенного пользователя, в домашней директории которого больше ничего нет; именно этому посвящена статья пользователи с минимальными привилегиями на VPS. Когда агент пишет код, а затем исполняет его, предоставьте ему машину, которую не жалко сломать: одноразовая виртуальная машина для агентов-программистов обеспечивает более надежную границу, чем любой флаг в этом compose-файле, так как вы просто удаляете её вместо очистки. Те же соображения лежат в основе безопасного запуска OpenClaw на VPS и самостоятельного хостинга агента Hermes на VPS. Плановые задачи также расходуют средства, пока вы спите, так как инференс тарифицируется согласно вашему плану Kiro, поэтому установите лимиты, описанные в контроль расходов на AI-агента на VPS, прежде чем добавлять ночные задания.

Создавайте резервную копию тома с состоянием перед каждым обновлением

Сначала определите реальное имя тома. Compose добавляет к именованным томам префикс с именем проекта, которое по умолчанию совпадает с именем директории. Поэтому том, объявленный как kirocrew-home в /opt/kirocrew/compose.yaml, создается с именем kirocrew_kirocrew-home:

docker volume ls

Остановите шлюз перед копированием любых данных. memory.db и memory_index.db — это базы данных SQLite. Копирование базы данных в процессе записи может привести к захвату незавершенной транзакции, что при восстановлении даст поврежденный файл. Инструкции по миграции от разработчиков проекта указывают на то же самое: перемещайте данные только при остановленных шлюзах.

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data:ro -v "$PWD":/backup \
  alpine tar czf /backup/kirocrew-2026-08-06.tgz -C /data .
sudo systemctl start kirocrew

Скопируйте архив с сервера. Восстановление выполняется той же командой при остановленном контейнере, но с заменой tar xzf на tar czf:

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data -v "$PWD":/backup \
  alpine tar xzf /backup/kirocrew-2026-08-06.tgz -C /data
sudo systemctl start kirocrew

Перенос на новый хост отличается от восстановления на текущем месте, и проект дает по этому поводу четкие указания. История чатов и заметки по проектам в workspace/memory/ переносятся, как и два файла базы данных вместе с config.json. PID-файлы, журнал событий безопасности и .env привязаны к старому хосту, поэтому оставьте их и заново введите секреты на новом сервере.

Как выполнить откат после неудачного обновления

Процесс обновления занимает мало времени и безопасен только при условии фиксации версии. Сначала создайте резервную копию, затем измените тег:

sudo systemctl stop kirocrew
# take the backup here, as above
sudo nano /opt/kirocrew/compose.yaml   # set the new image tag
sudo systemctl start kirocrew
docker compose -f /opt/kirocrew/compose.yaml ps
curl -s http://127.0.0.1:5476/api/health

docker compose up -d загружает образ, если его ещё нет на сервере, поэтому изменение тега — это и есть всё обновление. Откат выполняется в той же последовательности с использованием старого номера версии. Вы получите именно тот образ, который был до этого, так как теги версий неизменяемы.

Бинарный файл откатывается без проблем. Состояние системы — это часть, которая может не восстановиться. Более новая версия шлюза может перезаписать config.json или мигрировать базы данных в памяти в формат, который старая версия шлюза не сможет прочитать. По состоянию на август 2026 года пути для понижения версии не задокументированы. Если старый образ запускается, но работает некорректно, не пытайтесь его отлаживать. Остановите его, восстановите резервную копию, созданную до обновления, и начните заново. Именно поэтому резервное копирование выполняется в первую очередь, и именно поэтому привычка обновляться сейчас, а делать резервную копию потом, не работает в столь молодых проектах.

Что здесь не доказано

Будьте честны относительно возраста этого программного обеспечения. Версия 0.1.3 вышла всего несколько дней назад, ее примечания к выпуску представляют собой автоматизированные списки изменений, а не руководства по миграции, и опыта обновлений пока нет. Ничто в этом руководстве не является результатом долгосрочной эксплуатации, поэтому рассматривайте рост потребления памяти, размер базы данных и надежность планировщика как параметры, которые нужно измерять на собственном сервере, а не как нечто само собой разумеющееся.

Стоит самостоятельно протестировать два сценария, прежде чем полагаться на них в работе. Во-первых, проверяет ли откат версии состояние, записанное более новой версией: попробуйте это на копии тома, пока это не критично, а не во время сбоя. Во-вторых, как ведет себя шлюз, когда срок действия входа в Kiro истекает во время выполнения запланированной задачи. Оба этих примера — типичные «шероховатости», которые в молодых проектах тихо устраняются между релизами, и оба легко проверить прямо сейчас.

FAQ

Почему панель управления KiroCrew не открывается по публичному IP-адресу моего сервера?

Потому что в опубликованном примере порт привязан к интерфейсу loopback. Параметр -p 127.0.0.1:5476:5476 пробрасывает порт контейнера только на адрес loopback хоста, что сделано намеренно. Получите доступ к панели, перенаправив порт через SSH с помощью ssh -N -L 5476:127.0.0.1:5476 you@your-server, а затем откройте http://localhost:5476/?token=<token> на своем локальном компьютере. Удаление префикса 127.0.0.1: сделает шлюз доступным из публичного интернета, при этом правила межсетевого экрана не смогут его ограничить, так как правила DNAT для опубликованных портов Docker обрабатываются до того, как ufw отфильтрует трафик.

Где KiroCrew хранит данные и что нужно резервировать?

Все данные находятся в ~/.kiro/crew, что соответствует /home/kirocrew/.kiro/crew внутри образа контейнера, а KIROCREW_HOME позволяет изменить это расположение. Выполняйте резервное копирование всего каталога или всего тома Docker при остановленном шлюзе. Файлы memory.db и memory_index.db являются базами данных SQLite, поэтому копия, сделанная в момент записи данных шлюзом, может оказаться несогласованной. При переносе на новый хост файлы workspace/memory/, обе базы данных и config.json переносятся полностью, в то время как PID-файлы, журнал событий безопасности и .env относятся к старому хосту.

Стоит ли использовать тег stable или тег версии?

Используйте тег версии. Тег stable перемещается при каждом выпуске новой версии, поэтому версия, которую вы используете, может измениться без вашего ведома при следующем обновлении, а сам тег не дает информации о том, что именно запущено. Теги версий, такие как 0.1.3, неизменяемы, и именно это обеспечивает возможность отката: вы возвращаете старый номер версии и получаете идентичный образ. По состоянию на 6 августа 2026 года новейшим релизом является 0.1.3.

Почему мой агент отказывается выполнять какие-либо команды?

При первом запуске контейнер проверяет поддержку песочницы (sandbox). Если он не может изолировать подпроцессы агента, а переменная KIROCREW_ALLOW_UNSANDBOXED=1 не установлена, он отказывается их выполнять, вместо того чтобы запускать без ограничений. В результате шлюз выглядит работоспособным, но все задачи зависают. Команда docker logs kirocrew показывает решение о выборе песочницы, принятое при первом запуске. Установка этой переменной делает контейнер единственной границей между агентом и хостом, поэтому, если вы ее устанавливаете, не монтируйте ничего, что вы не готовы передать агенту напрямую.

Нужна ли учетная запись Kiro для самостоятельного хостинга KiroCrew?

Да, по состоянию на август 2026 года. KiroCrew является свободным программным обеспечением под лицензией Apache 2.0, но оно работает с kiro-cli, что требует однократного входа в систему, а инференс агента оплачивается согласно тарифному плану Kiro. Внутри контейнера выполните docker exec -it kirocrew kiro-cli login и подтвердите код устройства в браузере. Пока этот вход не будет выполнен, шлюз запустится и панель управления загрузится, но у агента не будет модели для взаимодействия.