Рано или поздно почти каждый фрилансер сталкивается с одинаковой проблемой. Проектов становится слишком много.
Один сайт для клиента А, второй — API для клиента Б, третий — старый WordPress, который «нужно иногда править», четвёртый — тестовый стенд под новый заказ. Каждый со своим доменом, своей базой, своими версиями PHP или Node.
Сначала всё это живёт на разных хостингах. Потом появляются VPS. Потом на одном сервере висит пять проектов, на другом — ещё семь, и в какой-то момент ты уже не помнишь, где что запущено и почему один сайт слушает порт 8083.
В этой статье я разберу практическую схему, как фрилансеру организовать один Docker VPS так, чтобы на нём спокойно жили 20 и больше проектов: с доменами, SSL, изоляцией, нормальной структурой и без постоянного бардака в портах и конфигурациях.
Типичная боль: проекты растут быстрее, чем инфраструктура
На старте всё просто. Один проект — один хостинг. Или один проект — один VPS.
Но фриланс редко развивается линейно. Проекты появляются, исчезают, возвращаются через полгода. Кто-то просит тестовый домен. Кто-то хочет временный стенд. Кто-то платит за поддержку, но почти не пишет.
В результате у тебя:
- несколько серверов у разных провайдеров;
- разные панели и пароли;
- проекты, про которые ты уже не помнишь, где живут;
- десятки портов, которые проброшены «временно»;
- SSL-сертификаты, которые истекают неожиданно.
Это не вопрос аккуратности. Это естественный итог роста без системы.
Идея, которая всё меняет: один мощный VPS вместо десяти маленьких
В какой-то момент приходит простая мысль: а что если держать не десять разных хостингов, а один нормальный сервер, на котором живут все проекты?
Не в виде десятка папок в Apache, а в виде отдельных контейнеров:
- каждый проект — отдельный стек;
- своя база;
- свои тома;
- свой домен;
- свой lifecycle.
И вот тут Docker начинает работать не как «модная технология», а как способ привести хаос в порядок.
Ключевой элемент: reverse proxy вместо портов
Самая большая ошибка начинающих — развешивать проекты по портам.
8081 — проект А 8082 — проект Б 8083 — тест 8084 — ещё что-то
Через месяц ты уже не помнишь, что где слушает. SSL превращается в кошмар. Давать клиенту ссылку с портом выглядит странно.
Решение простое и давно известное: reverse proxy.
Один вход (80/443), и дальше прокси сам разводит запросы по доменам:
- site1.com → контейнер №1
- api.site2.com → контейнер №2
- test.client3.net → контейнер №3
Самые популярные варианты:
- Traefik
- Nginx Proxy Manager
- классический nginx с ручной конфигурацией
Минимальный пример проксирования домена к контейнеру
Чтобы схема не выглядела абстрактно, вот максимально простой пример конфигурации nginx, который проксирует домен на контейнер с приложением:
server {
listen 80;
server_name client1.com;
location / {
proxy_pass http://web_client1:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
В Docker это обычно работает через общую сеть: контейнер с proxy видит контейнеры проектов по именам. Домены разводятся не портами, а правилами маршрутизации.
Traefik и Nginx Proxy Manager делают то же самое, только управляют этим через labels или веб-интерфейс и автоматически выпускают SSL.
Базовая архитектура одного «фриланс-сервера»
Практическая схема выглядит так:
- Один VPS с Docker
- Один reverse proxy контейнер (Traefik или NPM)
- Отдельный docker-stack на каждый проект
- Одна общая сеть для прокси + проекты
Снаружи:
- сервер слушает только 80 и 443
- все домены приходят в proxy
- proxy отправляет запросы нужному контейнеру
Ни одного торчащего порта. Ни одного ручного виртуального хоста.
Что это даёт фрилансеру на практике
1. Все проекты в одном месте
Ты знаешь, где живёт каждый проект. Один сервер. Одна точка входа. Одна схема.
2. Экономия денег
Вместо десятка разрозненных аккаунтов ты держишь один нормальный сервер с запасом ресурсов.
На практике один VPS часто заменяет 8–10 мелких хостингов без потери гибкости.
3. Проекты не мешают друг другу
Каждый стек изолирован:
- своя версия интерпретатора;
- своя база;
- свои тома;
- свои обновления.
Это сильно снижает шанс случайно «уронить» соседний проект.
Почему скорость диска начинает играть роль
Когда на сервере живёт два контейнера, разницы почти не видно. Но когда проектов становится 15–20, начинают работать другие законы.
Базы активно пишут в диск. Логи постоянно обновляются. Контейнеры создают и удаляют файлы.
И тут медленный диск превращается в узкое место. Контейнеры вроде бы запущены, но всё начинает «подвисать» без явной причины.
Именно поэтому в таких схемах важны быстрые NVMe-диски. Например, у Docker VPS от UkrLine используют NVMe-накопители, что хорошо ощущается именно при большом количестве контейнеров: базы отвечают стабильнее, сборки идут быстрее, меньше странных задержек.
Это не про бренд. Это про физику: когда проектов много, I/O начинает решать.
Ограничения и честные минусы
Эта схема подходит не всем.
- Нужна дисциплина в конфигурациях
- Нужно понимать сеть Docker и proxy
- Один сервер — одна точка отказа (без бекапов нельзя)
Но если проектов действительно много, альтернатива почти всегда хуже: десятки хаотичных аккаунтов и серверов без общей системы.
Чеклист фрилансера
- Больше 5–7 активных проектов
- Часто нужны тестовые домены
- Проекты на разных стеках
- Хочется меньше платить за хостинг
- Хочется перестать помнить, где что запущено
В этом случае один грамотно настроенный Docker VPS часто упрощает жизнь сильнее, чем любые панели.
Не потому что Docker магический. А потому что система наконец появляется там, где раньше был набор случайных решений.