Stop Running Docker Desktop: Offload Your Builds to a VPS Instead

Abre el Monitor de Actividad o el Administrador de tareas, arranca un contenedor pequeño, y Docker Desktop aún puede convertirse en lo más ruidoso de la máquina. En una incidencia de Docker Desktop de febrero de 2026, un usuario informó de com.docker.backend.exe que subía al 100% de CPU después de arrancar los contenedores, y seguía así incluso después de detenerlos.

Hay otra opción: saca el demonio de tu portátil por completo. Mantén solo el CLI de Docker en local, ejecuta Docker Engine en un VPS Linux y apunta docker context a él por SSH. Tu docker build no cambia. La compilación simplemente se ejecuta en otro sitio, sobre Linux nativo sin capa de VM, con el ancho de banda del VPS descargando las imágenes base en lugar de la wifi de tu cafetería, y sin ninguna licencia de Docker Desktop que controlar.

Esta es la configuración completa para esa vía: requisitos previos, los comandos exactos de docker context , compilaciones multiarquitectura con un driver de buildx remoto, cómo dimensionar la máquina, y dónde el enfoque remoto es la elección equivocada.

TL;DR

• El problema: Docker Desktop arrastra una VM local, empuja la E/S de archivos a través de una capa de virtualización, y requiere una suscripción de pago para uso profesional en organizaciones grandes, incluidas las empresas que superan los límites del nivel gratuito de Docker.
• La solución: elimina Docker Desktop. Ejecuta Docker Engine en un VPS Linux, crea un docker context que apunte a él por SSH, y tu docker build local se ejecuta en el VPS mientras tu CLI solo orquesta.
• El marco de costes: un VPS modesto sustituye a una licencia por asiento y te da la velocidad de compilación de Linux nativo. Un equipo entero puede compartir una única máquina de compilación en lugar de pagar por desarrollador.
• Las advertencias honestas: el VPS tiene que estar accesible (nada de compilar en un avión), y necesitas disciplina con .dockerignore para no subir un contexto de compilación de varios gigabytes en cada ejecución.

Requisitos previos: lo que necesitarás

Antes del primer comando, ten esto a mano. Nada aquí es exótico si ya usas Docker a diario.

• A Linux VPS con acceso root o sudo. Ubuntu 22.04/24.04 o Debian 12/13 funcionan bien.
• Docker Engine en el VPS. docker context por SSH necesita Docker Engine 18.09 o posterior en el host remoto, según la documentación de contextos de Docker.
• Docker CLI 19.03 o posterior en local. Ese es el cliente que entiende el comando de nivel superior context comando.
• An Un par de claves SSH. Solo autenticación por clave: la autenticación por contraseña no está soportada para docker context las conexiones SSH.
• El usuario remoto en el grupo docker grupo, para que pueda hablar con el socket del demonio sin sudo en cada llamada.

Lo que Docker Desktop te cuesta en realidad

Los costes no son un misterio. Se concentran en tres sitios, y quien ha llegado hasta aquí buscando ha sentido al menos uno de ellos. Nombrarlos con precisión es lo importante. Ya conoces el dolor.

Memoria y sobrecarga de la VM. Docker Desktop sigue implicando una VM Linux local. La documentación de ajustes de Docker dice que Docker Desktop puede limitar cuánta memoria usa la VM de Docker Desktop, que es la parte silenciosa del problema: sigue habiendo una VM de por medio. La huella exacta varía según el sistema operativo y el proyecto, pero los modos de fallo son reales. Una incidencia de Docker para Windows informa de que Docker Desktop consume muchos gigabytes de RAM sin ningún contenedor en ejecución, y una incidencia de WSL2 describe que las compilaciones de Docker dejan memoria sin liberar después de terminar los contenedores. La cuestión no es que cada máquina esté inactiva en el mismo número. Es que Docker Desktop mantiene la sobrecarga de la VM local dentro de tu bucle de desarrollo.

Velocidad de compilación y de E/S de archivos. Los montajes de tipo bind y las operaciones de archivos que cruzan la frontera de la VM son más lentos que el acceso nativo al sistema de archivos de Linux. La documentación de problemas conocidos de Docker reconoce el coste del sistema de archivos de virtualización. Los bancos de pruebas de la comunidad informan de forma habitual de algo en el rango de 3-10x más lento para los montajes bind a través de la capa de VM. Ese segundo número es experiencia de la comunidad, no un banco de pruebas publicado por Docker, pero la dirección no la discute nadie que haya visto una compilación arrastrarse en un Mac.

