WSL czy VPS do programowania? Porównanie rozwiązań

Czy do programowania wybrać WSL czy VPS?

Wybór między WSL a VPS w kontekście programowania sprowadza się do jednej właściwości: dostępności. WSL (Windows Subsystem for Linux) uruchamia Ubuntu wewnątrz maszyny wirtualnej, której cykl życia jest związany z sesją systemu Windows. VPS (virtual private server) uruchamia to samo Ubuntu pod publicznym adresem IP, który pozostaje aktywny nawet po zamknięciu laptopa. Większość programistów korzysta z obu rozwiązań, traktując serwer jako maszynę dostępną w trybie ciągłym.

System operacyjny nie stanowi istotnej różnicy, ponieważ w obu przypadkach jest to Ubuntu. Różnice dotyczą czasu pracy bez przerwy (uptime), dostępności z sieci Internet, gwarancji działania systemd, szybkości operacji na plikach, zachowania sieci oraz odpowiedzialności za kopie zapasowe. Każda z poniższych sekcji opisuje różnicę, którą można zaobserwować na własnej maszynie.

Dlaczego WSL zatrzymuje się po zamknięciu laptopa?

WSL 2 uruchamia rzeczywiste jądro Linux w lekkiej maszynie wirtualnej, którą system Windows uruchamia na żądanie. Maszyna wirtualna istnieje tylko wtedy, gdy działa dystrybucja, a dystrybucja działa tylko wtedy, gdy coś z niej korzysta. Sprawdź stan z poziomu PowerShell:

wsl --version
wsl --list --running

Zamknij wszystkie terminale WSL, odczekaj minutę, a następnie ponownie uruchom wsl --list --running. Gdy polecenie zgłosi brak uruchomionych dystrybucji, powłoka, którą uruchomiono, przestaje istnieć, podobnie jak wszystko, co w niej działało. wsl --shutdown wykonuje to samo działanie natychmiast, co stanowi przydatny sposób na przetestowanie zachowania konfiguracji po restarcie.

Tryb uśpienia i hibernacji również zatrzymują maszynę wirtualną. Licznik czasu ustawiony na wykonanie zrzutu bazy danych o godzinie 03:00 nie zadziała, gdy pokrywa laptopa jest zamknięta, ponieważ jądro, które miałoby go obsłużyć, nie jest wykonywane. Żaden proces nie rejestruje błędu, więc zadanie wygląda tak, jakby nigdy nie zostało zaplanowane. To zachowanie jest głównym powodem, dla którego użytkownicy przenoszą się na drugą maszynę: kolejka kompilacji, bot czatu, nocna kopia zapasowa czy odbiornik webhook wymagają komputera, który pozostaje włączony.

Czy systemd działa w WSL?

Tak. Wsparcie wprowadzono w WSL 0.67.6, jednak w starszych instalacjach jest ono domyślnie wyłączone. Bez niego systemctl status ssh zwraca błąd:

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

Najpierw odczytaj plik konfiguracyjny, ponieważ może on już istnieć. Jeśli nie zawiera sekcji [boot], dopisz ją; jeśli sekcja istnieje, dodaj w niej pojedynczą linię.

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

Uruchom wsl --shutdown w PowerShell, otwórz nową powłokę Ubuntu, a następnie sprawdź stan za pomocą systemctl list-units --type=service --state=running. Lista jednostek oznacza, że systemd działa jako PID 1, a journalctl -b od tego momentu funkcjonuje poprawnie.

Problem polega na tym, co enable gwarantuje na danej maszynie. Na VPS sudo systemctl enable --now caddy oznacza, że usługa startuje podczas rozruchu systemu, więc działa ona po restarcie lub aktualizacji jądra, nawet gdy nikt nie jest zalogowany. W WSL oznacza to, że usługa startuje w momencie uruchomienia dystrybucji, a dystrybucja startuje w momencie otwarcia terminala. W efekcie usługa działa tylko wtedy, gdy użytkownik pracuje, co jest sprzeczne z przeznaczeniem usług. Kontenery dziedziczą to samo ograniczenie, dlatego uruchamianie usług Docker Compose przy starcie systemu zależy od rozruchu, który WSL wykonuje tylko na żądanie.

