WSL o VPS per lo sviluppo: quale scegliere?

Usare WSL o un VPS per lo sviluppo?

La scelta tra WSL e un VPS per lo sviluppo dipende da una proprietà: la disponibilità. WSL (Windows Subsystem for Linux) esegue Ubuntu all'interno di una macchina virtuale che resta attiva solo durante la sessione Windows. Un VPS (virtual private server) esegue lo stesso Ubuntu su un indirizzo IP pubblico che rimane attivo anche quando il laptop è chiuso. La maggior parte degli sviluppatori finisce per usare entrambi, con il server come macchina sempre raggiungibile.

Il sistema operativo non rappresenta la differenza principale, perché in entrambi i casi è Ubuntu. Cambiano invece l'uptime, la raggiungibilità da Internet, ciò che systemd può garantire, la velocità dei file, il comportamento della rete e il responsabile dei backup. Ogni sezione seguente descrive una differenza che puoi osservare direttamente sulla tua macchina.

Perché WSL si arresta quando chiudi il laptop?

WSL 2 esegue un kernel Linux reale in una macchina virtuale leggera che Windows avvia su richiesta. La macchina virtuale esiste soltanto mentre è in esecuzione una distribuzione, e una distribuzione resta attiva soltanto finché qualcosa la utilizza. Verifica lo stato da PowerShell:

wsl --version
wsl --list --running

Chiudi tutti i terminali WSL, attendi un minuto, quindi esegui di nuovo wsl --list --running. Quando indica che non ci sono distribuzioni in esecuzione, la shell avviata non esiste più e con essa anche tutto ciò che stava eseguendo. wsl --shutdown produce immediatamente lo stesso risultato, quindi è un modo utile per verificare il comportamento della configurazione dopo un riavvio.

Anche la sospensione e l'ibernazione arrestano la macchina virtuale. Un timer impostato per eseguire il dump di un database alle 03:00 non si attiva mentre il coperchio è chiuso, perché il kernel che dovrebbe eseguirlo non è in funzione. Nessun componente registra un errore, quindi sembra che il job non sia mai stato pianificato. È proprio questo comportamento a spingere molte persone a usare una seconda macchina: una coda di build, un chatbot, un backup notturno o un ricevitore di webhook richiedono tutti un computer che rimanga acceso.

Il funzionamento di systemd in WSL

Sì. Il supporto è stato introdotto in WSL 0.67.6 ed è disabilitato per impostazione predefinita nelle installazioni precedenti. Senza questo supporto, systemctl status ssh restituisce:

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

Leggete prima il file di configurazione, perché potrebbe esisterne già uno. Se non contiene una sezione [boot], aggiungetene una; se la contiene, aggiungete la singola riga all'interno della sezione esistente.

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

Eseguite wsl --shutdown in PowerShell, aprite una nuova shell Ubuntu, quindi verificate con systemctl list-units --type=service --state=running. Un elenco di unità indica che systemd è il PID 1; da quel momento journalctl -b funziona.

Il punto critico è il significato di enable su ciascuna macchina. Su un VPS, sudo systemctl enable --now caddy significa che il servizio viene avviato al boot; quindi torna attivo dopo un riavvio o un aggiornamento del kernel anche se nessuno ha effettuato l'accesso. In WSL significa invece che il servizio viene avviato quando si avvia la distribuzione, e la distribuzione si avvia quando aprite un terminale. Il servizio è quindi attivo solo mentre state lavorando, cioè l'opposto dello scopo per cui esistono i servizi. I container presentano la stessa limitazione. Per questo avviare i servizi Docker Compose al boot dipende da un boot che WSL esegue soltanto quando lo richiedete.

Un webhook può raggiungere un server in esecuzione in WSL?

Non senza configurazioni aggiuntive, a causa della topologia di rete. Nella modalità predefinita, WSL 2 colloca la macchina virtuale dietro un NAT (network address translation), su un proprio adattatore virtuale. Verificate l'indirizzo:

ip -4 addr show eth0
ip route show default

Questo indirizzo è privato e viene assegnato nuovamente a ogni avvio della macchina virtuale, quindi cambia. Windows può comunque raggiungere localhost:3000, perché WSL inoltra le connessioni a localhost nella distribuzione. Un altro computer della rete non può farlo, a meno di aggiungere una regola proxy da PowerShell eseguito come Administrator:

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

