Docker Desktop cobra: ¿qué alternativa gratuita usar?

En pocas palabras: Sí: el motor dockerd es Apache-2.0 y corre gratis dentro de WSL2, sin pagar la suscripción de Docker Desktop. Microsoft ya integra su propio runtime, wslc.exe, desde WSL 2.9.3+, aunque todavía no expone la API Docker completa hacia Windows.

Docker Desktop pide suscripción paga desde 2021 en empresas que superan cierto tamaño, y ya hay quien armó una alternativa gratuita a Docker Desktop usando el motor libre que corre atrás. Microsoft, mientras tanto, integra su propio runtime, wslc.exe, en WSL 2.9.3+, aunque todavía no expone la API Docker completa.

Docker Desktop es la aplicación de escritorio que Docker Inc. distribuye para Windows y macOS, con interfaz gráfica, gestión de la máquina virtual de Linux y canal de actualizaciones propio. wslc.exe es el runtime de contenedores que Microsoft integra en Windows Subsystem for Linux desde la versión 2.9.3, con un motor Moby real corriendo adentro, pero sin puerto ni pipe expuesto hacia Windows.

¿Qué parte de Docker Desktop es paga y cuál es gratis en realidad?

La parte que cobra Docker Inc. es la aplicación de escritorio, no el motor de contenedores. Desde 2021, Docker Desktop exige suscripción paga a empresas que superan cierto tamaño, según describe el análisis que destapó el tema. El motor que corre atrás, dockerd, tiene licencia Apache-2.0 y anda perfecto adentro de WSL2 sin pagar un peso.

Pensalo así: instalás el motor en una distro WSL2, le servís la API en el pipe que docker.exe ya conoce (\\.\pipe\docker_engine), Compose sigue andando sin enterarse de nada, buildx tampoco nota el cambio, y lo único que tenés que acordarte es apagar la distro cuando no la usás, porque si no el proceso vmmem se queda ahí sentado consumiendo memoria (spoiler: eso es lo primero de lo que se van a quejar tus compañeros). Lo que vende Docker Desktop, en el fondo, es la interfaz gráfica, la gestión de la VM y el soporte técnico, no el motor.

¿Qué es wslc.exe, el runtime de contenedores que ya trae Windows?

wslc.exe es el runtime de contenedores que Microsoft empieza a integrar de manera nativa en WSL, disponible desde la versión 2.9.3 como pre-release según la documentación oficial de WSL container. Corre un motor Moby genuino, el mismo dockerd de siempre, y tiene una CLI parecida a la de Docker, rumbo a disponibilidad general aunque sin fecha confirmada todavía.

El autor del análisis original no se quedó con la palabra de Microsoft: entró a revisar qué corría adentro de la sesión de wslc y confirmó que es un dockerd de verdad hablando por un socket Unix, no una reimplementación con nombre parecido (sí, en serio, fue a mirar el socket). Para instalarlo hay que correr wsl --update --pre-release y confirmar con wsl --version. Una vez arriba, los comandos son directos: wslc run --rm hello-world para probar que anda, wslc image list para ver imágenes, wslc container list para contenedores corriendo. Microsoft también publicó un tutorial paso a paso con un ejemplo completo armando una imagen de Django a partir de un Containerfile.

Para quien programa aplicaciones Windows en C# o C++, hay algo más: el paquete NuGet Microsoft.WSL.Containers expone objetos como WslcService, Session, Container y Process para manejar contenedores desde código, sin pasar por la CLI. En el proceso de instalación paso a paso profundizamos sobre esto.

¿Por qué wslc.exe no alcanza para Compose, Testcontainers ni buildx?

Porque el motor arranca sin flag -H: no abre pipe con nombre, no abre puerto TCP, no deja ninguna ruta de entrada desde Windows. El motor está completo, pero inalcanzable para cualquier cosa que no sea la propia CLI de wslc.

Ahí está el problema real. Docker Compose, Testcontainers, Dev Containers, buildx, act, Dagger y cualquier herramienta que monte docker.sock hablan el protocolo de la API Docker, no ejecutan comandos de wslc. Como wslc solo imita el CLI de Docker para build y run, ahí se termina la imitación. ¿Tu pipeline de CI depende de Compose para levantar tres servicios? Nada anda, porque no hay API que Compose pueda tocar.

