WSL of een VPS voor ontwikkeling: wat moet u kiezen?

Moet u WSL of een VPS gebruiken voor ontwikkeling?

De keuze tussen WSL en een VPS voor ontwikkeling hangt af van één eigenschap: beschikbaarheid. WSL (Windows Subsystem for Linux) draait Ubuntu in een virtuele machine die start en stopt met uw Windows-sessie. Een VPS (virtual private server) draait dezelfde Ubuntu op een openbaar IP-adres dat actief blijft terwijl uw laptop is gesloten. De meeste ontwikkelaars gebruiken uiteindelijk beide, waarbij de server fungeert als de machine die bereikbaar blijft.

Het besturingssysteem is niet het interessante verschil, aangezien beide Ubuntu zijn. Wat verschilt is de uptime, de bereikbaarheid vanaf het internet, wat systemd kan garanderen, de snelheid van bestandsbewerkingen, het gedrag van het netwerk en wie de back-ups beheert. Elke onderstaande sectie beschrijft een verschil dat u op uw eigen machine kunt observeren.

Waarom stopt WSL wanneer u de laptop sluit?

WSL 2 draait een echte Linux-kernel in een lichtgewicht virtuele machine die Windows op verzoek start. Die virtuele machine bestaat alleen zolang een distributie actief is, en een distributie draait alleen zolang er iets gebruik van maakt. Controleer de status vanuit PowerShell:

wsl --version
wsl --list --running

Sluit elke WSL-terminal, wacht een minuut en voer daarna wsl --list --running opnieuw uit. Wanneer deze meldt dat er geen distributies actief zijn, is de shell die u startte verdwenen en daarmee ook alles wat daarin draaide. wsl --shutdown doet direct hetzelfde, wat een nuttige manier is om te testen hoe uw configuratie zich gedraagt na een herstart.

Slaapstand en sluimerstand stoppen de virtuele machine eveneens. Een timer die is ingesteld om om 03:00 uur een database te dumpen, wordt niet geactiveerd terwijl het deksel gesloten is, omdat de kernel die dit zou uitvoeren niet actief is. Niets logt een foutmelding, waardoor het lijkt alsof de taak nooit gepland was. Dit specifieke gedrag is de reden waarom mensen uitwijken naar een tweede machine: een build-wachtrij, een chatbot, een nachtelijke back-up of een webhook-ontvanger hebben allemaal een computer nodig die ingeschakeld blijft.

Werkt systemd in WSL?

Ja. Ondersteuning is toegevoegd in WSL 0.67.6, maar staat standaard uitgeschakeld bij oudere installaties. Zonder deze ondersteuning geeft systemctl status ssh de volgende melding:

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

Lees eerst het configuratiebestand, aangezien u er mogelijk al een heeft. Als er geen [boot]-sectie in staat, voeg deze dan toe; als deze er wel is, voeg dan de enkele regel toe aan de bestaande sectie.

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

Voer wsl --shutdown uit in PowerShell, open een nieuwe Ubuntu-shell en controleer vervolgens met systemctl list-units --type=service --state=running. Een lijst met units betekent dat systemd PID 1 is en dat journalctl -b vanaf dat moment werkt.

Het addertje onder het gras is wat enable op elke machine belooft. Op een VPS betekent sudo systemctl enable --now caddy dat de service start bij het opstarten, waardoor deze na een reboot of kernel-upgrade weer actief is zonder dat er iemand is ingelogd. In WSL betekent het dat de service start wanneer de distributie start, en de distributie start pas wanneer u een terminal opent. De service is dus alleen actief terwijl u werkt, wat haaks staat op de reden waarom services bestaan. Containers erven hetzelfde hiaat, en daarom is het automatisch starten van Docker Compose-services bij boot afhankelijk van een opstartproces dat WSL alleen uitvoert wanneer u daarom vraagt.

Kan een webhook een server bereiken die in WSL draait?

Niet zonder hulp, en de reden hiervoor is de netwerkstructuur. In de standaardmodus plaatst WSL 2 de virtuele machine achter NAT (network address translation) op een eigen virtuele adapter. Bekijk het adres:

ip -4 addr show eth0
ip route show default

Dat adres is privaat en wordt telkens opnieuw toegewezen wanneer de virtuele machine opstart, waardoor het verandert. Windows zelf kan localhost:3000 nog steeds bereiken, omdat WSL localhost-verbindingen doorstuurt naar de distributie. Een andere machine op uw netwerk kan dit niet, tenzij u een proxyregel toevoegt vanuit een PowerShell met Administrator-rechten:

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

