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 , 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 .

Qu’est-ce que container, l’outil de conteneurs d’Apple ?

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, , démarre les conteneurs très rapidement.
• Ressources : le dépôt GitHub officiel , le paquet 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. , 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 :

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 : 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é () 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 et suivez les instructions.

est également disponible via Homebrew, ce que beaucoup d’utilisateurs préfèrent pour gérer leurs outils en ligne de commande :

L’installateur de container va créer plusieurs binaires sous : , , , .

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 :

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) :

Pour arrêter le service (par exemple avant une mise à jour) :

Les mises à jour et retours arrière se gèrent avec les scripts et (installés dans ), ce dernier acceptant pour conserver vos données ou pour tout supprimer.

Note : depuis la 1.0, la configuration du système passe par un fichier TOML (). Les sous-commandes 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 , c’est la commande qu’il faudra utiliser. Voici comment lancer un conteneur interactif et obtenir un shell :

Pour lancer un conteneur en arrière-plan (mode détaché), l’option doit être spécifiée, comme avec Docker. Il est également possible de nommer le conteneur, ici à partir de l’image .

Les options et ( et ) 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 . L’équivalent de avec l’outil d’Apple est . Voici quelques exemples d’utilisation.

• Lister les conteneurs en cours d’exécution

• Lister tous les conteneurs, y compris ceux arrêtés

Les deux conteneurs exécutés à l’étape précédente sont bien visibles, dont celui nommé .

• Obtenir le détail (format JSON) d’un conteneur

• Exécuter une commande dans un conteneur

• Ouvrir un shell interactif dans un conteneur en cours d’exécution

• Suivre la consommation de ressources en direct

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 ). L’image sera téléchargée dans sa dernière version à partir du Docker Hub.

Forme complète équivalente à la commande ci-dessus :

Les images officielles (, , …) résident dans l’espace de noms de Docker Hub, tandis que les images publiées par un utilisateur ou une organisation suivent le schéma .

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 :

Pour tirer une image depuis un autre registre (GitHub Container Registry, registre privé…), on précise son hôte dans la référence :

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 :

Une fois l’image récupérée, on la retrouve dans la liste locale, et on peut consulter ses métadonnées :

Afficher les métadonnées détaillées d’une image (JSON) :

Et la recherche sur Docker Hub ? À ce jour, la CLI ne propose pas d’équivalent à : 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 (), 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 :

Le décrit, étape par étape, comment construire l’image :

Détaillons chaque instruction :

• : définit l’image de base. On part de Nginx sur Alpine Linux, une variante volontairement minimaliste pour obtenir une image légère.
• : 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.
• et : copient les fichiers locaux dans , le répertoire que Nginx sert par défaut.
• : indique le port sur lequel le service écoute.
• Pas de : 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 basique, avec un peu de texte et qui affiche le logo :

Note : placez votre fichier dans le dossier du projet, à côté du . Si vous ne souhaitez pas inclure de logo, retirez simplement la ligne du 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 ().

Il est possible que cette commande retourne l’erreur suivante :

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 :

Une fois l’installation terminée, relancez simplement votre build :

Cette fois-ci, l’opération est un succès !

Cette image personnalisée est à présent disponible :

La prochaine étape consiste à exécuter un conteneur basé sur cette image. Par exemple :

L’application Web est ensuite accessible :

Sur Apple Silicon, les images sont construites en ARM64 par défaut. sait aussi produire des images multi-architectures, pratique pour publier une image consommable aussi bien sur ARM64 que sur AMD64 :

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) :

Puis, étiqueter et pousser l’image :

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 :

Note : n’affiche que les registres où vous vous êtes connecté via . Docker Hub reste utilisable sans authentification pour récupérer des images publiques, comme nous avons pu le faire précédemment avec ou .

Réseau : une adresse IP par conteneur

C’est là que le modèle de 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 () pour accéder au service via . Avec , 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éseau : joindre un conteneur par son nom

L’outil 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 . Cette opération nécessite , car elle indique au système de router les requêtes vers le résolveur de . 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 . 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 à de l’utiliser. Déclarer dans 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é .

Enregistrez le domaine local au niveau de macOS (une seule fois) :

Créez le fichier de configuration et y déclarer le domaine par défaut :

Redémarrez le service pour appliquer les changements :

Vérifiez que le domaine est bien enregistré :

Une fois cette configuration en place, les conteneurs sont résolus sur le domaine (par exemple ), directement depuis votre Mac.

Note : le fichier n’existe pas par défaut, pas plus que le dossier ; 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. 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.

Détaillons la syntaxe :

• : la source, ici le dossier courant de votre Mac (vous pouvez indiquer n’importe quel chemin absolu).
• : la cible, le point de montage à l’intérieur du conteneur.
• : définit le répertoire de travail du conteneur sur ce point de montage.

Tout ce qui est écrit dans 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 , ce qui est une bonne pratique lorsque le conteneur ne doit pas modifier les fichiers :

Les volumes nommés : un stockage géré par container

Un volume nommé est un espace de stockage persistant, géré par 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 , en utilisant le nom du volume comme source.

Commencez par créer un volume nommé avec le nom :

Puis, attachez le volume au conteneur (ici, le répertoire de données de PostgreSQL) :

Le volume survit à la suppression du conteneur : vous pouvez arrêter et supprimer , puis recréer un conteneur attaché au même volume , vos données seront toujours là. Cela m’amène à vous présenter d’autres commandes pour gérer les volumes.

• Lister les volumes :

• Afficher les détails d’un volume (JSON) :

• Supprimer un volume (impossible s’il est utilisé par un conteneur) :

• Supprimer tous les volumes non utilisés :

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 ?

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 :

Pour ajuster ces limites, on peut compléter la commande de lancement avec les options et :

Quelques précisions sur ces options :

• : le nombre de cœurs alloués à la VM du conteneur.
• : la quantité de mémoire, avec un suffixe d’unité (, , , …). Les unités sont binaires : 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 , qui les expose dans un bloc :

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 .

Enfin, plutôt que de répéter ces options à chaque , il est possible de définir des valeurs par défaut persistantes dans le fichier (le même que celui utilisé pour le DNS), via une section dédiée aux conteneurs. Par exemple :

container machine : un environnement Linux persistant

La version 1.0 ne se limite pas aux conteneurs applicatifs : elle introduit aussi le mode , 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 et la lancer d’une seule commande n’est pas (encore) possible nativement avec .

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 ( / ). 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 . 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 . 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 (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 via la bibliothèque (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 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 . 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 <nom de l’app> 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) : .

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é 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

• La documentation et le code sur le dépôt et le paquet .
• Notre cours Maîtriser Docker et Kubernetes pour solidifier les fondamentaux de la conteneurisation.
• Dans un registre voisin et original : Dockur – exécuter Windows 11 et macOS dans un conteneur Docker.

FAQ