Ваш ИИ написал работающее приложение. Вот как вывести его в онлайн.

Проблема приложения, написанного в пятницу вечером

Один знакомый нам руководитель провёл пятничный вечер с ИИ-ассистентом и к полуночи получил по-настоящему полезный внутренний инструмент: трекинг задач, устроенный ровно так, как работает его команда, — потому что он знает эту работу лучше любого вендора. Работало всё отлично — на его ноутбуке.

Варианты в понедельник были один хуже другого. Попросить у ИТ-отдела сервер и неделями ждать, пока тикет проползёт по инстанциям. Отдать данные компании на чужую хобби-платформу. Или арендовать голый VPS и в одночасье стать ответственным за TLS, бэкапы, патчи и файрволы. Код был хорош. Не хватало дороги.

Почему привычные пути деплоя не подходят

Каждый из привычных путей предполагает что-то, чего у такого создателя нет. Деплой через git предполагает репозиторий и работу с ветками. Деплой образами предполагает container registry и уверенное владение Docker, чтобы этот registry наполнять. Оба предполагают, что публикующий — хотя бы на полставки — инженер по деплою.

А у создателя, работающего с ИИ, всё проще: папка с работающим кодом. Значит, именно с неё дорога и должна начинаться — с папки. Если репозиторий у вас всё же есть, смотрите деплой из Git; обе дороги ведут на одну и ту же платформу.

Папки достаточно

Установите один небольшой CLI, выполните одну команду в каталоге проекта — и cdnctl разберётся с остальным: язык и фреймворк, порт, есть ли Dockerfile (он может его сгенерировать) и даже какие ИИ-агенты для кодинга настроены в проекте — потому что агент, написавший приложение, обычно и будет продолжать его публиковать.

$ cdnctl init
Proje    : gorev-takip (node/express, port 3000)
Agent    : claude-code (claude on PATH), cursor
Paket    : ✓ Large (max 5 app)
Karne    : 2 HATA, 2 uyarı — ayrıntı: cdnctl check
Yazıldı  : cdnctl.yaml, AGENTS.md

→ Önce `cdnctl check` hatalarını düzeltin (deploy sonrası site açılmaz).

Табель успеваемости до того, как код покинет машину

Приложения, написанные ИИ, падают в продакшене по горстке очень повторяемых причин, и каждая из них видна в исходниках ещё до деплоя. cdnctl check работает целиком на вашей машине — код никуда не загружается — и отказывается публиковать заведомо сломанное приложение. Четыре находки ниже не гипотетические: это ровно те ошибки, с которыми было написано наше собственное тестовое приложение, пойманные с первого запуска.

$ cdnctl check
[ERROR] bind-localhost (server.js:61)
        The app binds to 127.0.0.1 — unreachable inside a container.
        → Bind to 0.0.0.0 (just drop the host argument).
[ERROR] secret-in-code (server.js:10)
        A hard-coded secret (API key/token/password).
        → Move it to --secret KEY=VALUE; read it via process.env.
[WARNING] sqlite-single-pod
        SQLite loses data on restart / multiple replicas.
        → Mount a persistent disk or switch to a managed database.
[WARNING] no-healthcheck
        No /health route — the platform can’t tell your app is alive.

Одна команда до живого URL

После исправлений деплой — это одна команда. Под капотом исходники архивируются, загружаются по TLS, собираются в контейнерный образ в изолированной песочнице, отправляются в приватное registry-пространство вашего аккаунта и запускаются за настоящим HTTPS-поддоменом — но ничего из этого не требует вашего внимания. Первый запуск занимает около минуты; каждый следующий релиз — та же самая одна команда.

$ cdnctl deploy
→ archiving source (gorev-takip)
→ uploading (0.1 MB)
→ starting build (Kaniko, isolated sandbox)
   build: running
   build: success        (41 s)
→ creating the app
→ assigning a subdomain
→ first deploy
→ waiting for the app to come up

✓ LIVE: https://ca…….cdn.com.tr

Безопасность и надёжность — по умолчанию, а не как обязанность

То, что делало путь через VPS пугающим, здесь — работа платформы. TLS выпускается и продлевается за вас. Build выполняется в песочнице, а образы живут в registry-пространстве, принадлежащем только вашему аккаунту. Healthcheck позволяет платформе перезапустить приложение, как только оно перестаёт отвечать. А когда табель обнаруживает файловую базу данных, он указывает на постоянные диски и управляемые MySQL/PostgreSQL — чтобы перезапуск пода никогда не съел ваши данные.

Ваш ИИ-агент может выполнить весь этот процесс сам

cdnctl init записывает раздел о деплое в AGENTS.md (и в CLAUDE.md, если он есть), так что агент, создавший приложение, на следующем ходу уже знает точные команды. Агенты получают машиночитаемый вывод через --json, MCP-сервер через cdnctl mcp и — что важно — собственный deploy-only токен: он может загружать, собирать и выпускать релизы, но НЕ может трогать DNS, оплату и остальную часть вашего аккаунта. Ваш пароль от панели никогда вас не покидает. Подробности — на справочных страницах cdnctl. Полная модель безопасности — границы токена, настройка MCP и проверенные на практике пределы — в статье дайте своему агенту доступ к деплою безопасно.

Какая дорога ваша?

Три дороги, одна платформа. Если вы держите код в репозитории и хотите push-to-deploy — вам на деплой из Git. Если вы уже собираете образы и запускаете compose-файл — смотрите Docker-хостинг. А если у вас есть работающая папка — та самая пятничная ситуация — эта дорога построена для вас: установите cdnctl, выполните init, выполните deploy и отправьте URL своей команде.