1. Введение: зачем CI/CD без облачных гигантов
В последние пару лет многие европейские компании начали смотреть на привычные CI/CD-сервисы вроде GitHub Actions, GitLab SaaS или AWS CodePipeline не так восторженно, как раньше. Причина проста: использовать «облачных монстров» стало не только дорого, но и неудобно.
Во-первых, стоимость. Когда у тебя десятки или сотни пайплайнов, которые крутятся ежедневно, счёт за минуты раннеров и дополнительные сервисы в облаке превращается в неприятный сюрприз для финансового директора. Особенно в 2025-м, когда тарифы крупных игроков ползут вверх быстрее, чем инфляция.
Во-вторых, GDPR и прочие регуляторные радости. Европейский бизнес всё жёстче проверяют на соответствие правилам обработки персональных данных. И когда твой код гоняется через чужую инфраструктуру в неизвестных дата-центрах, юристы начинают нервно поправлять очки.
Третий момент — зависимость от внешних API. Как только GitHub или AWS решат «прикрутить» новый лимит, изменить SLA или выкатить обновление, которое ломает обратную совместимость, твоя разработка превращается в заложника чужих решений. А бизнесу нужна предсказуемость, а не очередной ночной пожар в проде из-за чужого апдейта.
И наконец, контроль над инфраструктурой. Собственный VPS даёт ту самую свободу: ты сам решаешь, какой раннер использовать, где хранить артефакты и как именно настраивать пайплайны. Это не только про экономию, но и про уверенность — твой CI/CD живёт там, где ты сам определил, а не где захотелось облачному провайдеру.
Поэтому всё больше команд переходят к старому доброму подходу: свой VPS + самописный или open-source CI/CD. Немного больше возни на старте — зато полная независимость в долгую.
2. Выбор VPS для CI/CD: важные, но неочевидные параметры
Когда речь заходит о CI/CD на VPS, большинство разработчиков смотрит только на количество ядер и объём оперативки. Логика простая: чем больше ресурсов, тем быстрее будет собираться проект. Но на практике узкие места возникают совсем в других местах, и вот тут начинаются сюрпризы.
Первое — диск. Если твой провайдер до сих пор живёт на старых SATA или даже медленных SSD, забудь о комфортных билдах. При компиляции, особенно в проектах на Java, C++ или Rust, диск нагружается так, что CPU может спокойно скучать в ожидании. Поэтому ключевой параметр — это NVMe-скорости и IOPS. Чем выше, тем лучше. На практике разница может быть в разы: билд, который на SATA тянется 15 минут, на нормальном NVMe укладывается в 5–6.
Второе — сеть. На CI/CD она играет не меньшую роль, чем диск. Каждый docker pull и docker push — это десятки или сотни мегабайт, а иногда и гигабайты образов. Если у VPS-провайдера хитрый тариф с урезанной пропускной способностью или лимитом трафика, то пайплайн может неожиданно встать в пробку. Обращай внимание не только на «честные» мегабиты в секунду, но и на burst-скорости — они решают, насколько быстро будут уходить пики нагрузки.
Третье — nested virtualization. Если ты запускаешь интеграционные тесты, которые требуют KVM или QEMU, без поддержки вложенной виртуализации будет тяжело. Многие бюджетные провайдеры экономят на этом, а ты потом мучаешься с костылями. Лучше сразу проверять: поддерживает ли выбранный VPS nested virt, иначе часть тестов придётся выносить куда-то ещё.
И наконец — провайдеры. В Европе есть несколько проверенных игроков:
- Hetzner (Германия/Финляндия) — дешёвые и мощные VPS, NVMe отличного качества.
- OVHcloud (Франция/Германия/Польша) — гибкие тарифы, стабильная сеть, но иногда с поддержкой приходится повозиться.
- Scaleway (Франция/Нидерланды) — хорошие для старта, дружелюбные API.
- Time4VPS (Литва) — бюджетный вариант, но с приличным качеством.
Выбор VPS — это как выбор рабочего стула: если взять абы какой, потом будешь жалеть каждый день. Лучше один раз внимательно посмотреть на эти «невидимые» параметры, чем потом страдать от медленных билдов и падающих пайплайнов.
3. Локальные CI/CD-решения, подходящие для VPS
Окей, сервер мы выбрали, теперь встаёт главный вопрос: какой CI/CD туда поставить? На рынке хватает решений, но не все они одинаково удобны для VPS. Здесь важно не только «чтобы работало», но и «чтобы не съело всю машину ради одного пайплайна». Давай посмотрим на самые интересные варианты.
Woodpecker CI
Это практически «облегчённый клон» Drone, который пошёл своим путём после того, как Drone стал слишком корпоративным. Woodpecker — полностью self-hosted, легко запускается в Docker и не требует тонны оперативки. Его фишка — простота: пайплайны описываются YAML-ом, интеграция с Git-репозиториями минималистичная, но достаточная. Отличный вариант, если нужен CI/CD «без лишних кнопок» и ты хочешь контролировать каждый шаг.
Gitea + Actions
Если GitHub Actions нравится по концепции, но ты не хочешь зависеть от GitHub, то Gitea спасает ситуацию. В последних версиях у него появилась поддержка Actions, очень похожих на оригинальные. Разница в том, что всё это работает прямо на твоём VPS. Можно поднять Gitea как Git-сервер, а рядом настроить раннеры под свои пайплайны. Получается почти то же самое, что GitHub Actions, но локально и под твоим контролем. Для небольших команд — золотая середина между простотой и гибкостью.
GitLab CE
Community Edition — это бесплатная версия GitLab, и её часто выбирают как «комбайн для всего». В одном интерфейсе здесь есть и Git-репозиторий, и трекер задач, и Wiki, и полноценный CI/CD. Для команд, которым важна интеграция всего в одном месте, GitLab CE становится универсальным решением. Минус — он заметно тяжелее, чем Gitea или Woodpecker, поэтому стоит учитывать ресурсы VPS.
Jenkins (2.440+) с контейнерами
Да, Jenkins до сих пор жив — и не просто жив, а активно развивается. В свежих версиях у него появилось много оптимизаций, а если запускать билд-агентов в Docker-контейнерах, то Jenkins можно неплохо ужать под ресурсы VPS. Он уже не тот «монстр на Java», который ест гигабайты памяти ради пары пайплайнов. Конечно, Jenkins остаётся более тяжёлым вариантом по сравнению с Woodpecker, но если нужна максимальная гибкость и куча плагинов — это всё ещё рабочая лошадка.
Forgejo + Actions
Forgejo — это форк Gitea, который пошёл своим путём с упором на большие команды и корпоративные сценарии. По сути, если Gitea — это «GitHub для друзей», то Forgejo — «GitHub для отдела разработки». У него тоже есть Actions, поддержка федерации и больше возможностей для масштабирования. Если команда растёт и Gitea начинает казаться тесным, переход на Forgejo — логичный шаг.
В итоге:
- Для маленьких проектов и стартапов — Woodpecker или Gitea.
- Для команд, которым нужен «всё-в-одном» инструмент — GitLab CE.
- Для энтерпрайза или больших команд — Jenkins или Forgejo.
CI/CD на VPS — это уже давно не «экзотика», а вполне зрелый и гибкий подход.
4. Архитектура пайплайна без облака
Когда мы говорим «CI/CD на VPS», сразу возникает вопрос: а как грамотно выстроить архитектуру пайплайнов, чтобы и быстро, и надёжно, и не превращалось всё это в клубок костылей? На самом деле всё не так страшно. Достаточно разделить роли и чуть подумать о сетевой топологии.
Выделенный build-runner.
Первая ошибка, которую делают многие — запускают билд и деплой на одном сервере. Вроде бы удобно, но на практике это превращается в мешанину: билды жрут ресурсы, деплой начинает тормозить, а при падении VPS рушится весь процесс. Гораздо надёжнее — завести отдельный VPS под билд-агентов. Там они собирают проект, гоняют тесты и готовят артефакты.
Отдельный VPS для деплоя.
Второй сервер — это уже «спокойная гавань» для продакшн-деплоя или стейджинга. Он не перегружен сборкой, и туда прилетают только готовые артефакты. Так проще контролировать стабильность и разграничивать ответственность: билд упал — чинит команда разработки, деплой не взлетел — смотрит DevOps.
Сеть внутри дата-центра.
Если брать VPS у нормального провайдера, почти всегда можно настроить private networking или VLAN. Это значит, что билд-сервер и деплой-сервер общаются напрямую внутри одного дата-центра, без выхода в интернет. И это сильно ускоряет передачу артефактов: docker-образы или архивы гоняются по внутренней сети на гигабитных скоростях, а не через внешний канал с его ограничениями.
Оптимизация Docker-слоёв.
В CI/CD на VPS каждая секунда на счету, и тут помогает правильная структура Dockerfile. Если часто обновляешь только код, выноси тяжёлые зависимости в базовые слои. Тогда при билде будут пересобираться только последние шаги, а не весь контейнер целиком.
Кэширование зависимостей.
Ещё один лайфхак — кэш. Node.js, Python, Java, Go — все эти языки любят качать гигабайты пакетов. Настрой локальный кэш на VPS, и вместо постоянного обращения к npm или PyPI будешь получать зависимости мгновенно. Это режет время билда в разы.
Итого: простая схема «VPS для билдов + VPS для деплоя + внутренняя сеть + кэширование» превращает твой CI/CD в стабильный и быстрый механизм, который ничем не хуже облачных решений.
5. Безопасность CI/CD на VPS
CI/CD на VPS — это, конечно, свобода и экономия, но вместе с ней приходит и ответственность. Если в облачных решениях часть проблем решает провайдер, то тут всё на твоих плечах. Хорошая новость: большинство практик безопасности легко внедрить даже на обычном VPS.
Изоляция билд-агентов.
Первое правило — никогда не доверяй коду, который сам же и написал. Пайплайн может случайно (или специально) запускать команды, которые получат доступ к серверу. Поэтому билд-агенты лучше держать в «песочнице». Для этого есть два лёгких решения:
- LXD — быстрые контейнеры с полноценной изоляцией, почти как виртуалки.
- Firecracker — микровиртуалки от AWS, которые запускаются за миллисекунды и идеально подходят для временных билдов.
Оба варианта позволяют запускать билды так, чтобы случайный скрипт не пролез в соседние процессы.
Secrets management.
Вторая боль любого CI/CD — секреты: ключи, пароли, токены. Хранить их в YAML или, не дай бог, в репозитории — это прямой путь к утечке. Тут помогают системы управления секретами:
- Vault by HashiCorp — классика жанра, хранит секреты централизованно и раздаёт их по принципу «минимум, на ограниченное время».
- Sealed Secrets — вариант для Kubernetes, когда секреты шифруются и хранятся прямо в Git, а расшифровываются только на кластере. И да, это работает и без облака, если у тебя свой self-hosted Kubernetes.
SSH-доступ к деплой-серверам.
Самый уязвимый момент — это шаг деплоя, когда CI/CD должен подключиться к серверу. Здесь важно не хранить «вечные ключи» на диске, а использовать временные ключи или short-lived tokens. Например, CI/CD может генерировать ключ, который живёт 5 минут, используется для деплоя и тут же удаляется. Даже если кто-то его перехватит — пользы от него ноль.
В итоге: немного дополнительной изоляции, правильное хранение секретов и дисциплина с доступами — и твой CI/CD на VPS будет не менее безопасен, чем у облачных гигантов. Только без их ценников и лишней бюрократии.
6. Интеграция с европейскими DevOps-инструментами
CI/CD на VPS — это не только про сборку и деплой, но и про весь сопутствующий «сервисный хвост»: артефакты, мониторинг и логи. К счастью, для этого есть лёгкие и удобные инструменты, которые отлично встают на свои VPS.
Хранение артефактов.
Вместо того чтобы тащить всё в S3 от Amazon, можно использовать европейские альтернативы. Например, Bunny.net Storage — быстрый и недорогой CDN+хранилище с дата-центрами в Европе. Или вообще поднять MinIO на отдельном VPS — получишь полноценный S3-совместимый сторедж под свой контроль. Это особенно удобно, если у тебя несколько пайплайнов и нужно единое место, где лежат все бинарники, образы и пакеты.
Мониторинг пайплайнов.
Здесь классика — Prometheus + Grafana. Prometheus собирает метрики о билдах и раннерах, а Grafana превращает это в красивые дашборды. Видно сразу: где очередь на билд, какие пайплайны тормозят, а где всё летает. Дополнительно можно настроить алерты прямо в Grafana, чтобы не копаться в логах, а сразу видеть, где узкое место.
Логи и алерты.
Чтобы не зависеть от внешних лог-сервисов, можно поставить Loki (логи в стиле «Prometheus для текстов») и Alertmanager. В итоге у тебя полный цикл: пайплайн упал — приходит уведомление в Slack или Mattermost, при этом все логи остаются у тебя на VPS, без внешних интеграций.
И ещё один важный момент: все эти инструменты дружат между собой. Prometheus забирает метрики, Loki хранит текстовые логи, Alertmanager шлёт алерты, Grafana рисует красивые панели. В связке это даёт полноценную картину того, что происходит с пайплайнами. По сути, ты получаешь свой маленький «DevOps Cloud», только без облака и с полным контролем.
7. Заключение: гибкий и суверенный DevOps
CI/CD на VPS — это не про то, как сэкономить пару евро на подписках. Это про контроль и независимость. Ты сам решаешь, где будут храниться твои артефакты, как обрабатываются секреты и какие ограничения допустимы. Никаких «чёрных ящиков» от облачных гигантов, никакой внезапной смены SLA или новых лимитов «с завтрашнего дня». Всё честно и прозрачно: инфраструктура — твоя, правила — тоже твои.
Но важно понимать: чтобы этот подход реально работал, нужны правильные шаги на старте. Есть три вещи, которые стоит сделать сразу:
- Выбрать правильный VPS. С NVMe-дисками, нормальной сетью и поддержкой nested virtualization. Это база, без которой любой пайплайн будет страдать.
- Внедрить лёгкий self-hosted CI. Не обязательно сразу поднимать Jenkins с сотней плагинов. Для старта хватит Woodpecker или Gitea Actions. Главное — чтобы пайплайны жили рядом с кодом и управлялись тобой, а не внешним API.
- Обеспечить безопасность пайплайнов. Изоляция билд-агентов, управление секретами через Vault или Sealed Secrets, временные SSH-ключи — это не «излишество», а норма. Тогда твой CI/CD будет не только быстрым, но и надёжным.
В итоге у тебя получается гибкий и суверенный DevOps-стек: он может быть маленьким для стартапа или вырасти в полноценную систему для корпорации. Главное, что он полностью под твоим контролем. И это та самая ценность, ради которой компании сегодня массово уходят от облачных монстров к своим собственным решениям.
