MinIO 開源版在 4 月走進歷史：Garage 用 50MB 記憶體接下自架 S3 的位置

MinIO 的開源版本在 2026 年 4 月正式關上大門——GitHub 倉庫被標為 archived，社群版不再有新版本、安全更新或預編譯 binary。對長期把 MinIO 當作自架 S3 標配的人來說，這意味著手上的部署不再有上游維護，新環境也找不到能放心採用的選項。

社群這幾個月的取捨已經逐漸收斂。SeaweedFS 體量大、功能多但相對複雜；RustFS 仍然停在 alpha；Ceph 對小規模部署過度沉重。真正承接中小型自架物件儲存需求的，是法國 Deuxfleurs 合作社開發的 Garage——一支二十多 MB 的 Rust binary，把分散式物件儲存壓縮到一個極小的核心。

MinIO 留下的真空比想像中大

MinIO 退出的訊號其實從 2025 年就開始累積。管理介面（Console）先被搬出社群版，接著官方文件改寫成只剩 Enterprise 路徑，到了 2026 年 4 月倉庫直接 archived。雖然有 OpenMaxIO、pgsty/minio 等社群分支試圖續命，但活躍度都不足以支撐生產環境長期使用。

對 Restic、Kopia、Velero、Loki、Mimir 這類重度依賴 S3 API 的工具來說，問題並不在於 MinIO 馬上會停止運作，而在於：作業系統升級後是否仍能跑、新爆出的 CVE 是否有人修、Kubernetes 上的 Operator 是否還有人維護。沒有上游就意味著任何一個基礎環境變動都得自己扛。

替代品的選擇其實比想像中收斂。Ceph 是企業級答案，但需要至少三節點、底層儲存規劃和大量運維知識；SeaweedFS 適合大規模、混合檔案類型的部署，但啟動門檻較高；RustFS 路徑最像 MinIO 的 drop-in 替代，可惜版本還停在 1.0.0-alpha.X，文件本身就在警告未到生產等級。

剩下 Garage 站在最務實的位置——已經跑在多個合作社、非營利機構與中小型工作室的生產環境多年，單機可用、多節點可擴展，在檔案數量不爆炸的場景下表現穩定。

為什麼是 Garage，而不是 SeaweedFS 或 RustFS

Garage 的設計哲學很反直覺：它不追求每秒幾十萬 IOPS，也不假設機房內網有微秒級延遲。它的目標是「即使把節點分散在不同國家、用一般家用網路串起來，也能跑得起來的 S3」。

這個假設帶來幾個關鍵差別。Garage 沒有 primary node 概念，任何節點都能直接服務讀寫請求，不需要先轉發到主節點；後設資料層用 CRDT（Conflict-free Replicated Data Type）取代分散式共識，節點間斷線後恢復可以自動收斂，不會卡在等 etcd 選主；記憶體佔用約 50MB，對比 MinIO 動輒 500MB 以上，能直接放進已經吃緊的 VPS。

SeaweedFS 走另一條路：master/volume server 架構、檔案系統與物件儲存並存、對大量小檔案做了專門優化，但配置複雜度也跟著上升。RustFS 想走 MinIO drop-in，API 行為更貼近原本工作流，但 alpha 版本目前不該放進任何重要環境。

選擇邏輯可以簡化：要快速取代手上的 MinIO 且場景單純（備份、靜態檔案、日誌歸檔）——選 Garage；要服務需要極高並發或檔案系統介面的大規模應用——SeaweedFS；想等 MinIO 的精神後繼者——盯著 RustFS 但先別動。

把 Dynamo 加 CRDT 塞進一支 binary

Garage 內部結構是 Amazon Dynamo 那篇 2007 年論文的現代化變種。資料切成 block，每個 block 用 Blake2 hash 命名並去重；後設資料表（bucket、object、version、block reference）以 CRDT 形式存在 LMDB 或 sled 引擎中。

寫入時 Garage 預設使用 quorum write：把 block 同步送到三個負責節點，等其中兩個回 ack 就回應客戶端 200 OK，第三個在背景補完。讀取則只需要從任一存有副本的節點取回。這個策略讓單一節點抖動不會阻塞整個叢集。

CRDT 的好處在於節點間不需要時刻保持一致。網路分區發生時雙邊都能繼續服務寫入，分區結束後 Merkle tree 同步機制會把差異收斂回一致狀態。這也是 Garage 敢宣稱「能跑在資料中心之外」的底氣——家用網路偶爾的斷線重連，對它來說只是另一種正常狀況。

代價是 strong consistency 不存在。剛寫入的物件可能在另一個節點短暫看不到，這對備份和靜態檔案完全沒影響，但用來當作即時 session store 就不適合。

單機 VPS 跑得起來：實際的部署細節

Garage 在單機模式下其實非常簡單。一份 garage.toml、一個 systemd unit 或 docker-compose 就能跑起來：

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "lmdb"

replication_factor = 1

rpc_bind_addr = "127.0.0.1:3901"
rpc_public_addr = "127.0.0.1:3901"
rpc_secret = "<openssl rand -hex 32 的輸出>"

[s3_api]
api_bind_addr = "127.0.0.1:3900"
s3_region = "garage"
root_domain = ".s3.example.tw"

[s3_web]
bind_addr = "127.0.0.1:3902"
root_domain = ".web.example.tw"
index = "index.html"

