WSL oder VPS für die Entwicklung: Was ist besser?

WSL oder VPS für die Entwicklung verwenden?

WSL und ein VPS unterscheiden sich bei der Entwicklung vor allem in einer Eigenschaft: der Verfügbarkeit. WSL (Windows Subsystem for Linux) führt Ubuntu in einer virtuellen Maschine aus, die an Ihre Windows-Sitzung gebunden ist. Ein VPS (virtueller privater Server) führt dasselbe Ubuntu unter einer öffentlichen IP-Adresse aus und bleibt erreichbar, während Ihr Laptop geschlossen ist. Die meisten Entwickler verwenden letztlich beides. Der Server bleibt dabei das dauerhaft erreichbare System.

Das Betriebssystem ist nicht der entscheidende Unterschied, da beide Ubuntu verwenden. Unterschiede gibt es bei der Betriebszeit, der Erreichbarkeit aus dem Internet, den Möglichkeiten von systemd, der Dateigeschwindigkeit, dem Netzwerkverhalten und der Zuständigkeit für Backups. Jeder folgende Abschnitt beschreibt einen Unterschied, den Sie auf Ihrem eigenen System beobachten können.

Warum wird WSL beim Schließen des Laptops beendet?

WSL 2 führt einen echten Linux-Kernel in einer schlanken virtuellen Maschine aus, die Windows bei Bedarf startet. Diese virtuelle Maschine existiert nur, solange eine Distribution ausgeführt wird. Eine Distribution läuft wiederum nur, solange sie verwendet wird. Prüfen Sie den Status in PowerShell:

wsl --version
wsl --list --running

Schließen Sie alle WSL-Terminals, warten Sie eine Minute und führen Sie wsl --list --running erneut aus. Wenn gemeldet wird, dass keine Distributionen ausgeführt werden, ist die gestartete Shell beendet. Damit ist auch alles beendet, was sie ausgeführt hat. wsl --shutdown führt dies sofort aus. Das ist eine praktische Möglichkeit, das Verhalten Ihrer Umgebung nach einem Neustart zu testen.

Der Energiesparmodus und der Ruhezustand beenden die virtuelle Maschine ebenfalls. Ein Timer, der um 03:00 eine Datenbank sichern soll, wird bei geschlossenem Deckel nicht ausgeführt, weil der dafür erforderliche Kernel nicht läuft. Es wird kein Fehler protokolliert. Daher sieht es so aus, als wäre der Auftrag überhaupt nicht geplant worden. Dieses Verhalten veranlasst viele dazu, einen zweiten Rechner zu verwenden: Eine Build-Warteschlange, ein Chatbot, ein nächtliches Backup oder ein Webhook-Empfänger benötigt einen Rechner, der eingeschaltet bleibt.

Funktioniert systemd in WSL?

Ja. Die Unterstützung wurde in WSL 0.67.6 eingeführt und ist bei älteren Installationen standardmäßig deaktiviert. Ohne diese Unterstützung gibt systemctl status ssh Folgendes aus:

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

Lesen Sie zuerst die Konfigurationsdatei, da möglicherweise bereits eine vorhanden ist. Wenn sie keinen Abschnitt [boot] enthält, hängen Sie einen an. Wenn der Abschnitt vorhanden ist, fügen Sie die einzelne Zeile in den bestehenden Abschnitt ein.

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

Führen Sie wsl --shutdown in PowerShell aus, öffnen Sie eine neue Ubuntu-Shell und prüfen Sie anschließend mit systemctl list-units --type=service --state=running. Eine Liste von Units bedeutet, dass systemd als PID 1 läuft. Ab diesem Zeitpunkt funktioniert auch journalctl -b.

Entscheidend ist, was enable auf dem jeweiligen System bedeutet. Auf einem VPS bedeutet sudo systemctl enable --now caddy, dass der Dienst beim Booten gestartet wird. Er läuft daher auch nach einem Reboot oder einem Kernel-Upgrade wieder, ohne dass jemand angemeldet sein muss. In WSL bedeutet es dagegen, dass der Dienst beim Start der Distribution gestartet wird. Die Distribution startet wiederum erst, wenn Sie ein Terminal öffnen. Der Dienst läuft also nur, während Sie arbeiten. Das widerspricht dem eigentlichen Zweck von Diensten. Container übernehmen dieselbe Einschränkung. Deshalb hängt das Starten von Docker-Compose-Diensten beim Booten davon ab, dass WSL nur dann bootet, wenn Sie dies anfordern.

