После вайб-кодинга: зачем нужен AI-native сервис для управления десятками своих сайтов

AI уже сильно изменил разработку небольших сайтов и приложений. Ещё недавно основной вопрос звучал так: как быстро и недорого сделать сайт? Сейчас для опытного специалиста, а всё чаще и для человека без классической команды разработки, этот вопрос становится значительно проще.

Можно описать задачу агенту, получить код, поправить результат, запустить проект и за короткое время получить рабочую систему.

Но после того как создание стало дешёвым, наружу вышел следующий bottleneck.

Сайт сделать легко. А что делать с тридцатью сайтами?

Один проект не создаёт большой инфраструктурной проблемы. Нужно арендовать сервер, поставить Docker, настроить домен и HTTPS, собрать приложение, доставить его на сервер и запустить. Потом иногда обновлять.

Каждое действие само по себе небольшое. Проблема появляется при масштабе: 20–50 проектов, несколько серверов, dev/stage/production, разные домены, обновления, резервные копии, диагностика и массовые изменения.

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

стоимость создания проекта       ↓↓↓
стоимость эксплуатации портфеля  ↓ намного слабее

Именно эту проблему мы сейчас исследуем в Narasim.

Почему люди после вайб-кодинга всё равно идут в SaaS

Современный AI способен написать приложение, но его владельцу всё ещё приходится отвечать на неприятные вопросы: где оно будет работать, как направить домен, кто выпустит TLS-сертификат, как обновлять production, где лежат данные, как откатиться, что произошло, если контейнер не запустился.

Рациональный ответ для многих — managed-платформы. Они забирают эксплуатационную сложность и дают удобный workflow. Но вместе с удобством появляется платформенная модель проекта. Чем больше инфраструктурных решений принимает SaaS, тем сильнее приложение начинает зависеть от его API, runtime, deployment model и связанных сервисов.

AI делает интересной обратную модель: можно ли вернуть владельцу обычный Git-проект и обычный сервер, но не вернуть ему всю ручную эксплуатационную работу?

Рынок уже движется в эту сторону

Ближайшие существующие продукты — self-hosted PaaS и Docker control planes.

Coolify

Coolify — open-source control plane для собственных серверов. Он подключает серверы по SSH, работает с Docker, Git и Docker Compose, занимается deployment, доменами, HTTPS и health checks.

Это уже очень близко к нужному нижнему слою. При этом Coolify создаёт собственную модель ресурсов и deployment. Для Compose он парсит исходное описание и может добавлять или нормализовать container names, labels, networks, environment references и proxy configuration. Multi-server deployment существует, но документация отдельно указывает ограничения для Docker Compose applications и persistent storage.

Источники:

• https://coolify.io/docs/core/what-is-coolify
• https://coolify.io/docs/applications/builds/docker-compose
• https://coolify.io/docs/core/infrastructure/scaling/multi-server-deployments

Dokploy

Dokploy также работает с Docker Compose, Traefik и удалёнными серверами. Remote servers управляются по SSH; на них используется отдельный Docker и Traefik. Платформа позволяет централизованно разворачивать приложения на разных машинах. Для Compose домены можно задавать через интерфейс Dokploy либо вручную через Traefik labels.

Источники:

• https://docs.dokploy.com/docs/core/remote-servers
• https://docs.dokploy.com/docs/core/deployment-options
• https://docs.dokploy.com/docs/core/docker-compose

CapRover

CapRover решает похожую задачу, но его поддержка Docker Compose ограничена подмножеством спецификации. Часть полей Compose игнорируется, а стек с неподдерживаемыми возможностями предлагается запускать обычным docker compose вне lifecycle CapRover.

Источник:

• https://caprover.com/docs/docker-compose

Значит ли это, что новый сервис не нужен?

Нет, но делать ещё один «open-source Vercel» само по себе неинтересно. Docker deployment, Git integration, domains, HTTPS, remote servers и GUI уже существуют.

Интереснее другой вопрос:

