Con macOS 26 Apple permette di eseguire container Linux direttamente su Mac, senza installare applicazioni di terze parti come Docker Desktop. Lo fa con due componenti open source: il framework Containerization e lo strumento a riga di comando container, entrambi pensati per Apple silicon.

Al WWDC 2025 questa novità è passata quasi in sordina tra i molti annunci, ma per chi sviluppa su Mac è uno dei cambiamenti più interessanti dell'anno.

Cosa ha introdotto Apple

Il framework Containerization è un pacchetto Swift per eseguire container Linux su macOS, basato su Virtualization.framework. Sopra di esso si appoggia container, lo strumento da riga di comando che consente di creare ed eseguire i container. Entrambi i progetti sono rilasciati con licenza Apache-2.0.

I requisiti, secondo la documentazione ufficiale, sono un Mac con Apple silicon e macOS 26. Le versioni precedenti di macOS non sono supportate. Il progetto container è in sviluppo attivo: i mantenitori segnalano che alcune funzioni sperimentali possono ancora cambiare.

Come funziona sotto il cofano

Il punto tecnico da capire è che qui non c'è un'unica grande macchina virtuale condivisa. Come spiega la sessione WWDC25 "Meet Containerization", ogni container gira dentro una propria macchina virtuale leggera. Ne derivano alcune caratteristiche:

  • isolamento: secondo Apple lo stesso livello di sicurezza delle macchine virtuali tradizionali, con le cartelle condivise accessibili solo al container che le richiede;
  • rete: ogni container riceve un indirizzo IP dedicato, quindi non serve mappare le singole porte;
  • risorse: CPU e memoria sono allocate solo mentre i container sono in esecuzione;
  • avvio: Apple dichiara tempi di avvio inferiori al secondo, grazie a un kernel Linux ottimizzato e a un filesystem minimale con un sistema di init leggero.

Nella pagina del progetto non sono pubblicati benchmark, quindi i vantaggi in termini di consumo di batteria e prestazioni restano, per ora, promesse del produttore. Vale la pena misurarli sul proprio carico di lavoro.

L'architettura di container

La panoramica tecnica del progetto descrive come è composto lo strumento. La riga di comando parla con container-apiserver, un launch agent che si avvia con container system start e si ferma con container system stop. All'avvio il server lancia due servizi di supporto: uno per la gestione delle immagini e dell'archivio locale dei contenuti, uno per la rete virtuale. Per ogni container viene poi avviato un processo ausiliario che lo gestisce.

Sul piano pratico, la documentazione sottolinea tre vantaggi rispetto a una macchina virtuale Linux condivisa:

  • sicurezza: isolamento a livello di macchina virtuale, con un insieme minimo di utilità e librerie per ridurre la superficie di attacco;
  • riservatezza: si montano solo i dati dell'host che servono a quel container, senza esporre tutto a una VM comune;
  • prestazioni: ogni container usa meno memoria di una macchina virtuale completa, con tempi di avvio vicini a quelli dei container in una VM condivisa.

Compatibilità e primi passi

Lo strumento usa e produce immagini compatibili OCI: si scaricano immagini dai registri standard, si pubblicano quelle costruite in locale e si possono eseguire in altri strumenti compatibili. Il framework può anche eseguire container linux/amd64 su Apple silicon tramite Rosetta 2.

L'installazione avviene scaricando il pacchetto firmato dalla pagina delle release su GitHub. Dopo l'installazione si avvia il servizio e si lancia un primo container:

container system start
container run --rm alpine echo hello

Memoria, rete e limiti documentati

Il progetto dichiara in modo esplicito alcuni limiti, e conviene conoscerli prima di adottarlo:

  • Memoria: il framework di virtualizzazione di macOS supporta solo in parte il ballooning. Un container avviato con un limite di 16 GB può mostrare in Activity Monitor circa 2 GiB, ma la memoria liberata dal sistema Linux ospite non viene restituita a macOS. Con molti container che usano molta memoria può servire qualche riavvio occasionale.
  • Rete su macOS 15: lo strumento è progettato per macOS 26 ma gira anche su macOS 15, con limitazioni: i container non possono comunicare tra loro, i comandi container network non sono disponibili e possono verificarsi conflitti sulla subnet. I mantenitori non prevedono di correggere i problemi che non si riproducono su macOS 26.
  • Funzioni mancanti: la documentazione dice che la prima versione offre le funzioni di base per costruire ed eseguire container, ma molte funzioni comuni non sono ancora implementate.

Le guide pratiche del progetto coprono già molti argomenti: limiti di CPU e memoria, bind mount e volumi, port forwarding, immagini multipiattaforma per Apple silicon e x86-64, log, e perfino cluster Kubernetes locali. Il quadro però cambia in fretta e conviene verificare sempre la documentazione della versione installata.

Docker è davvero superato?

La versione iniziale di questo articolo parlava di eliminare la necessità di Docker. Rivedendo la documentazione conviene essere più precisi: Apple non toglie la virtualizzazione, la ripensa. Ogni container ha la sua macchina virtuale, ma ottimizzata per essere leggera e integrata nel sistema. Per molti flussi di lavoro locali, dove oggi si installa un'applicazione pesante solo per eseguire qualche immagine, questo può bastare.

Restano però dei limiti da valutare prima di cambiare strumenti: la dipendenza da Apple silicon e da macOS 26, la maturità di un progetto ancora giovane e l'ecosistema di strumenti costruito negli anni attorno a Docker, dagli orchestratori ai plugin degli editor. Per chi lavora su Mac e usa i container in modo semplice, vale la pena provarlo subito. Per ambienti di produzione o team misti, la prudenza è d'obbligo.