Docker Compose en Apple container: qué se rompió

Un desarrollador corrió 29 proyectos reales de docker-compose sobre el runtime nativo de Apple (Apple container 1.0, lanzado en junio de 2026) y 18 arrancaron sin drama: 14 sin tocar una sola línea y 4 con un cambio mínimo. Los otros 11 no fallaron por capricho, cada uno tenía una causa concreta. Acá está el desglose de qué se rompió con Docker Compose Apple Silicon y cómo zafar.

La pregunta ya no es si Apple container es interesante. Eso quedó claro cuando pegó el salto a 1.0 en junio y, sobre macOS 26, los contenedores por fin pueden hablar entre sí (lo que hace viable un stack multi-servicio de desarrollo). La pregunta real es otra: ¿es lo bastante compatible como para correr los compose.yml que la gente ya tiene guardados en sus repos?

Alguien decidió medirlo en vez de adivinar. Tomó la colección oficial de proyectos de ejemplo de Docker (WordPress, React+Express+Mongo, Spring+Postgres, Prometheus+Grafana y compañía) y corrió una tajada alfabética, sin elegir a dedo. Los resultados dan para hablar.

Apple container es el runtime de contenedores nativo de Apple para Mac con Apple Silicon, en su versión 1.0 desde junio de 2026. A diferencia de Docker Desktop, no mantiene una máquina virtual encendida todo el tiempo: levanta una micro-VM liviana por contenedor y solo gasta memoria mientras ese contenedor corre. Requiere macOS 26 y no funciona en Mac con Intel. Te puede servir nuestro artículo sobre cómo automatizar tu pipeline de CI/CD.

¿Funciona docker-compose en el nuevo Apple container 1.0?

Sí y no. El matiz importa.

Apple container corre imágenes de contenedor sin problema, pero es un runtime pelado. No trae el subcomando compose, no ordena dependencias entre servicios y no hace service discovery. O sea: le pasás un compose.yml y no sabe qué hacer con él. Para eso, el autor del experimento usó opossum, un orquestador chico estilo compose que viene construyendo sobre Apple container. Lee tu archivo y te devuelve el flujo familiar de up y down.

El setup mínimo es este:

• Arrancar el runtime una vez: container system start.
• Crear el dominio DNS para que los servicios se resuelvan por nombre: container system dns create opossum.
• Levantar el stack con el orquestador, darle unos 90 segundos y chequear.

El método fue prolijo: macOS 26 sobre Apple Silicon, Apple container 1.0, y para cada ejemplo, levantarlo, esperar, verificar, siguiente. A cada falla le buscó la causa raíz, que es la parte que sirve.

Resultados: 18 de 29 proyectos docker-compose arrancaron

Casi dos tercios funcionaron. Y de los que fallaron, buena parte no es culpa de Apple sino de imágenes upstream que ya venían rotas o directamente abandonadas.

Resultado	Cantidad	Qué significa
Funcionó sin cambios	14	Copiar, pegar, arrancar.
Funcionó con una línea de cambio	4	Un ajuste mínimo (plataforma o volumen).
Roto por upstream	5	La imagen o dependencia ya venía mal.
No soportado por diseño	3	Necesita algo que Apple container no expone.
Problema de setup	2	Configuración del proyecto, no del runtime.
Timeout	1	No levantó en el tiempo esperado.

Sumá 14 más 4 y tenés 18 stacks listos para desarrollar. Nada mal para un runtime que recién pegó el 1.0.

¿Qué se rompió? Los 5 tipos de problemas

Ponele que migrás tus proyectos hoy. Estos son los cinco muros contra los que te vas a chocar, en orden de frecuencia. Ya lo cubrimos antes en alternativas a Docker en Mac.

