WSL o VPS para desarrollo: diferencias clave

¿Debería usar WSL o un VPS para desarrollo?

La elección entre WSL y un VPS para desarrollo se reduce a una propiedad: la disponibilidad. WSL (Windows Subsystem for Linux) ejecuta Ubuntu dentro de una máquina virtual que se inicia y se detiene junto con su sesión de Windows. Un VPS (servidor privado virtual) ejecuta el mismo Ubuntu en una dirección IP pública que permanece activa incluso cuando cierra su portátil. La mayoría de los desarrolladores terminan usando ambos, empleando el servidor como la máquina que permanece accesible.

El sistema operativo no es la diferencia relevante, ya que ambos son Ubuntu. Lo que difiere es el tiempo de actividad, la accesibilidad desde internet, lo que systemd puede garantizar, la velocidad de los archivos, el comportamiento de la red y quién gestiona las copias de seguridad. Cada sección a continuación detalla una diferencia que puede observar en su propia máquina.

¿Por qué WSL se detiene al cerrar el portátil?

WSL 2 ejecuta un kernel de Linux real dentro de una máquina virtual ligera que Windows inicia bajo demanda. Esa máquina virtual solo existe mientras una distribución está en ejecución, y una distribución solo se ejecuta mientras algo la esté utilizando. Compruebe el estado desde PowerShell:

wsl --version
wsl --list --running

Cierre todas las terminales de WSL, espere un minuto y vuelva a ejecutar wsl --list --running. Cuando informe que no hay distribuciones en ejecución, el shell que inició habrá desaparecido, al igual que todo lo que estaba ejecutando. wsl --shutdown realiza la misma acción de forma inmediata, lo cual es una forma útil de probar cómo se comporta su configuración tras un reinicio.

La suspensión y la hibernación también detienen la máquina virtual. Un temporizador configurado para volcar una base de datos a las 03:00 no se activará mientras la tapa esté cerrada, porque el kernel que debería ejecutarlo no está en ejecución. No se registra ningún error, por lo que parece que la tarea nunca se llegó a programar. Este comportamiento es el motivo por el cual los usuarios recurren a una segunda máquina: una cola de compilación, un bot de chat, una copia de seguridad nocturna o un receptor de webhooks necesitan un equipo que permanezca encendido.

¿Funciona systemd en WSL?

Sí. El soporte llegó en WSL 0.67.6 y está desactivado por defecto en instalaciones antiguas. Sin él, systemctl status ssh muestra:

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

Lea primero el archivo de configuración, ya que es posible que ya tenga uno. Si no tiene una sección [boot], añádala; si ya existe, añada la línea única dentro de la sección que ya está allí.

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

Ejecute wsl --shutdown en PowerShell, abra una nueva terminal de Ubuntu y verifique con systemctl list-units --type=service --state=running. Una lista de unidades significa que systemd es el PID 1 y que journalctl -b funciona a partir de ese momento.

El inconveniente es lo que enable promete en cada máquina. En un VPS, sudo systemctl enable --now caddy significa que el servicio se inicia al arrancar, por lo que vuelve a estar activo tras un reinicio o una actualización del kernel sin necesidad de que nadie haya iniciado sesión. En WSL significa que el servicio se inicia cuando se inicia la distribución, y la distribución se inicia cuando usted abre una terminal. Por lo tanto, el servicio solo está activo mientras usted trabaja, lo cual es opuesto a la razón de ser de los servicios. Los contenedores heredan la misma carencia, razón por la cual hacer que los servicios de Docker Compose se inicien al arrancar depende de un arranque que WSL solo realiza cuando usted lo solicita.

¿Puede un webhook llegar a un servidor que se ejecuta en WSL?

No sin ayuda, y la razón es la configuración de red. En su modo predeterminado, WSL 2 coloca la máquina virtual detrás de NAT (traducción de direcciones de red) en su propio adaptador virtual. Observe la dirección:

ip -4 addr show eth0
ip route show default

Esa dirección es privada y se asigna de nuevo cada vez que la máquina virtual se inicia, por lo que cambia. Windows todavía puede acceder a localhost:3000, porque WSL redirige las conexiones de localhost hacia la distribución. Otra máquina en su red no puede, a menos que añada una regla de proxy desde una consola de PowerShell con privilegios de administrador:

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