La regola specifica un indirizzo, quindi smette di funzionare alla successiva modifica dell'indirizzo. La modalità di rete mirrored è un'opzione migliore: la distribuzione riceve le stesse interfacce e gli stessi indirizzi di Windows. Ad agosto 2026 richiede Windows 11 22H2 o versione successiva. Inserite questa configurazione in %UserProfile%\.wslconfig ed eseguite wsl --shutdown:

[wsl2]
networkingMode=mirrored

La modalità mirrored risolve il problema della rete locale. Non assegna un indirizzo pubblico. Il router esegue nuovamente il NAT, la maggior parte delle connessioni domestiche non offre una porta in ingresso sotto il vostro controllo e molti ISP aggiungono un ulteriore livello di NAT. Di conseguenza, GitHub non può inviare tramite POST un evento al vostro laptop e un collega non può aprire il link della vostra demo. Un servizio di tunneling risolve il problema, ma il client del tunnel viene eseguito sul laptop, che deve quindi restare acceso.

Un VPS parte dalla condizione opposta. Dispone di un indirizzo IPv4 pubblico e, in genere, di un indirizzo IPv6 pubblico, con accessibili soltanto le porte che aprite. Puntate un record A al VPS, consentite le porte 80 e 443 e il server risponderà da qualsiasi rete. Questa è anche la condizione necessaria per un certificato pubblico, perché la challenge HTTP-01 chiede a Let's Encrypt di recuperare un file tramite la porta 80 usando il nome pubblico. Ottenere un certificato Let's Encrypt con Certbot e nginx è un'operazione di cinque minuti su un server, ma è impossibile in WSL. Per il lavoro locale potete comunque ottenere HTTPS considerato attendibile dai browser all'interno di WSL aggiungendo la vostra CA all'archivio di certificati attendibili di Ubuntu.

Perché git è lento su /mnt/c?

Perché i file non si trovano nel filesystem Linux. WSL offre due aree di archiviazione con costi operativi molto diversi. La directory home si trova su un filesystem ext4 all'interno di un disco virtuale e si comporta come un normale disco Linux. /mnt/c è l'unità Windows, esposta tramite il protocollo 9P (protocollo del filesystem Plan 9) da un componente sul lato Windows; di conseguenza, ogni operazione di apertura e ogni chiamata a stat attraversano quel confine.

Un singolo file non crea problemi. git status su un repository di grandi dimensioni esegue migliaia di chiamate a stat, e ognuna comporta il costo dell'attraversamento. Misurate invece di fidarvi di un valore riportato da altri, incluso quello presente in questa 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

Eseguite ciascun comando due volte e confrontate i secondi risultati, in modo che entrambi siano ottenuti a cache calda. L'antivirus Windows con la scansione in tempo reale aggiunge ulteriore costo sul lato /mnt/c; per questo lo stesso repository può risultare più lento su un laptop aziendale rispetto a un dispositivo personale.

La soluzione in WSL consiste nel mantenere la copia di lavoro sotto ~ e aprirla con la modalità remota WSL dell'editor, che esegue il server dell'editor all'interno della distribuzione invece di attraversare il confine. Esplora file può continuare a esplorare quei file in \\wsl.localhost\Ubuntu\home\you. Un VPS non presenta questo problema, perché dispone di un unico filesystem Linux. Il costo è invece la latenza di rete durante la modifica, quindi si lavora in un multiplexer di terminale o in una sessione remota dell'editor. La condivisione della CPU è l'aspetto da considerare su un server di piccole dimensioni, e il tempo CPU sottratto da un vicino rumoroso compare in top nella colonna st.

Dove WSL è nettamente superiore

• È gratuito ed è già presente nel computer. Basta abilitarlo e installare Ubuntu per iniziare a lavorare in un minuto, senza costi e senza una superficie pubblica da proteggere.
• È usa e getta in un modo che un server non può essere. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar scrive l’intera distribuzione in un unico file e wsl --import la ripristina oppure la clona con un secondo nome. Provare qui una nuova release di Ubuntu significa creare un clone e poter eseguire un rollback; aggiornare un VPS da 24.04 a 26.04 è invece un’operazione a senso unico, da pianificare tenendo conto dei servizi già in esecuzione.
• Il lavoro con la GPU è diretto. Con un driver GPU Windows aggiornato, la scheda è disponibile all’interno della distribuzione, quindi i carichi di lavoro CUDA e ROCm vengono eseguiti sull’hardware che già possiedi. Noleggiare una GPU della stessa classe a ore ha un costo reale.
• Il ciclo di modifica è più breve. I file e il browser sono entrambi locali, quindi un server di sviluppo su localhost:5173 si apre nel browser in cui hai già effettuato l’accesso.