Czy webhook może połączyć się z serwerem działającym w WSL?

Nie bez dodatkowej konfiguracji, co wynika z architektury sieci. W trybie domyślnym WSL 2 umieszcza maszynę wirtualną za NAT (network address translation) na własnym wirtualnym adapterze. Należy sprawdzić adres:

ip -4 addr show eth0
ip route show default

Adres ten jest prywatny i jest przydzielany ponownie przy każdym uruchomieniu maszyny wirtualnej, więc ulega zmianie. System Windows nadal może uzyskać dostęp do localhost:3000, ponieważ WSL przekazuje połączenia z localhost do dystrybucji. Inne urządzenie w sieci lokalnej nie ma takiej możliwości, chyba że zostanie dodana reguła proxy z poziomu PowerShell uruchomionego jako administrator:

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

Reguła ta wskazuje konkretny adres, więc przestaje działać po jego zmianie. Lepszym rozwiązaniem jest tryb mirrored networking: dystrybucja otrzymuje te same interfejsy i adresy co system Windows. Od sierpnia 2026 roku wymaga to systemu Windows 11 22H2 lub nowszego. Należy umieścić poniższą konfigurację w %UserProfile%\.wslconfig i wykonać wsl --shutdown:

[wsl2]
networkingMode=mirrored

Tryb mirrored rozwiązuje problem sieci lokalnej. Nie zapewnia on jednak publicznego adresu IP. Router ponownie stosuje NAT, większość domowych łączy nie posiada otwartych portów przychodzących, a wielu dostawców ISP dodaje kolejną warstwę NAT powyżej. Z tego powodu GitHub nie może wysłać żądania POST z wydarzeniem na laptopa, a współpracownik nie może otworzyć linku do demonstracji. Rozwiązaniem jest usługa tunelowania, jednak klient tunelu musi działać na laptopie, co oznacza, że laptop musi pozostać włączony.

Serwer VPS rozwiązuje ten problem od podstaw. Posiada publiczny adres IPv4 oraz zazwyczaj publiczny adres IPv6, z otwartymi tylko wybranymi portami. Skierowanie rekordu A na ten adres oraz zezwolenie na ruch na portach 80 i 443 pozwala na dostęp z dowolnego miejsca. Jest to również warunek uzyskania publicznego certyfikatu, ponieważ wyzwanie HTTP-01 wymaga, aby Let's Encrypt pobrał plik przez port 80 dla danej domeny publicznej. Uzyskiwanie certyfikatu Let's Encrypt za pomocą Certbot i nginx to zadanie zajmujące pięć minut na serwerze, a niemożliwe do wykonania w WSL. Do pracy lokalnej nadal można uzyskać zaufane przez przeglądarkę połączenie HTTPS wewnątrz WSL poprzez dodanie własnego urzędu certyfikacji (CA) do magazynu zaufanych certyfikatów Ubuntu.

Dlaczego git działa wolno w /mnt/c?

Pliki nie znajdują się na systemie plików Linux. WSL udostępnia dwa obszary przechowywania danych o skrajnie różnych kosztach operacyjnych. Katalog domowy znajduje się na systemie plików ext4 wewnątrz wirtualnego dysku i zachowuje się jak standardowy dysk systemowy Linux. /mnt/c to partycja Windows, udostępniana przez protokół 9P (Plan 9 filesystem protocol) za pośrednictwem komponentu po stronie Windows, dlatego każda operacja otwarcia pliku i każde wywołanie stat przekracza tę granicę.

Pojedynczy plik nie stanowi problemu. git status w dużym repozytorium generuje tysiące wywołań stat, a każde z nich wiąże się z kosztem przekroczenia granicy systemów. Należy wykonać pomiar zamiast polegać na liczbach podawanych przez kogokolwiek, w tym na tej stronie:

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