Die regel benoemt één adres, dus hij werkt niet meer zodra het adres verandert. Mirrored networking is de betere optie: de distributie krijgt dezelfde interfaces en adressen als Windows. Sinds augustus 2026 vereist dit Windows 11 22H2 of nieuwer. Plaats dit in %UserProfile%\.wslconfig en voer wsl --shutdown uit:

[wsl2]
networkingMode=mirrored

De mirrored-modus lost het lokale netwerkprobleem op. Het geeft u echter geen publiek adres. Uw router voert opnieuw NAT uit, de meeste thuisverbindingen hebben geen inkomende poort die u beheert, en veel ISP's voegen daarbovenop nog een extra laag NAT toe. GitHub kan dus geen POST-event naar uw laptop sturen en een collega kan uw demolink niet openen. Een tunnelservice omzeilt dit, maar de tunnelclient draait op de laptop, wat betekent dat de laptop de machine is die aan moet blijven staan.

Een VPS benadert dit probleem vanaf de andere kant. Deze heeft een publiek IPv4-adres en meestal een publiek IPv6-adres, met alleen de poorten die u openstelt. Wijs een A-record naar de server, sta poort 80 en 443 toe, en de server reageert vanaf elke locatie. Dat is tevens de voorwaarde voor een publiek certificaat, omdat de HTTP-01 challenge van Let's Encrypt vereist dat er een bestand wordt opgehaald via poort 80 op de publieke domeinnaam. Een Let's Encrypt-certificaat verkrijgen met Certbot en nginx is een klus van vijf minuten op een server en onmogelijk in WSL. Voor lokaal werk kunt u nog steeds browser-vertrouwde HTTPS binnen WSL krijgen door uw eigen CA toe te voegen aan de Ubuntu trust store.

Waarom is git traag op /mnt/c?

Omdat de bestanden zich niet op het Linux-bestandssysteem bevinden. WSL biedt twee opslaglocaties met zeer verschillende prestaties. Uw home-directory bevindt zich op een ext4-bestandssysteem binnen een virtuele schijf en gedraagt zich als een normale Linux-schijf. /mnt/c is de Windows-schijf, die via het 9P-protocol (Plan 9 filesystem protocol) wordt aangeboden door een component aan de Windows-zijde. Hierdoor moet elke open- en stat-operatie die grens oversteken.

Eén bestand is geen probleem. git status op een grote repository veroorzaakt duizenden stat-aanroepen, waarbij elke aanroep de vertraging van de oversteek oploopt. Meet het zelf in plaats van af te gaan op cijfers van anderen, inclusief deze pagina:

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

Voer beide commando's twee keer uit en vergelijk de tweede resultaten, zodat de caches warm zijn. Real-time antivirusscans in Windows voegen extra vertraging toe aan de /mnt/c-zijde; dit is de reden waarom dezelfde repository op een zakelijke laptop trager kan aanvoelen dan op een privé-laptop.

De oplossing binnen WSL is om de werkmap onder ~ te houden en deze te openen met de WSL-remote-modus van uw editor. Hierbij draait de editor-server binnen de distributie in plaats van over de grens heen te werken. Explorer kan deze bestanden nog steeds benaderen via \\wsl.localhost\Ubuntu\home\you. Een VPS heeft dit probleem niet, aangezien er slechts één bestandssysteem is en dit Linux is. Wat u daar betaalt is netwerklatentie tijdens het bewerken, waardoor mensen in een terminal-multiplexer of een remote editor-sessie werken. Gedeelde CPU is het eerlijke voorbehoud bij een kleine server, en steal time van een luidruchtige buur is zichtbaar in top als de st-kolom.

Waar WSL onbetwist wint