Licencias. Desde el cambio de 2021, Docker Desktop requiere una suscripción de pago para empresas de más de 250 empleados o con más de 10 M$ de ingresos. Los niveles actuales en la página de precios de Docker son Personal ($0), Pro ($11/mo o $9 anuales), Team ($16/mo o $15 anuales) y Business ($24/mo). El nivel Team pasó de $9 a $15 anuales en diciembre de 2024, un salto que convierte una partida silenciosa en una conversación de compras, que es la parte que de verdad escuece cuando lo multiplicas por treinta asientos.

Las alternativas y la bifurcación local frente a remoto

Casi todas las alternativas a Docker Desktop que encontrarás cambian un demonio local por otro demonio local. Ese es el verdadero eje que hay que notar: la elección sobre la que la mayoría se agobia es entre herramientas locales, cuando la bifurcación más interesante es local frente a remoto. Solo la vía remota quita la VM de tu máquina.

Este es el panorama, en paralelo.

Algunas de estas merecen una frase de honestidad:

• OrbStack resuelve de verdad el problema de recursos en Mac para un desarrollador en solitario. Afirma ~300 MB en reposo y un arranque de contenedores hasta 10x más rápido (el sitio de OrbStack), ambos números del proveedor, no bancos de pruebas independientes. Si eres un desarrollador solo en Mac que no quiere gestionar infraestructura remota, OrbStack es la mejor opción, y su nivel comercial de $8/mo (precios de OrbStack) queda por debajo del nivel Team de Docker Desktop. La pega: es solo para Mac, y la licencia comercial trae de vuelta justo aquello de lo que intentabas escapar.
• Colima es gratis y prioriza el CLI, pero sus asperezas de "no es un reemplazo directo" están bien documentadas, y algunos equipos acaban volviendo a Docker Desktop tras una migración que se atasca.
• Podman Desktop y Rancher Desktop son ambos gratuitos y multiplataforma. Ninguno es un reemplazo directo y silencioso, y la compatibilidad con Compose de Podman pasa por su socket compatible con Docker.
• Docker Offload es el servicio gestionado de compilación/ejecución remota del propio Docker, pero no es una salida limpia de Docker Desktop. La documentación actual de Docker lo lista como algo que requiere Docker Desktop 4.68 o posterior, una suscripción a Docker Business y una suscripción a Docker Offload. Ejecuta las cargas en hosts en la nube gestionados por Docker, pero cada usuario obtiene una sesión de Offload a la vez, las sesiones inactivas terminan tras un periodo de gracia de 5 minutos, y el entorno es efímero, así que los contenedores, imágenes y volúmenes desaparecen cuando la sesión termina. Eso está bien si quieres capacidad remota gestionada dentro de Docker Desktop. No es lo mismo que un compilador en VPS persistente con tu propia caché, disco, acceso root y sin dependencia de Desktop.

Quedarse quieto sigue siendo racional en un caso: una persona por debajo del umbral del nivel gratuito y sin dolor de velocidad de compilación no tiene ninguna razón para cambiar nada. Todos los demás tienen una bifurcación que decidir.

Conclusión clave de la sección: la decisión que importa no es qué herramienta local elegir. Es si mantienes un demonio en tu portátil o no.

Cómo funciona docker context por SSH

Para compilar imágenes de Docker en un servidor remoto por SSH, ejecuta Docker Engine en ese servidor, crea un docker context que apunte a él con docker context create name --docker "host=ssh://user@host", luego ejecuta docker context use name. Después de eso, tu docker build normal se ejecuta en el host remoto, y el CLI local solo envía instrucciones mientras el demonio hace el trabajo.

Un contexto es un destino con nombre e intercambiable para el CLI de Docker. En lugar de hacer malabares con variables de entorno DOCKER_HOST o de montar un túnel SSH a mano cada vez, defines el remoto una vez y cambias a él como si cambiaras de directorio. La compilación se ejecuta por completo en el host remoto: las descargas de imágenes base usan el enlace de subida del VPS, las capas se cachean en el disco del VPS, y el trabajo de CPU ocurre en los núcleos del VPS. Los únicos pasos sensibles a la latencia son el apretón de manos SSH inicial y la subida de tu contexto de compilación. Todo lo demás es remoto.

Configurar tu máquina de compilación en VPS

Toda la configuración son cuatro comandos cortos más un bloque de configuración SSH. Mostraré la salida esperada donde te ayude a confirmar que cada paso ha funcionado.