Uruchom każde polecenie dwukrotnie i porównaj drugie przebiegi, aby pamięć podręczna była rozgrzana. Skanowanie antywirusowe w czasie rzeczywistym po stronie Windows zwiększa narzut na /mnt/c, dlatego to samo repozytorium może działać wolniej na laptopie służbowym niż na prywatnym.

Rozwiązaniem wewnątrz WSL jest przechowywanie kopii roboczej w ~ i otwieranie jej za pomocą trybu zdalnego WSL w edytorze, który uruchamia serwer edytora wewnątrz dystrybucji, zamiast sięgać przez granicę systemów. Eksplorator plików nadal może przeglądać te pliki pod adresem \\wsl.localhost\Ubuntu\home\you. VPS nie ma tego problemu, ponieważ istnieje tylko jeden system plików i jest to Linux. Kosztem jest tam opóźnienie sieciowe podczas edycji, dlatego użytkownicy pracują w multiplekserze terminala lub sesji zdalnego edytora. Współdzielony procesor jest istotnym ograniczeniem na małym serwerze, a steal time od sąsiada jest widoczny w top jako kolumna st.

Gdzie WSL wygrywa bezapelacyjnie

• Jest darmowy i już znajduje się na komputerze. Wystarczy go włączyć, zainstalować Ubuntu i po minucie można pracować, bez żadnych kosztów i konieczności zabezpieczania publicznego interfejsu.
• Jest jednorazowy w sposób, w jaki serwer nie może być. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar zapisuje całą dystrybucję do jednego pliku, a wsl --import przywraca ją lub klonuje pod inną nazwą. Testowanie nowego wydania Ubuntu w tym środowisku to kwestia klonowania i przywrócenia stanu, podczas gdy aktualizacja VPS z 24.04 do 26.04 jest procesem jednokierunkowym, który trzeba zaplanować z uwzględnieniem działających na nim usług.
• Praca z GPU odbywa się bezpośrednio. Dzięki aktualnym sterownikom GPU dla Windows karta jest dostępna wewnątrz dystrybucji, więc obciążenia CUDA i ROCm działają na posiadanym sprzęcie. Wynajmowanie GPU tej samej klasy na godziny wiąże się z realnymi kosztami.
• Pętla edycji jest krótsza. Pliki i przeglądarka znajdują się lokalnie, więc serwer programistyczny na localhost:5173 otwiera się w przeglądarce, w której użytkownik jest już zalogowany.

To realne zalety i właśnie dlatego zazwyczaj optymalnym rozwiązaniem jest korzystanie z obu maszyn jednocześnie, zamiast wybierać tylko jedną.

Kto odpowiada za kopie zapasowe?

Odpowiadasz za nie Ty, na obu maszynach, przy czym w przypadku WSL często jest to zaskoczeniem. Dystrybucja jest plikiem wirtualnego dysku (ext4.vhdx) wewnątrz profilu użytkownika Windows. Żaden dostawca nie wykonuje dla niej migawek. wsl --unregister Ubuntu usuwa go bez możliwości cofnięcia zmian, a reinstalacja systemu Windows usuwa go wraz z całą resztą danych. Eksportuj go zgodnie z harmonogramem, którego faktycznie będziesz przestrzegać:

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

Na serwerze VPS migawka dostawcy chroni przed awarią hosta. Nie chroni jednak przed rm -rf w niewłaściwym katalogu, a migawka przechowywana na tym samym koncie co serwer może zostać utracona wraz z nim w przypadku przejęcia danych logowania. Przesyłaj kopie zapasowe na poziomie plików poza serwer i przetestuj przywracanie danych, zanim zajdzie taka potrzeba. W obu przypadkach odpowiedzialność spoczywa na Tobie. Praktyczna różnica polega na tym, że serwer może samodzielnie wykonać kopię zapasową o godzinie 03:00 bez konieczności pozostawiania włączonego laptopa.

