Stop Running Docker Desktop: Offload Your Builds to a VPS Instead

Откройте «Мониторинг системы» или «Диспетчер задач», запустите небольшой контейнер, и Docker Desktop всё равно может стать самым шумным на машине. В issue Docker Desktop за февраль 2026 годапользователь сообщил, что com.docker.backend.exe поднимался до 100 % CPU после запуска контейнеров, а затем продолжал даже после их остановки.

Есть другой ход: уберите демон с вашего ноутбука полностью. Держите локально только Docker CLI, запускайте Docker Engine на Linux VPS и направьте на него docker context по SSH. Ваша команда docker build не меняется. Сборка просто выполняется в другом месте, на нативном Linux без слоя VM, где пропускная способность VPS тянет базовые образы вместо вашего кафейного Wi-Fi, и без лицензии Docker Desktop, которую нужно отслеживать.

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

Кратко (TL;DR)

• Проблема: Docker Desktop тащит локальную VM, проталкивает файловый ввод-вывод через слой виртуализации и требует платную подписку для профессионального использования в более крупных организациях, включая компании за пределами лимитов бесплатного уровня Docker.
• Решение: удалите Docker Desktop. Запустите Docker Engine на Linux VPS, создайте docker context который указывает на него по SSH, и ваша локальная команда docker build выполняется на VPS, пока ваш CLI лишь оркеструет.
• Рамка затрат: один скромный VPS заменяет лицензию на место и даёт вам нативную скорость сборки Linux. Целая команда может делить одну сборочную машину вместо оплаты за каждого разработчика.
• Честные оговорки: VPS должен быть достижим (никакой сборки в самолёте), и вам нужна дисциплина с .dockerignore чтобы не загружать многогигабайтный контекст сборки при каждом прогоне.

Предварительные условия: что вам понадобится

Перед первой командой выстройте это в ряд. Ничего экзотического здесь нет, если вы уже пользуетесь Docker ежедневно.

• A Linux VPS с доступом root или sudo. Ubuntu 22.04/24.04 или Debian 12/13 все прекрасно подходят.
• Docker Engine на VPS. docker context по SSH требует Docker Engine 18.09 или новее на удалённом хосте, согласно документации по context Docker.
• Docker CLI 19.03 или новее локально. Это клиент, который понимает команду верхнего уровня context команду.
• An Пара SSH-ключей. Только аутентификация по ключу: парольная аутентификация не поддерживается для docker context SSH-соединений.
• Удалённый удалённый пользователь в группе docker группа, чтобы он мог общаться с сокетом демона без sudo при каждом вызове.

Во что на самом деле обходится вам Docker Desktop

Затраты не загадка. Они приземляются в трёх местах, и тот, кто искал сюда дорогу, ощутил хотя бы одно из них. Точно их назвать в этом и суть. Боль вы уже знаете.

Память и накладные расходы VM. Docker Desktop по-прежнему означает локальную Linux VM. документация по настройкам Docker говорит, что Docker Desktop может ограничивать, сколько памяти использует VM Docker Desktop — это тихая часть проблемы: в цикле по-прежнему есть VM. Точный след меняется в зависимости от ОС и проекта, но режимы сбоя реальны. issue Docker for Windows сообщает, что Docker Desktop потребляет много гигабайт RAM без единого запущенного контейнера, а issue WSL2 описывает сборки Docker, оставляющие память неосвобождённой после завершения контейнеров. Суть не в том, что каждая машина простаивает на одном и том же числе. А в том, что Docker Desktop держит накладные расходы локальной VM внутри вашего цикла разработки.

Скорость сборки и файлового ввода-вывода. Bind-монтирования и файловые операции, пересекающие границу VM, медленнее, чем нативный доступ к файловой системе Linux. документация по известным проблемам Docker признаёт стоимость файловой системы виртуализации. Бенчмарки сообщества регулярно сообщают о чём-то в диапазоне 3-10x медленнее для bind-монтирований через слой VM. Это второе число это опыт сообщества, а не опубликованный Docker бенчмарк, но направление не оспаривает никто, кто видел, как сборка еле ползёт на Mac.

