WSL mi VPS mi: Geliştirme Ortamı Seçimi

Geliştirme ortamı için WSL mi yoksa VPS mi kullanılmalı?

Geliştirme sürecinde WSL ile VPS arasındaki seçim tek bir özelliğe dayanır: erişilebilirlik. WSL (Windows Subsystem for Linux), Windows oturumunuzla birlikte başlayıp biten bir sanal makine içinde Ubuntu çalıştırır. VPS (sanal özel sunucu) ise aynı Ubuntu işletim sistemini, dizüstü bilgisayarınız kapalıyken bile çalışmaya devam eden ve genel bir IP adresine sahip olan bir makinede barındırır. Çoğu geliştirici, sunucuyu her zaman ulaşılabilir bir makine olarak kullanarak her iki yöntemi de tercih eder.

İşletim sistemi ilginç bir fark oluşturmaz, çünkü her ikisi de Ubuntu'dur. Farklılıklar; çalışma süresi (uptime), internet üzerinden erişilebilirlik, systemd'nin sağlayabildiği olanaklar, dosya sistemi hızı, ağ davranışları ve yedekleme sorumluluğunun kimde olduğu noktalarında ortaya çıkar. Aşağıdaki her bölüm, kendi makinenizde gözlemleyebileceğiniz bir farkı ele almaktadır.

Dizüstü bilgisayarı kapattığımda WSL neden duruyor?

WSL 2, Windows'un talep üzerine başlattığı hafif bir sanal makine içerisinde gerçek bir Linux çekirdeği çalıştırır. Bu sanal makine yalnızca bir dağıtım çalışırken var olur ve bir dağıtım da yalnızca bir şey onu kullandığında çalışır. Durumu PowerShell üzerinden kontrol edin:

wsl --version
wsl --list --running

Tüm WSL terminallerini kapatın, bir dakika bekleyin ve ardından wsl --list --running komutunu tekrar çalıştırın. Çalışan hiçbir dağıtım olmadığını bildirdiğinde, başlattığınız kabuk ve onun çalıştırdığı her şey sonlanmış demektir. wsl --shutdown komutu aynı işlemi anında gerçekleştirir; bu, kurulumunuzun yeniden başlatma sonrasında nasıl tepki verdiğini test etmek için yararlı bir yoldur.

Uyku ve hazırda bekletme modları da sanal makineyi durdurur. Saat 03:00'te veritabanı dökümü almak için ayarlanan bir zamanlayıcı, kapak kapalıyken çalışmaz; çünkü onu çalıştıracak çekirdek o sırada yürütülmemektedir. Hiçbir şey hata günlüğü oluşturmaz, bu nedenle görev hiç planlanmamış gibi görünür. İnsanları ikinci bir makineye yönlendiren temel davranış budur: bir derleme kuyruğu, sohbet botu, gece yedeklemesi veya webhook alıcısı, sürekli açık kalan bir bilgisayara ihtiyaç duyar.

systemd WSL üzerinde çalışır mı?

Evet. Destek WSL 0.67.6 sürümüyle gelmiştir ve eski kurulumlarda varsayılan olarak kapalıdır. Bu destek olmadan systemctl status ssh şu çıktıyı verir:

System has not been booted with systemd as init system (PID 1). Can't operate.

Öncelikle yapılandırma dosyasını okuyun, çünkü halihazırda bir tane bulunuyor olabilir. Eğer dosyada [boot] bölümü yoksa bir tane ekleyin; eğer varsa, ilgili bölümün içine tek satırı ilave edin.

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

PowerShell üzerinde wsl --shutdown komutunu çalıştırın, yeni bir Ubuntu kabuğu açın ve ardından systemctl list-units --type=service --state=running ile kontrol edin. Birimlerin listelenmesi systemd'nin PID 1 olduğunu gösterir ve bu noktadan itibaren journalctl -b çalışır.

Buradaki sorun, enable komutunun her makinede neyi taahhüt ettiğidir. Bir VPS üzerinde sudo systemctl enable --now caddy, servisin açılışta başladığı anlamına gelir; bu sayede sistem yeniden başlatıldığında veya çekirdek yükseltildiğinde, kimse oturum açmamış olsa bile servis çalışır. WSL üzerinde ise bu, servisin dağıtım başladığında çalışmaya başlaması demektir; dağıtım ise siz bir terminal açtığınızda başlar. Dolayısıyla servis yalnızca siz çalışırken aktiftir, bu da servislerin varlık amacına terstir. Container'lar da aynı kısıtlamaya sahiptir; bu nedenle Docker Compose servislerini açılışta başlatmak, WSL'in yalnızca siz istediğinizde gerçekleştirdiği bir önyükleme işlemine bağlıdır.

