VPS для разработчика: что держать на своём сервере

VPS для разработчика: CI-раннер, свой PaaS, n8n, боты и API, Git и мониторинг на своём сервере — сколько ресурсов и трафика нужно и с чего начать.

Облачные сервисы для разработки удобны, пока хватает бесплатных лимитов: минут CI, запусков автоматизаций, «засыпающих» бесплатных инстансов. Дальше свой сервер обычно выгоднее: вы платите за ядра, память и диск, а не за каждую сборку и каждый запуск. Цена — администрирование: обновления, бэкапы и безопасность ложатся на вас. Ниже — что разработчики чаще всего держат на VPS, сколько это требует ресурсов и как разложить сервисы по серверам.

Что поднять на своём сервере

CI и сборки. Свой раннер GitHub Actions или GitLab Runner: NVMe, нужный объём памяти и кэши, которые живут между запусками. Инструкция — «Self-hosted runner GitHub Actions на VPS».
Деплой по пушу. Coolify или Dokploy вместо Heroku и Vercel: приложения из Git, превью-окружения, базы и бэкапы. Инструкция — «Coolify на VPS».
Автоматизации. n8n с PostgreSQL и вебхуками на своём домене, без лимита запусков. Инструкция — «n8n на своём сервере».
Боты и API. Telegram-боты, сервисы на FastAPI и Node.js под systemd или в Docker. Инструкции — «Telegram-бот на VPS», «FastAPI» и «Node.js и PM2».
Git для команды. Forgejo или Gitea: репозитории, ревью, реестр пакетов и свои Actions. Инструкция — «Свой Git-сервер на VPS».
Разработка на сервере. VS Code, Cursor или JetBrains поверх SSH: сборки идут на сервере, а ноутбук остаётся тонким клиентом. Инструкция — «Удалённая разработка на VPS».
Мониторинг. Uptime Kuma следит за сайтами, API и сроками сертификатов и пишет в Telegram. Инструкция — «Uptime Kuma».
Базы данных. PostgreSQL, MySQL и Redis на NVMe. Инструкции — «PostgreSQL», «MySQL и MariaDB» и «Redis».

Сколько ресурсов нужно

Ориентиры из инструкций, с запасом на систему, Docker и reverse proxy:

Бот или небольшой API — 1 vCPU и 2 ГБ памяти, и на таком сервере уживается несколько ботов.
n8n — 1 vCPU и 2 ГБ для личного инстанса, 2 vCPU и 4 ГБ для рабочего с узлом Code и AI-агентами, от 4 vCPU и 8 ГБ для queue mode с воркерами.
Uptime Kuma — 1 vCPU и 1 ГБ на пару десятков мониторов, 2 vCPU и 2 ГБ на две сотни.
Forgejo — 1–2 vCPU и 2 ГБ вместе с PostgreSQL для команды до пяти человек.
Coolify — от 2 vCPU и 4 ГБ. Сама панель в простое занимает около 300 МБ, память и ядра съедают сборки.
CI-раннер — 1–2 vCPU и 2 ГБ на линтеры и тесты, 2 vCPU и 4 ГБ на сборку фронтенда, 4 vCPU и 8 ГБ на Docker-образы и тесты с базами. Каждый параллельный раннер — ещё 2 vCPU и 2–4 ГБ.
IDE на сервере — 2 vCPU и 4 ГБ для VS Code или Cursor на обычном проекте, 4 vCPU и 8 ГБ для монорепозитория. JetBrains официально требует от 4 vCPU и 8 ГБ.

Swap на 2–4 ГБ ставьте всегда: сборки и языковые серверы дают короткие пики памяти, и без swap их обрывает OOM killer. NVMe заметно ускоряет всё, что работает с тысячами мелких файлов: npm install, сборки, индексацию проекта в IDE.

Один сервер или несколько

Всё на одном — нормальный старт. Бот, n8n и небольшой API уживаются на 2–4 ГБ, если на том же сервере не идут сборки.
Сборки — отдельно от продакшена. Сборка большого фронтенда легко забирает несколько гигабайт памяти и все ядра, и работающие рядом приложения начинают тормозить или падают. Раннер или build-сервер выносите на отдельную машину, в Coolify для этого есть build-серверы.
Мониторинг — отдельно от всего. Упавший сервер не пришлёт уведомление о собственном падении, поэтому Uptime Kuma держите на другом сервере, лучше в другой локации.
Эксперименты — не на продакшене. Отдельный небольшой сервер под пробы ничего не уронит, и его не жалко переустановить.
Внутренняя сеть между серверами. Приватную сеть между вашими серверами поддержка ForestsNet Cloud настраивает по запросу. По ней приложения ходят в базу и во внутренние сервисы, и те не открыты в интернет.

Трафик: что считается

В пакет тарифа ForestsNet Cloud идёт только исходящий трафик, входящий не считается. Для разработки это значит:

Бесплатно всё, что сервер скачивает: docker pull, apt, npm install, pip install, git clone и git fetch, push в ваш собственный Git-сервер, вебхуки и входящие запросы к API.
Считается всё, что сервер отдаёт: ответы API и сайтов, клоны с вашего Git-сервера, push образов во внешний реестр, выгрузка бэкапов в S3.

У CI, API и тестовых окружений исходящего обычно немного, поэтому пакета хватает с запасом. Как устроен учёт, разобрано в статье «Трафик и пропускная способность».

Подготовка сервера

Прежде чем ставить сервисы:

Настройте вход по SSH-ключу и отключите пароли — «Усиление SSH».
Закройте лишние порты файрволом — «Файрвол ufw». Docker публикует порты в обход ufw, поэтому сервисы в контейнерах привязывайте к 127.0.0.1 и выпускайте наружу через reverse proxy.
Поставьте Docker и Compose — «Docker Compose».
Добавьте swap и автоматические обновления безопасности — «Чек-лист безопасности сервера».
Направьте свой домен на сервер — A-запись, а для IPv6 ещё и AAAA — и получите сертификат: «Как привязать домен» и «Caddy», Caddy выпускает сертификаты Let's Encrypt сам.

Совет: каждому сервису — свой поддомен: n8n.example.com, git.example.com, status.example.com. Так один reverse proxy обслуживает всё, а сервисы переезжают на другой сервер сменой одной DNS-записи.

Что учесть на VPS

Снапшотов нет. Резервные копии баз и данных делайте сами и регулярно проверяйте восстановление — «Бэкапы restic», «Бэкапы баз данных» и «Расписание в cron».
Вложенная виртуализация есть. Внутри VPS можно запускать свои виртуальные машины, KVM, Firecracker и эмулятор Android. Вложенные машины работают медленнее самого VPS, поэтому для постоянной нагрузки удобнее выделенный сервер.
Администрирование на вас. Обновления ОС, Docker-образов и самих сервисов не приходят сами — заведите напоминание или включите автообновления там, где они безопасны.

Тарифы и сценарии для разработчиков собраны на странице «VPS для разработчиков».