Sono vantaggi concreti e spiegano perché, di norma, la risposta sia usare entrambe le macchine anziché una sola.

Chi è responsabile dei backup?

Lo sei tu, su entrambe le macchine. In WSL questo aspetto sorprende molti utenti. La distribuzione è un file di disco virtuale (ext4.vhdx) nella cartella del profilo utente Windows. Nessun provider ne crea automaticamente snapshot. wsl --unregister Ubuntu lo elimina senza possibilità di annullare l'operazione, mentre una reinstallazione di Windows lo elimina insieme a tutto il resto. Esportalo secondo una pianificazione che riuscirai davvero a rispettare:

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

Su un VPS, lo snapshot del provider protegge dal guasto dell'host. Non protegge da rm -rf nella directory sbagliata. Inoltre, se lo snapshot è conservato nello stesso account del server, è sufficiente che un accesso venga compromesso perché vada perso insieme al server. Invia i backup a livello di file fuori dal server e prova a ripristinarne uno prima di averne bisogno. In entrambi i casi, la responsabilità resta tua. La differenza pratica è che un server può eseguire il proprio backup alle 03:00 senza chiedere a nessuno di lasciare un laptop acceso.

Il ponte: SSH da WSL al VPS

Una seconda macchina sembra solo un impegno aggiuntivo finché la connessione non viene configurata correttamente. Esegui questa procedura una sola volta all'interno di WSL.

Genera la chiave nella distribuzione anziché sul lato Windows, così la chiave privata resta nel filesystem ext4 con permessi Unix accettati da ssh:

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

Le chiavi Ed25519 sono compatte e veloci, mentre ssh-copy-id aggiunge la chiave pubblica a ~/.ssh/authorized_keys sul server, impostando i permessi corretti. Nozioni di base sulla gestione delle chiavi SSH descrive come ruotarle e revocarle in seguito.

Assegna un nome al server in ~/.ssh/config:

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

A questo punto ssh dev stabilisce la connessione. IdentitiesOnly yes impedisce al client di proporre tutte le chiavi disponibili; è questo che causa Too many authentication failures quando un agent ne contiene diverse. ServerAliveInterval 30 mantiene attiva una sessione su una connessione domestica, evitando che si interrompa senza messaggi.

ForwardAgent yes è la riga che semplifica il flusso di lavoro. Con la chiave caricata nell'agent del laptop, git clone git@github.com:you/app.git funziona sul server senza che la chiave privata venga mai trasferita. Verificalo con ssh -T git@github.com dal VPS; dovrebbe rispondere Hi you! You've successfully authenticated. Inoltra l'agent soltanto verso server attendibili, perché l'account root su quella macchina può usare il socket dell'agent mentre sei connesso. Su un server condiviso con altre persone, una deploy key specifica per repository è la scelta più sicura.

WSL non mantiene attivo un agent tra shell diverse, quindi ogni nuovo terminale richiede nuovamente la chiave. keychain risolve il problema:

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

Apri una nuova shell ed esegui ssh-add -l. Dovrebbe visualizzare l'impronta digitale della chiave. Error connecting to agent indica invece che la riga non viene letta; verifica quindi che la shell esegua effettivamente il source di ~/.bashrc.

Esegui il lavoro sul server all'interno di un terminal multiplexer, così una connessione interrotta non lo termina:

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

La build continua mentre chiudi il laptop: è questo il motivo principale per usare una seconda macchina. Lo stesso approccio consente di eseguire Claude Code su un VPS in tmux e riprendere la sessione da un altro dispositivo.

Metti in sicurezza il server prima di installarvi qualsiasi cosa. I primi dieci minuti su un nuovo VPS descrive come creare un utente non-root, configurare SSH con sole chiavi, impostare un firewall e attivare gli aggiornamenti di sicurezza automatici, nell'ordine che evita di perdere l'accesso.

