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

Etkinlik İzleyici'yi ya da Görev Yöneticisi'ni açın, küçük bir konteyner başlatın ve Docker Desktop yine de makinedeki en gürültülü şey olabilir. Şubat 2026 tarihli bir Docker Desktop sorunundabir kullanıcı, com.docker.backend.exe konteynerler başladıktan sonra %100 CPU'ya tırmandığını ve konteynerler durdurulduktan sonra bile devam ettiğini bildirdi.

Farklı bir hamle var: arka plan hizmetini dizüstünüzden tamamen alın. Yalnızca Docker CLI'yi yerelde tutun, Docker Engine'i bir Linux VPS'te çalıştırın ve docker context SSH üzerinden ona yönlendirin. docker build komutunuz değişmez. Build yalnızca başka bir yerde çalışır, VM katmanı olmadan yerel Linux üzerinde, VPS'in bant genişliği kafe Wi-Fi'niz yerine temel imajları çekerek ve takip edilecek bir Docker Desktop lisansı olmadan.

Bu, o yolun tam kurulumu: ön koşullar, tam docker context komutları, uzak bir buildx sürücüsüyle çoklu mimari build'ler, makineyi nasıl boyutlandıracağınız ve uzak yaklaşımın yanlış tercih olduğu yer.

Özetle

• Sorun: Docker Desktop yerel bir VM taşır, dosya G/Ç'sini bir sanallaştırma katmanından geçirir ve ücretli bir abonelik gerektirir daha büyük kuruluşlarda profesyonel kullanım için, Docker'ın ücretsiz kademe sınırlarının ötesindeki şirketler dahil.
• Çözüm: Docker Desktop'ı kaldırın. Docker Engine'i bir Linux VPS'te çalıştırın, ona SSH üzerinden yönlendiren bir docker context oluşturun ve yerel docker build komutunuz VPS'te çalışırken CLI'niz yalnızca düzenleme yapar.
• Maliyet çerçevesi: mütevazı bir VPS, koltuk başına lisansın yerini alır ve size yerel Linux build hızı verir. Tüm bir ekip, geliştirici başına ödemek yerine tek bir build kutusunu paylaşabilir.
• Dürüst uyarılar: VPS erişilebilir olmalıdır (uçakta build yok) ve her çalıştırmada birkaç gigabaytlık bir build bağlamı yüklememek için .dockerignore disiplinine ihtiyacınız var.

Ön koşullar: neye ihtiyacınız olacak

İlk komuttan önce şunları hazırlayın. Docker'ı zaten günlük kullanıyorsanız burada egzotik hiçbir şey yok.

• A Linux VPS root ya da sudo erişimiyle. Ubuntu 22.04/24.04 ya da Debian 12/13 hepsi iyi çalışır.
• VPS'te Docker Engine. docker context SSH üzerinden uzak ana bilgisayarda Docker Engine 18.09 ya da daha yenisine ihtiyaç duyar, Docker'ın context belgelerine göre.
• Yerelde Docker CLI 19.03 ya da daha yenisi . Üst düzey context komutunu anlayan istemci budur.
• An Bir SSH anahtar çifti. Yalnızca anahtar tabanlı kimlik doğrulama: parola kimlik doğrulaması desteklenmez için docker context SSH bağlantıları.
• Uzak docker grubundaki uzak kullanıcı docker grup, böylece her çağrıda sudo olmadan arka plan hizmeti soketiyle konuşabilir.

Docker Desktop size gerçekte neye mal olur

Maliyetler gizem değil. Üç yere iner ve yolunu arayarak buraya gelen kişi bunlardan en az birini hissetmiştir. Onları tam olarak adlandırmak asıl noktadır. Acıyı zaten biliyorsunuz.

