Apple Container: cos’è, come funziona e come si usa su macOS

Per chi sviluppa su Mac, eseguire workload Linux e containerizzati significa da anni affidarsi a strumenti esterni come Docker Desktop, Podman o OrbStack, perché macOS non può eseguire direttamente container Linux. È proprio su questa esigenza che Apple è intervenuta con una novità relativamente recente: Container, il progetto open source presentato nel 2025 e arrivato alla versione 1.0 nel giugno 2026.

Apple Container permette di creare, eseguire e distribuire container Linux su macOS utilizzando direttamente le tecnologie di virtualizzazione del sistema operativo, mantenendo la compatibilità con immagini OCI, Dockerfile e registry già diffusi nello sviluppo cloud-native. Il risultato è un ambiente container costruito specificamente per Apple silicon e macOS, senza imporre un nuovo formato di immagini o un ecosistema separato.

La novità più interessante riguarda il modo in cui questi container vengono eseguiti. Invece di raccogliere più workload all’interno di una singola macchina virtuale Linux, Container assegna a ciascuno una VM Linux leggera dedicata, spostando il confine di isolamento fino al singolo container. È questa scelta a determinare buona parte dei vantaggi e dei limiti rispetto a Docker Desktop, Podman e OrbStack.

Apple ha sviluppato Container insieme a Containerization, il framework Swift che fornisce le primitive per immagini, filesystem, networking, virtualizzazione e processi Linux. Containerization costituisce il livello infrastrutturale, mentre Container è la CLI destinata agli sviluppatori, con i comandi necessari per eseguire immagini, costruirne di nuove e gestire ambienti Linux locali.

Dopo la fase iniziale di sviluppo, il progetto ha continuato a evolvere rapidamente. Al 30 agosto 2026 la versione disponibile è Container 1.3.1, pubblicata il 29 agosto.

Linux resta necessario anche sul Mac

Il punto di partenza è strutturale: i container utilizzati normalmente nello sviluppo backend e cloud dipendono dal kernel Linux, mentre macOS utilizza Darwin. Un Mac non può quindi eseguire direttamente un container Linux come avviene su un server Ubuntu, Debian o Red Hat.

Le soluzioni disponibili su macOS introducono per questo una macchina virtuale Linux, all’interno della quale vengono eseguiti i workload. La CLI presente sul Mac comunica con quell’ambiente e gli inoltra i comandi.

Apple Container segue la stessa necessità di fondo, ma modifica il modo in cui la virtualizzazione viene distribuita. Invece di concentrare molti container all’interno di una VM comune, crea una macchina virtuale distinta per ciascun workload.

Il confine di isolamento scende al singolo workload

Due container eseguiti contemporaneamente con Apple Container non condividono lo stesso kernel Linux guest. Ognuno dispone della propria VM, all’interno della quale viene avviato un ambiente ridotto all’essenziale.

Nei runtime basati su una VM condivisa, i container rimangono separati attraverso i normali meccanismi di isolamento del kernel Linux; con Apple Container, sotto quel livello, esiste anche il confine della virtualizzazione. Una vulnerabilità che consenta a un processo di superare l’isolamento del container non equivale quindi automaticamente all’accesso all’ambiente degli altri workload.

Questa separazione assume particolare rilievo per build, test automatici, coding agent e codice non completamente affidabile, casi nei quali può essere utile impedire che workload differenti condividano lo stesso kernel.

All’interno di ogni VM opera vminitd, un processo scritto in Swift e compilato staticamente che configura networking e filesystem, avvia il processo richiesto e gestisce la comunicazione con macOS. Le macchine virtuali vengono create attraverso Virtualization.framework e sono molto più ridotte di una VM Linux tradizionale destinata a eseguire un sistema operativo completo, tanto da poter essere avviate in meno di un secondo.

Compatibilità OCI, senza un formato proprietario