• Volúmenes de Postgres. initdb se niega a inicializar sobre un directorio que no está vacío, y el volumen montado trae un lost+found. Tres de los proyectos murieron por esto.
• Imágenes amd64 sin plataforma declarada. Si el compose.yml no dice platform y la imagen es solo x86_64, Apple Silicon la mira de reojo. Con una línea se arregla.
• El socket de Docker no está. Cualquier servicio que monte /var/run/docker.sock para hablarle al daemon se queda sin interlocutor. Apple container no expone ese socket.
• Módulos del kernel de Linux. Contenedores que esperan acceso a módulos o capabilities específicas del kernel del host no los encuentran dentro de la micro-VM.
• Dependencias upstream obsoletas. Versiones viejas de Flask, imágenes de Prometheus que ya no buildean. Esto se rompe igual en Docker Desktop, no es exclusivo de Apple.

¿Cuántas de estas fallas son realmente responsabilidad de Apple? Menos de las que parecen. El socket de Docker y los módulos del kernel son decisiones de arquitectura. El resto es basura acumulada en imágenes que nadie mantiene.

¿Cómo solucionar los errores de volúmenes con Postgres?

Este es el que más va a molestarte, así que vale la solución concreta.

El problema: montás un volumen en /var/lib/postgresql/data, pero ese directorio raíz del volumen ya tiene un lost+found del filesystem. Cuando Postgres corre initdb sobre una base nueva, se planta porque el directorio no está vacío.

La solución es no apuntar a la raíz del volumen. Usá un subdirectorio:

• Definí PGDATA a un nivel más abajo: PGDATA=/var/lib/postgresql/data/pgdata.
• Montá el volumen en el directorio padre (/var/lib/postgresql/data), y dejá que initdb cree y llene el subdirectorio limpio.

Ojo con un detalle de versiones: Postgres 18 cambió el layout por defecto de PGDATA respecto de Postgres 17, así que un compose.yml que andaba con la 17 puede fallar al saltar a la 18 aunque no toques Apple container. Fijate qué imagen estás usando antes de romperte la cabeza.

Apple container vs Docker Desktop: rendimiento y memoria

Acá viene lo bueno, y es donde Apple pega fuerte. La diferencia en el consumo de memoria es notable: Apple container solo gasta memoria mientras un contenedor está corriendo, mientras que Docker Desktop mantiene una VM encendida todo el tiempo, incluso cuando no hay ningún contenedor arriba.

Métrica	Apple container	Docker Desktop
Uso de memoria en reposo	Solo consume mientras corre un contenedor	Mantiene una VM encendida siempre
Arquitectura	Micro-VM por contenedor	Una VM compartida

Leé la tabla con criterio. Apple gana en memoria porque no mantiene una VM prendida cuando no hay nada corriendo. Docker Desktop, en cambio, ya tiene la VM caliente y lista todo el tiempo. Tema relacionado: entre Jenkins y GitHub Actions.

Entonces el trade-off es claro: si tenés la máquina con Docker Desktop abierto todo el día chupándote RAM, Apple container te devuelve varios gigas. Si vivís levantando y bajando contenedores todo el tiempo, tener la VM siempre caliente juega a favor de Docker Desktop. Elegí según tu flujo.

¿Qué alternativas a docker-compose hay para Mac?

Apple container no es la única opción, ni la más completa todavía. Si necesitás compose de verdad, andá por acá.

Si querés la opción más completa

OrbStack es hoy la más redonda para Mac: corre contenedores y máquinas Linux, soporta docker compose nativo y consume poca memoria. Es la que menos fricción te da si venís de Docker Desktop.

Si vivís en la terminal

• Colima: liviana, por línea de comandos, soporta compose sobre containerd o Docker.
• Podman: sin daemon, con podman compose, buena para quien quiere replicar entornos rootless.
• Lima: gestor de VMs Linux sobre el que se apoyan varias de las anteriores.

Si querés usar Apple container con tus compose.yml

Ahí entran las herramientas traductoras tipo Container Desktop o el mencionado opossum, que leen tu compose.yml y lo orquestan encima del runtime de Apple. No son magia, pero te ahorran levantar cada servicio a mano con container run. Sobre eso hablamos en documentación técnica multiidioma.

Guía práctica: migrar tus stacks a Apple container

Si te decidís a probarlo, este es el checklist mínimo antes de renegar:

