2026 年 3 月 27 日 14:57（UTC），sailboxhq/sailbox 這個 repo 建立。不到一分鐘後，第一個 commit，訊息是 first commit。

隔天，3 月 28 日，同一個 repo 發了四個 release（以下時間都是 UTC）：v0.1.0 在 08:12，v0.1.1 在 10:44，v0.1.2 在 10:59，v0.1.3 在 15:47。v0.1.1 和 v0.1.2 之間隔了十五分鐘。再隔一天，v0.1.4 到 v0.1.6 也出來了。七個版本，兩天。

新 repo 兩天推出七個版本，節奏很快，README 沒有解釋原因。我讀 README 時注意到的是另一件事：它交代自己為什麼存在，第一個講的就是底層用什麼。

一個叫 mini-Heroku 的東西

自架 PaaS 這個類別的起點，要回到 Dokku。repo 在 2013 年 6 月 8 日建立，README 的第一句是 “Docker powered mini-Heroku. The smallest PaaS implementation you’ve ever seen.”，首個 release 是同年 11 月 20 日的 v0.2.0-RC1。

這裡先講一個口徑。我下面講的「首個 release」，指的是 GitHub releases 列表最舊的那一筆，不等於第一個能用的版本，也不等於產品發表日。日期都是 gh api 在 2026 年 10 月 24 日取的。

接下來的故事，我只能照日期排，不能替它們編理由。每個專案為什麼出現，我手上沒有一手資料，所以下面只放「什麼時候建 repo、README 說底層是什麼」：

四代自架 PaaS 與它們的底層

2013-06-08 Dokku

repo 建立。README：Docker powered mini-Heroku。首個 release v0.2.0-RC1 在 2013-11-20。

2017-10-25 CapRover

repo 建立，首個 release v0.1.2 在 2017-11-17。README 寫 Docker Swarm under the hood for containerization and clustering。

2021-01-25 Coolify

repo 建立，首個 release v1.0.0 在 2021-03-24。README 的底層我沒讀，下面講的 Docker Compose 是 Sailbox README 比較表的標法。

2024-04-19 Dokploy

repo 建立，首個 release v0.0.1 在 2024-05-02。README 寫用 Docker Swarm 管叢集，同時原生支援 Docker Compose。

2026-03-27 Sailbox

repo 建立。README 自述：Self-hosted PaaS, powered by Kubernetes (K3s)。

把 K3s 的日期拿來對照這五列，有一件事很顯眼：K3s 的 repo 在 2018 年 5 月 31 日就建了，首個 release v0.1.0-rc1 在 2019 年 1 月 22 日。也就是說，Coolify 和 Dokploy 開工的時候，K3s 早就在那裡。它們為什麼選了別的底層，我查不到一手說法，不猜。

前四個到 2026 年 10 月 24 日都還活著。Dokku、CapRover、Coolify、Dokploy 的 archived 都是 false，最後一次 push 全落在當天；星數分別是 32,202、15,188、63,680、37,995。Sailbox 是 16。

「轉捩點」只有作者自己的說法

編年故事講到這裡，通常會冒出一個轉捩點：某件事讓大家換了底層。我手上有的只是 Sailbox README 的 “Why we built this”，所以只能寫成它自己的敘述：

We used Coolify, Dokploy, CapRover — they’re great projects… Under the hood, they rely on Docker Compose or Docker Swarm. That works well for many use cases — but when we needed real health checks, graceful rolling updates, autoscaling, or the ability to grow from one node to three, we found ourselves fighting the abstraction instead of shipping.

這是 Sailbox 作者自己踩到的限制，我沒有查證過：他們說自己在 health check、滾動更新、autoscaling、從一個節點長到三個節點這幾件事上，卡在跟抽象層打架。是哪個專案、哪個功能、卡在哪一步，README 沒寫。我能轉述的就這麼多。

接著他們講了另一個問題：一般的 Kubernetes 太重，要多個節點，要專職維運。然後找到 K3s，說它是塞進單一 binary、小於 100 MB 的 CNCF 認證發行版，五美元的 VPS、樹莓派、2 GB RAM 的裸機（這是我的轉述，不是逐字翻譯）都跑得動。最後一句是 “Sailbox doesn’t wrap Kubernetes — it is Kubernetes.”

這些全是 README 的話。「CNCF-certified」我沒在 K3s 的 README 查到對應字眼，這一點未查證。README 另外附了一張比較表，Orchestrator 那列把 Sailbox 標成 Kubernetes (K3s)、Coolify 標成 Docker Compose、Dokploy 標成 Docker Swarm，Autoscaling (HPA) 只有 Sailbox 打 Yes。表是作者填的，我沒有驗證競品那兩欄對不對。

