Как подобрать VPS для разработки и тестирования

Для кого эта задача

Отдельный dev-сервер удобен, чтобы разворачивать тестовые сборки, демонстрировать проекты заказчику, запускать Docker-окружения и не нагружать локальную машину.

Гайд — про универсальный сервер для разработки, staging-стендов и небольших внутренних сервисов.

Минимальные и рекомендуемые ресурсы

Минимум: 1 vCPU, 2 ГБ RAM, 20 ГБ SSD — для одного небольшого приложения или пары контейнеров.

Рекомендуется: 2 vCPU, 4 ГБ RAM, 40 ГБ SSD — комфортно для Docker Compose с несколькими сервисами и базой.

Если планируете собирать образы и держать много контейнеров — закладывайте RAM и диск с запасом.

На что обратить внимание

RAM под контейнеры. Каждый сервис (БД, кэш, приложение) ест память — 4 ГБ дают заметно больше свободы, чем 2 ГБ.

Диск под образы. Docker-образы и логи быстро занимают место; SSD от 40 ГБ снимает эту головную боль.

Регион. RU — ниже пинг при работе из России; EU — если тестируете доступ из-за рубежа или используете зарубежные сервисы.

Root-доступ. Нужен любой полноценный VPS — на shared-хостинге Docker и системные настройки недоступны.

Один сервер под несколько окружений

Соблазн держать на одном сервере и staging, и демо для заказчика, и личные эксперименты понятен: так дешевле. Работает это до первого случая, когда эксперимент кладёт машину в момент демонстрации.

Разумный компромисс — разделять окружения контейнерами и ограничивать их по памяти и процессору. Тогда сбой одного сервиса не утягивает остальные, а вы видите, кто сколько потребляет.

Продакшен на одной машине с dev-стендом держать не стоит вовсе: разница в цене между двумя серверами меньше, чем стоимость одного простоя.

Доступ и безопасность стенда

Dev-сервер обычно смотрит в интернет и при этом настроен небрежнее продакшена: открытые порты баз данных, отладочные панели, тестовые учётные записи с простыми паролями. Это делает его удобной точкой входа.

Минимум, который стоит сделать сразу: вход по ключу вместо пароля, закрытые наружу порты служебных сервисов, доступ к панелям только через SSH-туннель или VPN.

И отдельно про данные: копия боевой базы на открытом стенде — это утечка, которая ждёт своего часа. Для тестов используйте обезличенные данные.

Место под сборки и логи

Диск на dev-сервере заканчивается предсказуемо: образы контейнеров, кэши пакетных менеджеров, логи и артефакты сборок накапливаются постоянно, а удаляет их редко кто.

Настройте ротацию логов и регулярную очистку неиспользуемых образов с самого начала — это пять минут работы, которые экономят вечер отладки «почему всё сломалось».

Если собираете образы на этом же сервере, закладывайте кратный запас: промежуточные слои занимают заметно больше, чем итоговый образ.

Типичные ошибки

Брать 1 ГБ RAM под Docker Compose — сборки и несколько контейнеров упрутся в память.

Забыть про место под образы и логи — диск закончится в самый неподходящий момент.

Держать секреты и продовые данные на открытом dev-стенде без ограничений доступа.

Частые вопросы