WSL üzerinde çalışan bir sunucuya webhook ulaşabilir mi?

Yardımcı bir araç olmadan hayır; bunun nedeni ağ yapısıdır. WSL 2, varsayılan modunda sanal makineyi kendi sanal bağdaştırıcısı üzerinde NAT (ağ adresi çevirisi) arkasına yerleştirir. Adrese bakın:

ip -4 addr show eth0
ip route show default

Bu adres özeldir ve sanal makine her başladığında yeniden dağıtıldığı için değişir. Windows'un kendisi localhost:3000 adresine hala ulaşabilir, çünkü WSL localhost bağlantılarını dağıtıma iletir. Ağınızdaki başka bir makine, yönetici yetkili bir PowerShell üzerinden bir proxy kuralı eklemediğiniz sürece buna ulaşamaz:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

Bu kural tek bir adresi tanımlar, bu nedenle adres bir sonraki değiştiğinde kural bozulur. Yansıtılmış ağ (mirrored networking) daha iyi bir seçenektir: dağıtım, Windows ile aynı arayüzleri ve adresleri alır. Ağustos 2026 itibarıyla Windows 11 22H2 veya daha yeni bir sürüm gerektirir. Bunu %UserProfile%\.wslconfig içine ekleyin ve wsl --shutdown komutunu çalıştırın:

[wsl2]
networkingMode=mirrored

Yansıtılmış mod, yerel ağ sorununu çözer. Ancak size genel bir adres vermez. Yönlendiriciniz tekrar NAT çalıştırır, çoğu ev bağlantısında kontrol edebileceğiniz bir gelen port yoktur ve birçok İSS bunun üzerinde bir NAT katmanı daha ekler. Bu nedenle GitHub dizüstü bilgisayarınıza bir POST olayı gönderemez ve bir iş arkadaşınız demo bağlantınızı açamaz. Bir tünel servisi bu sorunu aşabilir ancak tünel istemcisi dizüstü bilgisayarda çalışır; bu da dizüstü bilgisayarın açık kalması gereken makine olduğu anlamına gelir.

Bir VPS, bu soruna diğer taraftan başlar. Genel bir IPv4 adresi ve genellikle genel bir IPv6 adresi vardır; sadece açtığınız portlar erişilebilirdir. Bir A kaydını ona yönlendirin, 80 ve 443 portlarına izin verin; sunucu her yerden yanıt verecektir. Bu aynı zamanda genel bir sertifika için de şarttır, çünkü HTTP-01 sınaması Let's Encrypt'in genel ad üzerindeki 80 portundan bir dosya çekmesini gerektirir. Certbot ve nginx ile Let's Encrypt sertifikası alma işlemi bir sunucuda beş dakikalık bir iştir ancak WSL içinde imkansızdır. Yerel çalışmalar için, kendi CA'nizi Ubuntu güven deposuna ekleyerek WSL içinde tarayıcı tarafından güvenilen HTTPS sertifikaları elde edebilirsiniz.

Neden git /mnt/c dizininde yavaş çalışır?

Dosyalar Linux dosya sisteminde bulunmadığı için yavaş çalışır. WSL, maliyetleri birbirinden çok farklı iki depolama alanı sunar. Ev dizininiz, sanal bir disk içindeki ext4 dosya sisteminde yer alır ve standart bir Linux diski gibi davranır. /mnt/c ise Windows tarafındaki bir bileşen tarafından 9P protokolü (Plan 9 dosya sistemi protokolü) üzerinden sunulan Windows sürücüsüdür; bu nedenle her dosya açma ve her stat işlemi bu sınırı geçer.

Tek bir dosya için bu sorun teşkil etmez. Büyük bir depoda git status komutunu çalıştırmak binlerce stat çağrısı yapar ve her biri bu sınır geçişinin maliyetini öder. Bu sayfadaki veriler dahil olmak üzere kimsenin verdiği sayıya güvenmek yerine kendiniz ölçüm yapın:

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

