WSL ou VPS: qual é melhor para desenvolver?

Deve usar WSL ou um VPS para desenvolvimento?

A escolha entre WSL e um VPS para desenvolvimento resume-se a uma propriedade: disponibilidade. O WSL (Windows Subsystem for Linux) executa o Ubuntu numa máquina virtual que inicia e termina com a sua sessão do Windows. Um VPS (virtual private server) executa o mesmo Ubuntu num endereço IP público que continua ativo enquanto o seu portátil está fechado. A maioria dos programadores acaba por usar ambos, com o servidor a funcionar como a máquina que permanece acessível.

O sistema operativo não é a diferença relevante, porque ambos usam Ubuntu. O que muda é o tempo de atividade, a acessibilidade a partir da Internet, o que o systemd pode garantir, a velocidade dos ficheiros, o comportamento da rede e quem mantém as cópias de segurança. Cada secção abaixo apresenta uma diferença que pode observar na sua própria máquina.

Por que o WSL para quando se fecha o laptop?

O WSL 2 executa um kernel Linux real numa máquina virtual leve que o Windows inicia sob demanda. Essa máquina virtual existe apenas enquanto uma distribuição está em execução, e uma distribuição só funciona enquanto há algo a utilizá-la. Verifique o estado no PowerShell:

wsl --version
wsl --list --running

Feche todos os terminais WSL, aguarde um minuto e execute wsl --list --running novamente. Quando indicar que não há distribuições em execução, a shell iniciada desapareceu, assim como tudo o que estava a executar. wsl --shutdown faz o mesmo imediatamente, o que é uma forma útil de testar o comportamento da configuração depois de um reinício.

A suspensão e a hibernação também param a máquina virtual. Um temporizador configurado para descarregar uma base de dados às 03:00 não é executado enquanto a tampa está fechada, porque o kernel que o executaria não está em funcionamento. Nenhum erro é registado, por isso parece que o trabalho nunca foi agendado. Este comportamento é suficiente para levar as pessoas a utilizar uma segunda máquina: uma fila de builds, um chatbot, uma cópia de segurança noturna ou um recetor de webhooks precisam de um computador que permaneça ligado.

O systemd funciona no WSL?

Sim. O suporte chegou no WSL 0.67.6 e fica desativado por padrão nas instalações mais antigas. Sem esse suporte, systemctl status ssh apresenta:

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

Leia primeiro o ficheiro de configuração, porque pode já existir um. Se não tiver uma secção [boot], acrescente uma. Se já tiver essa secção, adicione a linha única dentro da secção existente.

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

Execute wsl --shutdown no PowerShell, abra uma nova shell do Ubuntu e verifique com systemctl list-units --type=service --state=running. Uma lista de unidades significa que o systemd é o PID 1. A partir desse momento, journalctl -b funciona.

O ponto importante é o que enable garante em cada máquina. Num VPS, sudo systemctl enable --now caddy significa que o serviço arranca no boot. Por isso, volta a arrancar depois de um reboot ou de uma atualização do kernel, mesmo sem ninguém ter iniciado sessão. No WSL, significa que o serviço arranca quando a distribuição arranca, e a distribuição arranca quando abre um terminal. Assim, o serviço fica ativo apenas enquanto está a trabalhar. Isto é contrário à razão pela qual os serviços existem. Os contentores têm a mesma limitação. Por isso, fazer os serviços do Docker Compose arrancarem no boot depende de um boot que o WSL só executa quando lhe é pedido.

Uma webhook consegue alcançar um servidor em execução no WSL?

Não sem configuração adicional, devido à topologia da rede. No modo predefinido, o WSL 2 coloca a máquina virtual atrás de NAT (network address translation), num adaptador virtual próprio. Consulte o endereço:

ip -4 addr show eth0
ip route show default

Esse endereço é privado e é atribuído novamente sempre que a máquina virtual arranca, pelo que muda. O próprio Windows ainda consegue alcançar localhost:3000, porque o WSL encaminha as ligações a localhost para a distribuição. Outro computador da sua rede não consegue, a menos que adicione uma regra de proxy a partir de um PowerShell com privilégios de Administrator:

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