L’architettura adottata da Apple non introduce un formato di immagine specifico. Container utilizza le specifiche della Open Container Initiative (OCI) e può quindi lavorare con immagini già disponibili nei normali registry pubblici e privati.

Un’immagine costruita con Docker può essere eseguita da Container e, viceversa, un’immagine prodotta con Container può essere utilizzata da altri runtime OCI. Il meccanismo di esecuzione sul Mac rimane quindi separato dal formato utilizzato per distribuire l’applicazione.

Per avviare, per esempio, Alpine Linux, una distribuzione Linux minimale molto utilizzata nelle immagini container, è sufficiente:

container run --rm alpine echo hello

Se l’immagine non è già presente, Container la scarica, crea la relativa VM, esegue il comando e rimuove il workload al termine.

Per aprire invece una shell Ubuntu interattiva:

container run -it ubuntu:latest /bin/bash

La sintassi richiama quella di Docker e rende immediatamente riconoscibili molte delle operazioni più comuni, pur utilizzando una CLI distinta.

Apple silicon e macOS 26 come base

I requisiti correnti sono Apple silicon e macOS 26. I Mac Intel non sono supportati.

La scelta riflette l’impostazione dell’intero progetto: Container non nasce come runtime multipiattaforma adattato successivamente al Mac, ma come strumento costruito direttamente intorno all’hardware Apple e ai framework di virtualizzazione di macOS.

Questo non impedisce di lavorare con software destinato a infrastrutture x86. Su macOS 26 Container può utilizzare Rosetta 2 per eseguire software Linux amd64 sui Mac Apple silicon e può produrre immagini multipiattaforma arm64 e amd64, funzione utile quando lo sviluppo avviene su Mac ma il deployment finale viene effettuato su server cloud con architetture differenti.

Cosa cambia con macOS 27

Con macOS 27 Golden Gate cambia proprio il meccanismo utilizzato per eseguire software Linux x86-64. La traduzione dei binari Intel nelle VM Linux ARM viene integrata direttamente nel sistema operativo e non richiede più l’installazione separata di Rosetta. La possibilità di eseguire container Linux amd64 su Apple silicon continuerà quindi anche mentre Rosetta entra nella fase finale del proprio impiego come tecnologia generale per le applicazioni Mac Intel.

macOS 27 amplia anche alcune delle fondamenta sulle quali è costruito Container. vmnet aggiunge il port forwarding sulle connessioni loopback, mentre Virtualization.framework introduce topologie di rete più flessibili e dispositivi Virtio personalizzati, attraverso i quali un’applicazione può realizzare canali specializzati e ad alte prestazioni fra host e guest Linux.

Queste capacità possono essere sfruttate in futuro da Container e Containerization, ma non corrispondono automaticamente a nuove funzioni della CLI. Apple non ha finora annunciato per macOS 27, per esempio, un supporto nativo a Compose o alla Docker Engine API. Le principali estensioni funzionali arrivate nel 2026, come gli ambienti persistenti Container Machine, sono state distribuite attraverso l’evoluzione del progetto Container e non dipendono dal nuovo sistema operativo.

Installazione e primo avvio

Container viene distribuito come package .pkg firmato su GitHub. Dopo l’installazione, l’ambiente viene inizializzato dal Terminale con:

container system start

Al primo avvio vengono installati anche i componenti Linux necessari alla creazione delle macchine virtuali.

La versione installata può essere verificata con:

container system version

mentre:

container system stop

arresta i servizi.

Per aggiornare Container si può installare una versione più recente oppure utilizzare lo script incluso:

container system stop
/usr/local/bin/update-container.sh
container system start

La gestione di base rimane quindi centrata sulla riga di comando, senza richiedere un’applicazione desktop dedicata.

Dalla CLI al primo container

Anche nell’uso quotidiano Container mantiene una sintassi vicina a quella di Docker. Per eseguire Nginx in background e pubblicare la porta 80 del container sulla porta 8080 del Mac:

container run -d \
--name web \
-p 8080:80 \
nginx:latest

Il workload può poi essere visualizzato con:

container list

I log sono disponibili con:

container logs web

e una shell può essere aperta nel container già attivo con:

container exec -it web /bin/sh

Per arrestarlo:

container stop web

e per eliminarlo:

container delete web

Oltre alle operazioni di base, Container supporta bind mount, volumi persistenti, variabili d’ambiente, reti dedicate, filesystem tmpfs, root filesystem in sola lettura e limiti alle risorse.

Risorse separate per ogni workload

La presenza di una VM per container cambia anche il modo in cui vengono considerate CPU e memoria, perché le risorse vengono assegnate alla macchina virtuale che ospita il workload.

Per esempio:

container run --rm \
--cpus 4 \
--memory 8g \
ubuntu:latest

crea una VM con quattro CPU virtuali e un limite di 8 GB di memoria.

Questo non significa che tutti gli 8 GB vengano occupati immediatamente: il consumo cresce in funzione delle necessità effettive del processo. Il modello presenta tuttavia un compromesso rispetto alla VM condivisa, soprattutto quando vengono eseguiti molti workload contemporaneamente.

La memoria liberata dai processi all’interno della VM non viene sempre restituita immediatamente all’host. Con numerosi container caratterizzati da picchi di memoria elevati può quindi essere necessario riavviare periodicamente alcuni workload per ridurre il consumo complessivo.

Build da Dockerfile e immagini multipiattaforma

Container non serve soltanto a eseguire immagini già esistenti. Può anche costruirle a partire da un Dockerfile:

container build -t myapp:latest .

ottenendo l’immagine myapp:latest, eseguibile immediatamente:

container run --rm myapp:latest

L’autenticazione verso un registry avviene con:

container registry login registry.example.com

e un’immagine opportunamente taggata può essere pubblicata con:

container image push registry.example.com/user/myapp:latest

È inoltre possibile effettuare build multipiattaforma per arm64 e amd64, mantenendo lo stesso flusso di sviluppo quando il Mac utilizzato localmente e l’infrastruttura di produzione hanno architetture differenti.

Oltre il container effimero: gli ambienti persistenti

Con la versione 1.0 Apple ha introdotto Container Machine, una modalità destinata a esigenze differenti da quelle del normale container applicativo.

Un container tradizionale viene normalmente creato per eseguire uno specifico processo o servizio e può essere distrutto e ricreato con facilità. Una Container Machine costituisce invece un ambiente Linux persistente, il cui filesystem viene mantenuto tra un avvio e l’altro.

Per crearne una:

container machine create alpine:latest --name dev

e per aprire una shell, avviando prima la macchina se necessario:

container machine run -n dev

La home directory del Mac viene resa disponibile all’interno del guest e l’utente Linux corrisponde all’utente macOS. Diventa così possibile modificare i sorgenti con un editor nativo sul Mac e utilizzare contemporaneamente Linux per compilazione, test o altri strumenti di sviluppo.

Container Machine può eseguire anche ambienti più completi, comprese immagini dotate di systemd, e si presta quindi a essere utilizzato come ambiente Linux persistente di sviluppo senza introdurre una VM tradizionale separata.

Kubernetes locale, per ora sperimentale

Container include anche una funzione dedicata a Kubernetes:

container k8s create

che crea un cluster Kubernetes locale single-node.

Le risorse possono essere definite direttamente:

container k8s create \
--name dev-cluster \
--cpus 4 \
--memory 8g

mentre un’immagine già disponibile localmente può essere trasferita nel cluster con:

container k8s load-image \
--name dev-cluster \
myapp:latest

Il cluster utilizza componenti standard dell’ecosistema Kubernetes, compresi kindest/node e kubeadm, e aggiunge le credenziali alla configurazione utilizzata da kubectl. La funzione rimane però sperimentale, quindi sintassi e comportamento possono ancora cambiare.