Как должен выглядеть этот слой, если основным оператором инфраструктуры становится AI-агент?

Большинство существующих систем родилось из человеческой модели взаимодействия. Сложную инфраструктуру превращают в набор сущностей интерфейса: Server, Project, Environment, Application, Network, Domain, Deployment, Volume, Build.

Это полезно, но пользователь всё равно должен понимать модель платформы и правильно её конфигурировать.

AI позволяет поставить вопрос иначе. Человек может сказать: «Вот SSH от нового сервера. Подготовь его и разверни туда эти проекты». Агент способен установить Docker, проверить окружение, работать с Git, вызвать API, прочитать логи и проверить результат.

GUI перестаёт быть единственным способом управления системой. Он становится одним из интерфейсов наряду с API, агентом и прямой работой с файлами.

Но почему тогда не дать агенту просто SSH?

Можно. Для одного сервера этого зачастую достаточно.

Проблема снова появляется на масштабе. Один агент может настроить десять серверов десятью немного разными способами. Через год получится инфраструктурный зоопарк, только созданный быстрее благодаря AI.

Поэтому нужен небольшой инвариантный слой:

SERVER
│
├── Docker
│
└── Platform
    ├── API
    ├── GUI
    ├── domains / routing
    ├── HTTPS
    ├── project runtime
    └── lifecycle

Для установки платформы серверу в идеале нужен только Docker. После этого все серверы имеют одну известную основу. Её можно воспроизводить локально, тестировать, обновлять и одинаково раскатывать на существующие машины.

AI получает свободу действий, но работает поверх предсказуемого фундамента.

Платформа не должна становиться форматом проекта

Это принципиальная граница.

Дочерний проект должен оставаться обычным самостоятельным проектом:

project/
├── .git/
├── docker-compose.yml
├── Dockerfile
├── src/
└── ...

С ним можно работать через платформу, дать его coding agent, открыть файлы вручную, сделать branch/commit/merge/push. И можно вообще обойти платформенный runtime:

cd project
docker compose up

Если удалить управляющую платформу, проект не должен перестать быть нормальным Git/Docker-проектом.

Это более сильное понимание portability, чем кнопка Export: выход из платформы не должен быть миграцией.

Git как естественная основа dev, stage и production

Если каждый проект изначально имеет собственный Git, история изменений не принадлежит платформе. Изменения AI и человека одинаково проходят через обычный diff и commit.

Окружения можно связывать с явным состоянием репозитория:

dev   → текущее рабочее состояние / branch
stage → проверяемый commit
prod  → принятый commit

Конкретная модель может отличаться, но должно быть понятно, какой Git-state реально запущен на конкретном сервере. Это естественно даёт diff, rollback, аудит и переносимость.

Docker Compose как граница совместимости

Мы не хотим писать отдельную платформенную поддержку для Laravel, MODX, Ruby on Rails, Next.js, Django и каждого следующего стека.

Более интересный контракт:

Если проект воспроизводимо запускается как Docker Compose проект, платформа должна уметь с ним работать.

Внутри могут находиться PostgreSQL, MySQL, PHP, Node.js, Ruby, Python, TileServer или несколько собственных сервисов.

Platform standardizes HOSTING
Platform does not standardize APPLICATIONS

AI меняет старое правило: настройка против форка

Традиционные CMS, frameworks и PaaS стараются заранее предусмотреть как можно больше сценариев. Отсюда десятки настроек, plugin APIs, hooks, extension points и собственные абстракции.

С AI становится жизнеспособной противоположная стратегия. Берётся прозрачная универсальная основа. Если она почти подходит — делается fork, после чего AI помогает изменить её под конкретную задачу.

Поэтому важный критерий AI-native основы можно сформулировать так:

Качество определяется не количеством предусмотренных сценариев, а стоимостью реализации непредусмотренного сценария.

Если код небольшой, архитектура понятна, а поведение проверяемо, отсутствие очередной настройки перестаёт быть большой проблемой. Её можно реализовать.

