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

Sollten Sie für die Entwicklung WSL oder einen VPS verwenden?

Bei der Entscheidung zwischen WSL und einem VPS für die Entwicklung ist eine Eigenschaft entscheidend: die 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 ist dabei das System, das dauerhaft erreichbar bleibt.

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 beendet, wenn Sie den Laptop schließen?

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 etwas sie verwendet. Prüfen Sie den Status über 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 wurde auch alles beendet, was sie ausgeführt hat. wsl --shutdown führt denselben Vorgang sofort aus. Damit können Sie testen, wie sich Ihre Konfiguration nach einem Neustart verhält.

Der Energiesparmodus und der Ruhezustand beenden die virtuelle Maschine ebenfalls. Ein Timer, der um 03:00 eine Datenbank sichern soll, wird bei geschlossenem Laptop nicht ausgelöst, weil der Kernel, der ihn ausführen müsste, nicht aktiv ist. Es wird kein Fehler protokolliert. Daher sieht es so aus, als wäre der Auftrag überhaupt nicht geplant worden. Dieses Verhalten ist der Grund, warum viele auf einen zweiten Rechner ausweichen: Eine Build-Warteschlange, ein Chatbot, ein nächtliches Backup oder ein Webhook-Empfänger benötigen einen Computer, der eingeschaltet bleibt.

Funktioniert systemd in WSL?

Ja. Die Unterstützung wurde mit 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 journalctl -b.

Der entscheidende Punkt ist, was enable auf dem jeweiligen System bedeutet. Auf einem VPS bedeutet sudo systemctl enable --now caddy, dass der Dienst beim Booten startet. Nach einem Reboot oder einem Kernel-Upgrade wird er daher auch ohne angemeldeten Benutzer wieder gestartet. In WSL bedeutet es, dass der Dienst beim Start der Distribution startet. Die Distribution startet wiederum, wenn Sie ein Terminal öffnen. Der Dienst läuft also nur, während Sie arbeiten. Das ist das Gegenteil des eigentlichen Zwecks von Diensten. Container weisen dieselbe Einschränkung auf. Deshalb hängt das Starten von Docker Compose-Diensten beim Booten von einem Bootvorgang ab, den WSL nur auf Ihre Anforderung ausführt.

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

Nicht ohne zusätzliche Konfiguration. Der Grund ist die Netzwerkstruktur. Im Standardmodus setzt WSL 2 die virtuelle Maschine per NAT (Network Address Translation) hinter einen eigenen virtuellen Netzwerkadapter. Prüfen Sie die Adresse:

ip -4 addr show eth0
ip route show default

Diese Adresse ist privat und wird bei jedem Start der virtuellen Maschine erneut vergeben. Sie ändert sich daher. Windows selbst kann localhost:3000 weiterhin 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 Proxyregel 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. Sie funktioniert daher nicht mehr, sobald sich die Adresse ändert. Mirrored Networking ist die bessere Option: Die Distribution erhält dieselben Schnittstellen und Adressen wie Windows. Seit August 2026 ist dafür Windows 11 22H2 oder neuer erforderlich. Tragen Sie dies in %UserProfile%\.wslconfig ein und führen Sie wsl --shutdown aus:

[wsl2]
networkingMode=mirrored

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

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

Warum ist git unter /mnt/c langsam?

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

Eine Datei ist unproblematisch. git status in einem großen Repository führt jedoch Tausende stat-Aufrufe aus. Jeder einzelne verursacht dabei zusätzliche Kosten. Messen Sie die Werte, statt einer Zahl zu vertrauen, die Ihnen jemand nennt, auch 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 den zweiten Durchlauf, damit beide unter warmen Bedingungen erfolgen. Die Echtzeitprüfung durch den Windows-Virenscanner verursacht auf der /mnt/c-Seite zusätzliche Kosten. 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. Dadurch läuft der Editor-Server innerhalb der Distribution, statt die Grenze zu überschreiten. Der Explorer kann diese Dateien weiterhin unter \\wsl.localhost\Ubuntu\home\you anzeigen. Bei einem VPS tritt dieses Problem nicht auf, da dort ein einziges Dateisystem verwendet wird und dieses Linux ist. Dafür entsteht beim Bearbeiten Netzwerklatenz. Deshalb arbeiten viele Benutzer in einem Terminal-Multiplexer oder in einer Remote-Editorsitzung. Gemeinsame CPU-Nutzung ist auf einem kleinen Server der entscheidende Nachteil. CPU-Zeit von einem ausgelasteten Nachbarn wird in top als die Spalte st angezeigt.

Wo WSL eindeutig überlegen ist

• Es ist kostenlos und bereits auf dem Rechner vorhanden. Aktivieren Sie es, installieren Sie Ubuntu und arbeiten Sie innerhalb einer Minute damit. Sie müssen nichts bezahlen und keine öffentlich erreichbare Angriffsfläche absichern.
• Es lässt sich auf eine Weise verwerfen, wie es 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 zu testen, bedeutet Klonen und Zurückrollen. Ein VPS-Upgrade von 24.04 auf 26.04 ist dagegen eine nicht umkehrbare Änderung, die Sie auf die bereits laufenden Dienste abstimmen müssen.
• GPU-Arbeitslasten können direkt ausgeführt werden. Mit einem aktuellen Windows-GPU-Treiber ist die Grafikkarte innerhalb der Distribution verfügbar. Dadurch laufen CUDA- und ROCm-Arbeitslasten auf Hardware, die Sie bereits besitzen. Das stundenweise Mieten einer GPU derselben Leistungsklasse kostet tatsächlich Geld.
• Der Bearbeitungszyklus ist kürzer. Ihre Dateien und Ihr Browser sind beide lokal. Daher lässt sich ein Entwicklungsserver auf localhost:5173 in dem 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 Festplattendatei (ext4.vhdx) in Ihrem Windows-Benutzerprofil. Kein Anbieter erstellt dafür automatisch Snapshots. wsl --unregister Ubuntu löscht diese Datei ohne Wiederherstellungsmöglichkeit. Eine Neuinstallation von Windows entfernt sie zusammen mit allen anderen Daten. Exportieren Sie sie nach einem Zeitplan, den Sie tatsächlich einhalten:

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