Her birini iki kez çalıştırın ve ikinci çalıştırmaları karşılaştırın; böylece her ikisi de önbelleğe alınmış (warm) olur. Windows gerçek zamanlı antivirüs taraması /mnt/c tarafında ek maliyet oluşturur; aynı deponun şirket bilgisayarında kişisel bilgisayara göre daha yavaş hissedilmesinin nedeni budur.

WSL içindeki çözüm, çalışma kopyasını ~ altında tutmak ve düzenleyicinizin WSL uzak modunu kullanarak açmaktır; bu mod, düzenleyici sunucusunu sınırın ötesine geçmek yerine dağıtımın içinde çalıştırır. Explorer, bu dosyalara hala \\wsl.localhost\Ubuntu\home\you üzerinden göz atabilir. Bir VPS bu sorunu yaşamaz, çünkü tek bir dosya sistemi vardır ve o da Linux'tur. Orada ödediğiniz bedel düzenleme sırasındaki ağ gecikmesidir; bu yüzden insanlar bir terminal çoğullayıcı veya uzak düzenleyici oturumu içinde çalışırlar. Paylaşımlı CPU, küçük bir sunucudaki en önemli kısıtlamadır ve gürültülü bir komşudan kaynaklanan steal time değeri, top içinde st sütununda görünür.

WSL’in kesin olarak öne çıktığı noktalar

• Ücretsizdir ve halihazırda makinede yüklüdür. Özelliği açıp Ubuntu kurduğunuzda, hiçbir ücret ödemeden ve dış dünyaya açık bir saldırı yüzeyi oluşturmadan bir dakika içinde çalışmaya başlayabilirsiniz.
• Bir sunucunun aksine kolayca silinebilir ve yeniden oluşturulabilir. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar, tüm dağıtımı tek bir dosyaya yazar ve wsl --import bu dosyayı geri yükler veya farklı bir isimle kopyalar. Burada yeni bir Ubuntu sürümünü denemek, sadece bir klonlama ve geri alma işlemidir; oysa bir VPS’i 24.04 sürümünden 26.04 sürümüne yükseltmek, üzerinde çalışan servisleri göz önünde bulundurarak planlamanız gereken tek yönlü bir işlemdir.
• GPU kullanımı doğrudan gerçekleşir. Güncel bir Windows GPU sürücüsü ile ekran kartı dağıtım içerisinde erişilebilir durumdadır; bu sayede CUDA ve ROCm iş yükleri halihazırda sahip olduğunuz donanım üzerinde çalışır. Aynı sınıftaki bir GPU’yu saatlik olarak kiralamak ciddi bir maliyet gerektirir.
• Düzenleme döngüsü daha kısadır. Dosyalarınız ve tarayıcınız yereldir; bu nedenle localhost:5173 üzerindeki bir geliştirme sunucusu, halihazırda oturum açmış olduğunuz tarayıcıda doğrudan açılır.

Bunlar somut avantajlardır ve genellikle tek bir makine yerine her iki makinenin de kullanılmasının temel nedenidir.

Yedeklerin sahibi kimdir?

Her iki makinede de yedeklerin sahibi sizsiniz; WSL tarafında bu durum kullanıcıları şaşırtmaktadır. Dağıtım, Windows kullanıcı profiliniz içinde yer alan bir sanal disk dosyasıdır (ext4.vhdx). Hiçbir sağlayıcı sizin yerinize bunun anlık görüntüsünü (snapshot) almaz. wsl --unregister Ubuntu komutu, geri alma imkanı olmaksızın dosyayı siler ve Windows'un yeniden kurulması durumunda dosya diğer tüm verilerle birlikte kaybolur. Yedekleme işlemini, gerçekten uygulayabileceğiniz bir zaman çizelgesine göre dışa aktarın:

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

Bir VPS üzerinde, sağlayıcı tarafından alınan anlık görüntüler sizi ölü bir sunucuya karşı korur. Ancak bu görüntüler, yanlış dizinde çalıştırılan bir rm -rf komutuna karşı koruma sağlamaz. Sunucu ile aynı hesapta tutulan bir anlık görüntü, çalınan bir oturum bilgisiyle birlikte yok olmaya mahkumdur. Dosya düzeyindeki yedekleri sunucunun dışına aktarın ve ihtiyaç duymadan önce bir kez geri yükleme testi yapın. Her iki durumda da sorumluluk size aittir. Pratik fark şudur: Bir sunucu, kimsenin dizüstü bilgisayarını açık bırakmasını beklemeden, saat 03:00'te kendi yedeğini otomatik olarak alabilir.