Esa regla especifica una dirección, por lo que deja de funcionar la próxima vez que la dirección cambie. La red reflejada (mirrored networking) es la mejor opción: la distribución obtiene las mismas interfaces y direcciones que Windows. A fecha de agosto de 2026, requiere Windows 11 22H2 o superior. Coloque esto en %UserProfile%\.wslconfig y ejecute wsl --shutdown:

[wsl2]
networkingMode=mirrored

El modo reflejado soluciona el problema de la red local. No le proporciona una dirección pública. Su router ejecuta NAT de nuevo, la mayoría de las conexiones domésticas no tienen puertos de entrada que usted controle y muchos proveedores de servicios de Internet añaden otra capa de NAT por encima. Por lo tanto, GitHub no puede realizar un POST de un evento a su portátil y un colega no puede abrir su enlace de demostración. Un servicio de túnel soluciona esto, pero el cliente del túnel se ejecuta en el portátil, lo que significa que el portátil sigue siendo la máquina que debe permanecer encendida.

Un VPS parte del otro lado de ese problema. Tiene una dirección IPv4 pública y, por lo general, una dirección IPv6 pública, con solo los puertos que usted abra. Apunte un registro A hacia él, permita los puertos 80 y 443, y responderá desde cualquier lugar. Esa es también la condición para un certificado público, ya que el desafío HTTP-01 solicita a Let's Encrypt que obtenga un archivo a través del puerto 80 en el nombre público. Obtener un certificado de Let's Encrypt con Certbot y nginx es una tarea de cinco minutos en un servidor e imposible en WSL. Para el trabajo local, todavía puede obtener HTTPS de confianza en el navegador dentro de WSL añadiendo su propia CA al almacén de confianza de Ubuntu.

¿Por qué git es lento en /mnt/c?

Porque los archivos no están en el sistema de archivos de Linux. WSL ofrece dos áreas de almacenamiento con costes muy distintos. Su directorio home reside en un sistema de archivos ext4 dentro de un disco virtual y se comporta como un disco de Linux convencional. /mnt/c es la unidad de Windows, servida mediante el protocolo 9P (protocolo de sistema de archivos Plan 9) por un componente del lado de Windows, por lo que cada apertura y cada llamada stat cruza ese límite.

Un archivo no supone un problema. git status en un repositorio grande realiza miles de llamadas stat, y cada una paga el coste del cruce. Mídalo en lugar de confiar en una cifra de cualquiera, incluida 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

Ejecute cada una dos veces y compare las segundas ejecuciones para que ambas estén en caché. El análisis antivirus en tiempo real de Windows añade más coste en el lado de /mnt/c, razón por la cual el mismo repositorio puede sentirse más lento en un portátil de empresa que en uno personal.

La solución dentro de WSL es mantener la copia de trabajo bajo ~ y abrirla con el modo remoto WSL de su editor, el cual ejecuta el servidor del editor dentro de la distribución en lugar de cruzar el límite. Explorer puede seguir navegando por esos archivos en \\wsl.localhost\Ubuntu\home\you. Un VPS no tiene este problema, ya que existe un único sistema de archivos y es Linux. Lo que se paga ahí es la latencia de red durante la edición, por lo que se suele trabajar en un multiplexor de terminal o en una sesión de editor remoto. La CPU compartida es la advertencia honesta en un servidor pequeño, y el tiempo de robo de un vecino ruidoso aparece en top como la columna st.

Donde WSL destaca claramente

• Es gratuito y ya está en la máquina. Actívelo, instale Ubuntu y estará trabajando en un minuto, sin costes y sin superficie pública que defender.
• Es desechable de una forma que un servidor no lo es. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar escribe toda la distribución en un solo archivo y wsl --import la restaura o la clona con otro nombre. Probar una nueva versión de Ubuntu aquí es cuestión de clonar y revertir, mientras que actualizar un VPS de 24.04 a 26.04 es un proceso unidireccional que debe planificarse según los servicios que ya están ejecutándose en él.
• El trabajo con GPU es directo. Con un controlador de GPU de Windows actual, la tarjeta está disponible dentro de la distribución, por lo que las cargas de trabajo de CUDA y ROCm se ejecutan sobre hardware que usted ya posee. Alquilar una GPU de la misma categoría por horas cuesta dinero real.
• El ciclo de edición es más corto. Sus archivos y su navegador son locales, por lo que un servidor de desarrollo en localhost:5173 se abre en el navegador en el que ya ha iniciado sesión.