Most: SSH z WSL do VPS

Druga maszyna jest uciążliwa tylko do momentu poprawnej konfiguracji połączenia. Wykonaj to jednorazowo wewnątrz WSL.

Wygeneruj klucz wewnątrz dystrybucji, a nie po stronie Windows, aby klucz prywatny pozostał na systemie plików ext4 z uprawnieniami uniksowymi, które akceptuje ssh:

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

Klucze Ed25519 są krótkie i szybkie, a ssh-copy-id dopisuje klucz publiczny do ~/.ssh/authorized_keys na serwerze z odpowiednimi uprawnieniami. Podstawy zarządzania kluczami SSH opisują późniejszą rotację i unieważnianie kluczy.

Nadaj serwerowi nazwę w ~/.ssh/config:

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

Teraz ssh dev nawiązuje połączenie. IdentitiesOnly yes zapobiega oferowaniu przez klienta każdego posiadanego klucza, co powoduje Too many authentication failures, gdy agent ma załadowanych wiele kluczy. ServerAliveInterval 30 zapobiega zrywaniu sesji przy domowym łączu bez wyświetlenia komunikatu.

ForwardAgent yes to linia, która czyni pracę bezproblemową. Gdy klucz jest załadowany w agencie na laptopie, git clone git@github.com:you/app.git działa na serwerze bez konieczności przesyłania tam klucza prywatnego. Przetestuj to za pomocą ssh -T git@github.com z poziomu VPS, co powinno zwrócić Hi you! You've successfully authenticated. Przekazuj agenta tylko do zaufanych serwerów, ponieważ użytkownik root na tej maszynie może użyć gniazda agenta, gdy jesteś połączony. Na serwerze współdzielonym z innymi osobami bezpieczniejszym wyborem jest klucz wdrożeniowy (deploy key) dla konkretnego repozytorium.

WSL nie utrzymuje agenta aktywnego między powłokami, więc każda nowa terminal prosi o klucz ponownie. keychain rozwiązuje ten problem:

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

Otwórz nową powłokę i uruchom ssh-add -l. Powinien zostać wyświetlony odcisk klucza (fingerprint). Error connecting to agent oznacza, że linia nie jest odczytywana, więc sprawdź, czy powłoka faktycznie wczytuje ~/.bashrc.

Uruchamiaj zadania na serwerze wewnątrz multipleksera terminala, aby zerwane połączenie nie przerywało pracy:

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

Proces budowania trwa nadal po zamknięciu laptopa, co jest głównym powodem korzystania z drugiej maszyny. Ten sam schemat stosuje się, aby uruchomić Claude Code na VPS w tmux i wznowić sesję z innego urządzenia.

Zabezpiecz maszynę, zanim cokolwiek na niej umieścisz. Pierwsze dziesięć minut na nowym VPS przeprowadzi Cię przez proces tworzenia użytkownika bez uprawnień root, konfigurację SSH tylko na klucze, firewall oraz automatyczne aktualizacje bezpieczeństwa, w kolejności, która nie spowoduje zablokowania dostępu.

Która maszyna do jakiego zadania?

Używaj WSL, gdy pracujesz bezpośrednio przy swoim stanowisku. Edycja kodu, uruchamianie zestawów testów, serwer deweloperski na localhost, notatniki, eksperymenty z GPU – wszystko to, co uruchamiasz i obserwujesz w czasie rzeczywistym.

Używaj VPS, gdy praca musi być dostępna zdalnie lub musi trwać po zakończeniu Twojej sesji. Adres URL środowiska stagingowego dla klienta, punkt końcowy webhook, zadanie cron z rzeczywistym czasem, bot, niewielka baza danych dla innej usługi czy import danych uruchomiony w piątkowe popołudnie.

