Container Machines: un entorno Linux persistente en Mac

La herramienta container de Apple alcanzó la versión 1.0 durante la semana de la WWDC, y su función estrella responde a una carencia que los desarrolladores de Mac llevan años sorteando: container machine, un entorno Linux persistente que se comporta como parte de macOS.² La sesión de la WWDC que lo presenta resume la propuesta en una sola frase: “Una Container machine es rápida y ligera, como un contenedor, y persistente, como una máquina virtual.”¹ Tus repositorios y tus dotfiles están disponibles a ambos lados, el usuario con el que inicias sesión coincide con tu cuenta de Mac, y la máquina conserva su sistema de archivos entre sesiones, así que la cadena de herramientas de Linux que configuraste el martes sigue ahí el viernes.³

Sesión 389, “Discover container machines.”

TL;DR

• container machine se incluye en container 1.0.0, publicado en GitHub durante la semana de la WWDC. Ofrece “entornos Linux de larga duración con una integración estrecha con el host” sobre el framework Containerization que Apple liberó como código abierto en la WWDC 2025.²
• Mientras que los contenedores están “modelados según una aplicación”, una container machine está “modelada según un entorno Linux”: ejecuta el propio sistema de init de la imagen, conserva los cambios en el sistema de archivos y se crea a partir de imágenes OCI estándar.³
• La integración con el host es lo que la diferencia. El usuario de Linux con el que inicias sesión coincide con tu cuenta de Mac y dispone de sudo sin contraseña, tu directorio personal queda montado dentro de la máquina,⁴ y una shell interactiva te deja en el mismo directorio de trabajo del que venías en macOS.¹
• El conjunto completo de subcomandos es create, run, list, inspect, set, set-default, logs, stop y delete, con m como alias corto.⁴
• La versión 1.0 también introduce un cambio incompatible que conviene conocer antes de actualizar: un archivo de configuración TOML en ~/.config/container/config.toml reemplaza las antiguas propiedades del sistema respaldadas por UserDefaults, y los subcomandos container system property desaparecen.²

Un entorno Linux, no un sandbox de aplicación

La documentación de Apple traza la línea con precisión: “Los contenedores suelen modelarse según una aplicación. Una container machine se modela según un entorno Linux.”³ La distinción se manifiesta en tres comportamientos. Una container machine ejecuta el propio sistema de init de la imagen, como systemd u openrc, de modo que puedes registrar servicios de larga duración y probar tu aplicación bajo un supervisor de procesos real: systemctl start postgresql funciona igual que en una máquina Linux.³ Además conserva las modificaciones, así que las herramientas que instalas se van acumulando con el tiempo en lugar de desaparecer junto con el proceso.¹ Y arranca desde las mismas imágenes OCI que usan los contenedores, así que una imagen que construyes con container build sirve también como punto de partida de una máquina.¹

El pull request que incorporó la función expone la motivación con claridad: container ejecuta cada carga de trabajo en una VM efímera, así que antes de la 1.0 no había una forma integrada de mantener un entorno Linux persistente en el que iniciar sesión y trabajar.⁴ Por debajo, cada container machine sigue recibiendo el tratamiento de Containerization: su propia máquina virtual ligera, con aislamiento basado en VM y los tiempos de arranque por debajo del segundo en torno a los cuales se diseñó el framework.¹

La sesión plantea los objetivos de diseño en términos de flujo de trabajo: alternar entre macOS y Linux debería ser fácil, los entornos deberían crearse rápido, y “la creación rápida permite que varios proyectos tengan su propio entorno dedicado, sin preocuparse por dependencias o cadenas de herramientas en conflicto.”¹ Una máquina por distribución de destino es un patrón previsto, y cada máquina ve el mismo directorio personal y los mismos dotfiles de tu Mac.³

El ciclo: editas en el Mac, compilas dentro de Linux

La demo de la sesión es un servidor web Vapor, y el flujo de trabajo que recorre es justamente el meollo del asunto.¹ El proyecto se edita en Xcode en macOS. La compilación y la ejecución ocurren dentro de una container machine con la cadena de herramientas de Swift instalada. Safari en el Mac carga el servidor en ejecución mediante su dirección IP y puerto. Cuando el ponente vuelve a exportar el icono de una app desde Icon Composer en el Mac y sobrescribe el archivo, basta con recargar el navegador para ver el nuevo recurso sin ningún paso de copia, porque la máquina y el Mac comparten los mismos archivos.¹