[admin]
api_bind_addr = "127.0.0.1:3903"
admin_token = "<openssl rand -hex 32 的輸出>"

範例把四個 port 全部綁在 127.0.0.1，因為單機部署的拓樸就是同主機上的 Caddy/Nginx 在前面終止 TLS，再轉發到本機回 Garage。RPC（3901）與 admin API（3903）尤其不該對公網開放，即使有 secret 與 token 也一樣——對外只暴露反向代理上的 443，是最不容易出錯的設定。多節點部署則需要把 rpc_bind_addr 換成內網介面位址或 [::]，並用防火牆把 3901 的來源鎖在叢集成員之間。

啟動之後用 garage layout assign -z dc1 -c 100G <node_id> 為節點分配 zone 與容量，再 garage layout apply --version 1 寫入叢集設定。建立 access key、新增 bucket、設定權限三個指令就能對外提供服務。

實務上 metadata_dir 一定要放 SSD，因為 LMDB 的 random read/write 對 latency 非常敏感；data_dir 才是真正吃容量的部分，可以放大顆 HDD 或外接 block storage。把這兩塊分開能讓單台 VPS 的儲存規劃變得更彈性。

對外暴露的常見做法是讓 Caddy 或 Nginx 在前面終止 TLS，再轉發到 3900（S3 API）與 3902（static web）。S3 client 大多支援 path-style，所以 root_domain 不一定要設網域，但設了就能讓 bucket.s3.example.tw 這種 virtual-host 風格直接運作。

多節點部署：zone、容量與三副本的真實成本

副本數開到 3 才是 Garage 真正展現價值的時候。replication_factor = 3 搭配三個分散在不同 zone 的節點，可以容忍單一機房整體下線。zone 不限定是地理上的資料中心，也能是「不同電力線路」「不同網路供應商」等容錯邊界。

Garage 排副本的演算法會盡量讓三份資料落在三個不同 zone。如果手上只有兩個 zone，它會自動 fallback 成兩份在 A、一份在 B 的配置，並在日誌警告非最優佈局。多 zone 的指令直接寫：garage layout assign -z taipei -c 500G ...、-z tainan ...、-z singapore ... 各分配一節點，就能獲得跨地理冗餘。

容量規劃常被誤算：實際可用空間 ≈ 最小節點容量 × 節點數 ÷ 副本數。三節點各 500GB、副本數 3，意味著大概只有 500GB 可用，而不是 1500GB。Garage 把每筆資料都當成要寫三份計算，使用率超過單一節點容量後叢集會直接回報空間不足。

跨地理部署最常被低估的是 RPC 流量。每筆寫入都會在節點間複製，網路頻寬與成本要算進去——一份月 100GB 的寫入，意味著節點間至少 200GB 的 RPC 流量。

Garage 不擅長的事

務實要點：Garage 不是 MinIO 的功能完全替代。三件最常踩到的事——Object Lock 沒有實作，這代表搭配 Restic、Kopia 做 ransomware-resistant 備份時拿不到 bucket-level immutability；IAM policy 只支援極簡的 access key 模型，沒有 AWS 風格的 condition、resource policy；lifecycle 規則目前只支援 expiration，沒有 transition 到別的 storage class。

Server-side encryption 從 v1.0 後支援 SSE-C，但 SSE-S3（伺服器全自動加密）還沒列入路線圖。要全 disk-level 加密只能在底下用 LUKS 補。

對小檔案密集（單目錄超過數十萬物件）的場景，Garage 的 metadata 引擎會吃力。SeaweedFS 在這類工作負載下表現明顯好得多，需要的話可以接受配置成本上升換取效能。

從 MinIO 搬到 Garage 的路徑

絕大多數遷移可以用 rclone sync 或 mc mirror 解決，因為兩邊都是標準 S3 API：

1 2	rclone sync minio:bucket-a garage:bucket-a \ --transfers 8 --checksum --progress

要注意兩件事：原本依賴 MinIO admin API 的腳本（mc admin user add 等）要改用 Garage 的 garage bucket allow 與 garage key new；如果應用程式寫死了 path-style endpoint，要先確認 Garage 的 root_domain 設定一致，避免 SDK 自動切到 virtual-host 後解析失敗。

帶 versioning 的 bucket 可以遷移，但 Garage 的物件版本實作與 MinIO 略有差異，遷移前要先確認應用沒有依賴特定的 version-id 格式。對於有 Object Lock 需求的備份場景，與其勉強用 Garage 不如改走 application-level 的不可變策略，或評估 SeaweedFS。

把 S3 從第三方搬回 VPS

對八成以上的自架場景——備份目的地、靜態網站托管、日誌歸檔、Container registry storage、AI 模型權重存放——Garage 已經夠用，且資源開銷遠低於繼續維持 MinIO 殭屍版本。手上有兩三台跨地區 VPS 的人，把它們組成 Garage 叢集就能拿到自己的高可用 S3，不必把資料交給 AWS S3 或 Cloudflare R2。

如果手邊的 VPS 規格還在抗拒 MinIO 的記憶體開銷、或想開始規劃多節點 S3 卻沒有合適的網路冗餘，NCSE Network 提供臺灣本地的高效能 VPS 主機（Intel Gold CPU、NVMe SSD、是方電訊機房）與彈性的 IP Transit 頻寬規劃，能搭配跨機房或跨區域部署 Garage 叢集，需要評估自架 S3 架構時可以參考。