Docker Cloud Sandboxes: ejecuta agentes en tu laptop o en la nube con un solo comando

septiembre 28, 2026 Alfonso Moreno | Sysadmin Senior 34 Visitas 10 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 1-2 horas para el primer multi-stage, 30 min para los siguientes.
Requisitos: Docker 24+ con BuildKit habilitado.
Resultado: Imágenes 80-95% más pequeñas, builds 50-70% más rápidos.
Troubleshooting: DOCKER_BUILDKIT=1, dive para analizar layers, troubleshooting sin shell con stage debug.

Por qué Docker Sandboxes se mudó a la nube

Docker presentó Cloud Sandboxes el 24 de septiembre de 2026 como una extensión directa de Docker Sandboxes, la línea de microVMs aisladas que la compañía lanzó a principios de año. Si ya leíste nuestra guía sobre Docker en producción: 5 prácticas clave que evitan desastres, la idea te resultará familiar: cada agente de código corre dentro de una microVM con kernel y daemon propios, separada de tu máquina. La diferencia es que, hasta hace poco, esa microVM vivía en tu laptop. Ahora también puede vivir en cómputo administrado por Docker, y mover entre las dos superficies cuesta un solo comando.

El motivo que da el equipo de Docker — Timir Karia (Sr. Principal PM) y Srini Sekaran (Principal PMM for AI) — no es técnico sino operativo: los agentes de IA ya no hacen ráfagas cortas. Trabajan horas. Una laptop duerme cuando cierras la tapa, se frena con batería baja y se desconecta cuando te mueves. Eso no importa para una tarea de treinta segundos; importa para una refactorización que dura toda la noche. Cloud Sandboxes responde a la pregunta “¿cómo dejo a un agente correr 21 horas seguidas sin mirarlo?” con la misma respuesta que Docker Sandboxes ya tenía para “¿es seguro correrlo desatendido?”: microVM aislada, modelos de seguridad idénticos, comandos idénticos.

Qué cambió exactamente y qué no

Cloud Sandboxes es la misma microVM, ejecutada sobre cómputo administrado por Docker. El modelo de aislamiento es idéntico: kernel propio, daemon Docker propio, archivos y secretos del host protegidos. La CLI es idéntica. Lo que cambia es el sustrato físico: máquinas siempre encendidas y tantas como necesites.

El anuncio oficial destaca cuatro comportamientos habilitados por esa mudanza:

Cerrar la laptop y dejar la tarea corriendo: inicias un agente en la nube antes de salir, te desconectas y revisas lo que hizo por la mañana.
Empezar local y mudarte a la nube cuando la tarea excede la laptop: iteras con un agente sobre el código que tienes enfrente y luego le pasas tareas largas.
Correr 100 tareas en paralelo sin provisionar nada: Docker administra el cómputo; tú apuntas tus agentes. Cada uno obtiene su propia microVM, secretos y política de red.
Probar barato: levantas un agente preconstruido por una hora para validar una idea y luego lo apagas.

La operación central de todo el flujo es sbx move: captura el filesystem del sandbox actual y lo recrea del otro lado, en cualquier dirección. Si tu sandbox local llegó a la mitad de un refactor de un monorepo y la laptop se está quedando sin batería, sbx move my-project --to cloud continúa la tarea en cómputo cloud sin perder archivos.

Qué necesitas para usar Cloud Sandboxes hoy

El plan de instalación sigue siendo tres comandos. No hay requisito de Docker Desktop en la laptop — los Sandboxes locales siguen siendo standalone y gratuitos.

# 1. Instalar el cliente sbx (brew en macOS o binario en Linux)
brew install docker/tap/sbx
# 2. Autenticarte con tu cuenta Docker
sbx login
# 3. Levantar tu primer agente en la nube
sbx --cloud run claude

El cliente sbx requiere versión 0.45.1 o superior. Si tu versión local está por debajo, brew upgrade docker/tap/sbx o reemplaza el binario con el release más reciente desde el repo docker/sbx-releases en GitHub.