La documentación de Apple generaliza el patrón: tu repo vive en $HOME en macOS y queda montado dentro de la máquina, de modo que las herramientas nativas de macOS (profilers, navegadores, depuradores con interfaz gráfica) ven los mismos archivos que ve el entorno Linux. Como lo expresa la documentación, no hay ningún paso de copia entre “lo construí” y “lo estoy inspeccionando.”³

La integración con el host va más a fondo que un montaje compartido. La máquina crea automáticamente un usuario de Linux que coincide con tu nombre de usuario de Mac, le concede sudo sin contraseña y refleja tu directorio de trabajo actual, así que whoami y pwd responden lo mismo dentro y fuera.¹ El único comando que cambia su respuesta es uname: Darwin en el Mac, Linux en la máquina.¹

Hay un punto de fricción del primer día que conviene conocer antes de toparte con él: una container machine tiene una red aislada, y la sesión es explícita en que un servidor dentro de ella debe escuchar en la interfaz externa para que un navegador en el Mac pueda alcanzarlo.¹ La demo lo resuelve tal como lo harás tú: container machine list muestra la dirección IP de cada máquina junto a su nombre y recursos, la configuración del servidor enlaza a esa dirección, y Safari llega a la app en la IP y el puerto de la máquina.¹ Cuenta con el paso de la dirección IP en cualquier flujo de trabajo que sirva tráfico desde la máquina.

Los comandos

El inicio rápido son cuatro líneas:³

container machine create alpine:latest --name dev
container machine run -n dev whoami       # your host username, not root
container machine run -n dev pwd          # your Mac home directory, mounted in
container machine run -n dev              # interactive shell

container machine run cumple una doble función: con un comando lo ejecuta una vez y sale, sin él abre una shell interactiva, y si la máquina está detenida la arranca primero.³ Una máquina predeterminada elimina la opción -n de cada llamada:

container machine set-default dev
container machine run                     # operates on dev

La gestión usa los verbos de siempre: ls, inspect, logs, stop y rm, donde eliminar una máquina borra también su almacenamiento persistente.³ Los recursos se ajustan después de la creación con container machine set -n dev cpus=4 memory=8G, surtiendo efecto en el siguiente apagado y arranque; la memoria por defecto es la mitad de la memoria del host, y el montaje del directorio personal puede ser rw (el valor por defecto), ro o none.³ Todos los comandos aceptan también m como alias, así que m run y m ls funcionan.⁴

Trae tu propia imagen de máquina

Cualquier imagen de Linux que incluya /sbin/init funciona como container machine.³ La documentación de Apple incluye un Dockerfile resuelto que convierte ubuntu:24.04 en una imagen de máquina con systemd, OpenSSH y herramientas habituales de línea de comandos, y luego enmascara las unidades de systemd que no tienen sentido dentro de una VM ligera.³ La construyes con container build y pasas la etiqueta a container machine create.

El aprovisionamiento tiene una vía de escape. Por defecto, container ejecuta un script de configuración integrado en el primer arranque para crear el usuario correspondiente. Un ejecutable en /etc/machine/create-user.sh dentro de la imagen reemplaza ese script; se ejecuta una vez, como root, en el primer arranque, con CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME y CONTAINER_MACHINE_ID ya definidos, de modo que una organización puede codificar su propia configuración de usuario en una imagen base compartida.³

El resto de la 1.0, incluido el cambio incompatible

La función de máquina es el titular del lanzamiento, pero la 1.0 trae cambios que afectan a los usuarios existentes.²

El incompatible es la configuración. Un archivo TOML reemplaza las propiedades del sistema respaldadas por UserDefaults, y se eliminan los subcomandos container system property get y set.² El servicio lee ~/.config/container/config.toml al arrancar con precedencia de primera coincidencia (tu archivo de usuario, luego un archivo opcional incluido con la instalación del paquete, y por último los valores predeterminados codificados), y los cambios requieren reiniciar el servicio para surtir efecto.⁶

