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

Buka Activity Monitor atau Task Manager, jalankan kontainer kecil, dan Docker Desktop masih bisa menjadi hal paling berisik di mesin. Dalam sebuah issue Docker Desktop pada Februari 2026, seorang pengguna melaporkan com.docker.backend.exe melonjak ke 100% CPU setelah kontainer dimulai, lalu terus berlanjut bahkan setelah kontainer dihentikan.

Ada langkah lain: keluarkan daemon sepenuhnya dari laptop Anda. Simpan hanya Docker CLI secara lokal, jalankan Docker Engine pada VPS Linux, dan arahkan docker context padanya melalui SSH. Perintah docker build Anda tidak berubah. Build hanya dijalankan di tempat lain, di Linux native tanpa lapisan VM, dengan bandwidth VPS menarik image dasar alih-alih Wi-Fi kafe Anda, dan tanpa lisensi Docker Desktop untuk dilacak.

Ini penyiapan lengkap untuk jalur itu: prasyarat, perintah docker context yang tepat, build multi-arch dengan driver buildx jarak jauh, cara mengukur mesin, dan di mana pendekatan jarak jauh menjadi pilihan yang salah.

TL;DR

• Masalahnya: Docker Desktop membawa VM lokal, mendorong I/O berkas melalui lapisan virtualisasi, dan memerlukan langganan berbayar untuk penggunaan profesional di organisasi yang lebih besar, termasuk perusahaan di luar batas tingkat gratis Docker.
• Perbaikannya: hapus Docker Desktop. Jalankan Docker Engine pada VPS Linux, buat sebuah docker context yang mengarah padanya melalui SSH, dan perintah docker build lokal Anda berjalan di VPS sementara CLI Anda hanya mengorkestrasi.
• Kerangka biayanya: satu VPS sederhana menggantikan lisensi per kursi dan memberi Anda kecepatan build Linux native. Satu tim penuh bisa berbagi satu kotak build alih-alih membayar per pengembang.
• Catatan jujurnya: VPS harus dapat dijangkau (tidak bisa build di pesawat), dan Anda memerlukan kedisiplinan dengan .dockerignore agar Anda tidak mengunggah konteks build bergigabyte-gigabyte pada setiap proses.

Prasyarat: apa yang Anda perlukan

Sebelum perintah pertama, siapkan hal-hal ini. Tidak ada yang eksotis di sini jika Anda sudah memakai Docker sehari-hari.

• A Linux VPS dengan akses root atau sudo. Ubuntu 22.04/24.04 atau Debian 12/13 semuanya berfungsi baik.
• Docker Engine di VPS. docker context melalui SSH memerlukan Docker Engine 18.09 atau lebih baru di host jarak jauh, sesuai dokumentasi context Docker.
• Docker CLI 19.03 atau lebih baru secara lokal. Itulah klien yang memahami perintah tingkat atas context perintah.
• An Sepasang kunci SSH. Hanya autentikasi berbasis kunci: autentikasi kata sandi tidak didukung untuk docker context koneksi SSH.
• Pengguna pengguna jarak jauh dalam grup docker grup, agar ia bisa berbicara dengan soket daemon tanpa sudo pada setiap panggilan.

Berapa sebenarnya biaya Docker Desktop bagi Anda

Biayanya bukan misteri. Mereka mendarat di tiga tempat, dan orang yang mencari jalannya ke sini telah merasakan setidaknya satu di antaranya. Menamainya secara tepat adalah intinya. Rasa sakitnya sudah Anda kenal.

Memori dan overhead VM. Docker Desktop tetap berarti sebuah VM Linux lokal. Dokumentasi pengaturan Docker mengatakan Docker Desktop bisa membatasi berapa banyak memori yang dipakai VM Docker Desktop, yang merupakan bagian senyap dari masalah: masih ada VM di dalam loop. Jejak persisnya bervariasi menurut sistem operasi dan proyek, tetapi mode-mode kegagalannya nyata. Sebuah issue Docker for Windows melaporkan Docker Desktop mengonsumsi banyak gigabyte RAM tanpa kontainer yang berjalan, dan sebuah issue WSL2 menggambarkan build Docker yang menyisakan memori tak terbebaskan setelah kontainer berhenti. Intinya bukan bahwa setiap mesin menganggur pada angka yang sama. Melainkan bahwa Docker Desktop menahan overhead VM lokal di dalam loop pengembangan Anda.

Kecepatan build dan I/O berkas. Bind mount dan operasi berkas yang melintasi batas VM lebih lambat daripada akses sistem berkas Linux native. Dokumentasi masalah yang diketahui dari Docker mengakui biaya sistem berkas virtualisasi. Benchmark komunitas secara rutin melaporkan sesuatu di kisaran 3-10x lebih lambat untuk bind mount melalui lapisan VM. Angka kedua itu adalah pengalaman komunitas, bukan benchmark yang diterbitkan Docker, tetapi arahnya tidak dibantah siapa pun yang pernah menonton sebuah build merangkak di Mac.

