Деплой на платформу Zerovibe

Деплой на платформу Zerovibe

Публикует приложение: платформа собирает Docker-образ из ТВОЕГО кода (Dockerfile проекта), поднимает контейнер и выдаёт поддомен <sub>.zerovibe.ru с авто-TLS. Локально Docker не нужен — сборка идёт на платформе.

Предусловия

• Ключ настроен (~/.zerovibe/config.json). Нет → /zerovibe:install.
• Папка привязана (ZEROVIBE_PROJECT в .env). Нет → /zerovibe:init.
• В корне есть Dockerfile (как в эталоне; приложение слушает :8080).
• Для локальной проверки/предпросмотра нужен Go (ставится при /zerovibe:install). Если его нет — предупреди, что без него не получится показать приложение до публикации, и предложи /zerovibe:install.

Креды и привязка: ключ и базовый api — из ~/.zerovibe/config.json; ZEROVIBE_PROJECT (и, если задан, переопределяющий ZEROVIBE_API) — из .env проекта.

Шаг 0 — проверить и показать пользователю ДО публикации

Это важно: креатор должен увидеть, что приложение работает, ещё до прода.

1. Проверь, что собирается и тесты зелёные (в проекте есть make check). Покажи результат продуктовым языком: «проверил — всё работает» / «нашёл проблему, чиню». Красное — НЕ публикуем, сначала чини (см. skill testing-rules).

2. Подними приложение локально для живого предпросмотра и дай пользователю ссылку http://localhost:8080, чтобы он посмотрел вживую. Важные инварианты локалки: используй ВРЕМЕННУЮ базу (не трогай рабочие данные), SECURE_COOKIE=false и APP_BASE_URL=http://localhost:8080 (локалка без TLS); точка входа — cmd/server; готовность проверяй через /healthz. Дождись подтверждения пользователя.

3. Останови предпросмотр и убери временную БД перед публикацией.

Шаг 1 — собрать архив исходников

gzip-архив кода. КРИТИЧНО: Dockerfile и исходники лежат в КОРНЕ архива (без обёртки-папки). Исключи: .git, data, *.db, tmp, node_modules, .env (данные и секреты не заливаем).

Шаг 2 — залить архив

POST {api}/dev/projects/{ZEROVIBE_PROJECT}/source с X-API-Key. Ответ: upload_url (presigned PUT) и key. Залей архив PUT-ом на upload_url. key пойдёт как source_key в деплой.

Шаг 3 — запросить деплой

POST {api}/dev/projects/{ZEROVIBE_PROJECT}/deploy с X-API-Key, тело {"subdomain": "<sub>", "source_key": "<key из шага 2>"}.

Поддомен <sub>: только a-z, 0-9, дефис; 1..63 символа; уникален на платформе. Спроси у пользователя, если не задан.

Ответ содержит domain и status:

• running → готово, открывай https://<sub>.zerovibe.ru (можно проверить /healthz).
• failed → причина: занятый поддомен, красные тесты или ошибка сборки образа.

Что знать о платформе (грабли и факты)

• Все вызовы платформы — заголовком X-API-Key (не Bearer).
• TLS edge-Caddy выпускает автоматически при первом запросе.
• Данные приложения (SQLite) — в volume на VM, переживают рестарт контейнера.
• Платформенные переменные прокидываются автоматически: при деплое платформа сама кладёт в контейнер PLATFORM_API_URL/PLATFORM_API_KEY (отправка писем — восстановление пароля), APP_BASE_URL (свой домен), SECURE_COOKIE. Креатора про них не спрашивай.
• Миграции goose применяются при старте контейнера сами — новые таблицы появятся автоматически.

Аргумент пользователя (поддомен): $ARGUMENTS