Docker удобен, когда нужно быстро запускать сайты, API, базы данных, ботов, reverse proxy, очереди, monitoring и другие сервисы на одном сервере. Но Docker не делает слабый VPS мощным. Если неправильно выбрать ресурсы, несколько контейнеров быстро упрутся в RAM, CPU, диск, сеть или лимиты ввода-вывода.
Эта статья поможет понять, какой VPS нужен для Docker, если вы планируете запускать не один контейнер, а несколько сервисов одновременно: сайт, backend, базу данных, Redis, Nginx, worker, cron, monitoring, панель или тестовые окружения.
Почему Docker на VPS часто начинает тормозить
Основная ошибка — считать только количество контейнеров. Один легкий контейнер с Nginx может потреблять мало ресурсов, а один контейнер с PostgreSQL, Elasticsearch, Java-приложением или Next.js build-процессом может нагрузить сервер сильнее, чем десять небольших сервисов.
Проблемы обычно появляются не сразу. Сначала все запускается нормально. Потом растут логи, база данных становится больше, Docker images занимают диск, обновления требуют больше RAM, backup начинает грузить I/O, а один контейнер без лимитов забирает ресурсы у остальных.
Типичные симптомы неправильного выбора VPS под Docker:
- контейнеры периодически перезапускаются;
- сайт открывается медленно без видимой причины;
- база данных отвечает с задержкой;
- сервер зависает во время обновлений или сборки образов;
- Docker занимает слишком много места на диске;
- логи контейнеров разрастаются до нескольких гигабайт;
- при нехватке RAM система убивает процессы;
- один тяжелый контейнер мешает работе остальных;
- backup или rebuild контейнера резко нагружает диск;
- после перезагрузки не все сервисы стартуют корректно.
Главное правило: считайте не контейнеры, а сервисы
Контейнер — это форма упаковки приложения. Ресурсы потребляет не Docker как идея, а конкретный сервис внутри контейнера. Поэтому перед покупкой VPS нужно разложить проект на компоненты.
Например, небольшой сайт на Docker может включать:
- Nginx или Traefik как reverse proxy;
- PHP-FPM, Node.js, Python или Go backend;
- MySQL или PostgreSQL;
- Redis;
- cron или worker;
- контейнер для backup;
- monitoring или log collector.
Формально это уже 5–7 контейнеров. Но нагрузка у них разная. Nginx может быть почти незаметным, Redis может потреблять мало памяти на старте, а база данных станет главным потребителем RAM и диска. Поэтому VPS нужно выбирать под самый тяжелый сервис и общий запас, а не под число контейнеров в docker-compose.yml.
Минимальный VPS для Docker
Минимальный VPS под Docker подходит только для легких задач: тестового окружения, одного небольшого сайта, простого API, Telegram-бота, reverse proxy или нескольких сервисов без тяжелой базы данных.
Практический минимум:
- 1 vCPU;
- 1 GB RAM;
- 20 GB диска;
- Linux без тяжелой панели управления;
- 1 IPv4;
- порт от 1 Gb/s, если важна нормальная сеть;
- регулярная очистка Docker images, volumes и logs.
Такой сервер можно использовать для обучения, тестов и небольших production-задач с низкой нагрузкой. Но это плохой выбор, если на VPS будут база данных, несколько сайтов, Node.js-приложение, n8n, monitoring, GitLab, CI/CD или активные worker-процессы.
Оптимальный старт для нескольких контейнеров
Для реальной работы с несколькими контейнерами лучше начинать не с минимального тарифа, а с конфигурации, где есть запас по RAM и диску.
Хороший стартовый вариант:
- 2 vCPU;
- 4 GB RAM;
- 40–80 GB NVMe или SSD;
- 1 выделенный IPv4;
- 1 Gb/s порт;
- backup отдельно от основного диска;
- ограничения ресурсов для тяжелых контейнеров;
- настроенная ротация логов.
Эта конфигурация подходит для небольшого сайта с базой данных, backend-приложения, Telegram-бота с PostgreSQL, связки Nginx + app + DB + Redis, небольшого SaaS-проекта, n8n без тяжелых сценариев или нескольких легких сервисов.
VPS для Docker с базой данных
Если база данных работает в контейнере, требования к VPS нужно повышать. MySQL, MariaDB, PostgreSQL и MongoDB чувствительны к RAM, диску и стабильности I/O. На слабом VPS база может работать нормально на пустом проекте, но начать тормозить после роста данных, индексов, логов и backup-операций.
Для Docker-проекта с базой данных разумно выбирать:
- 2–4 vCPU;
- 4–8 GB RAM;
- 60–100 GB NVMe;
- отдельные volumes для данных;
- регулярные backup-копии;
- контроль размера логов;
- мониторинг RAM, I/O и свободного места;
- запас по диску минимум 30–40%.
Базу данных нельзя оценивать только по текущему размеру. Нужно учитывать рост таблиц, индексы, временные файлы, дампы, WAL/binlog, backup и логи. Если сейчас база занимает 5 GB, это не значит, что VPS с диском 20 GB будет нормальным выбором.
VPS для Docker Compose
Docker Compose часто используют на одном VPS для управления несколькими контейнерами. Это удобный вариант для малого и среднего проекта: один файл описывает приложение, базу, Redis, reverse proxy, worker и другие сервисы.
Для Docker Compose важно заранее продумать:
- какие контейнеры должны стартовать первыми;
- какие volumes хранят важные данные;
- какие порты открыты наружу;
- какие контейнеры должны быть доступны только внутри Docker-сети;
- какие сервисы требуют restart policy;
- какие контейнеры должны иметь лимиты CPU и RAM;
- где хранятся переменные окружения;
- как выполняется backup;
- как обновляются images;
- как откатиться после неудачного обновления.
Если проект коммерческий, не стоит запускать все “как получилось”. Docker Compose удобен, но хаос в compose-файле быстро превращается в проблему при первом сбое.
CPU: сколько vCPU нужно для Docker
CPU нужен не только для обработки запросов. Он также используется при сборке образов, сжатии backup, работе базы данных, выполнении worker-задач, генерации страниц, обработке изображений, cron-задачах и обновлениях.
Ориентиры по CPU:
- 1 vCPU — тесты, легкий сайт, простой бот, reverse proxy;
- 2 vCPU — небольшой production-проект, несколько контейнеров, сайт с базой данных;
- 4 vCPU — активный backend, несколько сайтов, Docker Compose с DB, Redis и worker;
- 6–8 vCPU и выше — high-load, тяжелые worker-задачи, CI/CD, аналитика, несколько активных проектов.
Важно смотреть не только на число vCPU, но и на стабильность производительности. У дешевых VPS может быть много виртуальных ядер на бумаге, но при нагрузке они работают нестабильно. Для Docker это критично, потому что несколько контейнеров могут одновременно запросить CPU.
RAM: главный ресурс для нескольких контейнеров
RAM почти всегда заканчивается раньше, чем ожидает владелец проекта. Каждый контейнер потребляет память. База данных использует кеш. Node.js, Java, Python, PHP-FPM, Redis, Elasticsearch, RabbitMQ, n8n и monitoring могут занимать заметный объем даже при умеренной нагрузке.
Ориентиры по RAM:
- 1 GB RAM — только легкие тесты или один простой сервис;
- 2 GB RAM — несколько легких контейнеров без тяжелой базы данных;
- 4 GB RAM — нормальный старт для Docker Compose с приложением, DB и Redis;
- 8 GB RAM — несколько проектов, активная база данных, workers, monitoring;
- 16 GB RAM и выше — production-нагрузка, несколько сайтов, тяжелые сервисы, аналитика, CI/CD.
Если на VPS будет база данных, не выбирайте тариф с 1 GB RAM. Он может запуститься, но стабильности не будет. Если контейнеры не имеют лимитов, один сервис может забрать память и уронить остальные процессы.
Почему важны лимиты CPU и RAM для контейнеров
По умолчанию контейнер может использовать столько ресурсов, сколько позволит ядро хоста. Это удобно на старте, но опасно в production. Один контейнер с ошибкой, memory leak или тяжелой задачей может забрать RAM и CPU у всего сервера.
Для нескольких контейнеров стоит задавать ограничения:
- лимит памяти для приложения;
- лимит CPU для worker-контейнеров;
- restart policy для критичных сервисов;
- healthcheck для проверки состояния контейнера;
- отдельные лимиты для фоновых задач;
- осторожные лимиты для базы данных, чтобы не задушить ее кеш.
Лимиты не заменяют нормальный VPS. Они только защищают сервер от ситуации, когда один контейнер ломает работу остальных.
Диск: Docker быстро занимает место
Многие недооценивают диск. Docker хранит images, layers, containers, volumes, build cache и logs. Даже если само приложение занимает мало места, через несколько месяцев сервер может заполниться старыми образами, логами и неиспользуемыми volumes.
Для Docker лучше выбирать диск с запасом:
- 20 GB — только тесты и легкие сервисы;
- 40 GB — небольшой проект без большого объема данных;
- 60–100 GB — нормальный старт для production с базой данных;
- 100–200 GB — несколько проектов, логи, backup, активная база;
- 200 GB и выше — heavy production, файлы, медиа, несколько окружений.
Если диск заполнится полностью, последствия могут быть неприятными: база данных перестанет писать данные, контейнеры не смогут стартовать, обновления сломаются, а Docker начнет выдавать ошибки при pull или build.
Логи контейнеров: скрытая причина падения VPS
Одна из частых проблем Docker на VPS — разросшиеся логи. Контейнер может писать много строк в stdout/stderr, а Docker сохраняет их на диск. Если ротация логов не настроена, один активный контейнер способен занять гигабайты.
Что нужно сделать заранее:
- настроить log rotation;
- ограничить размер логов контейнеров;
- не писать debug-логи в production без необходимости;
- регулярно проверять размер /var/lib/docker;
- не удалять Docker volumes вслепую;
- разделять application logs и system logs;
- выносить важные логи во внешний сервис, если проект критичный.
Очистка Docker должна быть аккуратной. Команды для удаления неиспользуемых images и volumes могут освободить много места, но при неправильном использовании можно удалить данные, которые нужны приложению.
NVMe или обычный SSD
Для Docker важен не только объем диска, но и скорость. NVMe особенно полезен, если на сервере есть база данных, много мелких файлов, активные логи, очереди, кеш, сборка образов или несколько приложений.
Обычный SSD может быть достаточным для легких проектов. Но если VPS используется для production, базы данных, CRM, CMS, API или нескольких контейнеров, NVMe дает более комфортную работу и снижает риск упора в I/O.
Диск становится узким местом в таких случаях:
- база данных активно пишет данные;
- контейнеры создают много логов;
- идет backup или восстановление;
- часто выполняется docker build;
- проект работает с медиафайлами;
- несколько сервисов одновременно читают и пишут данные.
Сеть: что важно для Docker на VPS
Для Docker-проектов сеть важна не меньше, чем CPU и RAM. Особенно если приложение работает с API, webhook, Telegram-ботами, платежными системами, CRM, CDN, внешними базами данных или пользователями из разных стран.
Перед заказом VPS проверьте:
- скорость порта;
- месячный лимит трафика;
- качество маршрутов до вашей аудитории;
- наличие IPv4;
- наличие IPv6, если он нужен;
- DDoS-защиту;
- правила по abuse-жалобам;
- возможность быстро увеличить ресурсы.
Для большинства Docker-проектов порт 1 Gb/s — хороший практический ориентир. Он дает запас для обновлений образов, отдачи контента, API-запросов, backup и пикового трафика.
Reverse proxy: почти обязательный элемент
Если на VPS несколько контейнеров с веб-сервисами, нужен reverse proxy. Обычно используют Nginx, Traefik или Caddy. Он принимает внешний трафик на 80/443 портах и направляет запросы в нужные контейнеры.
Reverse proxy помогает:
- разместить несколько сайтов на одном VPS;
- использовать SSL-сертификаты;
- не открывать наружу лишние порты;
- разделить сервисы по доменам;
- контролировать заголовки, редиректы и базовую защиту;
- упростить обновление отдельных контейнеров.
Без reverse proxy владельцы часто начинают открывать наружу случайные порты контейнеров. Это ухудшает безопасность и усложняет поддержку.
Docker и база данных: в контейнере или отдельно
Базу данных можно запускать в контейнере, но нужно понимать ответственность. Данные должны храниться в volume или bind mount, backup должен быть регулярным, а обновления образов нельзя делать без проверки совместимости.
Базу данных стоит выносить отдельно, если:
- проект коммерческий и критичный;
- база быстро растет;
- несколько приложений используют одну базу;
- нагрузка на запись высокая;
- нужно независимое масштабирование;
- backup и восстановление должны быть максимально надежными.
Для небольшого проекта база в Docker допустима. Для серьезного production лучше заранее планировать отдельный VPS, managed database или dedicated server.
Swap: можно ли использовать
Swap может помочь серверу пережить кратковременный скачок потребления памяти, но он не должен быть заменой нормальной RAM. Если контейнеры постоянно уходят в swap, приложение будет тормозить, база данных начнет отвечать медленно, а диск получит дополнительную нагрузку.
Swap можно использовать как страховку, но не как расчетный ресурс. Если Docker-проект стабильно использует почти всю RAM, нужно увеличивать тариф или оптимизировать контейнеры.
Backup: Docker не отменяет резервные копии
Docker упрощает запуск сервисов, но не защищает данные автоматически. Если сломался volume, удалился контейнер с данными, закончился диск или обновление испортило базу, без backup восстановление может быть невозможным.
Для Docker-проекта нужно резервировать:
- docker-compose.yml;
- .env-файлы без публикации секретов;
- volumes с данными;
- дампы баз данных;
- конфиги reverse proxy;
- SSL-сертификаты, если они не перевыпускаются автоматически;
- важные application files.
Backup лучше хранить не только на том же VPS. Если основной диск будет поврежден или сервер станет недоступен, локальная копия не спасет.
Мониторинг Docker на VPS
Без мониторинга владелец замечает проблему слишком поздно: когда сайт уже лежит, диск заполнен, база упала или контейнеры перезапускаются по кругу.
Минимально нужно следить за:
- CPU usage;
- RAM usage;
- swap usage;
- disk usage;
- размером /var/lib/docker;
- network traffic;
- block I/O;
- количеством restart у контейнеров;
- доступностью HTTP/HTTPS;
- состоянием базы данных.
Для быстрой проверки подходит docker stats. Для production лучше использовать полноценный мониторинг с историей и уведомлениями.
Как выбрать VPS под разные Docker-сценарии
Один небольшой сайт в Docker
Для одного легкого сайта, reverse proxy и небольшой базы данных можно начать с 1–2 vCPU, 2 GB RAM и 40 GB диска. Если сайт коммерческий, лучше сразу брать 2 vCPU и 4 GB RAM.
Сайт плюс база данных плюс Redis
Для связки Nginx, backend, PostgreSQL или MySQL и Redis лучше выбирать 2 vCPU, 4 GB RAM и 60–80 GB NVMe. Это нормальная база для небольшого production-проекта.
Несколько сайтов на одном VPS
Для нескольких сайтов через Docker Compose и reverse proxy лучше смотреть на 4 vCPU, 8 GB RAM и 100 GB NVMe. Если сайты активные или используют CMS, запас по RAM обязателен.
n8n, боты и automation
n8n, боты, очереди и automation-сценарии могут быть легкими на старте, но быстро растут по памяти и логам. Для такого сценария лучше начинать с 2 vCPU, 4 GB RAM и 60 GB диска. Если есть активные workflows и база данных, стоит брать 8 GB RAM.
Docker для разработки и staging
Для dev/staging можно использовать 2 vCPU, 2–4 GB RAM и 40–60 GB диска. Но если на сервере часто выполняются сборки, лучше добавить CPU и диск. Build-процессы могут быть тяжелее, чем работа готового приложения.
Production API или SaaS
Для production API, личного кабинета, SaaS или backend-сервиса лучше начинать с 4 vCPU, 8 GB RAM и 100 GB NVMe. Если база данных активная, ее лучше вынести отдельно или сразу выбрать более мощный сервер.
Когда VPS уже недостаточно
VPS подходит для старта, небольших проектов, staging, MVP, ботов, сайтов и умеренной production-нагрузки. Но если контейнеров становится много, база активно растет, трафик высокий, а CPU и RAM постоянно загружены, лучше переходить на Power VPS или dedicated server.
Переход нужен, если:
- CPU часто держится выше 70–80%;
- RAM почти всегда занята;
- сервер постоянно использует swap;
- диск заполнен больше чем на 80%;
- база данных тормозит из-за I/O;
- backup мешает работе приложения;
- контейнеры регулярно перезапускаются;
- проект стал коммерчески критичным;
- нужно больше IPv4 или отдельная сетевая схема;
- требуется предсказуемая производительность без соседей по ноде.
Чек-лист перед заказом VPS для Docker
- Посчитайте не количество контейнеров, а типы сервисов внутри них.
- Отдельно оцените базу данных, workers, build-процессы и monitoring.
- Не берите 1 GB RAM для production с базой данных.
- Для нескольких контейнеров начинайте минимум с 2 vCPU и 4 GB RAM.
- Для активного проекта смотрите на 4 vCPU и 8 GB RAM.
- Выбирайте NVMe, если есть база данных или активные логи.
- Берите диск с запасом под images, volumes, logs и backup.
- Настройте log rotation до запуска в production.
- Задайте лимиты ресурсов для тяжелых контейнеров.
- Используйте reverse proxy для нескольких веб-сервисов.
- Не открывайте наружу лишние порты контейнеров.
- Следите за /var/lib/docker и свободным местом.
- Храните backup отдельно от основного VPS.
- Проверяйте возможность быстрого апгрейда тарифа.
- Выбирайте провайдера с понятной поддержкой и стабильной сетью.
Почему xHost24 подходит для Docker-проектов
xHost24 подходит для клиентов, которым нужен VPS в Европе под Docker, сайты, backend-приложения, ботов, automation, staging, API и небольшие production-сервисы. Для Docker важны не только CPU и RAM, но и стабильная сеть, нормальный диск, выделенный IPv4, быстрый старт и возможность перейти на более мощный тариф.
В xHost24 доступны VPS и Power VPS в Европе, площадка в ДЦ Serverius, гарантированная сеть 1 Gb/s, IPv4-блоки и поддержка 24/7. Это важно для Docker-проектов, потому что несколько контейнеров на одном сервере требуют не минимального тарифа “на попробовать”, а предсказуемой инфраструктуры с запасом.
Если вы запускаете один небольшой сервис, можно начать с базового VPS. Если планируется Docker Compose с базой данных, Redis, reverse proxy и worker-контейнерами, лучше сразу выбирать тариф с запасом по RAM, CPU и диску. Посмотреть доступные варианты можно на сайте xHost24.
Как не ошибиться с выбором
Docker хорошо работает на VPS, если ресурсы выбраны с запасом и есть базовая дисциплина: лимиты контейнеров, ротация логов, мониторинг, backup и нормальная структура docker-compose.yml. Ошибка начинается там, где несколько сервисов пытаются запустить на минимальном тарифе без учета базы данных, логов, build cache и роста нагрузки.
Для легких тестов достаточно 1 vCPU и 1 GB RAM. Для нормального Docker Compose лучше начинать с 2 vCPU, 4 GB RAM и 40–80 GB диска. Для production-проекта с базой данных, worker и несколькими сервисами разумнее выбирать 4 vCPU, 8 GB RAM и NVMe-диск от 100 GB. Такой запас стоит дешевле, чем аварийная миграция после падения сервера.
