Apple container 1.0.0：Mac 上跑 Linux 容器，Apple 選了一條每個容器一台 VM 的路

如果你平常在 Mac 上寫程式，又常常需要 Linux container，應該很熟悉那種微妙的斷裂感：編輯器在 macOS，檔案在你的 home 目錄，真正跑起來的東西卻躲在某個 Linux VM 裡。出問題時，你要分辨是 container 的問題、VM 的問題、網路轉發的問題，還是 Mac 和 Linux 之間那層膠水突然不聽話。

Apple container 有趣的地方就在這裡。它碰的不是 CLI 外皮，而是 Mac 上那層 Linux container 執行模型。官方文件寫得很直接：這是一個用 Swift 寫、針對 Apple silicon 優化的工具，可以在 Mac 上把 Linux containers 跑成 lightweight virtual machines，而且吃的是標準 OCI image。

apple/container README 中的官方操作 GIF — 官方 README 內的操作 GIF，展示 container CLI 的基本使用體感。

這句話很容易被讀成行銷標語，但拆開看其實很硬。OCI image 代表你熟悉的 registry、image pull、image build、image push 這條路還在；lightweight VM 則把每個 container 的隔離單位往 VM 靠近。對寫後端、跑測試、折騰本地 AI 工具或需要乾淨 Linux 環境的人來說，這個取捨很值得看。

它真正換掉的是「Mac 上跑 Linux container」那層模型

在 Mac 上跑 Linux container，本來就不可能完全像 Linux host 那樣直接。macOS 不是 Linux kernel，所以中間一定要有虛擬化。常見工具的做法，是起一台 Linux VM，再把多個 container 放進去。這個模型成熟、好用、生態大，但它也讓很多東西變成同一個 VM 裡的狀態：檔案掛載、網路、DNS、資源、debug 線索，有時候都混在一起。

一般 Mac 容器工具共享 Linux VM 與 Apple container 每容器 VM 的差異圖 — 常見共享 Linux VM 模型，和 Apple container 每個 container 背後一台輕量 VM 的模型差異。

Apple container 的核心想法比較偏另一端。根據官方 technical overview，它透過底層的 Containerization Swift package，為每個 container 建立一個 lightweight VM。這不代表它要你把 container 當完整虛擬機管理，CLI 還是 `container run`、`container build`、`container image pull` 這種路線；只是背後的隔離邊界變得更清楚。

我覺得這裡最適合用「本地開發的心理模型」來看。先看 workload，再看它自己的 VM 邊界、runtime helper 和網路附著方式。這個角度比「我有一台 Linux VM，裡面塞了很多 container」更接近 Apple container 想做的事，也比較適合重視隔離、想少一點共享狀態的人。

CLI 後面其實是一組 macOS service

repo 裡的架構文件把流程講得很清楚：你操作的是 `container` CLI，但 CLI 會透過 client library 跟 `container-apiserver` 溝通。`container-apiserver` 是 launch agent，會在 `container system start` 之後啟動，負責管理 container 和 network resources。

後面還有幾個 helper。container-core-images 負責 image management 和 local content store；container-network-vmnet 負責虛擬網路；每次建立 container 時，container-apiserver 會啟動 container-runtime-linux，讓那個 container 的 runtime management API 有自己的入口。封面圖和下面這張流程圖想表達的就是這件事：一條 CLI 指令背後，有一組很 macOS 的 service 拆分。

Apple container 從 CLI 到 apiserver、image、network、runtime VM 的流程圖 — container CLI 後方的 apiserver、image helper、network helper、builder VM 與 runtime VM。

這也是為什麼 Apple container 看起來不像傳統 Linux 工具硬搬到 Mac。它用到 macOS Virtualization framework、vmnet、XPC、launchd、Keychain services 和 unified logging system。你可以把它想成 Apple 把「Linux container 在 Mac 上該怎麼像本地工具一樣活著」這件事，往系統框架裡塞得更深。

1.0.0 真正有感的是 container machine

截至我這次整理時，GitHub 上最新 release 是 1.0.0，發布時間是 2026 年 6 月 9 日。這版有幾個明顯會影響日常使用的點：`container machine`、TOML 設定檔、`container cp`，以及 JSON、YAML、TOML 這類 structured output 的整理。

Apple container 1.0.0 的 container machine、config TOML、container cp 與 structured output — 1.0.0 裡最影響使用方式的幾個變化：container machine、config.toml、container cp 與 structured output。

