GoLive берет на себя публикацию приложений, но контроль остается у владельца

Coding-agent уже может собрать небольшое приложение практически целиком, но готовый код еще нужно превратить в работающий сервис. Возникает менее эффектная часть работы: создать проект на хостинге, подключить базу данных, передать переменные окружения, настроить DNS, почту и платежи. Именно этот участок разработчик GoLive пытается передать агенту.

GoLive состоит из Agent Skill и локального CLI для Node.js. Схема работы намеренно разбита на этапы: инструмент изучает проект, определяет необходимые сервисы, составляет план изменений и только после подтверждения применяет его. Затем выполняется проверка созданной инфраструктуры. Текущая документация отдельно предупреждает, что такая проверка не означает автоматической проверки всего приложения.

Список уже реализованных сценариев довольно конкретный. В ранней альфа-версии проверялись развертывание через Vercel и Netlify, базы Supabase и Neon, настройка доменов через Porkbun и GoDaddy, транзакционная почта Resend, тестовые платежи Stripe и аутентификация Supabase. Есть и обратная операция teardown для удаления ресурсов, которые GoLive может достоверно связать со своей работой.

Но интереснее здесь не количество поддерживаемых сервисов, а модель доступа. Согласно документации проекта GoLive, отдельного аккаунта GoLive, собственного серверного backend и телеметрии у инструмента нет. Операции выполняются локально через API и CLI сторонних сервисов. Проект также открыт под лицензией MIT, поэтому код, который получает доступ к инфраструктуре, можно изучить самостоятельно.

Подтверждение перед изменениями реализовано не только как инструкция для агента. Команда plan работает в режиме чтения и формирует идентификатор плана. При выполнении apply инструмент повторно проверяет его. Если после подтверждения изменились версия GoLive, конфигурация или сам план операций, выполнение должно быть остановлено.

У этой схемы есть граница, которую легко пропустить за формулировкой «на своих аккаунтах». GoLive может использовать уже существующие авторизации Vercel, Supabase или Netlify в окружении coding-agent. Если агент и без GoLive имеет доступ к такой учетной записи, механизм подтверждения GoLive его не ограничивает. Контроль распространяется на действия самого GoLive, а не на все команды, которые способен выполнить агент.

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

Проект пока имеет статус early alpha. Это хорошо объясняет и ограниченный список проверенных сценариев, и осторожные формулировки документации. GoLive интересен прежде всего самой границей автоматизации: агент получает возможность довести написанное приложение до работающей инфраструктуры, но изменение реальных аккаунтов отделено от анализа проекта явным планом и подтверждением. При этом безопасность всей схемы все равно зависит от того, какие права уже получил сам coding-agent и какие ключи ему доступны.