Docker con Colima en macOS: cómo dar Docker a un agente de IA sin abrir tu Mac

Instalé Hermes, mi agente de IA, en un usuario de macOS sin permisos de administrador. Pronto necesité Docker para compilar mis apps de Android e iOS y para ejecutar Woodpecker como CI. El problema es que la libertad que da Docker también es un riesgo si el agente se descontrola. Aquí documento las formas que investigué para que Hermes use Docker, sus pros y contras, por qué acabé con Docker con Colima en macOS ejecutado por el propio usuario hermes, y los comandos exactos, con sus comprobaciones, para reproducirlo.

Contenido

• Por qué dar Docker a un agente es peligroso en un Mac

• Qué formas hay de que Hermes use Docker

• Cerebro y manos: ¿hay que instalar Hermes dentro de Docker?

• Qué limitaciones tiene la caja para compilar apps de Android e iOS

• Por qué elegí Colima y no Docker Desktop, OrbStack ni un macOS virtual

• Cómo instalar Colima y Docker en macOS paso a paso

• Cómo comprobar que Docker con Colima queda aislado

• Reglas para el día a día

Por qué dar Docker a un agente es peligroso en un Mac

Mi punto de partida fue una frase que le escribí al propio asistente con el que configuraba la máquina: necesitaba que Hermes usara Docker, pero sabía que Docker puede servir para "escapar" al resto del ordenador.

El primer matiz importante es que en macOS Docker no corre sobre el sistema. Corre dentro de una máquina virtual Linux, y esa máquina accede a mis carpetas a través de los directorios que comparte con el Mac. Por eso el riesgo real no es tanto que un contenedor rompa su aislamiento, sino que quien puede dar órdenes a Docker controla esa máquina virtual. Puede lanzar contenedores con privilegios, montar cualquier carpeta compartida y conectarse a internet desde la VM.

De ahí sale la regla que ordenó todo lo demás: lo que el agente alcanza a través de Docker depende de qué usuario de macOS ejecuta la máquina virtual.

• Si Docker corre en mi sesión (guido) y Hermes puede usarlo, el agente puede montar mi home y leer todo lo que yo veo. Se saltaría el chmod 700 con el que ya había blindado mi carpeta personal, y su tráfico de red saldría con mi identidad.

• Si la VM corre como hermes, "escapar de Docker" solo significa volver a ser hermes: un usuario sin administrador, sin acceso a mi home y sujeto a mis reglas de pf. El daño queda limitado a lo que ese usuario ya podía hacer.

Esa asimetría fue la decisión de diseño central. La pregunta pasó de "¿Docker sí o no?" a "¿qué usuario lo ejecuta y qué carpetas ve?".

Qué formas hay de que Hermes use Docker

Investigué las maneras de combinar Hermes y Docker y las reduje a dos familias.

1. Docker como caja para el agente. Hermes ejecuta los comandos del agente dentro de un contenedor en lugar de en el Mac. Se activa con terminal.backend en la configuración. Revisé el código de ese backend y está bien protegido:

• quita todos los privilegios con --cap-drop ALL,

• impide ganar privilegios después con no-new-privileges,

• limita CPU, memoria y número de procesos,

• puede cortar la red del todo con docker_network: false,

• y usa un proxy (iron-proxy) para que el contenedor reciba tokens falsos en lugar de mis claves reales.

2. Que el agente maneje Docker. Darle acceso a la orden docker para que lance sus propios contenedores, por ejemplo para montarme un n8n o un Grafana. Es más flexible, pero también más arriesgado: puede lanzar contenedores privilegiados o montar cualquier carpeta compartida. Si se hace, tiene que ser siempre con el motor corriendo como hermes, nunca como guido.

La primera opción es la que usaría cualquier guía de seguridad. Pero todavía me faltaba entender qué se mueve exactamente a la caja.

Cerebro y manos: ¿hay que instalar Hermes dentro de Docker?

Mi duda era si "la caja" significaba instalar Hermes entero dentro de un contenedor. La respuesta fue que no, y la analogía que más me ayudó fue separar cerebro y manos:

• El cerebro es el programa de Hermes: habla con el modelo (OpenRouter), recibe mis mensajes de Telegram y email, guarda la memoria y decide qué hacer. Sigue instalado en el Mac.

• Las manos son las herramientas que actúan sobre el sistema. Con backend: docker pasan al contenedor la terminal (terminal_tool), la ejecución de código (execute_code) y la lectura y escritura de archivos (file_tools, file_operations).

Se quedan en el Mac la conexión con el modelo, Telegram y email, la memoria, el cron, el navegador y los servidores MCP. Hay un detalle que conviene recordar: los MCP se lanzan con npx en el Mac, así que son el único componente que sí puede ejecutar cosas arbitrarias fuera de la caja.

Existe además la variante B: Hermes entero en Docker, con el Dockerfile y el docker-compose.yml oficiales que trae la instalación. Comparé las dos y la tabla me dejó estas diferencias:

La A protege mejor las claves, y por eso era la recomendada en un principio.

Qué limitaciones tiene la caja para compilar apps de Android e iOS

Aquí fue donde la opción recomendada dejó de encajar con mi objetivo. Mi pregunta fue directa: si quiero que Hermes me compile la app de Android o la de iOS, ¿sirve la opción A?

Para Android, sí, con matices. Para iOS, no. El contenedor es un Linux, no un Mac, y eso se traduce en limitaciones muy concretas:

• No hay xcodebuild, simuladores de iOS, osascript, open ni Homebrew.

• Mi M4 ejecuta contenedores ARM64 de forma nativa. Lo que solo existe para x86_64 funciona con Rosetta, pero más lento.

• Las carpetas compartidas son más lentas, lo que se nota en compilaciones con miles de archivos.

• No hay interfaz gráfica, así que no hay emuladores con pantalla, y tampoco USB para ver un móvil conectado por cable.

• Mi configuración tenía container_cpu: 1 y container_memory: 5120, y 5 GB y una CPU se quedan cortos para compilar.

• Todo lo que descargue (dependencias, SDKs) tiene que pasar por las reglas de pf.

• Lo que haya en /workspace lo ve el agente, incluidas claves de firma y ficheros con secretos de la app.

Había una conclusión incómoda: con la caja, Android es viable y iOS directamente imposible, porque Xcode solo corre en macOS.

Por qué elegí Colima y no Docker Desktop, OrbStack ni un macOS virtual

Mi requisito era claro: una sola instalación con la máxima libertad posible. Eso descartó la caja como solución única. Evalué la alternativa de meter Hermes entero en un macOS virtual con Tart, que daría iOS, Android y aislamiento fuerte con instantáneas para volver atrás. El problema es que, según lo que encontré, macOS no permite virtualización anidada dentro de un macOS virtual. Hay una consulta abierta en los foros de Apple de otro desarrollador con un M4 y macOS 26.5, como el mío, sin respuesta. Sin virtualización anidada, ni Docker ni el emulador de Android funcionarían dentro de esa VM. No lo probé por mi cuenta, así que lo dejo como "probablemente no".

Quedó esta comparación:

Elegí la tercera. Es la única que cubre todo lo que quiero hacer, y asumo conscientemente un aislamiento medio: la frontera de seguridad es el usuario hermes sin administrador, no un contenedor.

Y dentro de esa decisión, elegí Colima frente a las otras dos opciones de motor:

• Colima es gratuito, de línea de comandos, y la VM corre con el usuario que la arranca. No instala componentes con privilegios de root.

• Docker Desktop instala un servicio auxiliar que corre como root y está pensado para un solo usuario. Si lo arrancara desde guido, compartiría /Users.

• OrbStack es rápido, pero también instala componentes con privilegios.

En la imagen del logo, Colima aparece como una llama cargando tres cajas verdes, junto a la ballena de Docker con su pila de contenedores. Resume bien la arquitectura: Colima es la bestia de carga que transporta el motor, y el cliente docker sigue siendo el de siempre. Es un detalle menor, pero me ayudó a explicar la pieza a quien me preguntaba.

Cómo instalar Colima y Docker en macOS paso a paso

El procedimiento se divide en dos sesiones, porque instalar paquetes requiere administrador y ejecutar el motor no.