Para correr en la nube necesitas el plan pay-as-you-go, disponible tanto en Docker Personal como en Docker Pro. Las cuentas nuevas reciben USD 250 de crédito promocional durante un tiempo limitado (el cupón está en docker.com/c/sbx-promo/).

Kits: agentes preconfigurados listos para usar

Un Kit es un sandbox preconfigurado y preconstruido para un agente específico. Docker ya soporta los principales del mercado 2026: Claude Code, Codex, Copilot, Antigravity, Open Code y Hermes. La sintaxis es uniforme:

# Lanzar Codex en Cloud Sandboxes
sbx --cloud run codex
# Lanzar Claude Code en Cloud Sandboxes
sbx --cloud run claude
# Lanzar Hermes en Cloud Sandboxes
sbx --cloud run hermes

Si tu agente favorito no aparece en la lista oficial, el SDK de Kit Specification v3 — publicado el mismo 24 de septiembre — te permite empaquetar reglas de red, credenciales y volúmenes como una imagen OCI pineable. Es el mismo formato que usa Docker internamente para distribuir los Kits oficiales, así que un Kit propio se comporta exactamente igual que uno de catálogo.

MCP, secretos y políticas: la gobernanza por defecto

Cloud Sandboxes incluye tres primitivas que faltaban en el flujo típico “lanza un agente y reza”:

MCP Gateway: conectas una vez los servidores MCP que tus agentes necesitan (Jira, Linear, Grafana, incident.io o cualquier endpoint HTTP streameable) y todos los agentes — locales, cloud, o clientes como ChatGPT desktop — los consumen a través del mismo gateway.
Secrets: guardas claves una sola vez y Cloud Sandboxes las inyecta por request mediante proxy. El agente nunca ve el secreto real. Si un prompt injection logra sacar una variable de entorno, lo que se filtra es el proxy, no tu token.
Network policies: defines qué endpoints puede alcanzar cada agente. La gobernanza centralizada para empresas llega pronto vía Docker AI Governance.

Estas tres primitivas son la razón principal por la que mover agentes a la nube deja de ser “scary”: el perímetro de seguridad no depende del host donde corre el agente.

Planes y dimensionamiento (precios de septiembre 2026)

Cloud Sandboxes factura por segundo de cómputo. Un sandbox pausado cuesta cero. Volúmenes, egress y hosting de imágenes públicas son gratis. Si ya tienes tu propia clave de modelo, no pagas inference por parte de Docker — traes tu propio provider.

Tamaño	vCPUs	Memoria	Por hora
Micro	1	2 GiB	$0.07
Small (default)	2	4 GiB	$0.14
Medium	4	8 GiB	$0.28
Large	8	16 GiB	$0.56
XL	16	32 GiB	$1.12

Una sesión corre una hora por defecto y puede extenderse hasta 24 horas. Para cargas largas (CI, migración de dependencias, generación masiva de tests) el sweet spot suele ser Medium o Large: 4-8 vCPUs son suficientes para builds de proyectos medianos y la factura por hora sigue siendo barata comparada con mantener una VM dedicada en otro proveedor.

Errores comunes al empezar

El flujo típico genera tres tropiezos en las primeras 24 horas. Vale la pena anotarlos antes de perder tiempo debuggeando:

Olvidar --cloud: sbx run claude sin la flag arranca el sandbox local. Si lo que querías era nube, la flag es sbx --cloud run claude. La diferencia aparece recién en el log: el sandbox local duerme cuando cierras la laptop.
Asumir que move copia credenciales locales a la nube: las secrets stores de local y cloud están separadas. Si tu agente necesita una API key en la nube, configúrala en la nube. El comando sbx move mueve filesystem y estado, no credenciales.
Lanzar tareas de más de 24 horas en una sola sesión: el límite duro es 24h. Para tareas más largas (generación de corpus, builds incrementales overnight) hay que encadenar sesiones o partir el trabajo en bloques idempotentes.