Estas son ventajas reales y son la razón por la que la respuesta habitual es utilizar ambas máquinas en lugar de solo una.

¿Quién es el propietario de las copias de seguridad?

Usted lo es, en ambas máquinas, y WSL es donde esto sorprende a los usuarios. La distribución es un archivo de disco virtual (ext4.vhdx) dentro de su perfil de usuario de Windows. Ningún proveedor realiza instantáneas (snapshots) por usted. wsl --unregister Ubuntu lo elimina sin posibilidad de deshacer, y una reinstalación de Windows lo borra junto con todo lo demás. Exporte el archivo siguiendo una programación que realmente pueda cumplir:

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

En un VPS, la instantánea del proveedor le protege contra un fallo del host. No le protege contra un rm -rf en el directorio incorrecto, y una instantánea almacenada en la misma cuenta que el servidor puede perderse con un solo inicio de sesión comprometido. Envíe las copias de seguridad a nivel de archivo fuera del servidor y realice una restauración de prueba antes de que sea necesario. La responsabilidad recae sobre usted en ambos casos. La diferencia práctica es que un servidor puede enviar su propia copia de seguridad a las 03:00 sin necesidad de que nadie deje un portátil encendido.

El puente: SSH desde WSL hacia el VPS

Tener una segunda máquina parece una carga solo hasta que la conexión se configura correctamente. Realice esto una vez dentro de WSL.

Genere la clave en la distribución en lugar de en el lado de Windows, para que la clave privada permanezca en el sistema de archivos ext4 con los permisos de Unix que ssh acepta:

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

Las claves Ed25519 son cortas y rápidas, y ssh-copy-id añade la clave pública a ~/.ssh/authorized_keys en el servidor con los modos correctos. Conceptos básicos de gestión de claves SSH cubre cómo rotarlas y revocarlas más adelante.

Asigne un nombre al servidor en ~/.ssh/config:

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

Ahora ssh dev se conecta. IdentitiesOnly yes evita que el cliente ofrezca todas las claves que contiene, que es lo que produce Too many authentication failures cuando un agente tiene varias cargadas. ServerAliveInterval 30 evita que una sesión en una conexión doméstica se cierre sin previo aviso.

ForwardAgent yes es la línea que hace que el flujo de trabajo sea sencillo. Con su clave cargada en el agente de la computadora portátil, git clone git@github.com:you/app.git funciona en el servidor sin que la clave privada llegue nunca allí. Pruébelo con ssh -T git@github.com desde el VPS, que debería responder Hi you! You've successfully authenticated. Reenvíe el agente solo a servidores en los que confíe, ya que el usuario root en esa máquina puede usar el socket de su agente mientras usted está conectado. En un servidor que comparte con otras personas, una clave de despliegue por repositorio es la opción más segura.

WSL no mantiene un agente activo entre shells, por lo que cada terminal nueva solicita la clave de nuevo. keychain resuelve esto:

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

Abra una shell nueva y ejecute ssh-add -l. Debería imprimir la huella digital de la clave. Error connecting to agent en su lugar significa que la línea no se está leyendo, así que verifique que su shell realmente cargue ~/.bashrc.

Ejecute el trabajo en el servidor dentro de un multiplexor de terminal, para que una conexión interrumpida no lo detenga:

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

La compilación continúa mientras cierra la computadora portátil, que es la razón principal para tener la segunda máquina. El mismo patrón es el que utilizan las personas para ejecutar Claude Code en un VPS dentro de tmux y retomar la sesión desde otro dispositivo.

Refuerce el servidor antes de instalar nada en él. Los primeros diez minutos en un VPS nuevo detalla el uso de un usuario no root, SSH solo con claves, un firewall y actualizaciones de seguridad automáticas, en el orden que evita que se quede fuera del sistema.