Dove il modello Apple guadagna in sicurezza

Il confronto con Docker Desktop mette in evidenza soprattutto la differenza nel confine di sicurezza.

Su macOS Docker utilizza una macchina virtuale Linux nella quale vengono eseguiti il Docker Engine e i container. Apple Container crea invece una VM indipendente per ciascun workload, separando a livello di virtualizzazione processi che, in un ambiente Docker tradizionale, condividerebbero lo stesso kernel guest.

Il vantaggio è particolarmente rilevante quando viene eseguito codice non completamente affidabile oppure generato automaticamente, come accade sempre più spesso nei workflow basati su agenti AI. In questi casi la separazione del kernel riduce la superficie condivisa fra workload differenti.

Anche l’accesso al filesystem del Mac può essere circoscritto più precisamente, perché ogni VM riceve soltanto i mount necessari a quel determinato container.

Un runtime costruito intorno a macOS

Un altro elemento distintivo è l’integrazione con il sistema operativo. Container è scritto prevalentemente in Swift e utilizza direttamente Virtualization.framework, le API di networking di macOS e gli altri servizi messi a disposizione dalla piattaforma Apple.

Non nasce quindi come runtime Linux adattato al Mac, ma come implementazione progettata espressamente per Apple silicon e per l’infrastruttura di virtualizzazione di macOS.

Container e Containerization sono inoltre open source, con licenza Apache 2.0, una scelta che permette di studiarne direttamente l’architettura e di riutilizzarne i componenti in altri progetti.

La compatibilità OCI non equivale alla compatibilità Docker

Il limite principale emerge quando dal formato delle immagini si passa all’ecosistema di strumenti costruito intorno a Docker.

Container utilizza:

container run

invece di:

docker run

e dispone di un proprio API server interno, utilizzato dalla CLI e dagli altri componenti del sistema. Non implementa però nativamente la Docker Engine API né espone il tradizionale Docker socket sul quale fanno affidamento molti strumenti esterni.

Questo significa che un software progettato per collegarsi direttamente a un Docker daemon non può trattare Apple Container come un Docker Engine semplicemente cambiando il percorso del socket.

Esistono già però livelli di compatibilità esterni. Socktainer espone sopra Apple Container una REST API compatibile con una parte della Docker Engine API e registra un Docker context, rendendo possibile utilizzare operazioni comuni della Docker CLI come docker ps e docker images.

La compatibilità è ancora parziale e non trasforma Apple Container in un Docker Engine completo, ma permette già ad alcuni strumenti costruiti intorno all’API Docker di interagire con il runtime Apple.

Compose può essere aggiunto, ma non fa parte del runtime Apple

La stessa distinzione vale per Docker Compose. Container 1.3.1 non comprende un comando container compose né un’implementazione Apple capace di leggere direttamente un normale compose.yaml e trasformarlo in un insieme coordinato di workload.

Questo non rende però impraticabili i workflow Compose. container-compose implementa workflow compatibili con Docker Compose v2 come plugin per la CLI Apple ed è arrivato alla versione 0.13.0 stabile nell’agosto 2026.

Il progetto mostra anche quanto lavoro sia ancora necessario per colmare la distanza fra i due ambienti: alcune capacità richieste da Compose non sono presenti nelle release standard di Apple Container e container-compose mantiene per questo una propria combinazione coordinata di componenti del runtime e della build.

Per applicazioni costituite da pochi workload gestiti direttamente dalla CLI la differenza può avere un peso limitato; negli ambienti nei quali compose.yaml descrive decine di servizi e costituisce parte integrante del workflow di sviluppo, Docker Desktop, Podman e OrbStack rimangono soluzioni più immediate.

Una GUI Apple non c’è, ma le alternative sono già diverse