Именно так появился Narasim: он вырос из универсальной основы haih-agent с относительно небольшими специализированными изменениями.

Что уже проверено практически

В текущем прототипе мы проверили запуск самого haih-agent как произвольного дочернего проекта.

основной API
    ↓
внешний DinD
    ↓
Docker Compose проекта
    ↓
PostgreSQL + приложение
    ↓
Traefik
    ↓
домен проекта

Исходный репозиторий дочернего приложения при этом не пришлось превращать в специальный формат платформы. Эксперимент одновременно показал реальные следующие задачи: автоматическая Docker network routing через Traefik, readiness внутренних сервисов, доступ к логам, secrets, isolation и persistent build cache.

Это хороший подход к развитию: вместо абстрактного проектирования универсальной PaaS последовательно убирать конкретные операционные затраты, которые проявляются на реальных проектах.

Где здесь AI-native часть

Она не в кнопке «Deploy with AI».

AI-native архитектура начинается тогда, когда систему можно полноценно использовать без прохождения человеком через каждый экран настройки.

Например:

Добавь новый сервер. Перенеси туда проекты A и B. Для B сделай stage. Обнови production до проверенного commit. Проверь, почему C не отвечает.

Агент знает общий API платформы, Git-состояние проектов и доступные серверы. При необходимости он может спуститься ниже — в Docker, Compose, логи или исходный код.

GUI остаётся важным: человеку нужно видеть систему и иметь возможность управлять ей напрямую. Но GUI больше не обязан превращать каждую возможную операцию в отдельную форму.

Главная цель — не один deployment, а парк проектов

Для одного приложения существующие Coolify или Dokploy уже выглядят сильными решениями. Наша интересующая область начинается там, где проектов становится много.

                    owner / agent
                         │
             ┌───────────┼───────────┐
             ↓           ↓           ↓
          Project A   Project B   Project C ... × 50
             ↓           ↓           ↓
          Server 1    Server 2    Server 3

Нужно видеть, какие проекты существуют, где они запущены, какой commit находится на dev/stage/prod, какие домены к ним относятся, что работает, где требуется обновление, какие изменения можно применить массово, что недавно делал агент и что можно безопасно откатить.

То есть задача постепенно превращается из deployment management в управление собственным портфелем программных систем.

Для кого это может быть полезно

В первую очередь не для большой DevOps-команды.

Интереснее самостоятельные разработчики, небольшие агентства, технические предприниматели и сильные вайб-кодеры, которые уже способны создавать много программных проектов, но не хотят превращаться в системных администраторов каждого VPS.

AI дал им производственную мощность, которой раньше не было. Теперь инфраструктура должна перестать эту мощность съедать.

Как выглядит ставка

Мы не знаем, станет ли именно такая модель отдельной рыночной категорией. Coolify и Dokploy уже показывают, что open-source управление собственными серверами востребовано, и конкурировать с ними списком PaaS-функций бессмысленно.

Ставка в другом сочетании свойств:

1. Open source с самого начала. Платформа должна быть форкабельной, а не только расширяемой через заранее предусмотренные настройки.
2. Самостоятельный проект. Git и Docker Compose принадлежат проекту, а не платформе.
3. Минимальный одинаковый hosting layer. На серверах должна быть известная воспроизводимая основа для domains, HTTPS и runtime.
4. AI как основной оператор. API и архитектура должны быть удобны агенту не меньше, чем GUI человеку.
5. Прямой доступ остаётся. Специалист всегда может открыть Git, файлы, Docker и сервер и работать обычными средствами.
6. Оптимизация под множество проектов. Ценность растёт не от сложности одного deployment, а от сокращения операционного налога на весь парк.

Возможно, после эпохи «сделаем разработку сайта простой» начинается следующая задача:

сделать владение десятками собственных сайтов таким же обычным, каким AI уже сделал создание одного.

И если это получится, выбор между удобством SaaS и свободой собственного проекта станет значительно менее жёстким.