Jeśli nadal zastanawiasz się, do czego służy druga maszyna, lista rzeczy, które ludzie faktycznie uruchamiają na VPS jest bardziej użyteczna niż porównanie specyfikacji, a czym jest VPS wyjaśnia mechanizm wirtualizacji leżący u jego podstaw. Jeśli Twoje narzędzia działają tylko w systemie Windows, jest to osobna kwestia, a porównanie Linux z Windows Server to strona poświęcona temu zagadnieniu.

Jeden nawyk zapobiega sytuacji, w której dwie maszyny stają się dwiema połowicznie skonfigurowanymi jednostkami: kod znajduje się w git, a obie maszyny są klientami repozytorium. Nic istotnego nie powinno istnieć tylko na jednej z nich.

FAQ

Czy mogę hostować stronę internetową z prawdziwą domeną z poziomu WSL?

Nie w sposób niezawodny. WSL 2 działa za NAT-em wewnątrz maszyny, router ponownie stosuje NAT, a większość połączeń domowych nie pozwala na przekierowanie portów przychodzących. Usługa tunelowania może udostępnić port lokalny, ale klient tunelu działa na laptopie, więc strona jest niedostępna, gdy laptop przechodzi w stan uśpienia. Certyfikaty dodatkowo komplikują sprawę, ponieważ wyzwanie HTTP-01 wymaga, aby Let's Encrypt pobrał plik przez port 80 dla publicznej nazwy. VPS z publicznym adresem IP i rekordem A spełnia oba warunki bez konieczności stosowania obejść.

Czy systemctl enable działa w WSL?

Działa, gdy włączony jest systemd, co wymaga ustawienia systemd=true w sekcji [boot] w pliku /etc/wsl.conf, a następnie wykonania wsl --shutdown. Bez tego systemctl zwraca System has not been booted with systemd as init system (PID 1). Can't operate.. Nawet przy działającym systemd, enable uruchamia usługę w momencie startu dystrybucji, a dystrybucja uruchamia się po otwarciu powłoki. Na serwerze to samo polecenie oznacza, że usługa wraca po restarcie systemu, nawet gdy nikt nie jest zalogowany.

Dlaczego mój adres IP w WSL ciągle się zmienia?

W domyślnym trybie NAT maszyna wirtualna otrzymuje nowy prywatny adres z wirtualnego adaptera WSL przy każdym uruchomieniu. Każda reguła netsh interface portproxy lub wpisany na sztywno adres przestaje działać po wsl --shutdown. Sprawdź bieżący adres za pomocą ip -4 addr show eth0. Tryb sieci lustrzanej (mirrored networking) w Windows 11 eliminuje osobny adres, nadając dystrybucji te same interfejsy co w Windows: ustaw networkingMode=mirrored w sekcji [wsl2] w pliku %UserProfile%\.wslconfig.

Czy /mnt/c jest rzeczywiście wolniejsze, czy to mit?

Jest wolniejsze, a minuta testów na własnej maszynie to potwierdza. Pliki w ~ znajdują się na wirtualnym dysku ext4. Pliki w /mnt/c są obsługiwane przez protokół 9P przez komponent po stronie Windows, więc każde wywołanie stat przekracza granicę, a git status w dużym drzewie katalogów wykonuje ich tysiące. Skopiuj repozytorium do ~, uruchom time git status dwukrotnie w każdej lokalizacji i porównaj wyniki po rozgrzaniu pamięci podręcznej. Przechowuj kopie robocze w ~ i używaj trybu zdalnego WSL w edytorze.

Czy nadal potrzebuję WSL, mając VPS?

Większość osób korzysta z obu rozwiązań. WSL jest darmowy i uruchamia się natychmiast, więc pozostaje miejscem do edycji i testowania, tam również najlepiej wykonywać zadania wymagające GPU. Serwer to maszyna, która działa stale: posiada publiczną nazwę i wykonuje zadania, które muszą trwać po zamknięciu laptopa. Przechowuj kod w git i traktuj oba środowiska jako klientów repozytorium; przenoszenie pracy między nimi nie generuje żadnych kosztów.