Bei 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 nach dem Diebstahl eines einzigen Anmeldezugangs ebenfalls verloren. Übertragen Sie Backups auf Dateiebene aus dem System heraus. Stellen Sie eines wieder her, bevor Sie es 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 eingeschaltet lassen muss.

Die Brücke: SSH von WSL zum VPS

Ein zweiter Rechner wirkt erst dann umständlich, wenn die Verbindung nicht richtig eingerichtet ist. Richten Sie sie einmalig in WSL ein.

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, wie Sie die Schlüssel später austauschen und widerrufen.

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 verhindert, dass eine Sitzung über eine Heimverbindung ohne Meldung beendet wird.

ForwardAgent yes macht den Arbeitsablauf unkompliziert. 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 jemals ein privater Schlüssel dort abgelegt wird. Testen Sie dies mit ssh -T git@github.com vom VPS aus. Der Befehl sollte mit Hi you! You've successfully authenticated antworten. Leiten Sie den Agent nur an Server weiter, denen Sie vertrauen. Der Benutzer root 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. Daher fragt jedes neue Terminal erneut nach dem Schlüssel. 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 Befehl sollte den Fingerabdruck des Schlüssels ausgeben. Error connecting to agent bedeutet dagegen, dass die Zeile nicht gelesen wird. Prüfen Sie daher, ob Ihre Shell ~/.bashrc tatsächlich als Quelldatei einliest.

Führen Sie die Arbeit auf dem Server in einem Terminal-Multiplexer aus. Dadurch wird sie bei einer unterbrochenen Verbindung nicht beendet:

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. Nach demselben Muster führen Sie Claude Code in tmux auf einem VPS aus und setzen die Sitzung von einem anderen Gerät aus fort.

Härten Sie den Server ab, bevor Sie dort etwas installieren. Die ersten zehn Minuten auf einem neuen VPS beschreibt einen Benutzer ohne root-Berechtigungen, SSH nur mit Schlüsseln, eine Firewall und automatische Sicherheitsupdates. Die Reihenfolge verhindert, dass Sie sich aussperren.

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 Entwicklungsserver auf localhost, Notebooks, GPU-Experimente und alles, was Sie starten und anschließend beobachten.

Verwenden Sie den VPS, wenn die Arbeit erreichbar sein oder Ihre Sitzung überdauern muss. Dazu gehören eine Staging-URL, die ein Kunde öffnen kann, ein Webhook-Endpunkt, ein Cronjob mit einer echten Systemzeit, 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 gedacht ist, ist die Aufgaben, die tatsächlich auf einem VPS ausgeführt werden eine nützlichere Übersicht als ein Spezifikationsvergleich. Was ein VPS ist erklärt die Virtualisierung darunter. Wenn Ihre Werkzeuge nur unter Windows laufen, ist das eine separate Entscheidung. Dafür ist Linux im Vergleich zu Windows Server die passende Seite.

Eine Gewohnheit verhindert, dass aus zwei Maschinen zwei unvollständig konfigurierte Maschinen werden: Der Code liegt in git, und beide Maschinen greifen als Clients auf das Repository zu. Nichts Wichtiges existiert 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 dem NAT Ihres Rechners, und Ihr Router führt ein weiteres NAT durch. Bei den meisten privaten Internetanschlüssen gibt es keinen eingehenden Port, den Sie weiterleiten können. Ein Tunneldienst kann einen lokalen Port veröffentlichen. Der Tunnel-Client läuft jedoch auf dem Laptop, sodass die Website nicht erreichbar ist, sobald der Laptop in den Ruhezustand wechselt. Zertifikate machen die Situation zusätzlich 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 Voraussetzungen 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. Selbst bei laufendem systemd startet enable den Dienst, wenn die Distribution gestartet wird. Die Distribution startet, wenn Sie eine Shell öffnen. Auf einem Server bedeutet derselbe Befehl, dass der Dienst nach einem Reboot wieder startet, ohne dass jemand angemeldet sein muss.

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

Im Standardmodus mit NAT 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 er der Distribution dieselben Schnittstellen wie Windows zuweist. Setzen Sie dazu networkingMode=mirrored unter [wsl2] in %UserProfile%\.wslconfig.

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

Es ist langsamer. Eine einminütige Messung auf Ihrem eigenen Rechner weist das nach. 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 Systemgrenze, und git status in einem großen Verzeichnisbaum erzeugt Tausende solcher Aufrufe. Kopieren Sie das Repository nach ~, führen Sie time git status an jedem Ort zweimal aus und vergleichen Sie die Messwerte der Warmup-Läufe. Legen Sie Arbeitskopien unter ~ ab und verwenden Sie den WSL-Remote-Modus Ihres Editors.

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

Die meisten Benutzer behalten 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 Maschine, die dauerhaft läuft. Er verwaltet den öffentlichen Namen und führt Aufgaben aus, die auch bei geschlossenem Laptop weiterlaufen müssen. Halten Sie den Code in git und behandeln Sie beide Systeme als Clients des Repositorys. Dadurch können Sie Arbeit ohne zusätzlichen Aufwand zwischen ihnen verschieben.