Первый тенант: от заказа до боевого URL за 5 минут

wl-installer держит в registry готовые адаптеры для Hetzner, OVH, Vultr, DigitalOcean и Elistrax. При создании заказа клиент видит только те провайдеры, для которых в /admin/settings заведён рабочий токен (hetzner.token, ovh.app_key и т.д.). Если нужного провайдера нет в выпадайке — значит, оператор не залил ключ.

Регион и тип VPS подбираются по профилю продукта (lib profiles): минимальная конфигурация на старте, авто-скейл потом.

Через API провайдера создаётся машина с base-образом Ubuntu 22.04, к ней прикрепляется наш SSH-ключ из ssh.private_key + ssh.public_key. Адаптеры провайдеров живут в api/internal/cloud — каждый реализует Provision(ctx, spec) → Server.

После того, как машина получила IP, мы ждём готовности SSH-сокета (TCP 22 поднимается). На Hetzner — обычно 25–40 секунд.

Через ansible-профиль (lib/profiles) устанавливаются docker, caddy и тянутся образы продукта из нашего Docker-registry. Имя образа берётся из product_versions.artifact_image: при is_current = true это всегда последний стабильный тег.

Конфиг продукта пишется в /opt/app/.env — секреты (DB-пароль, JWT) генерируются на машине и шифруются нашим vault.Encrypt при записи в платформенную БД, чтобы потом мы могли их восстановить.

Если включён Cloudflare (cloudflare.token + cloudflare.zone_id), под бренд клиента создаётся A-запись с proxied = true. Это значит трафик идёт через CDN — DDoS-защита и кеширование статики из коробки.

Caddy на VPS клиента видит первый запрос на новый домен и автоматически выпускает Let's Encrypt-сертификат. Никаких ручных certbot.

Финальный health-чек: HTTP GET по app_url, ожидание 200. Если ок — статус deployment'а в БД становится running, клиент получает письмо с временным паролем админа.

Если не ок — статус failed, в deployment_events пишется stderr, оператор получает алерт в Telegram (если obs.telegram.bot_token настроен).