Montar un servidor local con Docker en Windows se ha convertido en el pan de cada día para muchos desarrolladores. Tanto si trabajas con aplicaciones web modernas como si mantienes sistemas heredados, tener un entorno reproducible, rápido de levantar y fácil de borrar te ahorra horas de sufrimiento con instalaciones manuales, conflictos de versiones y montones de “funciona en mi máquina”.
El problema llega cuando tu aplicación depende de tecnologías Linux pero tu cliente usa Windows. Es justo el escenario típico: back-end en Linux, front-end y usuario final en Windows 10, 11 o incluso Windows Server. Durante años la solución fácil ha sido tirar de Docker Desktop. Pero eso implica que el usuario tenga que acordarse de arrancarlo, gestionar actualizaciones, lidiar con WSL 2 o Hyper‑V… y no siempre sale bien. Por suerte, hoy podemos montar entornos locales y de servidor bastante finos usando Docker en Windows, tanto con Docker Desktop como con Docker Engine como servicio.
Qué es Docker en Windows y por qué merece la pena usarlo
Aunque Docker nació pegado al kernel de Linux, hoy en día es perfectamente posible usar contenedores también en Windows. La idea no cambia: empaquetar una aplicación con todas sus dependencias en una imagen para ejecutarla como contenedor aislado, sin tener que instalar bibliotecas, frameworks ni servicios directamente en el sistema operativo.
En sistemas Windows modernos, Docker funciona de dos maneras:
- Usando contenedores nativos de Windows (basados en imágenes como Nano Server, Server Core o Windows Server).
- Apoyado en una capa de virtualización (Hyper‑V o WSL 2) para ejecutar contenedores Linux. Esto permite, por ejemplo, que una empresa pueda contenedorizar aplicaciones ASP.NET clásicas en imágenes de Windows Server y, al mismo tiempo, desplegar microservicios Linux en el mismo ecosistema Docker, aunque lo recomendable sea separarlos por tipo de host.
Los contenedores Docker en Windows destacan porque son mucho más ligeros que una máquina virtual. En lugar de levantar un sistema operativo completo por cada servicio, se comparte el núcleo del sistema y cada contenedor aporta solo lo imprescindible para ejecutar la aplicación. Eso se traduce en arranques en segundos y actualizaciones seguras creando nuevas imágenes. Además de la capacidad de volver a una versión anterior en nada si algo falla.
Para quienes quieren modernizar su parque de software heredado, Docker ofrece una forma práctica de encapsular aplicaciones Windows antiguas (por ejemplo, con IIS y ASP.NET clásico) y ejecutarlas en entornos controlados y repetibles. Y para el desarrollo de nuevas aplicaciones, especialmente con stacks mixtos, supone la forma más cómoda de unificar entornos entre Linux, Windows y la nube.
Requisitos para usar Docker en Windows 10, 11 y Windows Server
Antes de lanzarse a instalar nada, conviene tener claro qué pide Docker en cada caso. Porque no es lo mismo un Windows 11 de escritorio que un Windows Server 2022.
En el lado cliente, Docker Desktop está soportado (a grandes rasgos) en Windows 10 Pro/Enterprise con Anniversary Update o Creators Update en adelante, y en Windows 11 siempre que el hardware y la versión del sistema soporten virtualización por hardware. Es importante que la opción de virtualización esté activada en la BIOS/UEFI. Eso es algo que puedes comprobar desde el Administrador de tareas en la pestaña de rendimiento.
En el lado servidor, el motor de Docker se puede instalar en Windows Server 2016, 2019, 2022 y 2025. Para usar aislamiento de Hyper‑V o ejecutar contenedores Linux en escenarios especiales, se requiere que la función Hyper‑V esté disponible y, si el servidor corre dentro de una VM, que esta soporte virtualización anidada y cuente con al menos 4 GB de RAM dedicados para hospedar contenedores.
Para Windows 11 y Windows 10, Docker Desktop se apoya en WSL 2 (Windows Subsystem for Linux). De este modo puede ofrecer una experiencia más cercana a Linux. Esta capa proporciona un kernel Linux ligero. Sobre él se ejecutan los contenedores con una buena integración con el sistema de archivos de Windows.
¿Y la compatibilidad? Docker sigue funcionando de maravilla en las principales distribuciones Linux de 64 bits (Debian, Ubuntu, Fedora, CentOS, Oracle Linux, RHEL, openSUSE, SUSE Enterprise…), ya sea en local o en servidores en la nube como Azure o AWS. Es habitual combinar hosts Windows y Linux según las cargas de trabajo.
Instalar Docker Desktop en Windows 10 y Windows 11
Instalar Docker Desktop en un equipo de desarrollo con Windows es, hoy por hoy, la forma más cómoda de empezar con contenedores. Sobre todo si vas a trabajar con imágenes Linux y quieres algo integrado con el escritorio.
El primer paso es ir a la web oficial de Docker. Allí hay que descargar el instalador de Docker Desktop para Windows. Una vez ejecutas el archivo, el asistente te propondrá habilitar la integración con WSL 2. Es muy recomendable marcar la casilla de “Usar WSL 2 en lugar de Hyper‑V” siempre que tu máquina lo soporte, ya que el rendimiento suele ser mejor y consume menos recursos que una VM tradicional.
Durante la instalación se descargará e instalará el subsistema de Windows para Linux (WSL 2) si aún no lo tienes. En algunos casos, el propio asistente de Docker te dará un enlace directo para descargar el paquete más reciente de WSL 2 desde la web de Microsoft. Solo tienes que seguir el asistente y reiniciar cuando lo pida.
Tras reiniciar, Docker Desktop se lanzará y te mostrará el acuerdo de licencia. El producto es gratuito para uso personal y pequeñas empresas, aunque para organizaciones grandes conviene revisar las condiciones de la licencia para asegurarse de que encaja con el tipo de uso y el tamaño de la empresa.
Para comprobar que todo está listo, puedes abrir PowerShell y lanzar una imagen de prueba como hello-world. Docker descargará la imagen desde Docker Hub y ejecutará el contenedor, mostrando un mensaje de confirmación si todo ha ido bien. Esto te asegura que el motor funciona, que tiene conectividad a Internet y que las imágenes se descargan correctamente.
Instalar Docker Engine en Windows Server
Cuando hablamos de entornos de servidor, especialmente en producción, lo normal no es usar Docker Desktop, sino instalar el motor de Docker como servicio de Windows. En Windows Server 2016, 2019, 2022 o 2025, Microsoft proporciona scripts que facilitan enormemente este proceso.
La forma recomendada en Windows Server 2022, por ejemplo, es abrir una sesión de PowerShell con privilegios de administrador y descargar el script oficial de instalación desde el repositorio de Microsoft en GitHub. Esto se logra con un comando que usa Invoke-WebRequest para traer el script install-docker-ce.ps1 y guardarlo en el disco.
Una vez descargado, solo hay que ejecutar el script desde la misma consola. El script se encargará de instalar Docker CE, registrar el servicio en Windows, configurar la red por defecto de contenedores y reiniciar el host para completar la operación. Al volver a iniciar sesión, ya tendrás el servicio Docker en marcha.
Igual que en Linux, puedes validar la instalación ejecutando un contenedor sencillo como hello-world. Esto te permite ver que el demonio responde bien y que se pueden crear contenedores. Desde ese momento, Docker se comporta como cualquier otro servicio del sistema, administrable desde services.msc o con cmdlets de PowerShell.
Conviene insistir en que, para cargas de trabajo de producción, Microsoft y Docker no recomiendan usar Docker Desktop en Windows Server. Está pensado para desarrollo, no para servidores. En servidores se debe recurrir al motor de Docker instalado como servicio, ya sea Docker EE/CE o el runtime que se utilice para Windows containers.
Configurar Docker Engine en Windows con daemon.json
En Windows Server, lo más limpio para afinar el comportamiento del demonio de Docker es usar un archivo de configuración JSON llamado daemon.json, ubicado en la ruta C:\ProgramData\Docker\config\. Si no existe, puedes crearlo tú mismo respetando el formato JSON.
En este archivo puedes ajustar una gran cantidad de parámetros. Por ejemplo: opciones de red, almacenamiento, logging y DNS hasta configuración de TLS, mirrors de registro o grupos de seguridad para acceder al socket de Docker. No hace falta rellenar todas las claves. Basta con incluir las que quieras personalizar y el resto heredará los valores por defecto.
En entornos donde se requiera cifrado extremo a extremo, se puede habilitar la opción «tlsverify» y especificar las rutas a los certificados de CA, certificado de servidor y clave privada mediante «tlscacert», «tlscert» y «tlskey». Con esta configuración, el demonio solo aceptará conexiones seguras en el puerto definido. Ello resulta clave cuando se expone Docker a otras máquinas en la red.
Además del archivo de configuración, existe la opción de ajustar parámetros del demonio modificando directamente el servicio de Docker con la utilidad sc config y añadiendo flags al binpath. Es menos flexible que daemon.json, pero sigue siendo útil en casos puntuales o entornos donde se prefiera mantener toda la configuración en el propio servicio.
Redes, seguridad y proxy en Docker para Windows
La parte de red en Windows con Docker tiene sus matices. Por defecto, el motor crea una red NAT para los contenedores, de forma que pueden salir a Internet a través del host y exponer puertos hacia el exterior mediante mapeos. Sin embargo, a veces interesa no crear esa red por defecto, por ejemplo en escenarios muy controlados o cuando quieres gestionar tú mismo todas las redes.
Para desactivar la creación de la red NAT predeterminada, se puede establecer en daemon.json el parámetro «bridge» a «none». A partir de ahí, serás tú quien deba definir las redes que usarán los contenedores, ya sea con comandos docker network o a través de orquestadores.
En cuanto al acceso al demonio, cuando trabajas localmente en el host de Docker, los comandos se envían normalmente a través de una named pipe de Windows. Por diseño, solo los miembros del grupo de administradores tienen acceso a esa tubería. Si quieres delegar la gestión de contenedores a un grupo específico, puedes usar el parámetro «group» en la configuración para indicar el nombre del grupo de seguridad que tendrá permiso para hablar con el motor.
En entornos corporativos es también habitual que las máquinas salgan a Internet mediante un proxy HTTP/HTTPS. Para que docker pull o docker search funcionen correctamente detrás de un proxy, tendrás que definir variables de entorno HTTP_PROXY y/o HTTPS_PROXY a nivel de máquina.
Para redes avanzadas, Windows ofrece comandos como Get-HNSNetwork y Remove-HNSNetwork para gestionar las redes creadas por Docker y el subsistema de redes de host de Windows. Esto resulta especialmente útil cuando estás limpiando un servidor o resolviendo conflictos de configuración que han quedado tras desinstalaciones o cambios agresivos.
Ejecutar contenedores Windows y Linux en el mismo host
A nivel técnico es posible combinar contenedores Windows y Linux en la misma máquina, pero conviene entender las implicaciones. Docker Desktop permite cambiar entre modo Windows y modo Linux, y en Windows Server existe la opción de aislamiento por Hyper‑V que habilita contenedores Linux mediante virtualización ligera.
Aun así, desde un punto de vista operativo, se recomienda mantener separados los hosts según el tipo de contenedor que vayan a ejecutar. Es mucho más cómodo para el administrador tratar con servidores que ejecutan exclusivamente contenedores Linux o exclusivamente contenedores Windows, ya que las imágenes base, herramientas de depuración y patrones de uso cambian bastante entre ambos mundos.
Para contenedores Windows existen varias imágenes base oficiales de Microsoft publicadas en repositorios como Docker Hub o el Microsoft Container Registry (MCR). Entre ellas destacan:
- Nano Server (la más ligera, ideal para aplicaciones modernas).
- Server Core (pensada para aplicaciones de servidor).
- Windows y Windows Server (las más completas, con compatibilidad total de API).
Cuando levantes un contenedor basado en Server Core, verás que el shell por defecto es PowerShell, no bash. Esto puede confundir al principio. Sobre todo porque el prompt del contenedor y el del host se parecen mucho y un despiste puede llevarte a ejecutar comandos peligrosos en el lugar equivocado. El comando hostname dentro del contenedor te mostrará el identificador del contenedor, no el del servidor físico o la VM.
Por diseño, los contenedores están pensados para ser desechables y reemplazables. La administración se centra en crear, ejecutar y eliminar contenedores, no en «cuidar» de ellos como si fueran máquinas virtuales a largo plazo. Cualquier configuración persistente debería estar en la imagen o fuera del contenedor (volúmenes, configuración externa), porque lo que cambies a mano dentro del contenedor se perderá al destruirlo.
Servidor web Node.js con recarga en caliente
A partir del «Hola Mundo» en consola puedes convertir tu ejemplo en un pequeño servidor HTTP usando express. Definiendo un app.get sobre la ruta «/» que responda con un texto simple y escuchando en el puerto 3000, ya tienes un entorno web funcional.
En docker-compose.yml puedes ajustar el comando de arranque a algo como sh -c «npm install; npm start» para que el contenedor instale dependencias la primera vez y luego arranque nodemon con app.js. Además, es el momento de mapear el puerto 3000 del contenedor al 3000 del host mediante la clave ports, de manera que puedas acceder desde el navegador a http://localhost:3000 (o a la IP de la VM si estás usando Docker Toolbox o un host Linux remoto).
Si después amplías la lógica de app.js para aceptar rutas dinámicas, por ejemplo «/:nombre» y devolver «Hola <nombre>!», podrás comprobar cómo cada cambio en el código se refleja al instante sin tener que reconstruir la imagen ni reiniciar manualmente el contenedor. Es exactamente el comportamiento de LiveReload, pero encapsulado en una imagen portátil que mañana puedes desplegar en un servidor Linux o en la nube.
Este patrón de trabajo con volúmenes y nodemon se puede trasladar a otros lenguajes y frameworks. Lo interesante es que el entorno de ejecución vive dentro del contenedor. Tu Windows solo actúa como host, lo que reduce mucho los roces con dependencias y versiones de librerías de otros proyectos.
Para proyectos más complejos, docker-compose.yml puede declarar varios servicios (base de datos, cache, cola de mensajes…) y enlazarlos entre sí. En Windows, mientras uses Docker Desktop con WSL 2, todo este entorno seguirá comportándose casi igual que en un Linux nativo.
Uso típico de Docker en Windows Server con IIS y aplicaciones heredadas
Más allá del desarrollo, muchas empresas quieren aprovechar Docker para encapsular aplicaciones Windows heredadas que usan IIS, ASP clásico o versiones antiguas de .NET. En estos casos, lo habitual es partir de una imagen base de Windows Server Core con IIS preinstalado.
Un contenedor de este tipo puede crearse con docker run especificando la imagen de IIS adecuada, el nombre del contenedor, el mapeo de puertos (por ejemplo, 8081:80 para exponer el puerto 80 interno en el 8081 del host) y montando una carpeta del host como c:\inetpub\wwwroot para depositar ahí los archivos de la aplicación.
Si arrancas el contenedor en modo interactivo, entrarás en una sesión de PowerShell dentro del servidor IIS contenedor. Desde ahí puedes inspeccionar logs, revisar configuraciones y, en general, entender cómo se comporta tu aplicación en este nuevo entorno. Cuando quieras parar la sesión sin tirar el contenedor, bastará con utilizar exit o detenerlo desde el host.
Si lo que necesitas es que la aplicación siga viva en segundo plano, lo ideal es arrancar el contenedor con el flag -d para que se ejecute en modo «detached». A partir de ahí, su gestión se hace como la de cualquier otro contenedor: docker ps para listar, docker logs para revisar registros, docker stop para apagarlo y docker rm para borrarlo cuando ya no te haga falta.
La creación de imágenes personalizadas para Windows funciona exactamente igual que en Linux. Se define un Dockerfile con las instrucciones de copia, instalación y configuración, se construye la imagen con docker build y luego se etiqueta y se publica en un registro privado si la vas a usar en varios servidores. La única diferencia práctica es que en Windows aceptas tanto barras normales como invertidas en las rutas, aunque conviene ser consistente para evitar confusiones.
Desinstalar Docker y limpieza completa en Windows
Si alguna vez tienes que quitar Docker por completo de una máquina Windows 10 o Windows Server 2016/2019, es importante seguir una secuencia ordenada. Así se evitará dejar basura por detrás ni perder datos que quisieras conservar.
Lo primero es asegurarte de que no haya contenedores corriendo. Puedes salir de cualquier «swarm» que tengas activo con docker swarm leave –force y luego detener todos los contenedores en ejecución con una combinación de docker ps –quiet piped a docker stop. A partir de ahí, puedes hacer un docker system prune –all –volumes si lo que quieres es un borrado agresivo de contenedores, imágenes, redes y volúmenes.
En Windows 10, la desinstalación de Docker Desktop se hace desde Configuración > Aplicaciones > Aplicaciones y características, buscando «Docker» en la lista, seleccionándolo y pulsando en Desinstalar. En Windows Server 2016, si instalaste Docker mediante módulos de PowerShell como DockerMsftProvider, la desinstalación pasa por Uninstall-Package y Uninstall-Module para eliminar tanto el paquete docker como el proveedor.
Una vez desinstalado el software, es buena idea eliminar las redes HNS asociadas a Docker con los comandos que proporciona el sistema. También borrar la carpeta C:\ProgramData\Docker con Remove-Item -Recurse para quitar los datos de programa restantes. Esto liberará el espacio que ocupaban imágenes y capas de contenedores.
En muchos equipos, la instalación de Docker Activó automáticamente características opcionales de Windows como Contenedores y, en algunos casos, Hyper‑V. Si ya no tienes intención de usar contenedores en esa máquina, puedes deshabilitar estas características desde el Panel de control en Windows 10 (Programas y características > Activar o desactivar características de Windows) o con Remove-WindowsFeature Containers / Hyper-V en Windows Server.
Tras todos estos pasos, lo sensato es reiniciar el sistema con Restart-Computer -Force desde una consola elevada. Así, todos los cambios de características y servicios se aplicarán correctamente y dejarás el equipo en un estado limpio.