Apple non distribuisce un’interfaccia grafica per Container e il progetto rimane centrato sulla CLI. Nel frattempo sono però comparsi frontend indipendenti, per cui non è più corretto considerare il Terminale come l’unico modo per amministrare il runtime.

Container Desktop, per esempio, è un’applicazione macOS in SwiftUI che utilizza la CLI container e il relativo output strutturato per gestire graficamente container, immagini, volumi, reti, registry e machine, oltre a mostrare log, statistiche e terminale.

Un’altra strada passa da Podman Desktop, che dispone di un’estensione dedicata ad Apple Container. L’integrazione utilizza Socktainer per presentare una superficie API compatibile con Docker e permette di amministrare i workload Apple dalla stessa GUI utilizzata per altri ambienti container.

Sono soluzioni esterne al progetto Apple, ma colmano già una delle differenze più visibili rispetto a Docker Desktop e OrbStack.

Anche gli IDE cominciano a integrarsi

La situazione è analoga per i Dev Containers. Apple Container non sostituisce in modo trasparente il workflow Docker utilizzato normalmente dalla relativa estensione di Visual Studio Code, soprattutto quando un progetto parte da devcontainer.json e si aspetta che l’IDE crei autonomamente l’intero ambiente.

Esistono tuttavia percorsi di integrazione che permettono di collegare gli strumenti di sviluppo a workload Apple già in esecuzione, mentre Container Machine può essere utilizzato come ambiente Linux persistente insieme a strumenti di accesso remoto come SSH.

La compatibilità con gli IDE va quindi considerata parziale e in evoluzione, piuttosto che semplicemente assente.

Alcune differenze riguardano ancora la semantica del runtime

Anche quando un comando Docker trova un equivalente immediato nella CLI Apple, non tutte le funzioni del runtime sono disponibili con la stessa semantica.

Nella versione corrente manca, per esempio, un equivalente completo della normale restart policy di Docker, con configurazioni come always o unless-stopped. Analoga la situazione degli healthcheck Docker-style: il progetto prevede già strutture preliminari per rappresentarne lo stato, ma il meccanismo completo di esecuzione periodica delle verifiche e gestione healthy/unhealthy non fa ancora parte del runtime corrente.

Sono differenze poco visibili negli esempi locali più semplici, ma diventano importanti quando si tenta di trasferire senza modifiche configurazioni Docker o Compose più articolate.

Podman: più maturo, ma con una VM condivisa

Anche Podman deve utilizzare una macchina virtuale Linux su macOS. podman machine crea l’ambiente nel quale vengono eseguiti i container e più workload condividono quindi lo stesso kernel Linux guest.

La differenza rispetto ad Apple Container riguarda ancora una volta il confine della virtualizzazione: Podman concentra il runtime in una VM Linux comune, mentre Apple assegna una VM a ciascun container.

Podman dispone però di un ecosistema più maturo, nato nel mondo Linux e sviluppato intorno a workflow ormai consolidati. Offre inoltre un livello di compatibilità più ampio con molti strumenti costruiti originariamente per Docker e una gestione degli ambienti multi-container più completa.

OrbStack: continuità con Docker e minore isolamento

OrbStack segue un’impostazione ancora diversa. Utilizza una VM Linux leggera ottimizzata per macOS nella quale esegue un ambiente compatibile con Docker e rende disponibili sul Mac i relativi strumenti.

Questo approccio consente di continuare a utilizzare direttamente docker, Docker Compose e gli strumenti che dipendono dalla Docker API con poche o nessuna modifica rispetto a Docker Desktop.

OrbStack integra inoltre Kubernetes, macchine Linux, networking, file sharing e un’interfaccia grafica. La VM condivisa permette di ridurre l’overhead quando vengono eseguiti molti workload contemporaneamente, mentre Apple Container accetta un costo potenzialmente maggiore pur di mantenere una separazione più netta fra i singoli container.

Quattro approcci diversi ai container su Mac