Köprü: WSL üzerinden VPS'e SSH bağlantısı

İkinci bir makine, bağlantı düzgün şekilde kurulana kadar zahmetli hissettirir. Bu işlemi WSL içinde bir kez yapın.

Özel anahtarın, ssh tarafından kabul edilen Unix izinlerine sahip ext4 dosya sisteminde kalması için anahtarı Windows tarafında değil, dağıtım içinde oluşturun:

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Ed25519 anahtarları kısa ve hızlıdır; ssh-copy-id, genel anahtarı sunucudaki ~/.ssh/authorized_keys dosyasına doğru izinlerle ekler. SSH anahtar yönetimi temelleri, anahtarların daha sonra nasıl değiştirileceğini ve iptal edileceğini açıklar.

~/.ssh/config dosyasında sunucuya bir isim verin:

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

Artık ssh dev ile bağlantı kurulabilir. IdentitiesOnly yes, istemcinin elindeki tüm anahtarları sunmasına engel olur; bu ayar, bir aracıda birden fazla anahtar yüklü olduğunda ortaya çıkan Too many authentication failures hatasını önler. ServerAliveInterval 30, ev bağlantısındaki bir oturumun sessizce kopmasını engeller.

ForwardAgent yes, iş akışını zahmetsiz hale getiren satırdır. Anahtarınız dizüstü bilgisayardaki aracıya yüklendiğinde, git clone git@github.com:you/app.git komutu özel anahtar sunucuya hiç gönderilmeden çalışır. Bunu VPS üzerinden ssh -T git@github.com ile test edin; sistem Hi you! You've successfully authenticated yanıtını vermelidir. Aracı yönlendirmesini yalnızca güvendiğiniz sunucular için kullanın; çünkü o makinedeki root kullanıcısı, siz bağlıyken aracı soketinizi kullanabilir. Başkalarıyla paylaştığınız bir sunucuda, depo bazlı bir deploy key kullanmak daha güvenli bir tercihtir.

WSL, kabuklar arasında bir aracı sürecini canlı tutmaz, bu nedenle her yeni terminal anahtarı tekrar ister. keychain bu sorunu çözer:

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

Yeni bir kabuk açın ve ssh-add -l komutunu çalıştırın. Anahtar parmak izini yazdırmalıdır. Error connecting to agent çıktısı alıyorsanız satır okunmuyor demektir; kabuğunuzun ~/.bashrc dosyasını gerçekten kaynak olarak kullanıp kullanmadığını kontrol edin.

Sunucudaki işleri bir terminal çoğullayıcı içinde çalıştırın, böylece bağlantı koptuğunda işlemleriniz sonlanmaz:

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

Dizüstü bilgisayarı kapatsanız bile derleme işlemi devam eder; ikinci makine kullanmanın temel amacı da budur. İnsanlar aynı yöntemi Claude Code'u tmux içinde VPS'te çalıştırmak ve oturumu başka bir cihazdan geri almak için kullanırlar.

Sunucuya herhangi bir şey yüklemeden önce sistemi sıkılaştırın. Yeni bir VPS'teki ilk on dakika rehberi; root olmayan kullanıcı oluşturma, yalnızca anahtarla SSH erişimi, güvenlik duvarı ve otomatik güvenlik güncellemeleri adımlarını, sizi sistem dışı bırakmayacak bir sırayla anlatır.

Hangi iş için hangi makine?

Çalışma ekranınızda gerçekleşiyorsa WSL kullanın. Düzenleme yapma, test paketlerini çalıştırma, localhost üzerinde bir geliştirme sunucusu, not defterleri, GPU deneyleri; kısacası başlatıp izlediğiniz her şey için bu geçerlidir.

Çalışmanın erişilebilir olması veya oturumunuzdan daha uzun süre yaşaması gerekiyorsa VPS kullanın. Bir müşterinin açabileceği bir staging URL'si, bir webhook uç noktası, gerçek bir saate bağlı cron işi, bir bot, başka bir servisin konuştuğu küçük bir veritabanı veya Cuma öğleden sonra başlattığınız bir içe aktarma işlemi için bu uygundur.

İkinci makinenin ne işe yarayacağına hala karar veriyorsanız, insanların aslında bir VPS üzerinde çalıştırdığı şeyler bir teknik özellik karşılaştırmasından daha faydalı bir listedir ve VPS nedir konusu, altındaki sanallaştırma teknolojisini açıklar. Araçlarınız yalnızca Windows üzerinde çalışıyorsa bu ayrı bir karardır ve Linux ile Windows Server karşılaştırması bunun için ayrılmış sayfadır.