• Declará la plataforma en cada servicio con imagen x86_64 (platform: linux/amd64), o buscá la variante arm64.
• Reacomodá PGDATA a un subdirectorio si usás Postgres con volumen.
• Sacá cualquier montaje de docker.sock: no existe en Apple container.
• Usá una herramienta intermediaria (Container Desktop u opossum) para tener el up y down de siempre.
• Creá el dominio DNS para que los servicios se encuentren por nombre.

Esto es para desarrollo local en tu Mac. Si lo que buscás es correr esos contenedores en producción sobre un VPS o servidor de verdad, eso ya es otra historia, y ahí conviene un hosting con soporte real como donweb.com antes que armar el circo en tu notebook.

Errores comunes al probar Apple container

• Intentar en Mac Intel o en un macOS viejo. Apple container pide macOS 26 y Apple Silicon. Sin eso no arranca, y no es un bug, es el requisito.
• Esperar que el compose.yml corra solo. Es un runtime, no un orquestador. Sin una herramienta arriba, no hay up que valga.
• Culpar a Apple por una imagen podrida. Si un Flask viejo o un Prometheus abandonado no buildea, se rompe también en Docker. Chequeá la imagen antes de quejarte del runtime.
• Montar el volumen en la raíz de PGDATA. El clásico. Mové la data a un subdirectorio y listo.

Preguntas Frecuentes

¿Funciona docker-compose en Apple container o necesito Docker Desktop?

Funciona, pero no de fábrica. Apple container es un runtime sin subcomando compose, así que necesitás una herramienta intermediaria como opossum o Container Desktop que lea tu compose.yml. Con eso, 18 de 29 proyectos oficiales de Docker arrancaron sin Docker Desktop.

¿Cuántos proyectos docker-compose se rompieron en el test?

Se rompieron 11 de 29. De esos, 5 fallaron por dependencias upstream ya obsoletas, 3 por funciones no soportadas por diseño (como el socket de Docker), 2 por problemas de configuración del propio proyecto y 1 por timeout.

¿Cómo arreglo los errores de volúmenes con Postgres?

Apuntá PGDATA a un subdirectorio en vez de la raíz del volumen, por ejemplo PGDATA=/var/lib/postgresql/data/pgdata. Así initdb inicializa sobre un directorio limpio y no choca con el lost+found del filesystem montado.

¿Cuánta memoria ahorra Apple container frente a Docker Desktop?

Bastante. Apple container solo consume memoria mientras hay un contenedor corriendo, mientras que Docker Desktop mantiene una VM encendida todo el tiempo, incluso sin contenedores activos. La contra: al tener la VM siempre lista, Docker Desktop no paga el arranque en frío de la micro-VM.

¿Qué requisitos tiene Apple container 1.0?

Necesitás una Mac con Apple Silicon y macOS 26. La comunicación entre contenedores, clave para stacks multi-servicio, recién está disponible sobre macOS 26. En versiones anteriores del sistema no vas a poder armar un entorno de desarrollo completo.

Conclusión

Apple container 1.0 dejó de ser una curiosidad. Corre 18 de 29 stacks reales de docker-compose y te devuelve varios gigas de RAM que Docker Desktop se guardaba para sí. No es un reemplazo directo todavía: le falta el orquestador nativo, no expone el socket de Docker y necesitás herramientas de terceros para tener el flujo compose de siempre.

¿Qué hacer con esto? Si trabajás en Mac con Apple Silicon y macOS 26, probalo con un proyecto real antes de casarte. Declará las plataformas amd64, reacomodá los volúmenes de Postgres y sumá una herramienta como OrbStack o Container Desktop si querés la experiencia completa. Para lo demás, todavía hay razones para tener Docker Desktop a mano.

Fuentes

• Apple container 1.0 – notas de lanzamiento oficiales (GitHub)
• Suruseas – “Corrí 29 proyectos docker-compose reales sobre Apple container” (dev.to)
• RepoFlow – Benchmark Apple container vs Docker Desktop
• Aron Schüler – Arreglar el arranque de Postgres 18 en docker-compose
• Apple container – issue #55 (compatibilidad de compose)