• Het is gratis en al aanwezig op de machine. Schakel het in, installeer Ubuntu en u kunt binnen een minuut aan de slag, zonder kosten en zonder publiek aanvalsoppervlak dat u moet beveiligen.
• Het is op een manier wegwerpbaar zoals een server dat niet is. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar schrijft de volledige distributie naar één bestand en wsl --import herstelt of kloont deze onder een tweede naam. Het uitproberen van een nieuwe Ubuntu-release is hier een kwestie van klonen en terugdraaien, terwijl het upgraden van een VPS van 24.04 naar 26.04 een eenrichtingsactie is die u moet inplannen rondom de services die er al op draaien.
• GPU-werk is direct. Met een actuele Windows GPU-driver is de kaart beschikbaar binnen de distributie, waardoor CUDA- en ROCm-workloads draaien op hardware die u al bezit. Het huren van een vergelijkbare klasse GPU per uur kost echt geld.
• De bewerkingscyclus is korter. Uw bestanden en uw browser zijn beide lokaal, dus een dev-server op localhost:5173 opent in de browser waar u al in bent aangemeld.

Dit zijn reële voordelen en daarom is het gebruikelijke antwoord beide machines in plaats van één.

Wie is de eigenaar van de back-ups?

U bent dat, op beide machines, en WSL is de plek waar dit mensen verrast. De distributie is een virtueel schijfbestand (ext4.vhdx) in uw Windows-gebruikersprofiel. Geen enkele provider maakt hier automatisch snapshots van voor u. wsl --unregister Ubuntu verwijdert het zonder mogelijkheid tot ongedaan maken, en een herinstallatie van Windows neemt het mee samen met al het andere. Exporteer het volgens een schema dat u daadwerkelijk zult aanhouden:

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

Op een VPS beschermt de snapshot van de provider u tegen een defecte host. Het beschermt u niet tegen rm -rf in de verkeerde map, en een snapshot die in hetzelfde account als de server wordt bewaard, is slechts één gestolen inloggegevens verwijderd van het verdwijnen samen met de server. Push back-ups op bestandsniveau naar een externe locatie en voer een herstel uit voordat u het echt nodig heeft. De verantwoordelijkheid ligt in beide gevallen bij u. Het praktische verschil is dat een server zijn eigen back-up kan pushen om 03:00 uur zonder dat iemand een laptop open hoeft te laten staan.

De brug: SSH van WSL naar de VPS

Een tweede machine voelt pas als een last totdat de verbinding correct is ingesteld. Voer dit eenmalig uit binnen WSL.

Genereer de sleutel in de distributie in plaats van aan de Windows-kant, zodat de privésleutel op het ext4-bestandssysteem blijft staan met Unix-rechten die ssh accepteert:

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

Ed25519-sleutels zijn kort en snel, en ssh-copy-id voegt de publieke sleutel toe aan ~/.ssh/authorized_keys op de server met de juiste permissies. Basisprincipes van SSH-sleutelbeheer behandelt het later roteren en intrekken ervan.

Geef de server een naam in ~/.ssh/config:

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

Nu maakt ssh dev verbinding. IdentitiesOnly yes voorkomt dat de client elke sleutel aanbiedt die hij bezit, wat de oorzaak is van Too many authentication failures wanneer een agent er meerdere geladen heeft. ServerAliveInterval 30 voorkomt dat een sessie op een thuisverbinding onverwacht wordt verbroken.

ForwardAgent yes is de regel die de workflow moeiteloos maakt. Met uw sleutel geladen in de agent op de laptop, werkt git clone git@github.com:you/app.git op de server zonder dat er ooit een privésleutel op de server terechtkomt. Test dit met ssh -T git@github.com vanaf de VPS, wat Hi you! You've successfully authenticated zou moeten antwoorden. Stuur de agent alleen door naar servers die u vertrouwt, omdat root op die machine uw agent-socket kan gebruiken terwijl u verbonden bent. Op een server die u deelt met anderen, is een per-repository deploy key de veiligere keuze.

WSL houdt een agent niet actief tussen shells, dus elke nieuwe terminal vraagt opnieuw om de sleutel. keychain lost dat op:

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

Open een nieuwe shell en voer ssh-add -l uit. Dit zou de vingerafdruk van de sleutel moeten tonen. Error connecting to agent betekent daarentegen dat de regel niet wordt ingelezen; controleer dus of uw shell ~/.bashrc daadwerkelijk inlaadt.

Voer het werk op de server uit binnen een terminal multiplexer, zodat een verbroken verbinding het proces niet beëindigt:

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

De build gaat door terwijl u de laptop sluit; dit is de voornaamste reden voor de tweede machine. Hetzelfde patroon wordt gebruikt door mensen die Claude Code in tmux op een VPS draaien en de sessie vanaf een ander apparaat hervatten.

