Коротко
За четыре месяца сотрудники «Флаувау» создали 262 приложения с помощью AI-агентов, а компания собрала для них отдельную инфраструктуру с деплоем, резервированием и многоуровневой защитой. Важный практический результат — замена 200 отдельных раннеров одним процессом, снизившая их потребление памяти примерно с 13 ГБ до 100 МБ.
Контекст
Автор — Артем Гамбицкий, сооснователь маркетплейса «Флаувау». В компании сотрудники без инженерного опыта начали создавать приложения с AI-агентами, но проекты размещались на личных ноутбуках и случайных виртуалках, а разработчики не могли брать каждую такую задачу в работу. Компания решила не запрещать эксперименты, а дать им отдельную управляемую и изолированную платформу.
Главное
- За первые четыре месяца в песочнице зарегистрировали 262 проекта примерно от 150 сотрудников и выполнили около 5 000 деплоев. Код проектов не проходил проверку программистом.
- Песочница отделена от инфраструктуры маркетплейса: у нее собственные машины, домены и деплой. Приложения доступны по поддоменам только через корпоративный VPN.
- Базовая инфраструктура — Traefik, Deploy API на FastAPI, docker-agent, SQLite, cron и systemd-таймеры. Она работает на виртуальной машине с 8 vCPU и 32 ГБ памяти стоимостью 20 тыс. рублей в месяц.
- Контейнерам задают лимиты в половину ядра и 512 МБ памяти. Около 200 контейнеров занимают 9–10 ГБ; автор оценивает вместимость машины примерно в 500 подобных проектов.
- В шаблоне предпочитают легкий стек: Node 24, Fastify, better-sqlite3 и SQLite; тяжелые фреймворки агент выбирает, только если автор проекта этого требует и объясняет зачем.
- Код ежедневно зеркалируется в отдельный приватный репозиторий, а данные проектов копируются в S3. Доступ к корпоративным данным по умолчанию закрыт; его отдельно согласуют с ИБ и ограничивают чтением конкретных таблиц.
- Из-за ограничений GitHub Actions каждому проекту сначала требовался отдельный self-hosted-раннер. К концу августа 165 раннеров занимали две трети памяти и половину диска.
- Раннеры заменили форком open-source-проекта chimera — реализации протокола GitHub Actions на Rust. Около 200 регистраций теперь обслуживаются одним процессом, который занимает примерно 100 МБ вместо прежних 13 ГБ.
- Среди неожиданных инфраструктурных ограничений были пул Docker-сетей на 256 адресов и лимит Linux keyring в 200 ключей на пользователя. Для сетей добавили пул на 2048 адресов; после переезда на chimera вместо сотен системных юнитов остался один.
- Защита включает инструкции агента с 14 обязательными инвариантами, шесть блокирующих хуков до выполнения действий и детектор утечки API-ключей после них, серверные ограничения запуска контейнеров и регулярный анализ безопасности кода.
- У приложений нет доступа к корпоративным данным по умолчанию. Новая версия контейнера запускается рядом со старой, проходит проверку и лишь затем получает трафик.
- Поддержку сначала оказывает агент автора, умеющий читать журналы своего контейнера через API с HMAC-подписью и скрытием секретов. Если он не справляется, подключается внутренний бот с ограниченными правами, который при необходимости передает вопрос человеку.
Как сделано
Автор проекта создает репозиторий из шаблона с правилами для агента, дизайн-системой и защитными хуками. Агент уточняет требования, готовит спецификацию и план, пишет код и тесты, передает результат субагенту на ревью и показывает локальное превью. Затем self-hosted-раннер собирает образ, а Deploy API запускает контейнер; приложение становится доступно во внутренней сети примерно через минуту.
Изоляция начинается на уровне отдельной инфраструктуры и продолжается серверными лимитами: пользователь может управлять Dockerfile, но не параметрами запуска контейнера и не получает root-доступ. Инструкции и хуки помогают предотвращать случайные опасные действия, однако автор прямо отмечает, что хуки в репозитории можно изменить, поэтому основную границу защиты обеспечивает сервер.
Для снижения накладных расходов отдельные раннеры заменили на chimera: один демон хранит регистрации проектов и создает воркеры только при поступлении задач. Код и данные резервируются, а доступ к внутренним базам предоставляется только через отдельное согласование. Агент и внутренний бот помогают диагностировать типовые проблемы по логам; решенные обращения используются для улучшения последующей поддержки.
Результаты
Песочница централизовала 262 проекта и около 5 000 деплоев за четыре месяца, заменив размещение приложений на личных ноутбуках и неизвестных виртуалках. Потребление памяти раннерами упало примерно с 13 ГБ до 100 МБ. Один из наиболее посещаемых проектов получает 5–10 тыс. визитов в день и достигает около 60 RPS; для типовых контейнеров автор приводит ориентиры 500 RPS для API с чтением из SQLite и около 1 000 RPS для статической SPA. Пользователи создают MVP, внутренние дашборды, инструменты анализа конкурентов и сервисы для рабочих процессов.
Ограничения
Автор не приводит независимую оценку безопасности, результаты нагрузочных тестов для всех проектов или сравнительный анализ других платформ. Показатели RPS — оценки для типового стека, тогда как реальные нагрузки обычно ниже. Код никто не проверял вручную, а хуки, размещенные в репозитории проекта, можно изменить; поэтому они служат защитой от случайных ошибок, а не полноценной границей безопасности. Не раскрыты точные затраты на резервное хранение и поддержку, а также подробности настройки мониторинга и security-консоли. Архитектура рассчитана на доступ через корпоративный VPN и не принимает входящие соединения извне.
Что взять себе
- Если сотрудники создают прототипы с AI, отдельная песочница с ограничениями и понятным деплоем может быть безопаснее, чем запреты или неформальные размещения на личных машинах.
- Не запускайте сотни простаивающих раннеров без проверки накладных расходов: общий демон с воркерами по требованию способен заметно экономить ресурсы.
- Инструкции и хуки полезны как первая линия защиты от ошибок агента, но границы доступа нужно обеспечивать сервером, а не правилами в редактируемом репозитории.
- Простые стеки, лимиты контейнеров, резервирование кода и данных и отдельное согласование доступа к корпоративным базам помогают сделать массовые эксперименты управляемыми.
- Внутренний бот, которому разрешено безопасно смотреть логи и историю деплоев, может снять часть типовых вопросов с команды поддержки.
Читать оригинал, если…
Откройте оригинал, если нужны подробности настройки хуков и chimera, инфраструктурных сбоев, внутренних процессов поддержки или практических примеров проектов.