Bellek ve VM ek yükü. Docker Desktop hâlâ yerel bir Linux VM anlamına gelir. Docker'ın ayar belgeleri Docker Desktop'ın, Docker Desktop VM'inin ne kadar bellek kullandığını sınırlayabileceğini söyler; bu da sorunun sessiz kısmıdır: döngüde hâlâ bir VM vardır. Tam ayak izi işletim sistemine ve projeye göre değişir, ama arıza biçimleri gerçektir. Bir Docker for Windows sorunu Docker Desktop'ın hiçbir konteyner çalışmazken çok sayıda gigabayt RAM tükettiğini bildirir ve bir WSL2 sorunu konteynerler sonlandıktan sonra Docker build'lerinin belleği serbest bırakmadığını anlatır. Nokta, her makinenin aynı sayıda boşta durması değildir. Docker Desktop'ın yerel VM ek yükünü geliştirme döngünüzün içinde tutmasıdır.

Build ve dosya G/Ç hızı. VM sınırını aşan bağlama noktaları ve dosya işlemleri, yerel Linux dosya sistemi erişiminden daha yavaştır. Docker'ın bilinen sorunlar belgeleri sanallaştırma dosya sistemi maliyetini kabul eder. Topluluk kıyaslamaları, VM katmanından geçen bağlama noktaları için düzenli olarak 3-10x daha yavaş civarında bir şey bildirir. Bu ikinci sayı topluluk deneyimidir, Docker'ın yayımladığı bir kıyaslama değil, ama yönü bir Mac'te bir build'in süründüğünü izlemiş hiç kimse tartışmaz.

Lisanslama. 2021 değişikliğinden bu yana Docker Desktop, 250'den fazla çalışanı olan ya da 10 milyon $'ın üzerinde geliri olan şirketler için ücretli bir abonelik gerektirir. Docker'ın fiyatlandırma sayfasındaki mevcut kademeler Personal ($0), Pro ($11/mo ya da yıllık $9), Team ($16/mo ya da yıllık $15) ve Business ($24/mo). Team kademesi Aralık 2024'te yıllık $9'dan $15'e çıktı; sessiz bir kalemi bir satın alma görüşmesine dönüştüren bir sıçrama ve otuz koltukla çarptığınızda gerçekten canını yakan kısım budur.

Alternatifler ve yerel-uzak çatallanması

Bulacağınız neredeyse her Docker Desktop alternatifi, bir yerel arka plan hizmetini bir başka yerel arka plan hizmetiyle değiştirir. Fark edilmesi gereken asıl eksen budur: çoğu insanın üzerinde kafa yorduğu seçim yerel araçlar arasındadır, oysa daha ilginç çatallanma yerel ile uzak arasındadır. VM'i makinenizden yalnızca uzak yol kaldırır.

İşte manzara, yan yana.

Bunlardan birkaçı bir cümle dürüstlüğü hak ediyor:

• OrbStack bir solo geliştirici için Mac kaynak sorununu gerçekten çözer. ~300 MB boşta ve 10x'e kadar daha hızlı konteyner başlangıcı iddia eder (OrbStack sitesi), her ikisi de satıcı rakamları, bağımsız kıyaslamalar değil. Uzak altyapı yönetmek istemeyen yalnızca Mac kullanan bir geliştiriciyseniz OrbStack daha iyi tercihtir ve ticari $8/mo kademesi (OrbStack fiyatlandırması) Docker Desktop'ın Team kademesinin altında kalır. İşin can alıcı noktası: yalnızca Mac içindir ve ticari lisans, kaçmaya çalıştığınız şeyin tam olarak geri getirir.
• Colima ücretsiz ve önce CLI'dir, ama "doğrudan yerine geçmez" pürüzleri iyi belgelenmiştir ve bazı ekipler bir geçiş tıkandıktan sonra Docker Desktop'a geri döner.
• Podman Desktop ve Rancher Desktop her ikisi de ücretsiz ve platformlar arasıdır. Hiçbiri sessiz bir yerine geçme değildir ve Podman'in Compose uyumluluğu Docker uyumlu soketinden geçer.
• Docker Offload Docker'ın kendi yönetilen uzak build/çalıştırma hizmetidir, ama Docker Desktop'tan temiz bir çıkış değildir. Mevcut Docker belgeleri onu Docker Desktop 4.68 ya da daha yenisini, bir Docker Business aboneliğini ve bir Docker Offload aboneliğini gerektiren bir şey olarak listeler. İş yüklerini Docker'ın yönettiği bulut ana bilgisayarlarında çalıştırır, ama her kullanıcı bir seferde bir Offload oturumu alır, boştaki oturumlar 5 dakikalık bir ek süreden sonra sonlanır ve ortam geçicidir; dolayısıyla oturum bittiğinde konteynerler, imajlar ve birimler kaybolur. Docker Desktop içinde yönetilen uzak kapasite istiyorsanız bu iyidir. Kendi önbelleğiniz, diskiniz, root erişiminiz olan ve Desktop bağımlılığı olmayan kalıcı bir VPS build'i ile aynı şey değildir.

