AI-конструктор с Vercel: деплой проекта на свой аккаунт

Да, собранный проект разворачивается на вашем аккаунте Vercel через штатную интеграцию. Публиковать через неё не обязательно: у каждого проекта и так есть адрес вида имя.zugo.run, и для большинства задач его достаточно. Vercel нужен тем, кому важно, чтобы раздачей проекта управляли вы, а не платформа.

Чем деплой на Vercel отличается от обычной публикации?

Публикация в Zugo это один шаг: проект получает рабочий адрес, и по нему его открывают люди. Ничего настраивать не нужно, никаких внешних аккаунтов не требуется.

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

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

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

Кому этот деплой действительно нужен?

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

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

Как выглядит переход по шагам?

Второй шаг стоит сделать в любом случае, даже если деплой пока не нужен. Репозиторий это резервная копия, которая не зависит ни от одной подписки, и делается она один раз. Подробности в статье про экспорт исходников в GitHub.

Пятый шаг требует внимания. Пока DNS-записи не разошлись, старый адрес продолжает работать, так что проект не пропадает. Планируйте перенос заранее, а не за час до рекламной кампании: как это устроено, разобрано в статье про подключение своего домена.

Что меняется в работе после переезда?

Меняется меньше, чем принято думать, но одна вещь меняется существенно.

Правки. Пока проект живёт в конструкторе, вы правите его текстом: одна фраза, новая версия. После переезда на свой хостинг у вас появляется вопрос, откуда берётся следующая версия. Либо вы продолжаете работать в Zugo и разворачиваете обновления, либо переходите к правкам в коде.

Ответственность. Логи, переменные окружения, обновления зависимостей и работоспособность сборки становятся вашей задачей. Это ровно то, за что вы и переезжали, но стоит признать, что это работа, а не подарок.

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

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

Что такое переменные окружения и зачем они вам?

Это самая частая причина, по которой люди переезжают на свой хостинг, и одновременно самая непонятная для тех, кто не писал код.

Переменная окружения это настройка, которая живёт рядом с проектом, а не внутри его файлов. Типичный пример: ключ доступа к внешнему сервису. Такой ключ нельзя писать прямо в коде, потому что код уезжает в репозиторий, а репозиторий видят люди.

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

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

Отсюда простой ориентир: переезд на свой хостинг оправдан тогда, когда вам действительно нужно управлять этими настройками, а не тогда, когда о них просто рассказали.

Сколько это стоит?

Интеграция кредитов не расходует. Vercel это внешний сервис со своими тарифами, и оплачивается он не через Zugo.

Кредиты уходят на генерацию. Сборка стоит 6 кредитов, правка 3, многостраничная платформа 12 за первые три страницы и по 3 за каждую следующую. Режим Hi-Fi вдвое дороже: сборка 12, правка 6. Бесплатный тариф даёт 5 кредитов, Pro стоит $25 в месяц за 200 кредитов, Business стоит $99 в месяц.

Полезно понимать масштаб времени. Простая сборка занимает около минуты, многостраничная платформа несколько минут. Развёртывание на своём хостинге к этим цифрам не относится: там время зависит от вашей настройки, а не от конструктора.

Как не сломать работающий проект при переезде?

Переезд редко идёт плохо технически и часто идёт плохо организационно. Помогает один принцип: новое должно заработать до того, как отключится старое.

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

Проверьте на новом адресе всё, что зависит от окружения. Формы, письма, оплата, вход. Именно эти вещи ломаются при переносе чаще всего, потому что они зависят от настроек, а не от кода.

Дальше переключите домен и подождите, пока изменения разойдутся. В этот период часть посетителей попадает на новый адрес, часть на старый, и оба должны работать. Отключать старое в этот момент нельзя.

Только когда новый адрес отвечает стабильно, снимайте временные настройки и обновляйте счётчик аналитики, чтобы данные не разъехались.

И выберите для переезда день, когда вы за компьютером. Ночь пятницы это плохой момент для любых изменений в инфраструктуре, независимо от платформы.

Где проходят честные границы?

Три вещи стоит назвать прямо.

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

Проверка в песочнице относится к сборке, а не к вашему деплою. Zugo запускает проект перед выдачей и не отдаёт сборку, которая не открылась. Это снижает риск белого экрана на его стороне и ничего не говорит о том, как проект поведёт себя после ваших изменений в чужом окружении.

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

Что делать дальше

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

Собрать проект, довести его правками и посмотреть, на какой он стадии, можно на zugo.dev. Решение про переезд честнее принимать, глядя на работающий проект, а не на схему в статье.