Lisensi. Sejak perubahan 2021, Docker Desktop memerlukan langganan berbayar bagi perusahaan dengan lebih dari 250 karyawan atau di atas $10M pendapatan. Tingkatan saat ini di halaman harga Docker adalah Personal ($0), Pro ($11/mo atau $9 per tahun), Team ($16/mo atau $15 per tahun), dan Business ($24/mo). Tingkatan Team naik dari $9 ke $15 per tahun pada Desember 2024, sebuah lompatan yang mengubah pos senyap menjadi percakapan pengadaan, yang merupakan bagian yang benar-benar terasa ketika Anda mengalikannya dengan tiga puluh kursi.

Alternatifnya dan percabangan lokal-versus-jarak-jauh

Hampir setiap alternatif Docker Desktop yang akan Anda temukan menukar satu daemon lokal dengan daemon lokal lain. Itu poros yang sebenarnya untuk diperhatikan: pilihan yang paling banyak diperdebatkan orang adalah antaralat lokal, padahal percabangan yang lebih menarik adalah lokal versus jarak jauh. Hanya jalur jarak jauh yang mengeluarkan VM dari mesin Anda.

Berikut lanskapnya, berdampingan.

Beberapa di antaranya layak mendapat satu kalimat kejujuran:

• OrbStack benar-benar memperbaiki masalah sumber daya Mac untuk pengembang solo. Ia mengklaim ~300 MB diam dan hingga 10x start kontainer lebih cepat (situs OrbStack), keduanya angka vendor, bukan benchmark independen. Jika Anda pengembang khusus Mac yang tidak ingin mengelola infrastruktur jarak jauh, OrbStack adalah pilihan yang lebih baik, dan tingkatan komersial $8/mo-nya (harga OrbStack) lebih murah daripada tingkatan Team Docker Desktop. Tangkapannya: ia khusus Mac, dan lisensi komersial membawa kembali persis hal yang Anda coba hindari.
• Colima gratis dan mengutamakan CLI, tetapi sudut-sudut kasar "bukan pengganti langsung"-nya terdokumentasi dengan baik, dan beberapa tim berakhir kembali di Docker Desktop setelah migrasi macet.
• Podman Desktop dan Rancher Desktop keduanya gratis dan lintas platform. Tidak satu pun merupakan pengganti senyap, dan kompatibilitas Compose Podman berjalan melalui soket kompatibel-Docker-nya.
• Docker Offload adalah layanan build/jalankan jarak jauh terkelola milik Docker sendiri, tetapi bukan jalan keluar yang bersih dari Docker Desktop. Dokumentasi Docker saat ini mencantumkannya sebagai sesuatu yang memerlukan Docker Desktop 4.68 atau lebih baru, langganan Docker Business, dan langganan Docker Offload. Ia menjalankan beban kerja di host cloud yang dikelola Docker, tetapi setiap pengguna mendapat satu sesi Offload sekaligus, sesi diam berakhir setelah masa tenggang 5 menit, dan lingkungannya fana, jadi kontainer, image, dan volume menghilang saat sesi berakhir. Itu baik-baik saja jika Anda ingin kapasitas jarak jauh terkelola di dalam Docker Desktop. Itu tidak sama dengan builder VPS yang persisten dengan cache, disk, akses root Anda sendiri, dan tanpa ketergantungan Desktop.

Tetap bertahan masih rasional dalam satu kasus: seorang individu di bawah ambang tingkat gratis tanpa nyeri kecepatan build tidak punya alasan untuk mengubah apa pun. Semua orang lain punya percabangan untuk dibuat.

Poin utama bagian ini: Keputusan yang penting bukanlah alat lokal mana yang dipilih. Melainkan apakah Anda menyimpan daemon di laptop Anda sama sekali.

Cara kerja docker context melalui SSH

Untuk membangun image Docker di server jarak jauh melalui SSH, jalankan Docker Engine di server itu, buat sebuah docker context yang mengarah padanya dengan docker context create name --docker "host=ssh://user@host", lalu jalankan docker context use name. Setelah itu perintah docker build normal Anda dijalankan di host jarak jauh, dan CLI lokal hanya mengirim instruksi sementara daemon melakukan pekerjaannya.

Sebuah konteks adalah target bernama dan dapat dialihkan untuk Docker CLI. Alih-alih bermain-main dengan variabel lingkungan DOCKER_HOST atau merakit terowongan SSH secara manual setiap kali, Anda mendefinisikan yang jarak jauh sekali dan beralih ke sana seperti berpindah direktori. Build dijalankan sepenuhnya di host jarak jauh: penarikan image dasar memakai uplink VPS, lapisan di-cache di disk VPS, dan pekerjaan CPU terjadi di inti VPS. Satu-satunya langkah yang sensitif terhadap latensi adalah handshake SSH awal dan pengunggahan konteks build Anda. Semua setelah itu bersifat jarak jauh.

