OpenWorkers 是什麼？把 Workers 搬回自己的伺服器

很多小 API 只要十幾行，部署它們卻常常得準備一台完整伺服器。

你可能只想接收聯絡表單、產生一張 QR Code，或每天固定時間檢查一次資料。功能很小，背後仍有作業系統更新、程式重啟、HTTPS、日誌和流量變化要處理。Cloudflare Workers、Vercel Functions 這類 Serverless 服務會替開發者接手這些管理工作。

OpenWorkers 提供了另一種選擇：沿用 Workers 的寫法，讓程式跑在自己的伺服器上。

OpenWorkers 是一套開源 Serverless 平台。你仍然用 JavaScript 或 TypeScript 寫一小段功能，平台負責接收請求、安排執行、連接資料庫與留下日誌。不同之處在於，這套平台可以由你部署和修改。截至 2026 年 7 月，官方服務仍是 public beta，現階段比較適合研究、測試與建立內部平台，還不能當成裝完便不必管理的成熟雲端服務。

Serverless 仍然需要伺服器，差別在於管理工作由誰負責。

OpenWorkers 可以拿來做什麼？

先看它能處理哪些工作，比直接閱讀架構圖容易理解。

例子一：產生 QR Code

使用者打開一個網址，輸入文字，系統回傳一張 QR Code。這個功能沒有複雜頁面，也不需要一台伺服器整天等著；它只在收到請求時短暫執行，產生結果後就結束。

OpenWorkers 官方網站正好展示了 QR Code generator。這是很典型的 Worker：輸入明確、工作短、回傳快，而且每次請求彼此獨立。

例子二：接住第三方 Webhook

假設你用金流服務收款。顧客付款後，金流平台會向你的網址送出一則通知，這就是 webhook。你需要一小段程式確認通知是真的，再把訂單改成「已付款」。

這段程式可能只有幾十行，卻必須穩定地對外開放。放進 Worker 後，你不必為了它建立一套大型後端。如果資料不能交給外部雲端，OpenWorkers 可以讓通知留在自己的網路裡處理，資料庫也放在附近。

例子三：每天固定執行的排程

你可以讓程式每天早上讀取庫存、整理前一天的數字，再把摘要送進 Email 或內部系統。這種任務平常不需要運作，只要在指定時間被喚醒。

OpenWorkers 具有 scheduler 元件與 scheduled event。它可以把「每天九點執行」這件事交給平台管理，不需要另外維護一個永遠在線、只為等待時鐘的程式。

例子四：公司內部的小型 API

客服查詢訂單、編輯器讀取文章狀態、後台取得會員權限，都可能需要一個簡單 API。OpenWorkers 提供 PostgreSQL 與 KV 等 bindings，Worker 不必自己管理每次資料庫連線，只需要使用平台交給它的資源。

這裡的 binding 可以理解成「平台預先接好的插座」。程式知道插座叫做 DB 或 KV，但不必把真正的密碼寫進程式碼裡。對開發者來說比較乾淨，對管理者來說也比較容易控制權限。

例子五：完整網頁，而不只是 API

官方展示頁還列出 SvelteKit SSR 時鐘、HTTP 測試工具、猜拳遊戲與 IP 資訊查詢。Worker 可以回傳 JSON，也能在伺服器端產生 HTML、處理互動，甚至擔任小型網站的後端。

長時間影片轉檔、需要大量記憶體的 AI 模型推論，或必須保留本機狀態的程式，不適合放進這種短生命週期的 Worker。平台能不能執行是一回事，執行模型是否合適是另一回事。

一次請求在 OpenWorkers 裡怎麼走？

你寫好的 Worker 先交給 openworkers-runner。Runner 像工作分派中心，決定哪個執行空間來處理請求，並管理逾時、排隊與資源限制。真正執行 JavaScript 的是 openworkers-runtime-v8；對外 API、排程、日誌與資料庫代理則分散在其他元件。

這也是 OpenWorkers 被拆成多個 GitHub repo 的原因。有人只需要把 V8 runtime 嵌進自己的 Rust 應用，有人則需要包含 dashboard、API、scheduler 與 logs 的完整平台。這些元件要依需求組裝，使用方式和下載後直接啟動的桌面工具不同。

Rust 與 V8 各自負責什麼？

V8 是 Chrome、Node.js 背後使用的 JavaScript 引擎。它的工作是理解並執行 JavaScript。OpenWorkers 選擇 V8，是因為開發者可以繼續使用熟悉的 Web API，例如 fetch()、Request 與 Response。

Rust 位於外層，負責管理這些執行環境。你可以把 V8 想成廚房，Rust 是分配爐台、控制時間和收拾現場的管理系統。使用者送進來的是訂單，Worker 則是食譜。

最小的 Worker 看起來大致如此：

export default {
  async fetch(request, env) {
    return new Response('Hello from OpenWorkers')
  },
}

即使不寫程式，也能從這段看出它的設計：收到一個 request，執行一個 fetch 函式，最後回傳 response。env 則放著平台授權給這段程式使用的資料庫、KV 或其他資源。

V8 Isolate 是什麼？為什麼不直接開一個 Node.js？

如果每個請求都啟動一套完整作業系統或 Node.js 程序，隔離清楚，但成本很高。V8 Isolate 提供另一種做法：在同一個程序裡建立彼此分開的 JavaScript 執行空間。

可以把它想成同一棟辦公室裡的獨立工作間。大家共用建築物的基礎設施，但每個工作間有自己的桌面與物品，不能任意走進別人的空間。這比每位員工都蓋一棟辦公大樓省資源，也比所有人擠在同一張桌子安全。

