2025 年 11 月發布的 OCI Runtime Spec v1.3 把 FreeBSD 正式列為官方支援平台，jails 從此透過新增的 freebsd 設定物件接上標準容器執行流程。這件事對只用 Linux 容器的團隊看起來很遙遠，實際上補上了容器生態長年缺的一塊——「一套跟 Linux cgroups 無關、卻能跑 OCI 標準映像檔的隔離方案」。配上 Doug Rabson 主導的 ocijail、Samuel Karp 的 runj、以及 Podman 的 FreeBSD port，2026 年開始 jail-based 容器化已經不是只能靠 BastilleBSD 那套獨立工具鏈才做得起來的事。
這一步拖了這麼久的原因
FreeBSD jails 1999 年就落地，概念上比 Docker 早十四年。真正讓 jails 一直沒走進主流容器生態的，是它的設定參數跟 Linux cgroups / namespaces 徹底無關——OCI runtime spec 從 1.0 開始就圍繞 Linux 的 cgroups、namespaces、capabilities 設計，所有實作預設只處理 linux 物件底下的東西。
Samuel Karp 2021 年發布 runj，試著把 jail 參數靠 OCI 1.0 的 extension 機制塞進去，走的是 runj.ext.json 這種非標準欄位。問題也顯而易見：各家容器引擎對 extension 的支援度不一致，runj 得等 Podman、containerd、Kubernetes 一個個改。隔年 Doug Rabson 把 Podman 跟 Buildah 加上 FreeBSD 支援，FreeBSD 基金會對這段過程的描述是「需要對 FreeBSD 核心做關鍵改動才能符合 OCI runtime spec 的要求」——不只是上層適配，連核心層面都要配合容器語意改。
三年多的推進之後，OCI 1.3 直接把 freebsd 物件寫進規範主幹，extension hack 的時代結束。這份規範一旦收乾，下游實作就有一份固定合約可以引用，runj 跟 ocijail 都已經切到新格式；runj 保留 runj.ext.json 當過渡期的相容層，之後會砍掉。
freebsd 物件把 jail 原生概念寫進規範
新加的 freebsd 物件跟原本的 linux 物件平行存在。參數名直接對應 jail(8) 的既有旗標：host.hostname、ip4.addr、ip6.addr、allow.mount、allow.raw_sockets 這些 FreeBSD 管理員熟悉的名字一比一搬進容器 spec。這個設計刻意不把 jail 包裝成「假的 Linux」，也不試圖做一套 cgroups 的 FreeBSD 翻譯層。
技術上的意義是什麼？容器映像檔從此可以帶一份正式的 FreeBSD 執行配置、被任何支援 OCI 1.3 的 runtime 直接消費，而不是被當成「某個私有擴充欄位」處理。這條路一打通，Docker Hub 跟 OCI registry 上的 FreeBSD 原生映像檔就有了標準化的執行語意，長年各家容器工具只能靠 Linux 相容層勉強跑 FreeBSD workload 的局面被繞開。
Podman 在 FreeBSD 上的實際樣貌
安裝一行 pkg install podman，想要 Buildah 跟 Skopeo 可以直接裝 podman-suite 整組。資料路徑預設落在 /var/db/containers。ZFS 使用者應該另外切一個 dataset 掛在這個路徑下，Podman 會自動啟用 ZFS storage driver，直接拿 copy-on-write、壓縮、snapshot 當 image layer 底層；沒跑 ZFS 的環境則退回 vfs，效能跟空間成本都明顯比較差——這點是沒有討論餘地的：想在 FreeBSD 上跑容器就該走 ZFS，不然底層優勢等於放棄一半。
網路需要 PF 做 NAT。port 內附一份範本可以直接改，-p 要用的話需要載入 pf 核心模組並把 net.pf.filter_local 開到 1。開機自動啟動走 FreeBSD 慣例的 sysrc podman_enable=YES，另外 podman_service_enable 旋鈕專門控制 API/socket 服務，給需要 Docker 相容工具的場景用。
兩種容器可以在同一台主機上並存，這是這套方案最實用的賣點：
1 | # 跑原生 FreeBSD 映像檔，底層是 ocijail |
原生 FreeBSD 映像檔走 ocijail runtime，是真正的 FreeBSD userland 在 jail 裡執行、沒有任何模擬，啟動延遲跟記憶體佔用都比 Linux VM 低一個數量級。Linux 映像檔透過 Linuxulator 翻譯系統呼叫，I/O 綁定為主的服務（PostgreSQL、Nginx、Redis 這類）實際跑起來的效能損耗落在個位數百分比。
跟 Linux Podman 不一樣的地方
這條路線的硬限制值得攤開來看，裝之前先認清楚：
沒有 systemd。連帶沒有 Quadlets、沒有 journald 整合、沒有 podman auto-update 的排程器。取代方式是 rc.d 腳本，用 REQUIRE: DAEMON podman 跟 rcorder 把啟動順序串起來，複雜度回到十年前管 Linux 服務的手感。日誌走 syslog 或 Podman 自帶的 log driver。auto-update 要自己寫 cron 拉 image 跟重建容器。
Rootless 不在今天的 FreeBSD 工作流程裡。所有容器部署實際上都跑 root 身份，威脅模型跟 Linux 主流做法差一截。這塊得靠 jail 本身的隔離能力撐住資安邊界——好消息是 jail 的歷史比 containers 悠久、邊界也更簡單；壞消息是繞過一旦出現（像 FreeBSD-SA-26:04 這個 nullfs 共享觸發的 CVE-2025-15576 jail 逃逸），影響等級跟 Linux 的 cgroup escape 一樣嚴重。多租戶部署前這點一定要先想清楚。
沒有 Linux cgroups、沒有 seccomp、沒有 eBPF。資源限制走 rctl，可以設 CPU、記憶體、open files 這些典型限制，但要做細粒度的磁碟 I/O 限制或網路 QoS，工具箱比 Linux 窮一截。想在 FreeBSD 上做容器層級的 Cilium、Falco、Pixie 這類 observability 工具目前沒有對應產品，這對 cloud-native 深度使用者是真正的硬傷。
Linuxulator 的覆蓋率是另一個現實考量。常見 server workload 幾乎都能動，但依賴 cgroups v2、eBPF、/sys/fs/cgroup 細節或某些冷門 syscall 的工具會踩到洞。這類專案正式部署前得實際跑一輪 smoke test。
這條路線值得走的三種場景
真正受惠的場景集中在三類：
本來就跑 FreeBSD 的團隊，原本為了容器化服務不得不另外開 Linux VM，現在可以直接在 FreeBSD host 上開 Podman，jail 跟 Linux 容器用同一個 CLI 管。長期維運成本直接砍半。
重 I/O 又靠 ZFS 的工作負載。PostgreSQL 的 WAL、備份服務的差異式快照、檔案伺服器的 dedup，這些跑在 FreeBSD 上，ZFS 整合比 Linux 的 OpenZFS 緊很多——snapshot、rollback 直接變成容器日常操作而不是另外一套工具。
把 FreeBSD 當 edge router、firewall 或 NAS 的設備。PF、CARP、hastd 這些東西在 FreeBSD 上成熟，當這類節點順便想跑一兩個監控或資料採集容器，不用為此多拉一台 Linux。
反過來，踩到以下任一條都建議留在 Linux：需要 rootless 容器（compliance 或多租戶場景）、吃 Kubernetes 且依賴 cgroups v2、大量用 eBPF 做 observability、開發團隊完全沒有 FreeBSD 操作經驗。硬套這條路線會在細節上吃虧。
當前成熟度跟 2026 年之後的方向
FreeBSD port 到 2026 年 4 月的狀態仍標為 experimental，但實際跑起來的體感比這個標籤樂觀。daemonless 專案補上了一批原生 FreeBSD OCI base image，常見 Linux base 都能透過 Linuxulator 跑起來。更關鍵的大勢是 OCI 1.3 已經把 freebsd 寫進規範，containerd 跟 Kubernetes 社群要支援 FreeBSD node 從此有官方契約可以引用——不會再有人用「這是 extension、不保證跨工具相容」把這條路擋在門外。
對 FreeBSD 社群的策略意義值得單獨拉出來講。這一步把 jail 從「一套只有 FreeBSD 自己認得的隔離技術」轉成「可以被 Docker Hub、container registry、CI/CD pipeline 直接消費的 OCI 相容 runtime」。多了這條路，FreeBSD 在雲端部署的門檻一次下降一大截，長年「選 FreeBSD 等於放棄現代容器生態」的刻板印象從現在開始站不住腳。對臺灣以中小團隊為主的自架社群而言，手上多一條路線並不是壞事——當 Linux 容器的某個痛點（例如 systemd 綁死、cgroup v1 淘汰、kernel 升級被容器 runtime 卡住）剛好打到專案時，有另一個相容生態可以切換，整體技術選擇就有彈性。
VPS 層級要不要走 FreeBSD + Podman 這條路，實際上得先在真實硬體上驗證 Linuxulator 對自家 workload 的覆蓋率，以及 ZFS 搭配容器工作負載的效能表現。NCSE Network 的臺灣是方電訊機房 VPS 搭配 Intel Gold CPU 跟 NVMe SSD，支援直接安裝 FreeBSD 14.3 作為基礎映像檔，7 天免費試用讓團隊有空間跑完完整的容器 workload 測試再決定是否轉移；若有結合 jail 跟現代容器生態的架構規劃需求，這是把兩條路線在同一環境並行比較的合適起點。