Esa brecha, un motor real sin puerta de entrada, es la razón concreta por la que sigue teniendo sentido instalar algo que sirva la API completa arriba del motor que ya tenés, sea el de wslc o uno independiente.

¿Cómo se comparan wslc y una alternativa que sí expone la API Docker?

Ninguno de los dos gana en todo: wslc es más rápido en llamadas de control plane y puertos publicados, mientras que un motor servido con API completa gana en volúmenes con nombre y usa menos memoria porque no levanta una segunda máquina virtual. Según las mediciones que publicó el autor del análisis, corridas en Windows 10 Pro 22H2 con WSL 2.9.11 y 4 vCPU / 7,8 GB de RAM visibles para cada VM, los números quedan bastante parejos en lo que la mayoría hace todo el día: correr un contenedor. Cubrimos ese tema en detalle en conectarte por SSH a una máquina virtual.

Métrica	wslc	Motor con API completa
Listar contenedores (mediana de 10)	53 ms	74 ms
Listar imágenes (mediana de 10)	57 ms	276 ms
exec en contenedor corriendo	109 ms	155 ms
run –rm alpine true (warm)	538 ms	528 ms
Lectura bind mount 256 MB	760 MB/s	192 MB/s
Escritura volumen con nombre 256 MB	1,5 GB/s	1,7-2,1 GB/s
Memoria en reposo	~750 MB (VM propia)	451 MB (motor compartido)

El caso más raro de la tabla es “listar imágenes”: 57 ms contra 276 ms, una diferencia de 3,3 veces que a primera vista parece un problema de la alternativa. El autor lo verificó pegándole directo al socket Unix del motor, sin pipe, sin vsock, sin código de por medio, y el resultado dio el mismo ratio: dockerd tarda eso en calcular el tamaño de las imágenes, algo que le costaría lo mismo a Docker Desktop. wslc gana esa carrera porque hace una pregunta más barata, no porque tenga mejor plomería.

Con bind mounts de carpetas Windows, wslc gana clarito gracias a virtiofs. Ese margen se cierra activando virtiofs también en la distro, una clave nueva que llega con WSL 2.9, que deja a la alternativa a la par de wslc. En volúmenes con nombre, que es donde vive la data de un proyecto real, la alternativa gana: entre 1,7 y 2,1 GB/s de escritura contra 1,5 GB/s de wslc.

¿Cuál es la alternativa gratuita a Docker Desktop que tiene sentido hoy en Windows?

Depende de qué necesite tu flujo de trabajo. Si tu día a día pasa por docker compose up, Testcontainers en los tests o Dev Containers en VS Code, wslc.exe todavía no sirve como reemplazo directo porque no expone la API que esas herramientas necesitan. Ahí la alternativa gratuita real pasa por levantar el motor con algo que sirva ese endpoint sobre WSL2, sea un proyecto de comunidad como el que describe la fuente u opciones ya conocidas como Rancher Desktop o Podman Desktop.

Rancher Desktop suma interfaz gráfica y clúster de Kubernetes integrado, también corre en macOS y Linux, y es gratuito y de código abierto. Podman Desktop apunta a contenedores sin privilegios de raíz por default, aunque hay que aceptar una API compatible con Docker en vez de la de Docker mismo. Ninguna de las dos, eso sí, resuelve fijar la versión exacta del motor para evitar el clásico “funciona en mi máquina, falla en CI” por drift de versiones, tarea que solo hacen herramientas más nicho pensadas para eso. Esto se conecta con lo que analizamos en comparamos el rendimiento entre Windows y Ubuntu.

Para equipos con builds multiarquitectura hay una trampa que no es exclusiva de ninguna alternativa: un motor WSL2 sin retoques no trae los handlers de qemu, así que docker buildx build --platform linux/arm64 tira exec format error. Docker Desktop instala binfmt solo; en cualquier motor propio hay que sumarlo a mano, y como ese estado vive en el kernel de la VM de utilidad de WSL2, se borra cada vez que corrés wsl --shutdown.