Si la sesión se cierra antes de terminar — por timeout o por exceder el plan — los artefactos en el filesystem se pierden. Para trabajos largos, sincroniza el filesystem a un volumen persistente cada cierto tiempo. La integración nativa con Docker Hub para imágenes OCI te permite pinear el estado entre sesiones sin tener que escribir lógica propia.

Cuándo Cloud Sandboxes NO es la herramienta correcta

Vale la pena decirlo explícito: Cloud Sandboxes no es la respuesta universal para correr agentes. Tiene huecos legítimos.

Si tu agente opera sobre bases de datos con compliance estricto: un sandbox cloud que toca datos HIPAA o PCI arrastra el cumplimiento a la infraestructura de Docker. Para esos casos, mejor mantener el agente en una microVM local o on-prem con red controlada.
Si necesitas modelos entrenados in-house: el sandbox no incluye training. Solo inference vía modelos externos o tu propio endpoint.
Si trabajas exclusivamente offline: Cloud Sandboxes requiere conexión a la cuenta Docker. Si tu política prohíbe dependencias externas durante desarrollo, el sandbox local (gratis, sin Docker Desktop) sigue siendo la opción.

Para todo lo demás — coding agents en modo background, generación masiva de tests, migraciones de dependencias, refactors largos — Cloud Sandboxes es una mejora real frente a tener un script bash corriendo en una pestaña de tmux.

Vale la pena actualizar?

Si ya usabas Docker Sandboxes en local, Cloud Sandboxes te da la pieza que faltaba: dejar la laptop cerrada sin perder la tarea. El comando sbx move funciona y es rápido; el resto del modelo de seguridad es idéntico. La barrera de entrada es baja (USD 250 de crédito inicial, pay-as-you-go por segundo, hasta 24h por sesión) y los planes default (Small, 2 vCPUs / 4 GiB / $0.14/h) cubren la mayoría de tareas de coding.

Si todavía no usabas Docker Sandboxes y tu flujo actual es “dejo al agente corriendo en una pestaña de tmux mientras rezo”, Cloud Sandboxes es estrictamente mejor en aislamiento y comparable en costo. La decisión real es cultural: ¿estás listo para delegar horas de cómputo a una microVM remota sin mirar?

Para equipos sysadmin y homelab Linux, el ángulo interesante es que Docker publicó simultáneamente la Sandbox Kit Specification v3 como propuesta abierta a la CNCF. Esto significa que las “reglas de un agente” (network, credenciales, volúmenes) serán un estándar vendor-neutral pineado vía OCI. Si trabajas en infraestructura reproducible — Kubernetes, Nomad, Ansible — conviene mirar el spec con tiempo antes de que se estabilice.

Resumen

Docker Cloud Sandboxes extiende la línea Docker Sandboxes al cómputo administrado en la nube con la misma microVM, el mismo comando y la misma política de seguridad. Es la respuesta a “¿dónde corre mi agente las próximas 21 horas?” sin tener que responder “¿es seguro dejarlo?”. El precio es por segundo, los planes default cuestan centavos por hora y hay crédito promocional para cuentas nuevas.

Si quieres empezar a probar:

Instala sbx 0.45.1+ desde brew o GitHub releases.
sbx login con tu cuenta Docker (Personal o Pro).
sbx --cloud run codex (o claude, hermes, copilot) para tu primer sandbox cloud.
Cuando tengas algo serio que tarda más de lo que quieres mirar, sbx move my-project --to cloud.

Preguntas frecuentes

¿Por qué Docker Cloud Sandboxes: ejecuta agentes en tu laptop o en la nube con un solo comando es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Docker Cloud Sandboxes: ejecuta agentes?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Docker Cloud Sandboxes: ejecuta agentes?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Docker Cloud Sandboxes: ejecuta agentes y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Docker Cloud Sandboxes: ejecuta agentes?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.