Essa regra especifica um único endereço, pelo que deixa de funcionar quando o endereço muda. A rede em modo mirrored é uma opção melhor: a distribuição recebe as mesmas interfaces e os mesmos endereços que o Windows. Em agosto de 2026, precisa do Windows 11 22H2 ou posterior. Coloque isto em %UserProfile%\.wslconfig e execute wsl --shutdown:

[wsl2]
networkingMode=mirrored

O modo mirrored resolve o problema da rede local. Não lhe fornece um endereço público. O router volta a executar NAT, a maioria das ligações domésticas não tem uma porta de entrada que possa controlar e muitos ISPs acrescentam outra camada de NAT. Por isso, o GitHub não consegue enviar um evento por POST para o seu portátil e um colega não consegue abrir a ligação para a sua demonstração. Um serviço de túnel contorna este problema, mas o cliente do túnel é executado no portátil. Isso significa que o portátil continua a ser a máquina que tem de permanecer ligada.

Um VPS começa do lado oposto desse problema. Tem um endereço IPv4 público e, normalmente, um endereço IPv6 público, com apenas as portas que abrir. Aponte um registo A para esse endereço, permita as portas 80 e 443 e o servidor responderá a partir de qualquer rede. Essa também é a condição para obter um certificado público, porque o desafio HTTP-01 pede ao Let's Encrypt que obtenha um ficheiro através da porta 80 no nome público. Obter um certificado Let's Encrypt com Certbot e nginx é uma tarefa de cinco minutos num servidor e é impossível no WSL. Para trabalho local, ainda pode obter HTTPS validado pelos browsers dentro do WSL adicionando a sua própria CA ao trust store do Ubuntu.

Porque o git é lento em /mnt/c?

Porque os ficheiros não estão no sistema de ficheiros Linux. O WSL disponibiliza duas áreas de armazenamento com custos muito diferentes. O seu diretório pessoal está num sistema de ficheiros ext4 dentro de um disco virtual e comporta-se como um disco Linux normal. /mnt/c é a unidade do Windows, disponibilizada através do protocolo 9P (protocolo de sistema de ficheiros Plan 9) por um componente do lado do Windows. Por isso, cada operação de abertura e cada chamada stat atravessam esse limite.

Um ficheiro não causa problemas. git status num repositório grande faz milhares de chamadas stat, e cada uma paga o custo dessa passagem. Meça o desempenho em vez de confiar num valor fornecido por qualquer pessoa, incluindo esta página:

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

Execute cada comando duas vezes e compare a segunda execução, para que ambas usem dados em cache. A análise antivírus em tempo real do Windows acrescenta custos no lado /mnt/c. Por isso, o mesmo repositório pode parecer mais lento num portátil da empresa do que num portátil pessoal.

No WSL, a solução é manter a cópia de trabalho em ~ e abri-la com o modo remoto WSL do seu editor. Esse modo executa o servidor do editor dentro da distribuição, em vez de atravessar o limite. O Explorer continua a poder navegar nesses ficheiros em \\wsl.localhost\Ubuntu\home\you. Um VPS não tem este problema, porque existe um único sistema de ficheiros e ele é Linux. Nesse caso, o custo é a latência da rede durante a edição. Por isso, é comum trabalhar num multiplexador de terminal ou numa sessão de editor remoto. A utilização partilhada do CPU é a limitação relevante num servidor pequeno, e o tempo roubado por um vizinho ruidoso aparece em top como a coluna st.

Onde o WSL é claramente superior

• É gratuito e já está disponível na máquina. Ative-o, instale o Ubuntu e comece a trabalhar num minuto, sem custos e sem uma superfície pública para proteger.
• É descartável de uma forma que um servidor não é. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar grava toda a distribuição num ficheiro, e wsl --import restaura-a ou clona-a com um segundo nome. Experimentar uma nova versão do Ubuntu aqui significa criar um clone e poder fazer rollback. Atualizar um VPS de 24.04 para 26.04 é uma alteração de sentido único que tem de ser planeada em função dos serviços que já estão em execução.
• O trabalho com GPU é direto. Com um controlador de GPU atual do Windows, a placa fica disponível dentro da distribuição. Assim, as cargas de trabalho CUDA e ROCm usam hardware que já possui. Alugar uma GPU da mesma classe à hora tem um custo real.
• O ciclo de edição é mais curto. Os ficheiros e o browser estão ambos locais. Por isso, um servidor de desenvolvimento em localhost:5173 abre no browser em que já iniciou sessão.