Parte 1: en la sesión de guido (administrador)

1. Instalo Homebrew:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Pide mi contraseña y, al terminar, hay que ejecutar las líneas de "Next steps":

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

2. Instalo Colima y el cliente de Docker:

brew install colima docker docker-buildx docker-compose

No arranco Colima desde guido. Es el error que anularía todo el diseño.

3. Instalo Rosetta (opcional, para imágenes Intel):

softwareupdate --install-rosetta --agree-to-license

4. Compruebo que los binarios pertenecen a guido:

ls -ld /opt/homebrew /opt/homebrew/bin/colima

El dueño debe ser guido y el grupo admin. Así hermes puede ejecutar los programas pero no modificarlos.

Parte 2: en la sesión de hermes

5. Añado Homebrew al PATH:

echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zprofile
source ~/.zprofile
which colima docker

Debe mostrar /opt/homebrew/bin/colima y /opt/homebrew/bin/docker.

6. Creo la carpeta compartida:

mkdir -p ~/hermes-workspace

7. Arranco Colima:

colima start \
  --vm-type vz \
  --vz-rosetta \
  --cpu 6 \
  --memory 12 \
  --disk 100 \
  --mount ~/hermes-workspace:w

Esta línea concentra las decisiones importantes:

• --vm-type vz usa el framework de virtualización de Apple, más rápido en Apple Silicon.

• --vz-rosetta permite imágenes x86_64; lo quito si no hice el paso 3.

• --cpu 6 --memory 12 --disk 100 resuelve el problema de recursos: pasé de 1 CPU y 5 GB a algo razonable para compilar.

• --mount ~/hermes-workspace:w es la línea crítica. Hace que solo se comparta esa carpeta en modo escritura. Sin ella, Colima compartiría todo el home de hermes, incluido ~/.hermes/.env con mis claves.

En adelante basta con colima start.

8. Pruebo Docker:

docker run --rm hello-world

Cómo comprobar que Docker con Colima queda aislado

Una configuración de seguridad que no se verifica es una suposición, así que añadí tres comprobaciones, todas desde hermes.

La VM corre como hermes:

ps -axo user,comm | grep -iE 'colima|limactl|Virtualization' | grep -v grep

En la primera columna solo debe aparecer hermes. Si aparece root o guido, algo salió mal.

Desde Docker no se ve lo que no está compartido:

docker run --rm -v /Users/hermes/.hermes:/x alpine ls -la /x
docker run --rm -v /Users/guido:/x alpine ls -la /x
docker run --rm -v /Users/hermes/hermes-workspace:/x alpine ls -la /x

Los dos primeros deben salir vacíos, porque esas rutas no existen dentro de la VM al no estar en el --mount. El tercero debe listar el contenido de hermes-workspace. Este es el test que más tranquilidad me da: intento montar mi home y el .env desde un contenedor y no veo nada.

El socket pertenece solo a hermes:

ls -la ~/.colima/default/docker.sock

Reglas para el día a día

Como la seguridad de esta configuración depende de la disciplina, me fijé unas reglas cortas:

• Nunca arrancar Colima desde guido para que lo use Hermes.

• No añadir más carpetas a mounts en ~/.colima/default/colima.yaml.

• Tras reiniciar el Mac, ejecutar colima start en la sesión de hermes.

• Si activo algún MCP, recordar que se lanza con npx en el Mac y no en un contenedor.

Mientras escribía estas notas tenía delante la foto de un volcán: un cono gris de ceniza que emerge sobre un bosque verde, con nubes cargadas encima. Me pareció una metáfora decente de lo que he montado. Docker es un volcán potencialmente peligroso, pero si decides con cuidado dónde lo pones y qué rodea al cráter, puedes vivir al lado y sacarle partido. Mi frontera es el usuario hermes y un único hermes-workspace; no es la más estricta posible, pero es la que me deja compilar Android, iOS y ejecutar Woodpecker con una sola instalación. El siguiente paso es afinar las reglas de pf para las descargas de SDKs y medir cuánto tarda una compilación real a través de la carpeta compartida.