Yerinde kalmak yalnızca bir durumda mantıklıdır: ücretsiz eşiğin altında, build hızı ağrısı olmayan bir birey, hiçbir şeyi değiştirmek için hiçbir nedene sahip değildir. Diğer herkesin yapacağı bir çatallanma var.

Bölümün ana çıkarımı: Önemli olan karar, hangi yerel aracı seçeceğiniz değildir. Dizüstünüzde bir arka plan hizmetini hiç tutup tutmayacağınızdır.

docker context SSH üzerinden nasıl çalışır

Uzak bir sunucuda SSH üzerinden Docker imajları oluşturmak için o sunucuda Docker Engine çalıştırın, ona işaret eden bir docker context'i docker context create name --docker "host=ssh://user@host"ile oluşturun, ardından docker context use namekomutunu çalıştırın. Bundan sonra normal docker build komutunuz uzak ana bilgisayarda çalışır ve yerel CLI yalnızca talimat gönderirken arka plan hizmeti işi yapar.

Bağlam, Docker CLI için adlandırılmış, değiştirilebilir bir hedeftir. Her seferinde ortam değişkenleriyle uğraşmak DOCKER_HOST ya da elle bir SSH tüneli kurmak yerine, uzak hedefi bir kez tanımlar ve dizin değiştirir gibi ona geçersiniz. Build tamamen uzak ana bilgisayarda çalışır: temel imaj çekimleri VPS'in yükleme bağlantısını kullanır, katmanlar VPS'in diskinde önbelleğe alınır ve CPU işi VPS'in çekirdeklerinde gerçekleşir. Gecikmeye duyarlı tek adımlar ilk SSH el sıkışması ve build bağlamınızın yüklenmesidir. Ondan sonrası uzaktadır.

VPS build kutunuzu kurma

Tüm kurulum dört kısa komut artı bir SSH yapılandırma bloğudur. Her adımın oturduğunu doğrulamanıza yardımcı olduğu yerde beklenen çıktıyı göstereceğim.