Лицензирование. С момента изменения 2021 года Docker Desktop требует платную подписку для компаний с более чем 250 сотрудниками или свыше 10 млн $ выручки. Текущие уровни на странице цен Docker это Personal ($0), Pro ($11/mo или $9 в год), Team ($16/mo или $15 в год) и Business ($24/mo). Уровень Team вырос с $9 до $15 в год в декабре 2024 года — скачок, превращающий тихую статью расходов в разговор с закупками, и это та часть, которая по-настоящему жжёт, когда вы умножаете её на тридцать мест.

Альтернативы и развилка локальное против удалённого

Почти каждая альтернатива Docker Desktop, которую вы найдёте, меняет один локальный демон на другой локальный демон. Вот настоящая ось, которую стоит заметить: выбор, над которым большинство мучается, лежит между локальными инструментами, тогда как более интересная развилка это локальное против удалённого. Только удалённый путь убирает VM с вашей машины.

Вот ландшафт, бок о бок.

Некоторые из них заслуживают одного предложения честности:

• OrbStack действительно решает проблему ресурсов на Mac для разработчика-одиночки. Он заявляет ~300 MB в простое и до 10x более быстрый старт контейнеров (сайт OrbStack), оба числа вендорские, а не независимые бенчмарки. Если вы разработчик только на Mac, который не хочет управлять удалённой инфраструктурой, OrbStack лучший выбор, а его коммерческий уровень $8/mo (цены OrbStack) дешевле уровня Team у Docker Desktop. Загвоздка: он только для Mac, а коммерческая лицензия возвращает ровно то, от чего вы пытались уйти.
• Colima бесплатен и ориентирован на CLI, но его шероховатости «не прямая замена» хорошо задокументированы, и некоторые команды возвращаются к Docker Desktop после того, как миграция застревает.
• Podman Desktop и Rancher Desktop оба бесплатны и кроссплатформенны. Ни один не является тихой заменой, и совместимость Podman с Compose идёт через его Docker-совместимый сокет.
• Docker Offload это собственный управляемый сервис Docker для удалённой сборки/запуска, но это не чистый выход из Docker Desktop. Текущая документация Docker перечисляет его как требующий Docker Desktop 4.68 или новее, подписку Docker Business и подписку Docker Offload. Он выполняет нагрузки на управляемых Docker облачных хостах, но каждый пользователь получает по одной сессии Offload за раз, простаивающие сессии завершаются после 5-минутного льготного периода, а среда эфемерна, так что контейнеры, образы и тома исчезают, когда сессия заканчивается. Это нормально, если вам нужна управляемая удалённая мощность внутри Docker Desktop. Это не то же самое, что постоянный VPS-сборщик с вашим собственным кэшем, диском, root-доступом и без зависимости от Desktop.

Остаться на месте всё ещё рационально в одном случае: у одного человека ниже бесплатного порога без боли от скорости сборки нет причины что-либо менять. У всех остальных есть развилка, которую нужно пройти.

Ключевой вывод раздела: Решение, которое имеет значение, не в том, какой локальный инструмент выбрать. А в том, держите ли вы вообще демон на своём ноутбуке.

Как docker context работает по SSH

Чтобы собирать образы Docker на удалённом сервере по SSH, запустите Docker Engine на этом сервере, создайте docker context, указывающий на него, с помощью docker context create name --docker "host=ssh://user@host", затем выполните docker context use name. После этого ваша обычная команда docker build выполняется на удалённом хосте, а локальный CLI лишь отправляет инструкции, пока демон делает работу.

Контекст это именованная переключаемая цель для Docker CLI. Вместо того чтобы жонглировать переменными окружения DOCKER_HOST или вручную городить SSH-туннель каждый раз, вы определяете удалённое один раз и переключаетесь на него, как меняете каталог. Сборка выполняется целиком на удалённом хосте: скачивание базовых образов использует аплинк VPS, слои кэшируются на диске VPS, а работа CPU происходит на ядрах VPS. Единственные чувствительные к задержке шаги это начальное SSH-рукопожатие и загрузка вашего контекста сборки. Всё после этого удалённо.

Настройка вашей сборочной машины VPS

Вся настройка это четыре короткие команды плюс блок конфигурации SSH. Я покажу ожидаемый вывод там, где он помогает вам подтвердить, что каждый шаг сел.