Beveilig de server voordat u er iets op plaatst. De eerste tien minuten op een nieuwe VPS doorloopt het instellen van een niet-rootgebruiker, SSH met alleen sleutels, een firewall en automatische beveiligingsupdates, in de volgorde die voorkomt dat u uzelf buitensluit.

Welke machine voor welke taak?

Gebruik WSL wanneer het werk zich op uw scherm afspeelt. Denk aan bewerken, het uitvoeren van testsuites, een ontwikkelserver op localhost, notebooks, GPU-experimenten; alles wat u start en vervolgens monitort.

Gebruik de VPS wanneer het werk bereikbaar moet zijn of uw sessie moet overleven. Bijvoorbeeld een staging-URL die een klant kan openen, een webhook-endpoint, een cron job met een echte klok, een bot, een kleine database waar een andere service mee communiceert, of een import die u op vrijdagmiddag start.

Als u nog beslist waar de tweede machine voor dient, is de lijst met zaken die mensen daadwerkelijk op een VPS draaien nuttiger dan een specificatievergelijking, en wat een VPS is legt de virtualisatie erachter uit. Als uw tooling alleen op Windows draait, is dat een aparte beslissing en is Linux vergeleken met Windows Server de juiste pagina.

Eén gewoonte voorkomt dat twee machines veranderen in twee half geconfigureerde machines: de code staat in git en beide machines zijn clients van de repository. Niets belangrijks mag op slechts één van beide bestaan.

FAQ

Kan ik een website met een echt domein hosten vanaf WSL?

Niet op een betrouwbare manier. WSL 2 bevindt zich achter NAT binnen uw machine, uw router gebruikt opnieuw NAT, en de meeste thuisverbindingen bieden geen inkomende poort om door te sturen. Een tunnelservice kan een lokale poort openstellen, maar de tunnelclient draait op de laptop, waardoor de site onbereikbaar is zodra de laptop in de slaapstand gaat. Certificaten maken dit nog lastiger, omdat de HTTP-01 challenge vereist dat Let's Encrypt een bestand ophaalt via poort 80 op de publieke naam. Een VPS met een publiek IP-adres en een A-record voldoet aan beide voorwaarden zonder dat er workarounds nodig zijn.

Werkt systemctl enable in WSL?

Het werkt zodra systemd is ingeschakeld, wat betekent dat systemd=true onder [boot] in /etc/wsl.conf moet staan, gevolgd door wsl --shutdown. Zonder dit antwoordt systemctl met System has not been booted with systemd as init system (PID 1). Can't operate.. Zelfs met systemd actief start enable de service wanneer de distributie start, en de distributie start wanneer u een shell opent. Op een server betekent hetzelfde commando dat de service terugkeert na een herstart, ook als er niemand is ingelogd.

Waarom blijft mijn WSL IP-adres veranderen?

In de standaard NAT-modus ontvangt de virtuele machine telkens wanneer deze start een nieuw privaat adres van de WSL virtuele adapter. Elke netsh interface portproxy-regel of hard-coded adres werkt niet meer na wsl --shutdown. Controleer het huidige adres met ip -4 addr show eth0. De 'mirrored networking'-modus op Windows 11 heft het aparte adres op door de distributie dezelfde interfaces te geven als Windows: stel networkingMode=mirrored in onder [wsl2] in %UserProfile%\.wslconfig.

Is /mnt/c echt trager, of is dat een mythe?

Het is trager, en één minuut testen op uw eigen machine bewijst het. Bestanden onder ~ staan op een ext4 virtuele schijf. Bestanden onder /mnt/c worden via het 9P-protocol geserveerd door een component aan de Windows-kant, waardoor elke stat-aanroep de grens overschrijdt en git status over een grote boomstructuur duizenden aanroepen genereert. Kopieer de repository naar ~, voer time git status twee keer uit op beide locaties en vergelijk de 'warm runs'. Houd werkbestanden onder ~ en gebruik de WSL remote-modus van uw editor.

Heb ik nog steeds WSL nodig als ik een VPS heb?

De meeste mensen behouden beide. WSL is gratis en start direct, dus het blijft de plek waar u bewerkt en test; ook GPU-taken horen daar thuis. De server is de machine die altijd aan staat: deze beheert de publieke naam en voert de taken uit die moeten blijven draaien als de laptop is gesloten. Houd de code in git en behandel beide als clients van de repository; het verplaatsen van werk tussen beide kost dan niets.