Kann ein Webhook einen Server erreichen, der in WSL läuft?

Nicht ohne zusätzliche Konfiguration. Der Grund ist die Netzwerkstruktur. Im Standardmodus stellt WSL 2 die virtuelle Maschine über NAT (Network Address Translation) hinter einen eigenen virtuellen Netzwerkadapter. Sehen Sie sich die Adresse an:

ip -4 addr show eth0
ip route show default

Diese Adresse ist privat. Sie wird bei jedem Start der virtuellen Maschine erneut vergeben und ändert sich daher. Windows selbst kann localhost:3000 trotzdem erreichen, weil WSL localhost-Verbindungen in die Distribution weiterleitet. Ein anderes Gerät in Ihrem Netzwerk kann das nicht, sofern Sie nicht über eine PowerShell mit Administratorrechten eine Proxy-Regel hinzufügen:

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

Diese Regel verwendet eine bestimmte Adresse. Beim nächsten Adresswechsel funktioniert sie daher nicht mehr. Der bessere Ansatz ist Mirrored Networking. Dabei erhält die Distribution dieselben Schnittstellen und Adressen wie Windows. Seit August 2026 wird dafür Windows 11 22H2 oder neuer benötigt. Tragen Sie Folgendes in %UserProfile%\.wslconfig ein und führen Sie wsl --shutdown aus:

[wsl2]
networkingMode=mirrored

Der Mirrored-Modus behebt das lokale Netzwerkproblem. Er stellt Ihnen jedoch keine öffentliche Adresse bereit. Ihr Router führt erneut NAT aus. Bei den meisten privaten Internetanschlüssen können Sie keinen eingehenden Port selbst verwalten. Viele ISPs setzen darüber hinaus eine weitere NAT-Schicht ein. Daher kann GitHub kein Ereignis per POST an Ihren Laptop senden. Auch ein Kollege kann Ihren Demo-Link nicht öffnen. Ein Tunnel-Dienst umgeht dieses Problem. Der Tunnel-Client läuft jedoch auf dem Laptop. Deshalb muss der Laptop weiterhin eingeschaltet bleiben.

Ein VPS setzt an der anderen Seite dieses Problems an. Er verfügt über eine öffentliche IPv4-Adresse und normalerweise auch über eine öffentliche IPv6-Adresse. Erreichbar sind nur die Ports, die Sie öffnen. Verweisen Sie mit einem A-Record auf den VPS und erlauben Sie Port 80 und 443. Dann antwortet er von überall. Das ist auch die Voraussetzung für ein öffentliches Zertifikat. Bei der HTTP-01-Challenge ruft Let's Encrypt eine Datei über Port 80 unter dem öffentlichen Namen ab. Ein Let's-Encrypt-Zertifikat mit Certbot und nginx erhalten ist auf einem Server in fünf Minuten erledigt und in WSL nicht möglich. Für lokale Arbeiten können Sie innerhalb von WSL trotzdem browservertrauenswürdiges HTTPS verwenden, indem Sie Ihre eigene CA in den Ubuntu-Truststore aufnehmen.

Warum ist git unter /mnt/c langsam?

Weil sich die Dateien nicht im Linux-Dateisystem befinden. WSL stellt Ihnen zwei Speicherbereiche mit sehr unterschiedlichen Kosten bereit. Ihr Home-Verzeichnis liegt auf einem ext4-Dateisystem in einer virtuellen Festplatte und verhält sich wie eine gewöhnliche Linux-Festplatte. /mnt/c ist das Windows-Laufwerk. Eine Komponente auf der Windows-Seite stellt es über das 9P-Protokoll (Plan-9-Dateisystemprotokoll) bereit. Deshalb überquert jeder open- und jeder stat-Aufruf diese Grenze.

Eine einzelne Datei ist unproblematisch. git status in einem großen Repository führt jedoch Tausende von stat-Aufrufen aus. Jeder einzelne verursacht dabei zusätzlichen Aufwand durch diese Grenze. Messen Sie die Zeit, statt einer Zahl von irgendjemandem zu vertrauen, auch nicht der auf dieser Seite:

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