Шаг 1: Доставьте Docker Engine на Linux VPS. Подготовьте машину и установите Docker Engine (18.09+ на удалённом это нижний порог для context SSH; вашему локальному CLI нужен 19.03+). Если вы предпочитаете не запускать установку сами, разверните VPS, который уже поставляется с ним (об этом ниже). Удалённый пользователь должен быть в группе docker:

sudo usermod -aG docker $USER

# log out and back in for the group change to take effect

Шаг 2: Настройте аутентификацию по SSH-ключу и псевдоним конфигурации. Аутентификация по ключу обязательна. Дайте хосту короткий псевдоним в ~/.ssh/config чтобы не перепечатывать IP и путь к ключу:

# ~/.ssh/config
Host my-vps
  HostName 1.2.3.4
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Шаг 3: Создайте контекст. Направьте его на удалённый демон по SSH. Используйте развёрнутую форму:

docker context create my-vps --docker "host=ssh://[email protected]"

Или, используя псевдоним конфигурации SSH из шага 2:

docker context create my-vps --docker "host=ssh://my-vps"

Шаг 4: Проверьте. Перечислите свои контексты и проверьте, что удалённый движок отвечает:

docker context ls

NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
my-vps                                                ssh://my-vps

docker --context=my-vps version

Если это выводит версию сервера удалённого демона, ваш CLI разговаривает с VPS.

Шаг 5: Переключитесь и соберите. Сделайте VPS активной целью, затем собирайте как обычно:

docker context use my-vps

docker build -t myapp .

Эта сборка выполняется на VPS. Предпочитаете не переключаться глобально? Нацельтесь на одну команду:

docker --context=my-vps build -t myapp .

Или задайте это для сессии оболочки:

export DOCKER_CONTEXT=my-vps

Когда вы захотите вернуть локальный демон своего ноутбука (если вы его оставили), переключитесь домой:

docker context use default

Совет: следите за своим .dockerignore. Контекст сборки загружается на удалённый хост до начала сборки. Затесавшийся каталог node_modules or .git означает, что вы отправляете гигабайты по проводу при каждом прогоне, и удалённый путь будет ощущаться медленнее локального без всякой причины. Плотный .dockerignore это единственное, что сильнее всего влияет на то, ощущается ли удалённый путь быстрым: исключите зависимости, артефакты сборки и метаданные VCS, и загрузка становится ошибкой округления.

Мультиархитектурные сборки с удалённым драйвером buildx

Создайте buildx-сборщик, который запускает BuildKit внутри контейнера на удалённом Docker-хосте, затем собирайте против него:

docker buildx create --name remote-builder \
  --driver docker-container \
  --use \
  ssh://ubuntu@your-vps-ip

docker buildx inspect --bootstrap

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64 \
  -t myapp:latest \
  --load .

Удалённый --load флаг важен для локального потребления на одной платформе: с драйвером docker-container driver, собранные образы не появляются автоматически в вашем локальном списке образов. Если вы собираете настоящий мультиплатформенный образ, вместо этого отправьте его в реестр:

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/myapp:latest \
  --push .

Это различие важно. Удалённую сборку на одной платформе можно загрузить обратно в ваше локальное хранилище образов. Мультиплатформенный образ обычно отправляется в реестр, потому что это список манифестов с отдельными вариантами для каждой целевой архитектуры. Этот раздел необязателен: если все ваши образы одноархитектурные, настройка контекста выше это вся работа.

Определение размера и защита сборочной машины

Два вопроса решают, хорошо ли служит вам эта машина: насколько большой её сделать и как держать демон запертым. Сборки Docker привязаны к CPU, так что логика определения размера в основном о ядрах и достаточной RAM, чтобы избежать свопа. Логика безопасности в основном о том, чтобы не выставлять демон никому, кроме вас.

На какой размер её настроить

Дайте ей общие характеристики. Вы можете сопоставить их с тем, что предлагает ваш провайдер.

• Нижняя граница (один разработчик, лёгкие сборки): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Что я бы на самом деле развернул (для большинства команд): 4 vCPU / 8-12 GB RAM / 240-300 GB NVMe. Four vCPUs stop your parallel build steps from serializing, 8-12 GB handles concurrent builds without touching swap, and the NVMe headroom keeps a healthy layer cache.
• Команда или тяжёлый CI: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Поскольку сборки привязаны к CPU, высокочастотные (оптимизированные под CPU) ядра покупают вам более быструю итерацию сильнее, чем дополнительная RAM за порогом свопа. GPU-планы здесь неуместны, поскольку сборки образов не задействуют GPU. А выбор дата-центра влияет только на отзывчивость SSH и время загрузки контекста, а не на скорость сборки: сборка выполняется на VPS независимо от того, где вы сидите, так что выбирайте местоположение поближе к себе ради шустрого рукопожатия и двигайтесь дальше.