Las mejoras de calidad de vida: un comando container cp para copiar archivos, una opción --stop-signal en container run, y una salida estructurada (JSON, YAML, TOML) más depurada para los comandos ls e inspect en contenedores, imágenes, redes y volúmenes.² La red recibe una corrección de exactitud que usa conexiones XPC como concesiones para frenar las fugas de direcciones IP.² Se elimina la compatibilidad con las APIs XPC de la versión 0, con una API versionada prometida para un lanzamiento posterior.²

Los requisitos se mantienen estables respecto a la línea 0.x: un Mac con Apple silicon, ejecutando macOS 26. Los mantenedores señalan que, por lo general, no atenderán problemas que no puedan reproducirse en macOS 26.⁵

Por qué los flujos de trabajo agénticos deberían tomar nota

Una lectura desde donde me sitúo, no una afirmación de Apple: una container machine es la forma de entorno que quieren los agentes de programación. Los agentes que se ejecutan en un Mac necesitan un lugar donde ejecutar compilaciones, levantar servidores e instalar dependencias sin tocar el host: rápido de crear, aislado por una frontera de VM real, y lo bastante persistente como para que una cadena de herramientas instalada en una sesión sobreviva a la siguiente. Hasta ahora las respuestas en Mac eran VMs al estilo de Docker Desktop (pesadas, un único entorno compartido grande) o contenedores efímeros (aislados pero desmemoriados). Una máquina por proyecto, creada a partir de una imagen OCI versionada, con el repo montado dentro y sudo sin contraseña adentro, encaja con la forma en que ya funcionan los sandboxes de agentes en hosts Linux.

Esa misma propiedad sirve para el trabajo multiplataforma corriente. Swift del lado del servidor es el beneficiario obvio: la demo de la sesión es Vapor, y el framework Foundation Models pasa a ser de código abierto este verano con soporte para Linux, así que el entorno de prueba para “¿mi código Swift corre en Ubuntu?” queda ahora a un solo container machine create de distancia. La comparación que se le ocurrirá a cualquiera que haya usado Windows es WSL, y la dirección de la integración es la misma: un kernel Linux real a una shell de distancia, con tus archivos visibles a ambos lados. La versión de Apple llega ya con un flujo de trabajo basado en imágenes incorporado.

FAQ

¿Qué es una container machine?

Una container machine es un entorno Linux persistente en macOS, incluido como función de la herramienta de código abierto container de Apple a partir de la versión 1.0.0.² Se ejecuta en su propia máquina virtual ligera a través del framework Containerization, arranca desde imágenes OCI estándar, ejecuta el sistema de init de la imagen y conserva los cambios del sistema de archivos entre sesiones.¹ Las integraciones con el host montan tu directorio personal dentro, hacen coincidir el usuario de Linux con tu cuenta de Mac con sudo sin contraseña, y mantienen tu directorio de trabajo consistente a través de la frontera.⁴

¿En qué se diferencia de un contenedor normal?

La documentación de Apple lo resume en una línea: los contenedores están “modelados según una aplicación”, una container machine está “modelada según un entorno Linux.”³ Una carga de trabajo container run normal es efímera y centrada en el proceso. Una máquina mantiene estado, ejecuta systemd u openrc, y está pensada para volver a ella con el tiempo, como una VM con la velocidad de creación de un contenedor.¹

¿Qué requiere?

Un Mac con Apple silicon ejecutando macOS 26, los mismos requisitos que la herramienta container en general.⁵ La herramienta es de código abierto en GitHub, escrita en Swift.⁵

¿Actualizar a la 1.0 rompe algo?

Una cosa: la configuración del sistema pasa de propiedades respaldadas por UserDefaults a un archivo TOML en ~/.config/container/config.toml, y se eliminan los subcomandos container system property get/set.² Las notas de la versión 1.0 enlazan un tutorial para la migración.² También se elimina la compatibilidad con la API XPC de la versión 0, lo cual importa si construiste clientes contra la API.²

Las container machines encajan en la misma historia que esta WWDC no dejó de contar: el Mac como un hogar serio para el desarrollo multiplataforma y agéntico. Ejecutar IA agéntica en el Mac con MLX cubre la mitad de esa historia, la del servicio de modelos, y Novedades en Swift (2026) cubre el trabajo de lenguaje que convierte a Swift-en-Linux en un objetivo de primera clase. El centro de la serie completa es la Serie del Ecosistema de Apple.

Referencias