Führen Sie jeden Befehl zweimal aus und vergleichen Sie die zweiten Durchläufe, damit beide Durchläufe aufgewärmt sind. Die Windows-Echtzeitprüfung durch die Antivirensoftware verursacht auf der /mnt/c-Seite zusätzlichen Aufwand. Deshalb kann sich dasselbe Repository auf einem Firmen-Laptop langsamer anfühlen als auf einem privaten Gerät.

Die Lösung innerhalb von WSL besteht darin, die Arbeitskopie unter ~ zu speichern und sie mit dem WSL-Remote-Modus Ihres Editors zu öffnen. Dabei läuft der Editor-Server innerhalb der Distribution, statt die Grenze zu überschreiten. Mit dem Explorer können Sie diese Dateien weiterhin unter \\wsl.localhost\Ubuntu\home\you durchsuchen. Bei einem VPS tritt dieses Problem nicht auf, weil es nur ein Dateisystem gibt und dieses Linux verwendet. Dafür entsteht beim Bearbeiten Netzwerklatenz. Deshalb arbeiten viele Benutzer in einem Terminal-Multiplexer oder in einer Remote-Editorsitzung. Die gemeinsam genutzte CPU ist bei einem kleinen Server der relevante Nachteil. Steal-Time von einem ausgelasteten Nachbarn wird in top als Spalte st angezeigt.

Wo WSL eindeutig im Vorteil ist

• Es ist kostenlos und bereits auf dem Rechner vorhanden. Aktivieren Sie es, installieren Sie Ubuntu, und Sie können innerhalb einer Minute arbeiten. Es fallen keine Kosten an, und es gibt keine öffentlich erreichbare Angriffsfläche, die Sie absichern müssen.
• Es lässt sich auf eine Weise verwerfen, die bei einem Server nicht möglich ist. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar schreibt die gesamte Distribution in eine Datei, und wsl --import stellt sie wieder her oder klont sie unter einem zweiten Namen. Eine neue Ubuntu-Version hier auszuprobieren bedeutet Klonen und Zurücksetzen. Ein VPS-Upgrade von 24.04 auf 26.04 ist dagegen eine Einbahnstraße, die Sie mit Blick auf die bereits laufenden Dienste planen müssen.
• GPU-Arbeitslasten greifen direkt auf die Hardware zu. Mit einem aktuellen Windows-GPU-Treiber ist die Grafikkarte innerhalb der Distribution verfügbar. Dadurch laufen CUDA- und ROCm-Arbeitslasten auf der Hardware, die Sie bereits besitzen. Das Mieten einer GPU derselben Leistungsklasse pro Stunde kostet echtes Geld.
• Die Bearbeitungsschleife ist kürzer. Ihre Dateien und Ihr Browser laufen beide lokal. Deshalb lässt sich ein Entwicklungsserver auf localhost:5173 im Browser öffnen, bei dem Sie bereits angemeldet sind.

Das sind konkrete Vorteile. Deshalb lautet die übliche Empfehlung, beide Systeme statt nur eines zu verwenden.

Wem gehören die Backups?

Auf beiden Systemen sind Sie dafür verantwortlich. Bei WSL überrascht das viele Nutzer. Die Distribution ist eine virtuelle Datenträgerdatei (ext4.vhdx) in Ihrem Windows-Benutzerprofil. Kein Anbieter erstellt dafür automatisch Snapshots. wsl --unregister Ubuntu löscht sie ohne Rückgängig-Funktion. Eine Neuinstallation von Windows nimmt sie zusammen mit allen anderen Daten mit. Exportieren Sie die Distribution regelmäßig nach einem Zeitplan, den Sie tatsächlich einhalten:

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

Auf einem VPS schützt Sie der Snapshot des Anbieters vor einem Ausfall des Hosts. Er schützt Sie jedoch nicht vor rm -rf im falschen Verzeichnis. Ein Snapshot, der im selben Konto wie der Server gespeichert ist, ist nur einen gestohlenen Login davon entfernt, zusammen mit dem Server verloren zu gehen. Übertragen Sie Backups auf Dateiebene auf ein externes System. Führen Sie eine Wiederherstellung durch, bevor Sie sie benötigen. In beiden Fällen liegt die Verantwortung bei Ihnen. Der praktische Unterschied besteht darin, dass ein Server sein eigenes Backup um 03:00 erstellen kann, ohne dass jemand einen Laptop geöffnet lassen muss.

Die Brücke: SSH von WSL zum VPS