`container machine` 是我覺得最有意思的新增功能。一般 container 比較像「跑一個 app」；container machine 則比較像「給我一個會長駐、可重複進出的 Linux 環境」。官方文件說它會把 macOS 的 username 和 home directory 對應進 Linux 環境裡，你可以在 Mac 上用原本的 editor 或 IDE 編輯檔案，然後進 container machine 裡 build、test、跑服務。

container machine 讓 Mac 編輯與 Linux build test 接在一起的工作流圖 — container machine 把 macOS home、repo、Linux build/test 和長駐服務接成同一條工作流。

這對 Codex Desktop App 這種工作流其實滿有畫面。很多時候我們缺的是「穩定、乾淨、可重進」的 Linux 工作間，而不只是一個短命 container。repo 在 Mac home 裡，AI agent 或你自己在 Mac 上改檔，Linux 端負責 build 和測試。以前你可能會開 Docker container、devcontainer、遠端 VPS 或完整 VM；Apple container machine 則把這種需求做成它自己的子命令。

它甚至支援比較接近真 Linux 環境的服務測試。文件提到，如果 image 有 systemd，你可以用像 systemctl start postgresql 這種方式跑長駐服務。這個功能不會每個人天天用，但如果你的痛點是「我想用 Mac 當主機，又想測 Linux service 行為」，它比每次開一個短命 container 更貼近需求。

config.toml、container cp、structured output：這幾個比較務實

1.0.0 的另一個變化，是系統設定改成 TOML config。舊的 UserDefaults backed system properties 被替換掉，設定入口變成 `~/.config/container/config.toml`。這件事聽起來不華麗，但對會自動化環境的人很重要。設定檔可以進 dotfiles、可以 diff、可以備份，也比較適合讓 agent 或腳本去讀。

container cp 則是很接地氣的補洞。host 和 container 之間搬檔案，最理想就是一個指令解決，不用每次都繞 volume、重新 build image，或用一些臨時 shell 管線硬接。這種功能不會讓人驚呼，但少了就會每天卡一下。

structured output 的調整也值得一提。Release note 提到 container、image、network、volume 的 ls 和 inspect 類輸出形狀被整理過。一般使用者看到的是表格更整齊；寫腳本的人、讓 AI agent 讀 CLI 結果的人，會在這裡省下不少防呆。輸出格式穩，後面的自動化才不會每次被欄位小變動弄到翻車。

更像 Apple 自己的本地容器路線

如果你現在每天靠 Docker Desktop、Compose、Kubernetes、devcontainer 或一堆現成教學工作，Apple container 目前不會是無痛替換。官方文件也沒有把它包裝成萬能替代品。它支援基本 build、run、image、network、volume、registry、logs、stats、exec、cp 等命令，但成熟度、生態外掛、團隊既有流程，這些都不是一個 1.0.0 版號就能瞬間補齊。

限制也要看清楚。README 寫明主要需求是 Apple silicon Mac，並且支援 macOS 26，因為它用了新版 virtualization 和 networking 能力。technical overview 也提到 macOS 15 有網路隔離、多 network、container IP address 等限制，維護者不打算處理那些只在舊系統重現的問題。換句話說，如果你的 Mac 還停在舊版 macOS，這東西不適合拿來當主力。

另外，每個 container 一台 VM 的模型很漂亮，但它也不是免費午餐。它帶來更清楚的隔離邊界，也讓 host data mount 可以更精準；不過你仍然要理解 VM resource、memory 行為、network 模型，尤其官方文件提到目前 memory ballooning 在 macOS Virtualization framework 只支援部分情境，container VM 裡被釋放的 memory page 不一定會回到 host。你跑很多吃記憶體的 workload 時，可能還是得重啟 container 來降用量。

如果你只是想找一個今天就把所有 Docker workflow 搬過去的工具，我不會建議你衝太快。這個 repo 更像是 Apple 在告訴開發者：Mac 上的 Linux container 不必永遠長成「一台共享 VM 加一堆轉接線」的樣子。Apple silicon、Virtualization framework、vmnet、XPC 和 Swift package 可以組出另一條本地路線。

我會特別留意三種使用場景。第一種是需要比較乾淨隔離邊界的本地測試。第二種是想把 Mac editor 和 Linux build/test 接起來的 container machine。第三種是 agent 自動化，因為 CLI structured output、TOML config、`container cp` 這些都會影響後續能不能穩定串流程。

所以這篇不把 Apple container 寫成 Docker killer。它比較像一個方向很明確的 Mac-native container platform：OCI image 還在，Linux 還在，CLI 還在，但底下的模型從「大家住同一台 Linux VM」變成「每個 workload 有自己的輕量 VM 邊界」。如果你是 Apple silicon 使用者，而且常常在本地折騰 Linux 開發環境，這個 repo 值得放進觀察清單。