Estas são vantagens reais. É por isso que a resposta habitual é usar as duas máquinas, e não escolher apenas uma.

Quem é responsável pelos backups?

É você, nas duas máquinas. No WSL, isso costuma surpreender. A distribuição é um ficheiro de disco virtual (ext4.vhdx) dentro do seu perfil de utilizador do Windows. Nenhum fornecedor cria snapshots desse ficheiro por si. wsl --unregister Ubuntu elimina-o sem possibilidade de desfazer a operação, e uma reinstalação do Windows elimina-o juntamente com todo o resto. Exporte-o segundo um calendário que consiga realmente cumprir:

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

Num VPS, o snapshot do fornecedor protege contra uma falha do host. Não protege contra rm -rf no diretório errado. Além disso, um snapshot mantido na mesma conta que o servidor desaparece com ele se as credenciais dessa conta forem roubadas. Envie backups ao nível dos ficheiros para fora da máquina e faça uma restauração antes de precisar dela. A responsabilidade é sua nos dois casos. A diferença prática é que um servidor pode enviar o seu próprio backup às 03:00 sem depender de alguém deixar um portátil ligado.

A ponte: SSH do WSL para o VPS

Uma segunda máquina só parece um incómodo até a ligação estar configurada corretamente. Faça isto uma vez dentro do WSL.

Gere a chave na distribuição, e não no lado do Windows, para que a chave privada permaneça no sistema de ficheiros ext4, com as permissões Unix aceites por ssh:

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

As chaves Ed25519 são curtas e rápidas, e ssh-copy-id acrescenta a chave pública a ~/.ssh/authorized_keys no servidor, com os modos corretos. Noções básicas de gestão de chaves SSH explica como as rodar e revogar mais tarde.

Dê um nome ao servidor em ~/.ssh/config:

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

Agora ssh dev estabelece a ligação. IdentitiesOnly yes impede que o cliente apresente todas as chaves que tem disponíveis. Isto evita Too many authentication failures quando um agente tem várias chaves carregadas. ServerAliveInterval 30 mantém uma sessão numa ligação doméstica ativa, para que não termine sem uma mensagem.

ForwardAgent yes é a linha que torna o fluxo de trabalho simples. Com a sua chave carregada no agente do portátil, git clone git@github.com:you/app.git funciona no servidor sem que uma chave privada seja alguma vez colocada nele. Teste com ssh -T git@github.com a partir do VPS. O comando deve responder Hi you! You've successfully authenticated. Encaminhe o agente apenas para servidores em que confia, porque o root dessa máquina pode usar o socket do seu agente enquanto estiver ligado. Num servidor partilhado com outras pessoas, uma chave de implementação por repositório é uma opção mais segura.

O WSL não mantém um agente ativo entre shells, por isso cada novo terminal pede novamente a chave. keychain resolve este problema:

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

Abra um novo shell e execute ssh-add -l. O comando deve apresentar a impressão digital da chave. Error connecting to agent significa que a linha não está a ser lida. Nesse caso, confirme que o seu shell carrega realmente ~/.bashrc.

Execute o trabalho no servidor dentro de um multiplexador de terminal, para que uma ligação interrompida não o termine:

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

A compilação continua enquanto fecha o portátil. Essa é a razão principal para ter uma segunda máquina. O mesmo padrão permite executar Claude Code num VPS com tmux e retomar a sessão noutro dispositivo.

Reforce a segurança da máquina antes de instalar qualquer coisa nela. Os primeiros dez minutos num VPS novo explica como configurar o utilizador sem privilégios root, o SSH apenas com chaves, uma firewall e atualizações de segurança automáticas, pela ordem que evita bloquear o seu próprio acesso.

