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. Потік команд той самий. Налаштування на віддаленому боці відрізняється.