Errores comunes al migrar de Docker Desktop en Windows

• Pensar que wslc.exe es un reemplazo 1:1 de Docker Desktop. No expone la API Docker hacia Windows, así que Compose, Testcontainers y buildx quedan afuera hasta que eso cambie.
• Dejar el motor prendido todo el día por las dudas. Un motor WSL2 sin apagar sostiene una VM consumiendo memoria en reposo; conviene apagar la distro con wsl --shutdown cuando no la estás usando.
• No fijar la versión del motor entre tu máquina y el CI. El clásico “funciona local, falla en CI” casi siempre es drift de versión de dockerd, containerd o BuildKit, y ni Docker Desktop ni Rancher ni Podman lo resuelven de fábrica.
• Asumir que los builds cross-arch andan solos en cualquier motor WSL2. Sin binfmt instalado, un build para linux/arm64 desde un host amd64 tira exec format error; Docker Desktop lo resuelve solo, un motor propio necesita el contenedor privilegiado que lo instala.

Preguntas Frecuentes

¿Docker Desktop es gratis o pago en 2026?

Sigue gratis para uso personal, educativo y en empresas chicas, pero desde 2021 exige suscripción paga a empresas que superan cierto tamaño, según describe el análisis publicado en dev.to. El motor de contenedores que usa por dentro, dockerd, tiene licencia Apache-2.0 y es gratuito sin importar el tamaño de la empresa.

¿Qué es wslc.exe de Microsoft?

Es el runtime de contenedores que Microsoft integra de manera nativa en Windows Subsystem for Linux desde la versión 2.9.3, con una CLI parecida a la de Docker. Corre un motor Moby real dentro de la sesión de WSL, pero sin exponer la API Docker hacia Windows.

¿Cómo corro contenedores en Windows sin Docker Desktop?

Instalando el motor dockerd, que es gratis y open source, dentro de una distro WSL2 y sirviendo su API en el pipe que el cliente docker.exe ya usa. Con esa API servida, Compose, buildx y el resto de las herramientas siguen funcionando igual que con Docker Desktop instalado. Relacionado: montar un firewall de aplicaciones con contenedores.

¿wslc reemplaza a Docker Compose y Testcontainers?

No, todavía no. wslc arranca su motor sin flag -H, sin pipe con nombre y sin puerto TCP, así que ninguna herramienta que hable la API Docker (Compose, Testcontainers, Dev Containers, buildx) se puede conectar a él por ahora.

¿Qué alternativas gratuitas hay a Docker Desktop en Windows?

Aparte de wslc.exe, el runtime propio de Microsoft, limitado a build y run, hay opciones gratuitas y de código abierto como Rancher Desktop, que suma interfaz gráfica y Kubernetes integrado, y Podman Desktop, pensado para contenedores sin privilegios de raíz. También existen proyectos de comunidad que sirven la API Docker completa arriba del motor que WSL2 ya trae instalado.

Conclusión

Lo que cambió no es que Docker Desktop se volvió malo, es que dejó de ser la única puerta de entrada al motor. Microsoft metió un pie con wslc.exe, y es un motor Moby real, no un invento de marketing, pero todavía no es el “reemplazo total” que promete la novedad: sin API expuesta, Compose y Testcontainers siguen sin poder hablarle.

Si tu flujo depende de esas herramientas, la salida práctica hoy pasa por servir la API Docker completa arriba del motor que WSL2 ya trae, con Rancher Desktop, Podman Desktop o un proyecto de comunidad equivalente al que describe la fuente. Antes de migrar, probá tu pipeline de CI completo contra la alternativa elegida (no solo docker run hello-world) y fijá la versión del motor si la herramienta lo permite: eso evita sorpresas el día que algo funcione en tu laptop y explote en el runner.

Fuentes

• Microsoft Learn – WSL container (documentación oficial de wslc.exe y la API)
• Microsoft Learn – Tutorial para empezar con contenedores en WSL
• dev.to – Docker Desktop costs money now. Your Windows box already has the engine