Quale macchina usare per quale attività?

Usa WSL quando il lavoro si svolge sul tuo computer. Modifica dei file, esecuzione della suite di test, un server di sviluppo su localhost, notebook, esperimenti con GPU: tutto ciò che avvii e poi monitori.

Usa il VPS quando il lavoro deve essere raggiungibile o deve continuare anche dopo la fine della sessione. Un URL di staging che un cliente può aprire, un endpoint webhook, un cron job basato su un orologio reale, un bot, un piccolo database utilizzato da un altro servizio, un'importazione avviata il venerdì pomeriggio.

Se non hai ancora deciso a cosa debba servire la seconda macchina, le attività che vengono realmente eseguite su un VPS offre un elenco più utile di un confronto delle specifiche, mentre che cos'è un VPS spiega il funzionamento della virtualizzazione sottostante. Se i tuoi strumenti funzionano soltanto su Windows, si tratta di una decisione distinta: Linux a confronto con Windows Server è la pagina da consultare.

Un'abitudine impedisce che due macchine diventino due macchine configurate solo parzialmente: il codice risiede in git ed entrambe le macchine sono client del repository. Nulla di importante deve esistere in una sola delle due.

FAQ

Posso ospitare un sito web con un dominio reale da WSL?

Non in modo affidabile. WSL 2 si trova dietro il NAT del computer, il router applica un secondo NAT e la maggior parte delle connessioni domestiche non fornisce una porta in ingresso da inoltrare. Un servizio di tunnel può esporre una porta locale, ma il client del tunnel viene eseguito sul laptop, quindi il sito non è disponibile quando il laptop entra in sospensione. I certificati complicano ulteriormente la situazione, perché la challenge HTTP-01 richiede che Let's Encrypt recuperi un file tramite la porta 80 usando il nome pubblico. Un VPS con un indirizzo IP pubblico e un record A soddisfa entrambe le condizioni senza workaround.

systemctl enable funziona in WSL?

Funziona quando systemd è attivo, cioè dopo aver impostato systemd=true in [boot] in /etc/wsl.conf e aver eseguito wsl --shutdown. Senza questa configurazione, systemctl risponde System has not been booted with systemd as init system (PID 1). Can't operate. Anche con systemd in esecuzione, enable avvia il servizio quando viene avviata la distribuzione, e la distribuzione viene avviata quando si apre una shell. Su un server, lo stesso comando significa che il servizio torna disponibile dopo un riavvio senza che sia necessario effettuare l'accesso.

Perché l'indirizzo IP di WSL continua a cambiare?

Nella modalità NAT predefinita, la macchina virtuale riceve un nuovo indirizzo privato dall'adattatore virtuale WSL ogni volta che viene avviata. Qualsiasi regola netsh interface portproxy o indirizzo codificato nel file di configurazione smette di funzionare dopo wsl --shutdown. Verifica quello attuale con ip -4 addr show eth0. La modalità di rete con mirroring in Windows 11 elimina l'indirizzo separato assegnando alla distribuzione le stesse interfacce di Windows: imposta networkingMode=mirrored in [wsl2] in %UserProfile%\.wslconfig.

/mnt/c è davvero più lento o è un mito?

È più lento, e un minuto di test lo dimostra sulla tua macchina. I file in ~ risiedono su un disco virtuale ext4. I file in /mnt/c vengono forniti tramite il protocollo 9P da un componente lato Windows, quindi ogni chiamata stat attraversa il confine tra i due ambienti e git status su un albero di grandi dimensioni ne esegue migliaia. Copia il repository in ~, esegui time git status due volte in ciascuna posizione e confronta le esecuzioni a regime. Conserva le copie di lavoro in ~ e usa la modalità remota WSL del tuo editor.

Ho ancora bisogno di WSL dopo aver configurato un VPS?

La maggior parte degli utenti mantiene entrambi. WSL è gratuito e si avvia immediatamente, quindi resta l'ambiente in cui modificare e testare il codice; anche le attività che usano la GPU vanno eseguite lì. Il server è la macchina sempre attiva: ospita il nome pubblico ed esegue i processi che devono continuare a funzionare quando il laptop è chiuso. Conserva il codice in git e considera entrambi come client del repository: spostare il lavoro dall'uno all'altro non comporta costi.