Menyiapkan kotak build VPS Anda

Seluruh penyiapan adalah empat perintah singkat plus satu blok konfigurasi SSH. Saya akan menampilkan output yang diharapkan di tempat yang membantu Anda memastikan tiap langkah berhasil.

Langkah 1: Bawa Docker Engine ke VPS Linux. Sediakan mesinnya dan pasang Docker Engine (18.09+ di jarak jauh adalah batas bawah untuk context SSH; CLI lokal Anda butuh 19.03+). Jika Anda lebih suka tidak menjalankan instalasi sendiri, deploy VPS yang sudah menyertakannya (lebih lanjut di bawah). Pengguna jarak jauh harus berada dalam grup docker:

sudo usermod -aG docker $USER

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

Langkah 2: Siapkan autentikasi kunci SSH dan sebuah alias konfigurasi. Autentikasi berbasis kunci wajib. Beri host sebuah alias singkat di ~/.ssh/config agar Anda tidak mengetik ulang IP dan jalur kunci:

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

Langkah 3: Buat konteksnya. Arahkan ke daemon jarak jauh melalui SSH. Gunakan bentuk penuh:

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

Atau, dengan memakai alias konfigurasi SSH dari Langkah 2:

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

Langkah 4: Verifikasi. Daftarkan konteks Anda dan periksa apakah mesin jarak jauh menjawab:

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

Jika itu mencetak versi server dari daemon jarak jauh, CLI Anda sedang berbicara dengan VPS.

Langkah 5: Beralih dan build. Jadikan VPS target aktif, lalu build seperti biasa:

docker context use my-vps

docker build -t myapp .

Build itu dijalankan di VPS. Lebih suka tidak beralih secara global? Sasar satu perintah:

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

Atau setel untuk sesi shell:

export DOCKER_CONTEXT=my-vps

Ketika Anda ingin daemon lokal laptop Anda kembali (jika Anda menyimpannya), beralihlah pulang:

docker context use default

Kiat pro: perhatikan .dockerignoreAnda. Konteks build diunggah ke host jarak jauh sebelum build dimulai. Sebuah direktori node_modules or .git yang tersasar berarti Anda mengirim gigabyte melalui saluran pada setiap proses, dan jalur jarak jauh akan terasa lebih lambat daripada lokal tanpa alasan yang bagus. Sebuah .dockerignore yang ketat adalah satu hal yang paling memengaruhi apakah jalur jarak jauh terasa cepat: kecualikan dependensi, artefak build, dan metadata VCS, dan unggahan menjadi kesalahan pembulatan.

Build multi-arch dengan driver buildx jarak jauh

Buat builder buildx yang menjalankan BuildKit di dalam kontainer di host Docker jarak jauh, lalu build terhadapnya:

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 .

Pengguna --load flag penting untuk konsumsi lokal satu platform: dengan driver docker-container driver, image yang dibangun tidak muncul otomatis di daftar image lokal Anda. Jika Anda membangun image multi-platform sejati, dorong ke registry sebagai gantinya:

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

Perbedaan itu penting. Build jarak jauh satu platform bisa dimuat kembali ke penyimpanan image lokal Anda. Image multi-platform biasanya didorong ke registry, karena ia adalah daftar manifest dengan varian terpisah untuk tiap arsitektur target. Bagian ini opsional: jika semua image Anda satu-arsitektur, penyiapan konteks di atas adalah seluruh pekerjaannya.

Mengukur dan mengamankan kotak build

Dua pertanyaan menentukan apakah kotak ini melayani Anda dengan baik: seberapa besar Anda membuatnya, dan bagaimana Anda menjaga daemon terkunci. Build Docker terikat-CPU, jadi logika pengukuran sebagian besar tentang inti dan RAM yang cukup untuk menghindari swap. Logika keamanan sebagian besar tentang tidak mengekspos daemon ke siapa pun selain Anda.

Ukuran berapa yang harus disetel

Beri ia spesifikasi generik. Anda bisa memetakannya ke apa pun yang ditawarkan penyedia Anda.

• Batas bawah (satu pengembang, build ringan): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Yang benar-benar akan saya deploy (kebanyakan tim): 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.
• Tim atau CI berat: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Karena build terikat-CPU, inti berfrekuensi tinggi (dioptimalkan CPU) membeli Anda iterasi lebih cepat lebih daripada RAM tambahan di luar ambang swap. Paket GPU tidak relevan di sini, karena build image tidak menyentuh GPU. Dan pilihan pusat data hanya memengaruhi ketanggapan SSH dan waktu unggah konteks, bukan kecepatan build: build dijalankan di VPS di mana pun Anda duduk, jadi pilih lokasi yang dekat dengan Anda untuk handshake yang cekatan dan lanjutkan.