Ein zweiter Rechner wirkt erst dann lästig, wenn die Verbindung nicht richtig eingerichtet ist. Führen Sie diese Schritte einmal in WSL aus.

Erzeugen Sie den Schlüssel in der Distribution und nicht auf der Windows-Seite. Dadurch bleibt der private Schlüssel im ext4-Dateisystem mit Unix-Berechtigungen, die ssh akzeptiert:

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

Ed25519-Schlüssel sind kurz und schnell. ssh-copy-id hängt den öffentlichen Schlüssel mit den korrekten Berechtigungen an ~/.ssh/authorized_keys auf dem Server an. Grundlagen der SSH-Schlüsselverwaltung beschreibt später das Rotieren und Sperren dieser Schlüssel.

Geben Sie dem Server in ~/.ssh/config einen Namen:

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

Jetzt stellt ssh dev die Verbindung her. IdentitiesOnly yes verhindert, dass der Client jeden vorhandenen Schlüssel anbietet. Das verursacht Too many authentication failures, wenn ein Agent mehrere Schlüssel geladen hat. ServerAliveInterval 30 hält eine Sitzung über eine Heimverbindung aufrecht, damit sie nicht ohne Meldung abbricht.

ForwardAgent yes ist die Zeile, die den Ablauf erheblich vereinfacht. Wenn Ihr Schlüssel im Agent auf dem Laptop geladen ist, funktioniert git clone git@github.com:you/app.git auf dem Server, ohne dass dort jemals ein privater Schlüssel abgelegt wird. Testen Sie dies mit ssh -T git@github.com vom VPS aus. Die Ausgabe sollte Hi you! You've successfully authenticated sein. Leiten Sie den Agent nur an Server weiter, denen Sie vertrauen. Der root-Account auf diesem Rechner kann während Ihrer Verbindung den Agent-Socket verwenden. Auf einem Server, den Sie mit anderen Personen gemeinsam nutzen, ist ein Deploy-Schlüssel pro Repository die sicherere Wahl.

WSL hält einen Agent nicht zwischen Shells aktiv. Deshalb wird bei jedem neuen Terminal erneut nach dem Schlüssel gefragt. keychain behebt dieses Problem:

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

Öffnen Sie eine neue Shell und führen Sie ssh-add -l aus. Der Fingerabdruck des Schlüssels sollte ausgegeben werden. Error connecting to agent bedeutet dagegen, dass die Zeile nicht gelesen wird. Prüfen Sie daher, ob Ihre Shell ~/.bashrc tatsächlich lädt.

Führen Sie die Arbeit auf dem Server innerhalb eines Terminal-Multiplexers aus. Dadurch beendet eine abgebrochene Verbindung den Vorgang nicht:

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

Der Build läuft weiter, während Sie den Laptop schließen. Genau dafür gibt es den zweiten Rechner. Dasselbe Muster verwenden Sie, um Claude Code auf einem VPS in tmux auszuführen und die Sitzung von einem anderen Gerät aus wieder aufzunehmen.

Härten Sie den Server ab, bevor Sie dort etwas installieren. Die ersten zehn Minuten auf einem neuen VPS führt Sie in der richtigen Reihenfolge durch den nicht-root-Benutzer, SSH nur mit Schlüsseln, eine Firewall und automatische Sicherheitsupdates. So sperren Sie sich nicht aus.

Welche Maschine für welche Aufgabe?

Verwenden Sie WSL, wenn die Arbeit auf Ihrem Bildschirm stattfindet. Dazu gehören das Bearbeiten von Dateien, das Ausführen der Testsuite, ein Dev-Server auf localhost, Notebooks, GPU-Experimente und alles, was Sie starten und anschließend beobachten.

Verwenden Sie den VPS, wenn die Arbeit erreichbar sein muss oder Ihre Sitzung überdauern soll. Dazu gehören eine Staging-URL, die ein Kunde öffnen kann, ein Webhook-Endpunkt, ein Cronjob mit einer echten Uhrzeit, ein Bot, eine kleine Datenbank, mit der ein anderer Dienst kommuniziert, oder ein Import, den Sie am Freitagnachmittag starten.