Adım 1: Docker Engine'i bir Linux VPS'e getirin. Kutuyu hazırlayın ve Docker Engine kurun (uzakta 18.09+ context SSH için alt sınırdır; yerel CLI'niz 19.03+ ister). Kurulumu kendiniz yapmak istemezseniz, onu zaten getiren bir VPS dağıtın (aşağıda daha fazlası). Uzak kullanıcı docker grubunda olmalıdır:

sudo usermod -aG docker $USER

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

Adım 2: SSH anahtar kimlik doğrulaması ve bir yapılandırma takma adı kurun. Anahtar tabanlı kimlik doğrulama zorunludur. IP'yi ve anahtar yolunu yeniden yazmamak için ana bilgisayara ~/.ssh/config içinde kısa bir takma ad verin:

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

Adım 3: Bağlamı oluşturun. Onu SSH üzerinden uzak arka plan hizmetine yönlendirin. Açık biçimi kullanın:

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

Ya da adım 2'deki SSH yapılandırma takma adını kullanarak:

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

Adım 4: Doğrulayın. Bağlamlarınızı listeleyin ve uzak motorun yanıt verdiğini kontrol edin:

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

Bu, uzak arka plan hizmetinin sunucu sürümünü yazdırırsa CLI'niz VPS ile konuşuyordur.

Adım 5: Geçin ve build alın. VPS'i etkin hedef yapın, ardından normal şekilde build alın:

docker context use my-vps

docker build -t myapp .

O build VPS'te çalışır. Global olarak geçmemeyi mi tercih edersiniz? Tek bir komutu hedefleyin:

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

Ya da onu shell oturumu için ayarlayın:

export DOCKER_CONTEXT=my-vps

Dizüstünüzün yerel arka plan hizmetini geri istediğinizde (bir tane tuttuysanız), eve dönün:

docker context use default

Profesyonel ipucu: kendi .dockerignore. Build bağlamı, build başlamadan önce uzak ana bilgisayara yüklenir. Başıboş bir node_modules or .git dizini, her çalıştırmada hat üzerinden gigabayt gönderdiğiniz anlamına gelir ve uzak yol iyi bir neden olmadan yereldenden daha yavaş hissettirir. Sıkı bir .dockerignore uzak yolun hızlı hissettirip hissettirmediğini en çok etkileyen tek şeydir: bağımlılıkları, build çıktılarını ve VCS meta verilerini hariç tutun ve yükleme bir yuvarlama hatasına dönüşür.

Uzak bir buildx sürücüsüyle çoklu mimari build'ler

Uzak Docker ana bilgisayarında bir konteyner içinde BuildKit çalıştıran bir buildx builder'ı oluşturun, ardından ona karşı build alın:

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 .

Uzak --load bayrağı tek platformlu yerel tüketim için önemlidir: docker-container sürücüsüyle, build edilen imajlar yerel imaj listenizde otomatik olarak görünmez. Gerçek bir çoklu platform imajı build ediyorsanız, onu bunun yerine bir kayıt defterine gönderin:

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

O ayrım önemlidir. Tek platformlu uzak bir build, yerel imaj deponuza geri yüklenebilir. Çoklu platform imajı genellikle bir kayıt defterine gönderilir, çünkü her hedef mimari için ayrı varyantlara sahip bir manifest listesidir. Bu bölüm isteğe bağlıdır: tüm imajlarınız tek mimariyse, yukarıdaki bağlam kurulumu işin tamamıdır.

Build kutusunu boyutlandırma ve güvenli hale getirme

İki soru, bu kutunun size iyi hizmet edip etmediğine karar verir: onu ne kadar büyük yapacağınız ve arka plan hizmetini nasıl kilitli tutacağınız. Docker build'leri CPU bağımlıdır, dolayısıyla boyutlandırma mantığı çoğunlukla çekirdekler ve swap'tan kaçınmak için yeterli RAM ile ilgilidir. Güvenlik mantığı çoğunlukla arka plan hizmetini sizden başkasına açmamakla ilgilidir.

Onu hangi boyuta ayarlamalı

Ona genel özellikler verin. Bunları sağlayıcınızın sunduğu her neyse ona eşleyebilirsiniz.

• Taban (tek geliştirici, hafif build'ler): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Aslında dağıtacağım şey (çoğu ekip): 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.
• Ekip ya da ağır CI: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Build'ler CPU bağımlı olduğu için, yüksek frekanslı (CPU için optimize edilmiş) çekirdekler size, swap eşiğinin ötesindeki ekstra RAM'den daha fazla hızlı yineleme kazandırır. GPU planları burada alakasızdır, çünkü imaj build'leri GPU'ya dokunmaz. Ve veri merkezi seçimi yalnızca SSH yanıt verme hızını ve bağlam yükleme süresini etkiler, build hızını değil: build nerede oturuyorsanız oturun VPS'te çalışır, dolayısıyla hızlı bir el sıkışma için size yakın bir konum seçin ve devam edin.

Uzak arka plan hizmetini güvenli hale getirme

Yukarıdaki kurulum doğru varsayılanı zaten zorunlu kılar: SSH anahtar kimlik doğrulaması, ağa açık hiçbir arka plan hizmeti bağlantı noktası yok. Böyle tutun. BuildKit'i ya da arka plan hizmetini SSH'ın ötesine açtığınız an (ham bir TCP uç noktası, açık bir BuildKit bağlantı noktası), bir hedef olursunuz. Hacker News başlığı yavaş build'ler üzerine, uzak VPS fikrini ilk ortaya atan, açık BuildKit uç noktalarında kripto madenciliği saldırıları konusunda da uyardı. Açık internette kimliği doğrulanmamış bir build arka plan hizmeti, ücretsiz bir hesaplama büfesidir.

Profesyonel ipucu: arka plan hizmetini açmayın. Yalnızca SSH sizin için yeterliyse (çoğu tek kutu kurulumu için yeterlidir), asla bir arka plan hizmeti TCP bağlantı noktası açmayın . Gerçekten TCP erişimine ihtiyacınız varsa, önüne karşılıklı TLS (mTLS) koyun ki yalnızca geçerli sertifikaya sahip istemciler bağlanabilsin. Yalnızca SSH ya da mTLS: internetten erişilebilir bir build kutusu için kabul edilebilir bir üçüncü seçenek yoktur.

Kutu bir kez ayağa kalktığında, genel amaçlı bir Linux sunucusudur ve üzerinde çalıştırmaya değer çok daha fazla şey vardır. indie hackerlar için self-hosted yığın rehberimiz VPS'inizde başka nelerin yer hak ettiği konusunda makul bir sonraki okumadır.

Docker Engine kurulumunu atlayıp doğrudan docker context creategitmeyi tercih ederseniz, Docker pazar yeri uygulamamız Docker Engine, Compose V2 ve buildx'in önceden yapılandırıldığı bir VPS dağıtır. Tek tıkla kutu SSH'a hazırdır, dolayısıyla yukarıdaki adım adım kılavuz adım 1 yerine adım 2'den başlar.

Sıkça Sorulan Sorular

Uzak bir sunucuda Docker build'leri çalıştırıp yerel CLI'mi kullanabilir miyim?

Evet. Docker Engine'i uzak ana bilgisayarda çalıştırın, ona SSH üzerinden işaret eden bir docker context oluşturun ve o bağlama geçin. Yerel docker build komutunuz o zaman uzak sunucuda çalışır, makinenizdeki CLI ise yalnızca düzenleme yapar, yerel bir arka plan hizmeti gerekmeden.

docker context ile DOCKER_HOST arasındaki fark nedir?

A docker context bir kez tanımlayıp docker context use. DOCKER_HOST ile seçtiğiniz adlandırılmış, değiştirilebilir, kalıcı bir hedeftir. Her shell için elle ayarlayıp kaldırdığınız tek bir ortam değişkenidir. Bağlam, tünel artı ortam değişkeni şeklindeki eski yaklaşımın modern yerine geçenidir.

docker compose uzak bir bağlamla çalışır mı?

Evet. Compose V2 etkin Docker bağlamına saygı gösterir, dolayısıyla docker compose komutları bağlamın işaret ettiği ana bilgisayara karşı çalışır. Hizmetler ve her türlü imaj build'i uzak ana bilgisayarda çalışır, tıpkı sıradan bir docker build.

Docker Offload nedir ve ücretsiz mi?

Docker Offload, Docker Desktop iş akışını korurken konteyner işini Docker'ın yönettiği bulut ana bilgisayarlarına taşımak için Docker'ın kendi yönetilen uzak build/çalıştırma hizmetidir. Mevcut Docker belgeleri onu Docker Desktop 4.68 ya da daha yenisini gerektirenbir şey olarak listeler, artı Docker Business ve Docker Offload abonelikleri. Ayrıca oturum tabanlıdır: her kullanıcı bir seferde bir Offload oturumu alır, boştaki oturumlar 5 dakikalık bir ek süreden sonra sonlanır ve uzak ortam geçicidir.

Docker Desktop'ın bu kadar çok bellek kullanmasını nasıl engellerim?

Docker Desktop'ın kaynak sınırlarını ayarlamak yalnızca hiçbir zaman sıfıra inmeyen bir ayak izini küçültür, çünkü VM'in her zaman bir tabanı vardır. Bellek maliyetini gerçekten kaldıran yol, yerel arka plan hizmetini tamamen kaldırmaktır: Docker Engine'i bir VPS'te çalıştırın ve docker context üzerinden SSH ile bağlanın, böylece makinenizde CLI'den başka hiçbir şey çalışmaz.

Bunu bunun yerine Podman ile yapabilir miyim?

Yapabilirsiniz. Podman, Docker uyumlu bir motor olarak mevcuttur ve docker context uzak bir Podman ana bilgisayarına işaret edebilir, ama bu, Podman'in Docker uyumlu soketini SSH üzerinden açığa çıkarmasını gerektirir. Komut akışı aynıdır. Uzak taraftaki kurulum farklıdır.