Mengamankan daemon jarak jauh

Penyiapan di atas sudah memaksa default yang benar: autentikasi kunci SSH, tidak ada porta daemon yang terekspos ke jaringan. Pertahankan begitu. Saat Anda mengekspos BuildKit atau daemon di luar SSH (endpoint TCP mentah, porta BuildKit terbuka), Anda menjadi target. Hacker News tentang build lambat yang pertama memunculkan ide VPS jarak jauh juga memperingatkan tentang serangan cryptomining pada endpoint BuildKit yang terekspos. Daemon build tak terautentikasi di internet terbuka adalah bufet komputasi gratis.

Kiat pro: jangan ekspos daemon. Jika SSH-saja sudah cukup bagi Anda (cukup untuk kebanyakan penyiapan satu kotak), jangan pernah membuka porta TCP daemon . Jika Anda benar-benar butuh akses TCP, taruh TLS mutual (mTLS) di depannya agar hanya klien dengan sertifikat sah yang bisa terhubung. SSH-saja atau mTLS: tidak ada opsi ketiga yang dapat diterima untuk kotak build yang dapat dijangkau dari internet.

Begitu kotaknya menyala, ia adalah server Linux serbaguna, dan ada banyak hal lain yang layak dijalankan padanya. panduan tumpukan self-hosted untuk indie hacker kami adalah bacaan lanjutan yang masuk akal tentang apa lagi yang layak mendapat tempat di VPS Anda.

Jika Anda lebih suka melewati instalasi Docker Engine dan langsung ke docker context create, aplikasi Docker marketplace kami men-deploy VPS dengan Docker Engine, Compose V2, dan buildx yang sudah dikonfigurasi. Satu klik dan kotaknya siap-SSH, jadi panduan di atas dimulai dari Langkah 2 alih-alih Langkah 1.

Pertanyaan yang Sering Diajukan

Bisakah saya menjalankan build Docker di server jarak jauh dan memakai CLI lokal saya?

Ya. Jalankan Docker Engine di host jarak jauh, buat sebuah docker context yang mengarah padanya melalui SSH, dan beralih ke konteks itu. Perintah docker build lokal Anda kemudian dijalankan di server jarak jauh sementara CLI di mesin Anda hanya mengorkestrasi, tanpa daemon lokal yang diperlukan.

Apa perbedaan antara docker context dan DOCKER_HOST?

A docker context adalah target bernama, dapat dialihkan, dan persisten yang Anda definisikan sekali dan pilih dengan docker context use. DOCKER_HOST adalah satu variabel lingkungan yang Anda setel dan hapus secara manual untuk tiap shell. Konteks adalah pengganti modern dari pendekatan terowongan-plus-variabel-lingkungan lama.

Apakah docker compose berfungsi dengan konteks jarak jauh?

Ya. Compose V2 menghormati konteks Docker aktif, jadi perintah docker compose dijalankan terhadap host yang ditunjuk konteks. Layanan dan build image apa pun dijalankan di host jarak jauh, sama seperti docker build.

Apa itu Docker Offload dan apakah gratis?

Docker Offload adalah layanan build/jalankan jarak jauh terkelola milik Docker sendiri untuk memindahkan pekerjaan kontainer ke host cloud yang dikelola Docker sambil mempertahankan alur kerja Docker Desktop. Dokumentasi Docker saat ini mencantumkannya sebagai sesuatu yang memerlukan Docker Desktop 4.68 atau lebih baru, plus langganan Docker Business dan Docker Offload. Ia juga berbasis sesi: setiap pengguna mendapat satu sesi Offload sekaligus, sesi diam berakhir setelah masa tenggang 5 menit, dan lingkungan jarak jauhnya fana.

Bagaimana cara menghentikan Docker Desktop memakai memori sebanyak itu?

Menyetel batas sumber daya Docker Desktop hanya mengecilkan jejak yang tak pernah mencapai nol, karena VM selalu punya lantai. Jalur yang benar-benar menghapus biaya memori adalah menghapus daemon lokal sepenuhnya: jalankan Docker Engine di VPS dan sambungkan via docker context melalui SSH, agar tidak ada yang berjalan di mesin Anda selain CLI.

Bisakah saya melakukan ini dengan Podman saja?

Bisa. Podman tersedia sebagai mesin yang kompatibel dengan Docker, dan docker context bisa mengarah ke host Podman jarak jauh, tetapi itu memerlukan Podman untuk mengekspos soket kompatibel-Docker-nya melalui SSH. Alur perintahnya sama. Penyiapan di sisi jarak jauh berbeda.