Paso 1: pon Docker Engine en un VPS Linux. Aprovisiona la máquina e instala Docker Engine (18.09+ en el remoto es el mínimo para el SSH de contextos; tu CLI local necesita 19.03+). Si prefieres no hacer la instalación tú mismo, despliega un VPS que ya lo incluya (más sobre eso abajo). El usuario remoto tiene que estar en el grupo docker:

sudo usermod -aG docker $USER

# log out and back in for the group change to take effect

Paso 2: configura la autenticación por clave SSH y un alias de configuración. La autenticación por clave es obligatoria. Dale al host un alias corto en ~/.ssh/config para no reescribir la IP y la ruta de la clave:

# ~/.ssh/config
Host my-vps
  HostName 1.2.3.4
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Paso 3: crea el contexto. Apúntalo al demonio remoto por SSH. Usa la forma sin abreviar:

docker context create my-vps --docker "host=ssh://[email protected]"

O, usando el alias de configuración SSH del paso 2:

docker context create my-vps --docker "host=ssh://my-vps"

Paso 4: verifica. Lista tus contextos y comprueba que el motor remoto responde:

docker context ls

NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
my-vps                                                ssh://my-vps

docker --context=my-vps version

Si eso imprime la versión del servidor del demonio remoto, tu CLI está hablando con el VPS.

Paso 5: cambia y compila. Haz del VPS el destino activo y luego compila con normalidad:

docker context use my-vps

docker build -t myapp .

Esa compilación se ejecuta en el VPS. ¿Prefieres no cambiar de forma global? Apunta a un solo comando:

docker --context=my-vps build -t myapp .

O configúralo para la sesión de shell:

export DOCKER_CONTEXT=my-vps

Cuando quieras recuperar el demonio local de tu portátil (si conservaste uno), vuelve a casa:

docker context use default

Consejo: cuida tu .dockerignore. El contexto de compilación se sube al host remoto antes de que empiece la compilación. Un node_modules or .git hace que envíes gigabytes por la red en cada ejecución, y la vía remota se sentirá más lenta que la local sin ningún motivo. Un .dockerignore ajustado es lo que más influye en si la vía remota se siente rápida: excluye dependencias, artefactos de compilación y metadatos de control de versiones, y la subida se convierte en un error de redondeo.

Compilaciones multiarquitectura con un driver de buildx remoto

Crea un builder de buildx que ejecute BuildKit dentro de un contenedor en el host Docker remoto, y luego compila contra él:

docker buildx create --name remote-builder \
  --driver docker-container \
  --use \
  ssh://ubuntu@your-vps-ip

docker buildx inspect --bootstrap

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64 \
  -t myapp:latest \
  --load .

El --load importa para el consumo local de una sola plataforma: con el driver docker-container driver, las imágenes compiladas no aparecen automáticamente en tu lista de imágenes local. Si estás compilando una imagen multiplataforma de verdad, súbela a un registro en su lugar:

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/myapp:latest \
  --push .

Esa distinción es importante. Una compilación remota de una sola plataforma se puede cargar de vuelta en tu almacén de imágenes local. Una imagen multiplataforma normalmente se sube a un registro, porque es una lista de manifiestos con variantes separadas para cada arquitectura de destino. Esta sección es opcional: si todas tus imágenes son de una sola arquitectura, la configuración de contexto de arriba es todo el trabajo.

Dimensionar y proteger la máquina de compilación

Dos preguntas deciden si esta máquina te sirve bien: cuánto de grande hacerla y cómo mantener el demonio bien protegido. Las compilaciones de Docker están limitadas por CPU, así que la lógica de dimensionamiento va sobre todo de núcleos y de RAM suficiente para evitar el swap. La lógica de seguridad va sobre todo de no exponer el demonio a nadie más que a ti.

Con qué tamaño montarla

Dale especificaciones genéricas. Puedes trasladarlas a lo que ofrezca tu proveedor.

• Mínimo (un solo dev, compilaciones ligeras): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• Lo que yo desplegaría en la práctica (la mayoría de los equipos): 4 vCPU / 8-12 GB RAM / 240-300 GB NVMe. Four vCPUs stop your parallel build steps from serializing, 8-12 GB handles concurrent builds without touching swap, and the NVMe headroom keeps a healthy layer cache.
• Equipo o CI intensivo: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