OpenWorkers 推薦的 PINNED 模式會重用 V8 Isolate，但每次請求建立新的 context。意思是昂貴的引擎與記憶體管理可以重用，JavaScript 看見的工作環境則重新準備，降低上一個請求把全域狀態留給下一個請求的機會。

若你更重視隔離，也可以使用 ONESHOT：每次請求建立全新的 Isolate，用完便丟掉。它比較慢，但行為更容易理解，也適合除錯。兩種模式處理的是效率與隔離之間的取捨，沒有一個模式適用所有情況。

OpenWorkers、Cloudflare Workers、傳統 VPS 怎麼選？

這三種做法都能讓網址背後執行程式，差別主要在於誰負責管理基礎設施。

如果你只想讓一個 webhook 今天上線，Cloudflare Workers 通常是更直接的答案。如果你需要完整 Linux 環境、背景程序與自由安裝套件，VPS 會比較自然。

OpenWorkers 位在兩者之間。它保留 Workers「一個函式處理一個事件」的寫法，同時讓使用者管理 runtime、資料與部署位置。這份控制權也包含原本由雲端平台負責的維運工作。

哪些團隊真的值得研究？

最直接的使用情境，是公司裡已經有許多小型 API、排程與 webhook。每個功能若各自建立服務，部署方式、權限和日誌很快就會各走各的。內部 Worker 平台可以替它們訂出共同規則。

資料位置也是團隊研究 OpenWorkers 的理由。服務可能必須靠近既有 PostgreSQL、只能在內部網路執行，或不能把敏感資料送到第三方 runtime。這些團隊可以把執行層放進自己的基礎設施。

研究 JavaScript sandbox、多租戶執行或 V8 嵌入的工程師，也能直接查看 isolate 如何建立、資源如何限制，以及 Rust 與 JavaScript 如何交換資料。雲端產品通常只公開使用方式，開源 runtime 則把實作放在眼前。

外掛平台、自動化工具或低程式碼服務，可能需要讓使用者上傳程式。這是風險最高的使用情境。V8 Isolate 提供一層隔離，但網路權限、CPU 與記憶體限制、秘密管理、資料庫租戶隔離仍要逐項驗證。

個人開發者若只想快速上線兩三個 API，通常不需要為了「開源、自架」而接手整套平台維運。自架不等於免費，它只是把一部分服務費換成維護時間、機器成本和責任。

真正開始之前，要準備哪些東西？

完整平台需要 Rust、Bun、PostgreSQL 與 NATS。PostgreSQL 保存平台與使用者資料；NATS 像內部傳話系統，讓 runner、scheduler 與其他服務交換工作。正式環境還要補上反向代理、TLS、備份、監控與更新流程。

研究時可以分成三個階段，不必第一天就部署整套平台：

1. 先執行官方範例，確認基本 fetch、Request 與 Response 行為。
2. 再加入一個 binding，例如 KV 或測試用 PostgreSQL，理解資源如何交給 Worker。
3. 最後才評估 scheduler、logs、dashboard 與多租戶隔離是否符合需求。

開源工具正在把一些原本由雲端平台託管的能力搬回使用者自己的機器。Shimmy 用 Rust 把本機 LLM 包成 OpenAI 相容 API也採用這個方向，只是它處理的是模型推論。其他專案可參考 2026 Q2 開源工具整理。

若準備長時間在本機編譯 Rust 與測試多個服務，桌面周邊也會影響工作流；這份桌面四件套開發者基本盤可作為整理開發環境的參考。

（本文含蝦皮聯盟連結，透過連結購買不會增加你的成本，但能支持本站持續產出內容。）

我怎麼看 OpenWorkers

我不會把 OpenWorkers 推薦給只想快速上線的人。對這類需求而言，成熟的託管平台比較省事。

它真正吸引人的地方，是讓 Serverless 的執行層變得可見，也允許使用者修改。你能從 QR Code、排程通知和 webhook 這些小功能開始，再往 V8 Isolate、Rust runtime、多租戶與資源隔離深入。

如果團隊需要控制 runtime、讓程式靠近內部資料，或正在研究 Serverless 如何運作，OpenWorkers 值得放進測試清單。測試的內容不能只有功能是否跑得動，還要包括維運成本與安全邊界。

是否採用它，取決於團隊需不需要這份控制權，也取決於團隊是否準備好接手附帶的維運責任。

常見問題

OpenWorkers 可以直接取代 Cloudflare Workers 嗎？

不能把它視為一比一替代品。OpenWorkers 盡可能相容 Workers 的開發方式，但 Cloudflare 提供成熟的全球託管網路；OpenWorkers 的重點則是開源、自架與執行環境控制。遷移既有程式前，仍要逐項測試 API、bindings、效能與部署流程。

使用 OpenWorkers 一定要會 Rust 嗎？

只寫 Worker 功能時，主要使用 JavaScript 或 TypeScript，不一定要會 Rust。要自行部署整套平台、修改 runtime 或追查效能問題時，Rust 與基礎維運知識才會變得重要。

個人開發者適合自架嗎？

適合拿來學習架構、測試 side project；如果只是想快速上線幾個小 API，託管平台通常更省時間。自架的價值來自控制權，不保證比較便宜。

V8 Isolate 是否代表使用者程式一定安全？

不是。V8 Isolate 提供一層程序內隔離，但正式多租戶環境還要處理資源限制、網路權限、秘密管理、資料庫隔離與異常終止。安全性必須用完整系統來評估，不能只看 runtime 名稱。

資料來源

OpenWorkers GitHub 組織集中收錄 runtime、runner、API、scheduler 與平台服務；官方網站提供 public beta 狀態，以及 QR Code、SvelteKit SSR、HTTP 測試工具與 IP 查詢等公開範例。