Docker n’est plus la seule façon de lancer des conteneurs sur un Mac. Depuis 2025, Apple propose son propre outil open source, sobrement baptisé Container pour exécuter des conteneurs Linux nativement sur les Mac Apple Silicon. Sans Docker Desktop, sans daemon permanent, et avec un modèle d’isolation différent. L’outil a récemment passé un cap : sa version 1.0 stable est disponible depuis juin 2026. Autour de ce socle, une petite galaxie d’outils communautaires a déjà vu le jour : un équivalent à Docker Compose, des interfaces graphiques façon Docker Desktop… Dans cet article, je vous propose de découvrir ce qu’est container, comment l’installer et l’utiliser au quotidien.
Si la conteneurisation est un terrain nouveau pour vous, la lecture de notre article Qu’est-ce que Docker et pourquoi l’utiliser ? vous donnera les bases (images, conteneurs, registres) qui valent aussi pour container.
Qu’est-ce que container, l’outil de conteneurs d’Apple ?
container est un outil open source développé par Apple qui permet de créer et d’exécuter des conteneurs Linux au format OCI (comme les images de Docker) directement sur un Mac équipé d’une puce Apple Silicon. Sa particularité tient à son architecture : chaque conteneur s’exécute dans sa propre machine virtuelle légère, via le framework Virtualization de macOS, là où Docker Desktop fait tourner tous les conteneurs dans une seule VM Linux partagée.
En pratique, l’outil sait faire ce qu’on attend d’un runtime de conteneurs : pull, build, run et push d’images OCI depuis n’importe quel registre standard (Docker Hub, GitHub Container Registry, registre privé…). La ligne de commande ressemble beaucoup à celle de Docker, ce qui limite le dépaysement.
Quelques mots sur cet outil édité par Apple :
Licence : open source, sous licence Apache 2.0.
Modèle économique : gratuit, c’est un outil first-party livré par Apple.
Stack technique : écrit en Swift, il s’appuie sur le framework Virtualization de macOS et sur un noyau Linux optimisé (de la famille Kata). Il repose sur le paquet Swift Containerization, qui expose les API bas niveau (images, réseau, démarrage des VM). Un mini système d’init écrit en Swift, vminitd, démarre les conteneurs très rapidement.
Ressources : le dépôt GitHub officiel apple/container, le paquet apple/containerization et la page projet sur Apple Open Source.
Note : container a atteint sa version 1.0.0 le 9 juin 2026, un an après sa présentation à la WWDC 2025. C’est la première version stable : la CLI et les API (XPC) sont désormais figées, avec une garantie de compatibilité entre versions correctives (1.0.x). Le projet reste actif et des évolutions sont à attendre sur les futures versions mineures. Vérifiez la version courante sur la page des releases.
Une architecture : une VM par conteneur
Docker Desktop sur Mac démarre une unique machine virtuelle Linux qui héberge le moteur Docker et l’ensemble des conteneurs. container, lui, démarre une micro-VM dédiée pour chaque conteneur, avec son propre noyau Linux et sa propre pile réseau.
Ce choix a des conséquences directes :
Isolation renforcée : un conteneur ne partage ni noyau ni espace mémoire avec un autre. La surface d’attaque entre conteneurs s’en trouve réduite.
Ressources à la demande : il n’y a pas de grosse VM qui tourne en permanence en arrière-plan. Les ressources (CPU, mémoire) sont allouées quand un conteneur est actif, et libérées ensuite.
Un noyau par conteneur : on peut, en théorie, faire cohabiter des conteneurs s’appuyant sur des noyaux différents.
Une IP par conteneur : chaque conteneur obtient sa propre adresse réseau au niveau de l’hôte Mac, ce qui change la façon de l’exposer (nous y reviendrons).
container ou Docker Desktop : quelles différences ?
Voici une comparaison synthétique pour situer les deux approches :
Critèrecontainer (Apple)Docker DesktopÉditeurAppleDocker, Inc.LicenceOpen source (Apache 2.0)Propriétaire (gratuit sous conditions, payant en entreprise)ArchitectureUne micro-VM légère par conteneurUne VM Linux partagée pour tous les conteneursNoyau LinuxUn noyau dédié par conteneurUn noyau partagéRéseauUne IP par conteneur (pile réseau macOS)NAT / bridge via la VMPlateformeApple Silicon + macOS 26 uniquementIntel et Apple Silicon ; macOS, Windows, LinuxDaemonPas de daemon système permanentDaemon Docker + icône en barre de menusDocker ComposePas de support natif (projets tiers)IntégréDémarrageSous la seconde, ressources à la demandeVM active en permanence en arrière-planMaturité / écosystèmeStable depuis la 1.0 (juin 2026), écosystème encore en constructionMature, écosystème très large
container n’est donc pas (encore) un remplaçant universel de Docker Desktop. C’est un outil pensé d’abord pour le développement local sur Mac, qui est adapté avec les workflows mono-conteneur, mais qui ne vise pas l’orchestration ni la production. Pour cela, on reste sur Docker et, à l’échelle supérieure, sur Kubernetes.
Installer container sur macOS
Prérequis
Pour suivre ce guide et profiter d’Apple Container, il vous faut :
Un Mac équipé d’une puce Apple Silicon (M1, M2, M3, M4…). L’outil n’est pas conçu pour les Mac Intel.
macOS 26 (Tahoe). C’est la version officiellement prise en charge : container exploite des nouveautés de virtualisation et de réseau introduites dans cette release. Les mainteneurs indiquent ne pas traiter les problèmes qui ne sont pas reproductibles sur macOS 26.
Télécharger et installer le paquet
La méthode officielle consiste à récupérer le paquet d’installation signé (.pkg) depuis la page des releases GitHub. Choisissez de préférence le paquet signé et notarisé par Apple : il évite d’avoir à contourner Gatekeeper. Double-cliquez sur le .pkg et suivez les instructions.
container est également disponible via Homebrew, ce que beaucoup d’utilisateurs préfèrent pour gérer leurs outils en ligne de commande :
brew install container
L’installateur de container va créer plusieurs binaires sous /usr/local/bin : container, container-apiserver, uninstall-container.sh, update-container.sh.
Démarrer le service et vérifier l’installation
Une fois l’outil installé, on lance le service système qui gère le cycle de vie des conteneurs :
container system start
Au premier lancement, l’outil vous proposera de télécharger et d’installer un noyau Linux par défaut : acceptez.
On vérifie ensuite que tout répond en listant les conteneurs (la liste est vide au départ) :
# Lister tous les conteneurs (y compris arrêtés)
container ls -a
# La sortie affiche des en-têtes vides :
ID IMAGE OS ARCH STATE IP CPUS MEMORY STARTED
# Afficher les informations de version (pour container et container-apiserver)
container system version
Pour arrêter le service (par exemple avant une mise à jour) :
container system stop
Les mises à jour et retours arrière se gèrent avec les scripts update-container.sh et uninstall-container.sh (installés dans /usr/local/bin), ce dernier acceptant -k pour conserver vos données ou -d pour tout supprimer.
Note : depuis la 1.0, la configuration du système passe par un fichier TOML (~/.config/container/config.toml). Les sous-commandes container system property get/set des versions précédentes ont été retirées. Un détail à connaître si vous migrez depuis une version 0.x.
Premiers pas : exécuter et gérer des conteneurs sur Mac
La bonne nouvelle, si vous connaissez déjà Docker, c’est que la syntaxe est très proche. Voyons les commandes essentielles à connaître pour prendre en main Container sur votre Mac.
Lancer un conteneur
Au lieu d’exécuter un docker run, c’est la commande container run qu’il faudra utiliser. Voici comment lancer un conteneur interactif et obtenir un shell :
container run -it alpine sh
Pour lancer un conteneur en arrière-plan (mode détaché), l’option -d doit être spécifiée, comme avec Docker. Il est également possible de nommer le conteneur, ici serveur-web à partir de l’image nginx.
container run -d –name serveur-web nginx
Les options -i et -t (–interactive et –tty) raccordent votre terminal au shell du conteneur. Là encore, ces options sont identiques à celles de Docker.
Lister, inspecter et entrer dans un conteneur
Première différence à connaître : il n’y a pas de container ps. L’équivalent de docker ps avec l’outil d’Apple est container ls. Voici quelques exemples d’utilisation.
Lister les conteneurs en cours d’exécution
container ls
Lister tous les conteneurs, y compris ceux arrêtés
container ls -a
Les deux conteneurs exécutés à l’étape précédente sont bien visibles, dont celui nommé serveur-web.
Obtenir le détail (format JSON) d’un conteneur
container inspect serveur-web
Exécuter une commande dans un conteneur
container exec serveur-web ls /usr/share/nginx/html
Ouvrir un shell interactif dans un conteneur en cours d’exécution
container exec -it serveur-web sh
Suivre la consommation de ressources en direct
container stats
Container ID Cpu % Memory Usage Net Rx/Tx Block I/O Pids
serveur-web 0.00% 22.29 MiB / 1.00 GiB 31.49 KiB / 0.59 KiB 16.30 MiB / 8.00 KiB 6
Si la logique du cycle de vie d’un conteneur ne vous est pas familière, notre tutoriel Création et gestion des conteneurs Docker détaille les mêmes notions côté Docker, directement transposables ici.
Travailler avec les images
Dans cette section, nous verrons comment télécharger une image depuis le Registre, comment lister les images locales et nous verrons également comment créer une image personnalisée à l’aide d’un Dockerfile.
Pour récupérer une image depuis un registre, exécutez la commande suivante (exemple avec alpine). L’image sera téléchargée dans sa dernière version à partir du Docker Hub.
container image pull alpine
Forme complète équivalente à la commande ci-dessus :
container image pull docker.io/library/nginx:latest
Les images officielles (nginx, alpine, ubuntu…) résident dans l’espace de noms library de Docker Hub, tandis que les images publiées par un utilisateur ou une organisation suivent le schéma docker.io//.
Pour récupérer une version précise, on indique le tag après le nom de l’image, comme on le fait habituellement avec Docker :
container image pull nginx:1.27-alpine
container image pull alpine:3.20
Pour tirer une image depuis un autre registre (GitHub Container Registry, registre privé…), on précise son hôte dans la référence :
# GitHub Container Registry
container image pull ghcr.io//:
Sur Apple Silicon, c’est la variante arm64 qui est récupérée par défaut. On peut forcer une autre architecture ou plateforme, par exemple pour obtenir une image amd64 :
container image pull –platform linux/amd64 nginx:latest
Une fois l’image récupérée, on la retrouve dans la liste locale, et on peut consulter ses métadonnées :
container image ls
NAME TAG DIGEST
alpine latest 28bd5fe8b56d
nginx alpine 54f2a904c251
nginx latest ec4ed8b5299e
Afficher les métadonnées détaillées d’une image (JSON) :
container image inspect nginx:latest
Et la recherche sur Docker Hub ? À ce jour, la CLI container ne propose pas d’équivalent à docker search : il n’existe pas de commande pour interroger Docker Hub directement depuis le terminal. Pour trouver une image, passez par le site de Docker Hub (hub.docker.com), ou par l’un des clients graphiques évoqués plus loin (Orchard, par exemple), qui intègrent une recherche dans les registres.
Construire une image
Pour illustrer la construction d’une image, créons une petite application : une page web statique servie par Nginx, avec un logo IT-Connect, que nous afficherons ensuite dans un conteneur. On commence par créer un dossier de projet contenant trois fichiers :
mon-app/
├── Dockerfile
├── index.html
└── logo-it-connect.png
Le Dockerfile décrit, étape par étape, comment construire l’image :
# Image de base légère : Nginx sur Alpine Linux
FROM nginx:alpine
# Métadonnées de l’image
LABEL org.opencontainers.image.title=”mon-app” \
org.opencontainers.image.description=”Page de demonstration IT-Connect servie par Nginx” \
org.opencontainers.image.authors=”IT-Connect”
# Copier la page et le logo dans le repertoire servi par Nginx
COPY index.html /usr/share/nginx/html/index.html
COPY –chmod=644 logo-it-connect.png /usr/share/nginx/html/logo-it-connect.png
# Documenter le port sur lequel le conteneur ecoute
EXPOSE 80
# Pas de CMD ici : l’image officielle Nginx demarre deja le serveur au premier plan
Détaillons chaque instruction :
FROM nginx:alpine : définit l’image de base. On part de Nginx sur Alpine Linux, une variante volontairement minimaliste pour obtenir une image légère.
LABEL : ajoute des métadonnées normalisées (titre, description, auteur) à l’image. C’est facultatif, mais cela documente votre travail et c’est exploité par certains outils.
COPY index.html et COPY logo-it-connect.png : copient les fichiers locaux dans /usr/share/nginx/html, le répertoire que Nginx sert par défaut.
EXPOSE 80 : indique le port sur lequel le service écoute.
Pas de CMD : l’image officielle Nginx définit déjà la commande de démarrage (lancement du serveur au premier plan), que notre image hérite automatiquement.
Voici un exemple de page index.html basique, avec un peu de texte et qui affiche le logo :
mon-app – Demo container
Conteneur construit avec l’outil container d’Apple.
Note : placez votre fichier logo-it-connect.png dans le dossier du projet, à côté du Dockerfile. Si vous ne souhaitez pas inclure de logo, retirez simplement la ligne COPY logo-it-connect.png du Dockerfile ainsi que la balise de la page.
Il ne reste plus qu’à construire l’image depuis le dossier du projet. Avant d’exécuter la commande suivante, positionnez-vous dans le répertoire du projet (cd mon-app).
container build -t mon-app .
Il est possible que cette commande retourne l’erreur suivante :
Error: internalError: “failed to bootstrap container” (cause: “internalError: “failed to bootstrap container buildkit (cause: “unknown: “Error Domain=VZErrorDomain Code=2 “Rosetta is not installed” UserInfo={NSLocalizedFailure=Invalid virtual machine configuration., NSLocalizedFailureReason=Rosetta is not installed}””)””)
Le builder BuildKit s’appuie sur Rosetta, et si vous obtenez ce message, c’est qu’il n’est pas installé sur votre Mac. Pour rappel, Rosetta est la couche de traduction d’Apple qui permet à un Mac équipé d’une puce Apple Silicon (ARM) d’exécuter des programmes compilés pour les processeurs Intel (x86-64), en les traduisant à la volée.
La solution consiste à installer Rosetta 2, ce qui se fait en une commande dans le Terminal :
softwareupdate –install-rosetta –agree-to-license
Une fois l’installation terminée, relancez simplement votre build :
container build -t mon-app .
Cette fois-ci, l’opération est un succès !
Cette image personnalisée est à présent disponible :
container image list
NAME TAG DIGEST
mon-app latest 29217fcb9696
La prochaine étape consiste à exécuter un conteneur basé sur cette image. Par exemple :
container run -d –name serveur-itco mon-app
L’application Web est ensuite accessible :
Sur Apple Silicon, les images sont construites en ARM64 par défaut. container sait aussi produire des images multi-architectures, pratique pour publier une image consommable aussi bien sur ARM64 que sur AMD64 :
# Construire pour les deux architectures
container build –arch amd64,arm64 -t mon-app:1.0.0 .
Pour publier sur un registre, on s’authentifie puis on pousse l’image. Comme avec Docker, privilégiez un jeton d’accès personnel (PAT) plutôt que votre mot de passe de compte, et fixez-lui une date d’expiration.
Il faut commencer par se connecter à un registre (Docker Hub ici) :
container registry login –username docker.io
Puis, étiqueter et pousser l’image :
container image tag mon-app:latest docker.io//mon-app:1.0.0
container image push docker.io//mon-app:1.0.0
Les notions d’images, de couches et de registres sont communes à tout l’écosystème OCI : notre chapitre sur les concepts clés (images, conteneurs, registres) reste une bonne référence.
Enfin, puisque nous venons de nous connecter à un registre, sachez que vous pouvez vérifier les registres pour lesquels des identifiants ont été enregistrés :
container registry list
Note : container registry list n’affiche que les registres où vous vous êtes connecté via container registry login. Docker Hub reste utilisable sans authentification pour récupérer des images publiques, comme nous avons pu le faire précédemment avec nginx ou alpine.
Réseau : une adresse IP par conteneur
C’est là que le modèle de container se démarque vraiment. Docker attribue lui aussi une adresse IP à chaque conteneur, mais sous Docker Desktop ces adresses vivent sur un réseau interne à la VM Linux et ne sont pas joignables directement depuis macOS : on publie alors un port (-p) pour accéder au service via localhost. Avec container, chaque conteneur reçoit une IP exposée sur le réseau de l’hôte macOS, que l’on peut donc contacter directement, sans publication de port.
Testez les manipulations ci-dessous et vous verrez :
# Récupérer l’adresse du conteneur
container ls
# Exemple de sortie : serveur-web running 192.168.64.3
# Ouvrir le service directement sur son IP
open http://192.168.64.3
Réseau : joindre un conteneur par son nom
L’outil container d’Apple permet aussi de joindre un conteneur par un nom (.) plutôt que par son IP, mais cela demande une mise en place en deux étapes complémentaires, qui ne font pas la même chose :
Enregistrer le domaine au niveau de macOS avec container system dns create. Cette opération nécessite sudo, car elle indique au système de router les requêtes *. vers le résolveur de container. C’est elle qui rend le domaine réellement résolvable depuis l’hôte.
Désigner ce domaine comme domaine par défaut des conteneurs, dans le fichier ~/.config/container/config.toml. Ce fichier utilisateur ne fait que choisir le domaine à appliquer par défaut. Il ne peut pas réaliser l’enregistrement auprès du système, qui exige des privilèges administrateur (d’où la première étape-.
Les deux sont donc requis : la première crée le domaine dans le système, la seconde indique à container de l’utiliser. Déclarer dans config.toml un domaine qui n’a jamais été créé reviendrait à pointer vers un domaine que macOS ne sait pas router. Voici la séquence complète, avec un domaine local nommé mac.
Enregistrez le domaine local au niveau de macOS (une seule fois) :
sudo container system dns create mac
Créez le fichier de configuration et y déclarer le domaine par défaut :
mkdir -p ~/.config/container
cat > ~/.config/container/config.toml << ‘EOF’
[dns]
domain = “mac”
EOF
Redémarrez le service pour appliquer les changements :
container system stop
container system start
Vérifiez que le domaine est bien enregistré :
container system dns list
DOMAIN
mac
Une fois cette configuration en place, les conteneurs sont résolus sur le domaine mac (par exemple serveur-web.mac), directement depuis votre Mac.
Note : le fichier config.toml n’existe pas par défaut, pas plus que le dossier ~/.config/container/ ; c’est pourquoi on les crée à l’étape 2. Le service ne lit ce fichier qu’au démarrage : après toute modification, redémarrez-le.
Persistance des données
Par défaut, tout ce qu’un conteneur écrit dans son système de fichiers disparaît avec lui : supprimez le conteneur, et les données sont perdues. Pour conserver un état au-delà de la vie d’un conteneur (une base de données, des fichiers téléversés, des journaux) il faut stocker ces données à l’extérieur. container propose pour cela deux mécanismes, exactement comme Docker : les bind mounts et les volumes nommés.
Les bind mounts : monter un dossier de l’hôte
Un bind mount relie un dossier de votre Mac à un chemin dans le conteneur. C’est l’idéal en développement, lorsque vous voulez que le conteneur travaille directement sur des fichiers que vous éditez côté macOS. Voici un exemple pour monter le dossier courant de l’hôte dans le conteneur.
container run -it -v $(pwd):/app -w /app alpine sh
Détaillons la syntaxe -v : :
$(pwd) : la source, ici le dossier courant de votre Mac (vous pouvez indiquer n’importe quel chemin absolu).
/app : la cible, le point de montage à l’intérieur du conteneur.
-w /app : définit le répertoire de travail du conteneur sur ce point de montage.
Tout ce qui est écrit dans /app côté conteneur l’est en réalité dans le dossier de l’hôte, et inversement : les modifications sont visibles des deux côtés, en temps réel. Vous pouvez aussi monter un dossier en lecture seule en ajoutant ,readonly, ce qui est une bonne pratique lorsque le conteneur ne doit pas modifier les fichiers :
container run -it -v $(pwd)/data:/data,readonly alpine sh
Les volumes nommés : un stockage géré par container
Un volume nommé est un espace de stockage persistant, géré par container lui-même, indépendant de tout dossier de l’hôte. C’est la solution recommandée pour les données applicatives que vous ne manipulez pas directement, comme le répertoire de données d’une base. On le crée, puis on l’attache à un conteneur avec la même syntaxe -v, en utilisant le nom du volume comme source.
Commencez par créer un volume nommé avec le nom donnees-bdd :
container volume create donnees-bdd
Puis, attachez le volume au conteneur bdd (ici, le répertoire de données de PostgreSQL) :
container run -d –name bdd \
-e POSTGRES_PASSWORD=motdepasse \
-v donnees-bdd:/var/lib/postgresql/data \
postgres:16
Le volume survit à la suppression du conteneur : vous pouvez arrêter et supprimer bdd, puis recréer un conteneur attaché au même volume donnees-bdd, vos données seront toujours là. Cela m’amène à vous présenter d’autres commandes pour gérer les volumes.
container volume ls
Afficher les détails d’un volume (JSON) :
container volume inspect donnees-bdd
Supprimer un volume (impossible s’il est utilisé par un conteneur) :
container volume delete donnees-bdd
Supprimer tous les volumes non utilisés :
container volume prune
Un volume utilisé par un conteneur, même arrêté, ne peut pas être supprimé : il faut d’abord retirer le conteneur qui le référence.
Bind mount ou volume nommé : lequel choisir ?
CritèreBind mount (-v /chemin/hote:/cible)Volume nommé (-v nom:/cible)EmplacementUn dossier précis de votre MacGéré par container, hors de votre arborescenceCas d’usage typeDéveloppement : éditer le code sur le Mac, l’exécuter dans le conteneurDonnées applicatives : base de données, contenus générésAccès direct aux fichiersOui, depuis le FinderNon, on passe par le conteneurPortabilitéDépend de l’arborescence de l’hôteIndépendant du poste
En pratique : bind mount pour le code que vous éditez, volume nommé pour l’état que l’application produit.
Allouer CPU et mémoire à un conteneur
Par défaut, un conteneur reçoit 4 CPU et 1 Go de RAM. On peut le vérifier avec la commande container ls :
Pour ajuster ces limites, on peut compléter la commande de lancement avec les options –cpus et –memory :
container run -d –name web –cpus 2 –memory 2g nginx
Quelques précisions sur ces options :
–cpus : le nombre de cœurs alloués à la VM du conteneur.
–memory : la quantité de mémoire, avec un suffixe d’unité (k, m, g, t…). Les unités sont binaires : 2g correspond donc à 2 Go. Sans suffixe, la valeur est interprétée en octets.
On peut vérifier les ressources réellement attribuées à un conteneur avec container inspect, qui les expose dans un bloc resources :
container inspect web
…
“readOnly” : false,
“resources” : {
“cpuOverhead” : 1,
“cpus” : 2,
“memoryInBytes” : 2147483648
},
Note – le cas du builder : la VM qui construit les images (buildkit) a ses propres valeurs par défaut, plus modestes : 2 CPU et 2 Gio de RAM. Pour une construction lourde, vous pouvez les augmenter en démarrant le builder explicitement au préalable, par exemple container builder start –cpus 8 –memory 8g.
Enfin, plutôt que de répéter ces options à chaque run, il est possible de définir des valeurs par défaut persistantes dans le fichier ~/.config/container/config.toml (le même que celui utilisé pour le DNS), via une section dédiée aux conteneurs. Par exemple :
[container]
cpus = 2
memory = “2g”
container machine : un environnement Linux persistant
La version 1.0 ne se limite pas aux conteneurs applicatifs : elle introduit aussi le mode container machine, qui fournit un environnement Linux persistant sur le Mac. Là où un conteneur est calqué sur une application éphémère, une container machine est calquée sur un système Linux complet : votre dossier personnel macOS y est monté, vous éditez côté Mac et compilez côté Linux, et vous pouvez y faire tourner des services au long cours. C’est l’équivalent le plus proche de WSL (disponible sur Windows) côté macOS.
Le sujet méritant un traitement à part entière, je lui consacre un article dédié : container machine : un environnement Linux persistant sur macOS, façon WSL.
Aller plus loin : un équivalent à Docker Compose pour container
Le plus gros manque actuellement, c’est l’absence de support natif de Docker Compose. Décrire une stack multi-services dans un fichier docker-compose.yml et la lancer d’une seule commande n’est pas (encore) possible nativement avec container.
Qu’est-ce que Docker Compose ? C’est un outil qui permet de définir une application multi-conteneurs (par exemple une base de données, une API et un front-end) dans un seul fichier YAML, puis de la démarrer ou l’arrêter d’une commande (docker compose up / down). Vraiment très pratique dès qu’une application dépasse un conteneur.
La communauté a déjà commencé à combler ce vide avec des projets open source qui lisent un fichier au format Compose et le traduisent en commandes container. Je vous recommande de regarder cet outil :
Container-Compose (par Mcrich23) : un outil écrit en Swift, sous licence MIT, qui mappe les volumes et le réseau définis dans un fichier Compose vers leurs équivalents container. Attention, ce n’est pas un wrapper non plus, et tout n’est pas pris en charge. Mais, si vous voulez tester, voici le lien vers le dépôt : github.com/Mcrich23/Container-Compose.
Gérer ses conteneurs Apple avec une interface graphique
Autre brique manquante côté Apple : il n’existe pas de tableau de bord officiel équivalent à l’interface de Docker Desktop. Là encore, plusieurs interfaces graphiques open source ont émergé. Elles s’appuient sur la CLI container (ou sur ses API) pour offrir une gestion visuelle des conteneurs, images, volumes et réseaux. Quelques projets à connaître :
Orchard : une application macOS native écrite en Swift, qui dialogue avec container via la bibliothèque ContainerAPIClient (en XPC). Elle permet de créer, démarrer, arrêter et supprimer des conteneurs, de parcourir et puller des images, de chercher sur Docker Hub, de suivre les logs de plusieurs conteneurs en parallèle et de monitorer CPU, mémoire et réseau. Installation via Homebrew ou paquet préconstruit. Dépôt : github.com/andrew-waters/orchard.
iContainer : une application macOS native écrite en SwiftUI (licence MIT), vibe-codée à l’aide de Claude, qui s’appuie sur la CLI container officielle. Elle propose un tableau de bord, la gestion complète du cycle de vie des conteneurs (création depuis une image ou un build de Dockerfile, démarrage, arrêt, redémarrage, édition des ports/volumes/variables d’environnement), des onglets par conteneur (informations réseau et montages, statistiques avec graphiques, shell interactif persistant, logs en mode suivi), la gestion des images (liste, pull, inspection, suppression, authentification aux registres) ainsi que le pilotage du service container. Installation via Homebrew (cask) ou paquet préconstruit. Dépôt : github.com/nico81/iContainer.
On peut aussi citer AppleContainerGUI et Container Desktop, que je vous laisserai regarder si cela vous intéresse.
Attention : plusieurs de ces clients communautaires (iContainer, Container Desktop…) ne sont pas notarisés par Apple, faute pour leurs auteurs de disposer d’un compte développeur payant. La notarisation est le contrôle par lequel Apple vérifie qu’une application ne contient pas de code malveillant. Sans elle, macOS bloque le premier lancement avec un message du type “Apple n’a pas pu confirmer que ne contenait pas de logiciel malveillant”. Ne cliquez pas sur « Placer dans la corbeille », mais sur « Terminé », puis autorisez l’application via les paramètres de sécurité ou avec la commande suivante pour retirer l’attribut de mise en quarantaine (exemple avec iContainer) : xattr -dr com.apple.quarantine /Applications/iContainer.app.
Conclusion
L’outil Container d’Apple est une initiative qui change la donne pour l’exécution de conteneurs sur Mac : un runtime de conteneurs open source, natif et signé par Apple, bâti sur une architecture taillée pour Apple Silicon. Pour des usages mono-conteneur ou limités à quelques services, il est déjà agréable à utiliser, et son modèle “une VM par conteneur” est intéressant pour le cloisonnement.
Avec la version 1.0 publiée en juin 2026, l’outil est désormais stable : la CLI et les API sont stabilisées, et la fonctionnalité container machine ouvre la voie à des environnements Linux persistants sur le Mac. Maintenant, nous attendons une prise en charge native des fichiers Docker Compose natif, et pourquoi pas une interface officielle. Aujourd’hui, ces deux points sont compensés par des projets communautaires prometteurs mais pour la plupart immatures.
Pour aller plus loin
FAQ
Qu’est-ce que l’outil container d’Apple ?
C’est un outil open source développé par Apple qui permet de créer et d’exécuter des conteneurs Linux au format OCI directement sur un Mac Apple Silicon. Chaque conteneur s’exécute dans sa propre machine virtuelle légère via le framework Virtualization de macOS.
container remplace-t-il Docker sur Mac ?
Avec la version 1.0 stable, container devient une option crédible pour le développement local sur Mac, en particulier pour des usages mono-conteneur ou basés sur quelques services. Il lui manque toutefois encore le support natif de Docker Compose. Vous pouvez tout à fait conserver Docker en parallèle.
Quels sont les prérequis pour utiliser container ?
Un Mac équipé d’une puce Apple Silicon (M1 ou plus récent) et macOS 26 (Tahoe), la version officiellement prise en charge. La construction d’images nécessite en plus Rosetta 2. macOS 15 peut fonctionner partiellement, mais avec des limites réseau.
container fonctionne-t-il sur un Mac Intel ?
Non. L’outil est conçu et optimisé pour Apple Silicon. Les Mac à processeur Intel ne sont pas pris en charge.
Comment installer container sur macOS ?
On télécharge le paquet d’installation signé (.pkg) depuis la page des releases du dépôt apple/container, puis on l’installe par double-clic. Il faut ensuite démarrer le service avec container system start. L’installation via Homebrew est aussi proposée.
Comment lancer un conteneur avec container ?
La syntaxe ressemble à Docker : container run -it alpine sh pour un shell interactif, ou container run -d –name serveur-web nginx pour un conteneur en arrière-plan. On liste ensuite les conteneurs avec container ls.
Existe-t-il un équivalent à Docker Compose pour container ?
Pas nativement. Mais des projets communautaires comme Container-Compose (de Mcrich23, en Swift) lisent un fichier au format docker-compose.yml et le traduisent en commandes container. Cela manque de maturité actuellement.
Existe-t-il une interface graphique pour Apple Container ?
Apple ne fournit pas d’interface officielle, mais plusieurs clients graphiques open source existent, comme Orchard, Container Desktop, AppleContainerGUI ou iContainer. Ils s’appuient sur la CLI container pour gérer visuellement conteneurs, images, volumes et réseaux.
container peut-il utiliser les images de Docker Hub ?
Oui. Container peut exécuter et produire des images OCI standard. Il peut donc récupérer et exécuter des images depuis Docker Hub, GitHub Container Registry ou tout autre registre compatible, et y pousser vos propres images.
Quelle est la version actuelle de container ?
container a atteint sa version 1.0.0, publiée le 9 juin 2026, un an après son lancement en aperçu à la WWDC 2025. C’est la première version stable, avec une CLI et des API figées. Le projet continue d’évoluer : consultez la page des releases du dépôt apple/container pour vérifier quelle est la version la plus récente.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.