¿Qué máquina para qué tarea?

Utilice WSL cuando el trabajo se realice en su pantalla. Edición, ejecución de suites de pruebas, servidores de desarrollo en localhost, notebooks, experimentos con GPU; cualquier cosa que inicie y supervise directamente.

Utilice el VPS cuando el trabajo deba ser accesible desde el exterior o deba persistir tras finalizar su sesión. Una URL de pruebas que un cliente pueda abrir, un endpoint para webhooks, una tarea cron con un reloj real, un bot, una base de datos pequeña con la que interactúen otros servicios o una importación que inicie un viernes por la tarde.

Si aún está decidiendo para qué sirve la segunda máquina, la lista de cosas que la gente realmente ejecuta en un VPS es más útil que una comparación de especificaciones, y qué es un VPS explica la virtualización subyacente. Si sus herramientas solo funcionan en Windows, esa es una decisión distinta, y Linux comparado con Windows Server es la página adecuada para ello.

Un hábito evita que dos máquinas se conviertan en dos equipos configurados a medias: el código reside en git y ambas máquinas son clientes del repositorio. Nada importante debe existir únicamente en una de ellas.

FAQ

¿Puedo alojar un sitio web con un dominio real desde WSL?

No de forma fiable. WSL 2 se encuentra detrás de NAT dentro de su máquina, su router vuelve a aplicar NAT y la mayoría de las conexiones domésticas no permiten redirigir puertos de entrada. Un servicio de túnel puede exponer un puerto local, pero el cliente del túnel se ejecuta en el portátil, por lo que el sitio se cae cada vez que el portátil entra en suspensión. Los certificados complican aún más la situación, ya que el desafío HTTP-01 requiere que Let's Encrypt obtenga un archivo a través del puerto 80 en el nombre público. Un VPS con una dirección IP pública y un registro A cumple ambas condiciones sin necesidad de soluciones alternativas.

¿Funciona systemctl enable en WSL?

Funciona una vez que systemd está activo, lo que implica systemd=true bajo [boot] en /etc/wsl.conf seguido de wsl --shutdown. Sin esto, systemctl responde System has not been booted with systemd as init system (PID 1). Can't operate.. Incluso con systemd en ejecución, enable inicia el servicio cuando se inicia la distribución, y la distribución se inicia cuando usted abre una terminal. En un servidor, el mismo comando significa que el servicio se reinicia tras un reinicio del sistema sin necesidad de que haya nadie conectado.

¿Por qué mi dirección IP de WSL cambia constantemente?

En el modo NAT predeterminado, la máquina virtual recibe una nueva dirección privada del adaptador virtual de WSL cada vez que se inicia. Cualquier regla netsh interface portproxy o dirección codificada de forma rígida deja de funcionar después de wsl --shutdown. Compruebe la dirección actual con ip -4 addr show eth0. El modo de red reflejada en Windows 11 elimina la dirección independiente al otorgar a la distribución las mismas interfaces que Windows: configure networkingMode=mirrored bajo [wsl2] en %UserProfile%\.wslconfig.

¿Es /mnt/c realmente más lento o es un mito?

Es más lento, y un minuto de pruebas lo demuestra en su propia máquina. Los archivos bajo ~ residen en un disco virtual ext4. Los archivos bajo /mnt/c se sirven a través del protocolo 9P por un componente del lado de Windows, por lo que cada llamada stat cruza el límite y git status sobre un árbol grande realiza miles de ellas. Copie el repositorio a ~, ejecute time git status dos veces en cada ubicación y compare las ejecuciones en caliente. Mantenga las copias de trabajo bajo ~ y utilice el modo remoto WSL de su editor.

¿Sigo necesitando WSL una vez que tengo un VPS?

La mayoría de la gente mantiene ambos. WSL es gratuito y se inicia al instante, por lo que sigue siendo el lugar donde editar y probar, y el trabajo con GPU también pertenece allí. El servidor es la máquina que permanece encendida: mantiene el nombre público y ejecuta las tareas que deben sobrevivir al cierre del portátil. Mantenga el código en git y trate a ambos como clientes del repositorio; mover el trabajo entre ellos no tiene coste.