Qual máquina usar para cada tarefa?

Use o WSL quando o trabalho acontece no seu ecrã. Isso inclui editar, executar a suite de testes, manter um servidor de desenvolvimento em localhost, usar notebooks, fazer experiências com GPU ou iniciar algo que ficará a monitorizar.

Use a VPS quando o trabalho tiver de estar acessível ou continuar depois de terminar a sua sessão. Isso inclui uma URL de staging que um cliente possa abrir, um endpoint de webhook, um cron job com um relógio real, um bot, uma base de dados pequena usada por outro serviço ou uma importação iniciada na sexta-feira à tarde.

Se ainda estiver a decidir para que serve a segunda máquina, as tarefas que as pessoas realmente executam numa VPS é uma lista mais útil do que uma comparação de especificações, e o que é uma VPS explica a virtualização subjacente. Se as suas ferramentas só funcionarem no Windows, essa é uma decisão separada, e Linux comparado com Windows Server é a página indicada.

Um hábito impede que duas máquinas se transformem em duas máquinas parcialmente configuradas: o código fica no git, e ambas as máquinas são clientes do repositório. Nada importante existe apenas numa delas.

FAQ

Posso alojar um site com um domínio real a partir do WSL?

Não de forma fiável. O WSL 2 fica atrás de NAT dentro do seu computador, o router aplica NAT novamente e a maioria das ligações domésticas não fornece uma porta de entrada que possa encaminhar. Um serviço de túnel pode expor uma porta local, mas o cliente do túnel é executado no portátil, por isso o site fica indisponível sempre que o portátil entra em suspensão. Os certificados complicam ainda mais a situação, porque o desafio HTTP-01 exige que o Let's Encrypt obtenha um ficheiro através da porta 80 no nome público. Um VPS com um endereço IP público e um registo A cumpre ambas as condições sem soluções alternativas.

O systemctl enable funciona no WSL?

Funciona quando o systemd está ativo, o que significa systemd=true em [boot] dentro de /etc/wsl.conf, seguido de wsl --shutdown. Sem isso, systemctl responde System has not been booted with systemd as init system (PID 1). Can't operate. Mesmo com o systemd em execução, enable inicia o serviço quando a distribuição inicia, e a distribuição inicia quando abre uma shell. Num servidor, o mesmo comando significa que o serviço volta a iniciar depois de um reboot, sem ninguém ter iniciado sessão.

Por que razão o endereço IP do meu WSL está sempre a mudar?

No modo NAT predefinido, a máquina virtual recebe um novo endereço privado do adaptador virtual do WSL sempre que inicia. Qualquer regra netsh interface portproxy ou endereço definido de forma fixa deixa de funcionar depois de wsl --shutdown. Consulte o endereço atual com ip -4 addr show eth0. O modo de rede em espelho do Windows 11 elimina o endereço separado ao atribuir à distribuição as mesmas interfaces que o Windows: defina networkingMode=mirrored em [wsl2] dentro de %UserProfile%\.wslconfig.

O /mnt/c é realmente mais lento ou isso é um mito?

É mais lento, e um minuto de testes comprova isso na sua própria máquina. Os ficheiros em ~ ficam num disco virtual ext4. Os ficheiros em /mnt/c são disponibilizados através do protocolo 9P por um componente do lado do Windows, por isso cada chamada stat atravessa a fronteira, e git status numa árvore grande faz milhares dessas chamadas. Copie o repositório para ~, execute time git status duas vezes em cada localização e compare as execuções em cache. Mantenha as cópias de trabalho em ~ e use o modo remoto WSL do seu editor.

Ainda preciso do WSL depois de ter um VPS?

A maioria das pessoas mantém ambos. O WSL é gratuito e inicia imediatamente, por isso continua a ser o local onde edita e testa, e o trabalho com GPU também deve ser feito aí. O servidor é a máquina que permanece ligada: mantém o nome público e executa os trabalhos que têm de sobreviver ao encerramento do portátil. Mantenha o código no git e trate ambos como clientes do repositório; assim, mover o trabalho entre eles não tem custo.