автор Vitaly NikitinБольшинство инструментов для деплоя предполагают, что у вас есть облачный аккаунт. Выбрать регион, поднять управляемый кластер, настроить реестр, после часа работы и трёх IAM-политик — наконец-то задеплоить контейнер.
Simple Container теперь работает иначе. Если у вас есть машина, к которой можно подключиться по SSH, — этого достаточно.
Путь «у меня есть VPS»
Новый тип ресурса vm с драйвером byo позволяет указать Simple Container на любой хост — адрес, имя пользователя и SSH-ключ. Дальше SC сам собирает образ в CI, доставляет его по SSH в виде сжатого архива, разворачивает Docker Compose стек на хосте и ставит перед ним Caddy
с автоматическим TLS. Переключение между синим и зелёным деплоем происходит через caddy reload — старый контейнер продолжает отвечать на запросы до тех пор, пока новый не пройдёт health check.
Мы запустили проверку на обычном VPS и измерили качество переключения: 3 092 пробных запроса за полный цикл деплоя — 3 092 ответа HTTP 200, ноль ошибок. Само переключение произошло атомарно между двумя последовательными пробами с разрывом 194 миллисекунды. Второй независимый тест на смёрдженном коде: 853 запроса, два переключения, ни одного ответа, кроме 200.
Одна честная оговорка: в текущей проверке использовался nginx в качестве рабочей нагрузки. Сервисы Forge пока не адаптированы под VM-таргет — эта работа идёт следующей. Что уже готово — сам механизм доставки: любой собранный образ можно разместить на любой собственной машине с рабочим TLS-сертификатом и обновлением без даунтайма.
Передача образа идемпотентна: sc image ship проверяет id образа на хосте и пропускает повторную загрузку, если это тот же билд. Архитектура также проверяется заранее — никакого молчаливого SIGILL в рантайме.
k3s на собственном хосте
Второй новый таргет идёт дальше: SC теперь умеет устанавливать k3s — лёгкий дистрибутив Kubernetes — по SSH на любой указанный хост, экспортировать kubeconfig и использовать его так же, как кластер GKE Autopilot.
Вот что здесь важно. Новый ресурс k3s-cluster экспортирует kubeconfig под тем же именем стека-вывода, которое всегда использовал GKE-таргет. Всё выше этой границы — путь деплоя через Kubernetes, маршрутизация через Caddy, Helm-операторы — переиспользуется без единого изменения. Чтобы добавить новый тип кластера, потребовался один новый ресурс, а не переработка половины платформы.
Результат живой проверки: kubectl get nodes вернул статус Ready на k3s v1.36.5+k3s1, стек с типом cloud-compose задеплоился через неизменённый Kubernetes-путь, сервис LoadBalancer получил внешний IP, а curl вернул HTTP 200 за 48 мс.
Одно предупреждение: удаление ресурса k3s-cluster пока не деинсталлирует k3s с хоста — хук Delete ещё не реализован, процесс остаётся на машине. Это важно знать, если вы планируете полностью освободить хост.
История отладки, которую стоит рассказать
Проверка k3s нашла шесть ошибок в уже смёрдженном коде — именно для этого проверки и нужны. Самая показательная: вспомогательная функция глубоко в парсере конфигурации нормализовала все nil-срезы и nil-карты к пустым значениям. Это уничтожало различие между nil и пустым значением для каждого флага в каждом разобранном конфиге.
Практический результат: флаг --disable traefik никогда не попадал в итоговый вывод. В каждом кластере k3s Traefik продолжал слушать порты 80 и 443 — из-за этого первый сервис LoadBalancer навсегда оставался в состоянии <pending> без единого сообщения об ошибке. Юнит-тест для логики генерации флагов всё это время был зелёным, потому что тест вообще не проходил через затронутый путь кода.
«Зелёный» не значит «правильный». Проверка поймала ошибку. Исправление выпущено.
Что это меняет
До сих пор каждый таргет деплоя в Simple Container требовал либо управляемого Kubernetes-кластера, либо облачного аккаунта. Оба варианта хорошо работают для многих задач. Но ни один из них не подходит для ситуации «у меня один VPS, и я хочу разместить на нём приложение с рабочим сертификатом и обновлением без даунтайма».
Теперь такой путь существует. Принесите свою машину. sc provision, sc deploy — готово.
k3s-путь идёт дальше: если вам нужна полная поверхность Kubernetes — Helm, операторы, сервисы LoadBalancer — на собственном железе, SC установит кластер, настроит реестр и выдаст kubeconfig, который работает со всеми существующими примитивами деплоя SC. Без облачного аккаунта, без внешней плоскости управления.
Релиз опубликован под тегом 2026.10.24
в публичном репозитории — с CycloneDX SBOM, SLSA in-toto аттестацией и cosign-бандлом.
Если вы сегодня запускаете нагрузки на VPS и стандартный cloud-first подход к деплою вам не подходил, это как раз тот путь, который мы для вас и строили .