Защита удалённого демона

Настройка выше уже навязывает правильное значение по умолчанию: аутентификация по SSH-ключу, ни один порт демона не выставлен в сеть. Держите так. В тот момент, когда вы выставляете BuildKit или демон за пределы SSH (сырой TCP-эндпоинт, открытый порт BuildKit), вы становитесь целью. ветка на Hacker News о медленных сборках, впервые поднявший идею удалённого VPS, также предупреждал об атаках криптомайнинга на выставленные эндпоинты BuildKit. Неаутентифицированный сборочный демон в открытом интернете это бесплатный вычислительный буфет.

Совет: не выставляйте демон. Если вам достаточно только SSH (достаточно для большинства однокоробочных настроек), никогда не открывайте TCP-порт демона . Если вам действительно нужен TCP-доступ, поставьте перед ним взаимный TLS (mTLS), чтобы подключаться могли только клиенты с действительным сертификатом. Только SSH или mTLS: приемлемого третьего варианта для сборочной машины, достижимой из интернета, нет.

Как только машина поднята, это Linux-сервер общего назначения, и на нём стоит запускать ещё много чего. Наше руководство по self-hosted стеку для инди-хакеров разумное следующее чтение о том, что ещё заслуживает места на вашем VPS.

Если вы предпочитаете пропустить установку Docker Engine и сразу перейти к docker context create, наше приложение Docker из маркетплейса разворачивает VPS с уже настроенными Docker Engine, Compose V2 и buildx. Один клик, и машина готова к SSH, так что прохождение выше начинается с шага 2 вместо шага 1.

Часто задаваемые вопросы

Могу ли я запускать сборки Docker на удалённом сервере и использовать свой локальный CLI?

Да. Запустите Docker Engine на удалённом хосте, создайте docker context указывающий на него по SSH, и переключитесь на этот контекст. Ваша локальная команда docker build тогда выполняется на удалённом сервере, пока CLI на вашей машине лишь оркеструет, без необходимости в локальном демоне.

В чём разница между docker context и DOCKER_HOST?

A docker context это именованная переключаемая постоянная цель, которую вы определяете один раз и выбираете с помощью docker context use. DOCKER_HOST это единственная переменная окружения, которую вы вручную устанавливаете и снимаете для каждой оболочки. Контекст это современная замена старому подходу «туннель плюс переменная окружения».

Работает ли docker compose с удалённым контекстом?

Да. Compose V2 учитывает активный контекст Docker, так что команды docker compose выполняются против хоста, на который указывает контекст. Сервисы и любые сборки образов выполняются на удалённом хосте, так же как обычная docker build.

Что такое Docker Offload и бесплатен ли он?

Docker Offload это собственный управляемый сервис Docker для удалённой сборки/запуска, переносящий работу с контейнерами на управляемые Docker облачные хосты, сохраняя при этом рабочий процесс Docker Desktop. Текущая документация Docker перечисляет его как требующий Docker Desktop 4.68 или новее, плюс подписки Docker Business и Docker Offload. Он также основан на сессиях: каждый пользователь получает по одной сессии Offload за раз, простаивающие сессии завершаются после 5-минутного льготного периода, а удалённая среда эфемерна.

Как остановить Docker Desktop от использования такого объёма памяти?

Настройка лимитов ресурсов Docker Desktop лишь уменьшает след, который никогда не доходит до нуля, потому что у VM всегда есть пол. Путь, который действительно устраняет затраты на память, это полностью убрать локальный демон: запустите Docker Engine на VPS и подключайтесь через docker context по SSH, чтобы на вашей машине не работало ничего, кроме CLI.

Могу ли я сделать это с Podman вместо этого?

Можете. Podman доступен как Docker-совместимый движок, и docker context может указывать на удалённый Podman-хост, но это требует, чтобы Podman выставил свой Docker-совместимый сокет по SSH. Поток команд тот же. Настройка на удалённой стороне отличается.