İki makinenin de yarım yapılandırılmış hale gelmesini engelleyen tek bir alışkanlık vardır: kod git üzerinde barındırılır ve her iki makine de deponun birer istemcisidir. Önemli hiçbir şey yalnızca birinde bulunmaz.

FAQ

WSL üzerinden gerçek bir alan adı ile web sitesi barındırabilir miyim?

Güvenilir bir yöntem değildir. WSL 2, makinenizin içinde NAT arkasında çalışır, yönlendiriciniz tekrar NAT uygular ve çoğu ev interneti bağlantısı, port yönlendirme yapabileceğiniz bir gelen bağlantı portu sunmaz. Bir tünel servisi yerel bir portu dışarıya açabilir ancak tünel istemcisi dizüstü bilgisayarda çalıştığı için bilgisayar uyku moduna geçtiğinde site erişilemez hale gelir. Sertifika işlemleri durumu daha da zorlaştırır; çünkü HTTP-01 doğrulaması, Let's Encrypt servisinin herkese açık isim üzerinden 80 numaralı porttan bir dosya çekmesini gerektirir. Genel IP adresine ve A kaydına sahip bir VPS, herhangi bir geçici çözüm gerektirmeden her iki koşulu da karşılar.

systemctl enable WSL içinde çalışır mı?

systemd etkinleştirildiğinde çalışır; bunun için /etc/wsl.conf dosyasında [boot] altında systemd=true ayarı yapılmalı ve ardından wsl --shutdown komutu çalıştırılmalıdır. Bu yapılmadığında systemctl, System has not been booted with systemd as init system (PID 1). Can't operate. hatasını döndürür. systemd çalışıyor olsa bile, enable komutu servisi dağıtım başladığında başlatır ve dağıtım da siz bir kabuk (shell) açtığınızda başlar. Bir sunucuda aynı komut, servislerin kimse oturum açmamış olsa bile yeniden başlatma sonrasında otomatik olarak ayağa kalkması anlamına gelir.

WSL IP adresim neden sürekli değişiyor?

Varsayılan NAT modunda sanal makine, her başladığında WSL sanal bağdaştırıcısından yeni bir özel IP adresi alır. Herhangi bir netsh interface portproxy kuralı veya sabit kodlanmış adres, wsl --shutdown sonrasında çalışmayı durdurur. Mevcut adresi ip -4 addr show eth0 ile kontrol edebilirsiniz. Windows 11 üzerindeki yansıtmalı ağ (mirrored networking) modu, dağıtıma Windows ile aynı arayüzleri vererek ayrı adres sorununu ortadan kaldırır: bunun için %UserProfile%\.wslconfig dosyasında [wsl2] altında networkingMode=mirrored ayarını yapın.

/mnt/c gerçekten daha mı yavaş, yoksa bu bir efsane mi?

Daha yavaştır ve bir dakikalık test kendi makinenizde bunu kanıtlar. ~ altındaki dosyalar ext4 sanal diskinde bulunur. /mnt/c altındaki dosyalar ise Windows tarafındaki bir bileşen tarafından 9P protokolü üzerinden sunulur; bu nedenle her stat çağrısı sınırları aşar ve büyük bir dizin ağacı üzerinde git status komutu binlerce çağrı yapar. Depoyu ~ dizinine kopyalayın, her iki konumda da time git status komutunu iki kez çalıştırın ve ısınmış (warm) çalıştırma sürelerini karşılaştırın. Çalışma kopyalarını ~ altında tutun ve düzenleyicinizin WSL uzak modunu kullanın.

VPS sahibi olduktan sonra WSL'e hala ihtiyacım var mı?

Çoğu kullanıcı her ikisini de kullanmaya devam eder. WSL ücretsizdir ve anında başlar; bu nedenle düzenleme ve test işlemleri için idealdir, ayrıca GPU ile ilgili işler de burada yürütülür. Sunucu ise her zaman açık kalan makinedir: herkese açık ismi barındırır ve dizüstü bilgisayar kapandığında da çalışması gereken işleri yürütür. Kodu git üzerinde tutun ve her iki ortamı da deponun birer istemcisi olarak görün; bu sayede işleri iki ortam arasında taşımak hiçbir maliyet getirmez.