Como las compilaciones están limitadas por CPU, los núcleos de alta frecuencia (optimizados para CPU) te dan una iteración más rápida más que la RAM extra pasado el umbral del swap. Los planes con GPU son irrelevantes aquí, ya que las compilaciones de imágenes no tocan la GPU. Y la elección de centro de datos afecta solo a la capacidad de respuesta de SSH y al tiempo de subida del contexto, no a la velocidad de compilación: la compilación se ejecuta en el VPS estés donde estés, así que elige una ubicación cercana a ti para un apretón de manos ágil y sigue adelante.

Proteger el demonio remoto

La configuración de arriba ya fuerza el valor por defecto correcto: autenticación por clave SSH, ningún puerto del demonio expuesto a la red. Mantenlo así. En el momento en que expongas BuildKit o el demonio más allá de SSH (un endpoint TCP en crudo, un puerto de BuildKit abierto), te conviertes en un objetivo. El hilo de Hacker News sobre compilaciones lentas que planteó por primera vez la idea del VPS remoto también advertía sobre ataques de criptominería en endpoints de BuildKit expuestos. Un demonio de compilación sin autenticar en la Internet abierta es un bufé de cómputo gratis.

Consejo: no expongas el demonio. Si con solo SSH te basta (le basta a la mayoría de las configuraciones de una sola máquina), nunca abras un puerto TCP del demonio . Si de verdad necesitas acceso TCP, pon un TLS mutuo (mTLS) por delante para que solo los clientes con un certificado válido puedan conectarse. Solo SSH o mTLS: no hay una tercera opción aceptable para una máquina de compilación accesible desde Internet.

Una vez que la máquina está en marcha, es un servidor Linux de propósito general, y hay mucho más que merece la pena ejecutar en ella. Nuestra guía de stack autoalojado para creadores indie es una buena siguiente lectura sobre qué más se gana un sitio en tu VPS.

Si prefieres saltarte la instalación de Docker Engine e ir directo a docker context create, nuestra app de Docker del marketplace despliega un VPS con Docker Engine, Compose V2 y buildx ya configurados. Un clic y la máquina está lista para SSH, así que el tutorial de arriba empieza en el paso 2 en lugar del paso 1.

Preguntas frecuentes

¿Puedo ejecutar compilaciones de Docker en un servidor remoto y usar mi CLI local?

Sí. Ejecuta Docker Engine en el host remoto, crea un docker context que apunte a él por SSH, y cambia a ese contexto. Tu docker build local se ejecuta entonces en el servidor remoto mientras el CLI de tu máquina solo orquesta, sin ningún demonio local necesario.

¿Cuál es la diferencia entre docker context y DOCKER_HOST?

A docker context es un destino con nombre, intercambiable y persistente que defines una vez y seleccionas con docker context use. DOCKER_HOST es una única variable de entorno que pones y quitas a mano en cada shell. El contexto es el reemplazo moderno del viejo enfoque de túnel más variable de entorno.

¿Funciona docker compose con un contexto remoto?

Sí. Compose V2 respeta el contexto activo de Docker, así que los comandos docker compose se ejecutan contra el host al que apunte el contexto. Los servicios y cualquier compilación de imágenes se ejecutan en el host remoto, igual que un docker build.

¿Qué es Docker Offload y es gratis?

Docker Offload es el servicio gestionado de compilación/ejecución remota del propio Docker para mover el trabajo de contenedores a hosts en la nube gestionados por Docker manteniendo el flujo de Docker Desktop. La documentación actual de Docker lo lista como algo que requiere Docker Desktop 4.68 o posterior, además de suscripciones a Docker Business y Docker Offload. También se basa en sesiones: cada usuario obtiene una sesión de Offload a la vez, las sesiones inactivas terminan tras un periodo de gracia de 5 minutos, y el entorno remoto es efímero.

¿Cómo evito que Docker Desktop use tanta memoria?

Ajustar los límites de recursos de Docker Desktop solo reduce una huella que nunca llega a cero, porque la VM siempre tiene un mínimo. La vía que de verdad elimina el coste de memoria es quitar el demonio local por completo: ejecuta Docker Engine en un VPS y conéctate mediante docker context por SSH, para que en tu máquina no corra nada más que el CLI.

¿Puedo hacer esto con Podman en su lugar?

Puedes. Podman está disponible como motor compatible con Docker, y docker context puede apuntar a un host remoto de Podman, pero eso requiere que Podman exponga su socket compatible con Docker por SSH. El flujo de comandos es el mismo. La configuración en el lado remoto difiere.