Wenn Sie noch entscheiden, wofür die zweite Maschine eingesetzt werden soll, ist eine Liste der Dinge, die tatsächlich auf einem VPS ausgeführt werden hilfreicher als ein Vergleich von Spezifikationen. Was ein VPS ist erklärt die zugrunde liegende Virtualisierung. Wenn Ihre Werkzeuge ausschließlich unter Windows laufen, ist das eine separate Entscheidung. Die passende Seite dafür ist Linux im Vergleich zu Windows Server.

Eine Gewohnheit verhindert, dass aus zwei Maschinen zwei halb konfigurierte Maschinen werden: Der Code liegt in git, und beide Maschinen sind Clients des Repositorys. Nichts Wichtiges befindet sich nur auf einer der beiden Maschinen.

FAQ

Kann ich mit WSL eine Website unter einer echten Domain hosten?

Nicht zuverlässig. WSL 2 befindet sich hinter NAT auf Ihrem Rechner, Ihr Router führt erneut NAT aus, und die meisten privaten Internetanschlüsse bieten keinen eingehenden Port, den Sie weiterleiten können. Ein Tunneldienst kann einen lokalen Port veröffentlichen. Der Tunnelclient läuft jedoch auf dem Laptop, sodass die Website nicht erreichbar ist, sobald der Laptop in den Energiesparmodus wechselt. Zertifikate machen die Situation noch schwieriger, weil die HTTP-01-Challenge voraussetzt, dass Let’s Encrypt eine Datei über Port 80 unter dem öffentlichen Namen abruft. Ein VPS mit öffentlicher IP-Adresse und einem A-Record erfüllt beide Bedingungen ohne Workaround.

Funktioniert systemctl enable unter WSL?

Es funktioniert, sobald systemd aktiviert ist. Dazu führen Sie systemd=true unter [boot] in /etc/wsl.conf aus und anschließend wsl --shutdown. Ohne diese Einstellung antwortet systemctl mit System has not been booted with systemd as init system (PID 1). Can't operate. Auch bei laufendem systemd startet enable den Dienst, sobald die Distribution gestartet wird. Die Distribution wird gestartet, sobald Sie eine Shell öffnen. Auf einem Server bedeutet derselbe Befehl, dass der Dienst nach einem Reboot wieder verfügbar ist, ohne dass jemand angemeldet sein muss.

Warum ändert sich meine WSL-IP-Adresse ständig?

Im standardmäßigen NAT-Modus erhält die virtuelle Maschine bei jedem Start eine neue private Adresse vom virtuellen WSL-Adapter. Jede netsh interface portproxy-Regel und jede fest codierte Adresse funktioniert nach wsl --shutdown nicht mehr. Prüfen Sie die aktuelle Adresse mit ip -4 addr show eth0. Der Modus für gespiegelte Netzwerke unter Windows 11 entfernt die separate Adresse, indem die Distribution dieselben Schnittstellen wie Windows erhält: Setzen Sie networkingMode=mirrored unter [wsl2] in %UserProfile%\.wslconfig.

Ist /mnt/c wirklich langsamer, oder ist das ein Mythos?

Es ist langsamer. Ein einminütiger Test auf Ihrem eigenen Rechner belegt das. Dateien unter ~ liegen auf einer virtuellen ext4-Festplatte. Dateien unter /mnt/c werden von einer Windows-Komponente über das 9P-Protokoll bereitgestellt. Dadurch überschreitet jeder stat-Aufruf die Grenze zwischen den Systemen, und git status über einen großen Verzeichnisbaum erzeugt Tausende solcher Aufrufe. Kopieren Sie das Repository nach ~, führen Sie time git status an beiden Speicherorten zweimal aus und vergleichen Sie die Messungen aus dem Warmstart. Bewahren Sie Arbeitskopien unter ~ auf und verwenden Sie den WSL-Remotemodus Ihres Editors.

Benötige ich WSL noch, wenn ich einen VPS habe?

Die meisten Benutzer verwenden weiterhin beide Systeme. WSL ist kostenlos und startet sofort. Daher bleibt es der Ort, an dem Sie Code bearbeiten und testen. Auch GPU-Aufgaben gehören dorthin. Der Server ist die dauerhaft laufende Maschine. Er verwaltet den öffentlichen Namen und führt Aufgaben aus, die auch bei geschlossenem Laptop weiterlaufen müssen. Bewahren Sie den Code in git auf und behandeln Sie beide Systeme als Clients des Repositorys. Dann kostet das Verschieben der Arbeit zwischen ihnen nichts.