ORCHARD : le GUI natif macOS pour apple/container

⏱️ Temps de lecture estimé : 4 minutes

https://orchard.andon.dev/

📌 ORCHARD est une application macOS native, écrite en Swift, qui donne une interface graphique au runtime container d’Apple. Conteneurs, machines virtuelles, clusters Kubernetes, projets Compose et modèles IA locaux : tout se pilote depuis la fenêtre, sans repasser par le terminal.

Le geste du quotidien, c’est celui d’un compose up. Vous pointez Orchard sur votre compose.yaml, la stack se monte dans l’ordre des dépendances, et chaque service apparaît avec son IP et son hostname, à côté du réseau que le projet a créé. Une stack lancée en terminal se retrouve quand même dans l’app : les projets sont repérés par les labels posés sur les conteneurs, pas par un fichier qu’Orchard aurait gardé de son côté. À l’ouverture, c’est le dashboard qui vous accueille, avec la consommation CPU, mémoire, réseau et disque de tout ce qui tourne.

Le point que je regarde en premier, c’est la manière dont il parle au daemon. Orchard passe par la même API XPC typée que le CLI container, pas par un shell qui lance des commandes et en relit la sortie. Concrètement : pas de process enfant à chaque rafraîchissement, des erreurs typées plutôt que des codes de sortie, et de vrais flux de logs qui alimentent la visionneuse multi-panneaux. Le projet admet quelques exceptions — démarrage du système, cycle de vie des builders, domaines DNS qui demandent root, sélection du noyau — mais le chemin principal reste natif. C’est aussi ce qui explique la différence avec Podman Desktop, une app Electron qui passe par un shim Docker API.

Le morceau qui m’accroche le plus est le pont vers l’IA locale. Les VM de container n’ont pas accès au GPU, donc l’inférence doit tourner sur l’hôte. Orchard découvre les serveurs déjà en place (Ollama, LM Studio, MLX), peut démarrer lui-même des mlx_lm.server supervisés avec leurs logs, puis calcule l’adresse joignable depuis le conteneur — la gateway du réseau — et l’injecte en OPENAI_BASE_URL dès la création. Le conteneur embarque ensuite le SDK OpenAI, sans câblage manuel.

Les sandboxes vont plus loin : un conteneur relié à un modèle local sur un réseau host-only, qui atteint le modèle mais pas Internet, avec un badge honnête — Isolated ou Egress open — et un interrupteur d’arrêt. La doc est explicite : l’isolation vient de la frontière VM de container et du réseau que vous choisissez, Orchard n’en ajoute pas. J’apprécie qu’un outil affiche ses limites au lieu de les emballer. Deux bémols : les serveurs qu’il détecte restent en lecture seule, et la création d’un réseau host-only depuis l’app est encore annoncée comme à venir.

• 🎛 Cmd+K interroge tout : recherche floue et actions en clair (« stop db », « logs api », « console web »)
• 🧠 OPENAI_BASE_URL calculé et injecté vers votre serveur MLX, sans configuration réseau
• 🛡 Sandboxes host-only : le modèle reste joignable, Internet non
• 📊 Journaux de build BuildKit conservés entre deux redémarrages
• 🔗 Deep links orchard:// vers n’importe quel onglet ou ressource

Le reste suit la même logique. Les container machines sont des VM Linux persistantes, créées depuis n’importe quelle image avec init, réglables en CPU, mémoire, home-mount ou noyau, avec un garde-fou qui vous prévient avant de partir d’une image sans système d’init. Les clusters Kubernetes locaux s’appuient sur le plugin k8s de container : nœuds groupés avec rôle et IP, chargement d’images locales dans le containerd, et un kubectl déjà positionné sur le bon contexte. Un second up compare chaque service à un hash estampé sur le conteneur qu’il a produit, et l’onglet Problems liste avant le premier lancement ce que le fichier demande et que le runtime ne peut pas honorer.

Deux limites valent d’être dites : le runtime ne remontant pas de healthcheck, up démarre les dépendances avant les dépendants sans attendre qu’elles soient prêtes, et les hostnames doivent être uniques sur toute la machine — un service répond donc sous -.

L’installation tient en une ligne, brew install orchard, et chaque version est signée avec un Apple Developer ID puis notarisée par Apple. Le projet est en MIT, compte 1 601 étoiles, et la 2.4.3 date du 21 septembre. Ce n’est pas un jouet, mais c’est un pari assumé : macOS 26 Tahoe obligatoire, et Orchard ne pilote que le runtime d’Apple. Si vous êtes chez OrbStack ou Docker Desktop, il ne vous apporte rien, et la compatibilité Docker API n’est pas au programme. Pour qui teste sérieusement apple/container, je trouve l’ensemble convaincant et inhabituellement honnête. Pour les autres, il peut attendre.

Sources

• Site officiel — Orchard
• GitHub — andrew-waters/orchard