README 自己也承認了缺口：同一張表裡，Docker Compose support 和 One-click templates 兩列，Sailbox 欄都是「—」，競品是 Yes。這張表上，Sailbox 的賣點是 HPA 和真的 K8s，而範本和 Compose 這兩樣大家習慣的東西，標的是沒有。

讀到這裡，我自己的想像是這樣的：把底層從 Compose 換成 K3s，像是把房子的地基整個打掉重灌。地基換了，樓上的裝潢還是要有人鋪，這個專案自己就是一層面板，把 K8s 的物件包成「部署應用、資料庫、cron job」。複雜度只是換了地方放。出事時使用者要面對的，會是哪一層，我不知道。這段是推論，不是我讀到的事實。

它自己的時間線只有短短一段

先交代我讀了什麼：Sailbox 的 repo 元資料、release 列表、全部 15 個 commit 的紀錄、README、NOTICE、倉庫裡的 install.sh。沒有裝過，沒有執行 install.sh，也沒有開過它的面板。我只讀了倉庫內的 install.sh，沒有打開線上的 get.sailbox.dev，所以線上那份是不是同一個，我不知道。

README 給的安裝方式是一行：

1
2
3
curl -sSL https://get.sailbox.dev | sudo sh
# Opens at http://your-server-ip:3000
# Requirements: Linux (x86_64 / arm64), 2 CPU, 2 GB RAM minimum.

倉庫裡的 install.sh 在第 77 行有 “Install K3s” 那段；第 84 到 88 行偵測 WireGuard，支援的話把 flannel 的 backend 設成 wireguard-native，輸出 “WireGuard detected — using encrypted network”。換句話說，這個腳本替你裝的是整個 K3s，不只是一個面板。

接下來是我最想讓人看的部分，全部 15 個 commit 裡我挑四筆：

1
2
3
4
2026-03-27 14:58Z  9629c11f  first commit
2026-03-29 02:55Z  54143b0e  feat: add self-upgrade via one-shot upgrader container and invitation email
2026-04-02 01:26Z  699318af  Refactor error handling and resource management across multiple services
2026-09-13 04:30Z  ad01f840  feat: add resource limits update functionality for databases

最後兩筆之間，我從 15 筆的日期排序推出，沒有任何 commit。四月二日到九月十三日，五個多月。v0.1.7 在 4 月 2 日，v0.1.8 在 9 月 13 日。之後到 10 月 24 日，又是 41 天，這個數字是我自己把 9 月剩下的 17 天加上 10 月的 24 天算的。

貢獻者只有一位，alanisme，15 個 commit，剛好是全部。README 用的是 “We”，我只能說 README 以「我們」自稱，不能由此推論有團隊。16 顆星，8 個 fork。測試檔我數了一下：檔名符合 _test.go 的只有一個，apps/api/internal/auth/session_test.go。這個數字只算 Go 測試檔，前端和其他語言我沒查。

授權有兩個口徑，要分開講。gh api 回報的 license 是 AGPL-3.0。但倉庫裡的 NOTICE 另外寫了一條：所有複製和衍生作品，要在使用者介面上保留 “Powered by Sailbox” 的標示，不能藏、不能縮小、不能弄得不明顯；想拿掉得另外談商業授權。只看 API 欄位的人，會漏掉這一條。

所以我的立場很具體：現在不會把正式環境的工作負載放在 Sailbox 上。理由不是它是 K3s，是下面這幾件事疊在一起：一位貢獻者、一個 Go 測試檔、最後一個 commit 距今 41 天、版本號還在 0.1.x。這些都不證明它不好，只證明出事時沒有人可以保證有人回你。

要讓我鬆口，不必三件事都成立。九月十三日之後 repo 重新有 commit，而且不只一筆，算一件。出現第二位貢獻者，算一件。有作者以外的人公開拿它跑過多節點的場景，也算一件。其中任何一件出現，「不放正式環境」就可以降成「可以拿一台備用機試」。

要是只是想看看真的 K3s 在一台 2 GB 的機器上，被包成面板是什麼樣子，那另當別論，拿一台沒有重要資料的 VPS 玩，風險有限。但那一行 curl | sudo sh 的習慣，我還是會先讀過 install.sh 再跑。

另外有一份讀書筆記提到原始碼層面的幾個細節，例如腳本把 docker.sock 掛進面板容器、映像用 :latest、K3s 的 kubeconfig 權限等等。那些我這次沒有回頭去重驗，這裡只算讀書筆記的說法，不當成我驗證過的事實。

時間線最右邊那一格，目前停在 2026 年 9 月 13 日 04:30（UTC）的一筆資料庫資源限制更新。下一格會不會有人填，要看有沒有人再提交一筆。