OpenConnector 自行部署還是 OOMOL 託管？先讓業務跑起來

準備將 Google、Zoom、monday.com 串接到應用或 Agent 時，你可能會先想到：OpenConnector 已經開源，要不要直接部署自己的閘道？

自己的閘道有明確價值。憑證存在哪裡、允許哪些操作、如何記錄呼叫，都可以由團隊掌控。但連接服務啟動後，還有一件容易低估的事：為各個應用準備授權設定。

對於大多數希望盡快上線的團隊，我們建議先使用 OOMOL 託管版，透過 SDK 完成業務串接。 如果已經明確要求連接服務與憑證留在自己的基礎設施，或需要修改閘道與連接器實作，就選擇自行部署 OpenConnector。

也可以分階段進行：先用託管版跑通業務，同時準備自己的 OAuth 應用，條件成熟後再遷移。

先看你現在需要什麼

目前的需求	建議選擇
希望盡快串接應用，可以使用外部託管服務	從 OOMOL 託管版開始
多人共用應用連線，需要集中管理成員與操作權限	使用 OOMOL 託管版的團隊功能
計畫使用自己的 OAuth 應用，目前仍在設定或等待審核	先託管，準備完成後再評估遷移
憑證、連接閘道與執行紀錄必須留在自己的基礎設施	自行部署 OpenConnector
需要修改連接器程式碼、調整閘道行為或控制對外網路存取	自行部署 OpenConnector

企業規模可以影響這個決定，但更直接的問題是：團隊目前需要多少控制權，又準備承擔多少維護工作？

自行部署的工作，往往從 OAuth 設定開始

透過 Docker 啟動 OpenConnector 後，你已經有了連接閘道。要存取需要 OAuth 授權的服務，還需要在各服務的開發者後台建立自己的 OAuth 應用。

這裡有兩組不同的憑證：OAuth 應用的 Client ID、Client Secret 用來識別你的應用；使用者授權後取得的存取權杖，用來存取該使用者允許開放的資源。

前一組需要先準備好，後一組才會在帳號授權後產生。

以 Google 為例，需要建立專案、啟用所需 API、建立 OAuth 用戶端、填寫回呼網址，並決定要申請哪些權限。依權限範圍與使用方式，也可能需要應用驗證。Google OAuth 官方說明

其他 OAuth 服務也有各自的設定與發布規則。只串接一個應用時，這些工作可能還容易處理；同時串接多個應用，就需要分別維護各家的用戶端設定、回呼網址、授權範圍與審核狀態。

內部測試與開放給大量客戶，要求也可能不同。有些服務允許先連接自己的帳號或測試使用者，有些情境需要管理員核准或額外審核。具體要求應以服務商的後台與文件為準。

OpenConnector 可以儲存 OAuth 設定、連接帳號與執行操作。使用自己的 OAuth 應用時，建立應用及符合服務商要求的工作仍由團隊負責。步驟請參考 OAuth 應用設定指南。

用託管版，把時間留給業務串接

如果目前的目標是讓一項功能上線，例如查詢行事曆、整理郵件或更新專案紀錄，通常可以先把業務需要的連線跑通。

對於支援託管 OAuth 應用的整合，OOMOL 可以減少逐家建立與維護 OAuth 應用的工作。你仍需連接自己的帳號、核准所需權限；使用 API key 或其他驗證方式的服務，也需要提供對應設定。

帳號連接完成後，OOMOL 託管服務負責儲存憑證、更新權杖與實際的應用呼叫。後端透過 SDK 選擇連線、提交參數並接收結果，不需要把第三方帳號的原始權杖放進業務程式碼或 Agent 提示詞。託管 Connector 使用說明

圖：兩種部署方式的呼叫關係。閘道位置與管理責任不同，存取外部應用仍受服務商授權與網路條件限制。

多人使用時，託管版也提供團隊管理。管理員可以集中管理成員，設定每個連線允許執行的操作，再決定哪些成員可以使用。

例如，同一個信箱帳號可以建立兩個連線：一個只允許讀取郵件，分配給需要查閱資訊的成員；另一個允許寄送郵件，只分配給負責對外溝通的人員。成員使用獲准的操作，無需取得信箱的原始存取權杖。團隊與連線權限說明

這些功能讓團隊在串接多個應用後，仍能管理誰可以使用什麼。特定資料能否存取，還受到原應用帳號權限與授權範圍的限制。

如果產品需要讓每位終端使用者連接自己的帳號，託管端應使用 Connector for SaaS 與 ProjectConnector 用戶端，依使用者隔離連線。

需要掌控執行環境時，選擇 OpenConnector

有些團隊一開始就有明確要求：第三方帳號憑證必須由自己的金鑰與儲存系統保護，連接閘道必須在企業網路內執行，執行紀錄也必須依內部規則保存。

這類要求直接決定部署方式。自行部署 OpenConnector 後，團隊可以管理閘道、憑證、操作策略與執行紀錄，也能控制資料庫、備份、升級與網路存取。

OpenConnector 的開源價值也體現在程式碼。連接執行環境、連接器定義、操作執行程式碼與 Web 控制台都有公開原始碼，配套的 Connector SDK 與 oo CLI 也開源。需要檢查呼叫過程、增加整合或調整實作時，可以從現有專案開始。第三方服務的 API 授權與使用條款仍需另外遵守。

控制權同時帶來維護責任。團隊需要有人負責金鑰管理、存取保護、更新、備份與故障處理。安全效果取決於這些工作如何落實。

可以依環境選擇部署方式：

• Docker Compose：在自己的伺服器或企業網路中執行，適合自行管理儲存與存取邊界的團隊。
• Cloudflare Workers：自行管理 OpenConnector 部署，使用 Cloudflare 的 D1、R2 等基礎設施，適合接受雲端執行環境的團隊。
• 從原始碼執行：適合開發連接器、除錯或修改 OpenConnector 實作。

Cloudflare 屬於雲端部署方案。嚴格要求在企業內網執行時，應選擇符合要求的伺服器環境。

內網閘道也需要規劃對外網路存取。呼叫 Google、Zoom 等外部 SaaS，仍需連接對應的 API 與授權端點；完全隔絕外網的環境，應先確認目標服務是否有可存取的內部介面。

部署步驟請參考 OpenConnector 自行部署指南。

可以先託管，準備好後再遷移

如果已計畫使用自己的 OAuth 應用，但仍在設定或等待審核，可以同時推進兩件事：用託管版驗證業務，並準備自行部署所需的應用憑證與執行環境。

託管與自行部署使用同一個 @oomol-lab/connector SDK 套件。它提供託管服務用的 Connector、產品終端使用者用的 ProjectConnector，以及自行部署執行環境用的 OpenConnector。這些用戶端共用操作型別與呼叫方式，但驗證方式、帳號邊界與可用方法不同。TypeScript SDK 參考

遷移時，已支援操作的識別碼、輸入參數與呼叫方式可以沿用。例如，搜尋郵件的業務邏輯可以保留相同操作名稱與查詢參數，改用連接自行部署環境的用戶端執行。

遷移準備包括：

1. 在新環境部署並保護 OpenConnector，設定自己的 OAuth 應用。
2. 建立帳號連線，確認所需授權範圍。
3. 調整 SDK 用戶端、服務網址、執行環境權杖與連線選擇。
4. 核對目標操作的執行支援，以及業務依賴的團隊、專案使用者與權限功能。
5. 先驗證一個常用操作，再逐步切換其他呼叫。

帳號連線與託管管理功能需要分別處理。共用 SDK 的便利在於保留既有操作呼叫與參數結構，減少重新串接各家 API 的工作。

遷移並非每個團隊的必經階段。如果託管版持續滿足業務與管理需求，可以繼續使用；當掌控執行環境成為明確需求時，再接管閘道。

從一個真實操作開始

如果目前沒有必須自行部署的要求，先選一項希望上線的功能：讀取今天的行事曆、搜尋客戶郵件，或查詢專案進度。

在 OOMOL Console 連接應用，完成授權後，按照 SDK 串接指南從後端呼叫操作。先確認業務能跑通，再設定團隊成員與連線權限。

已經明確需要自行部署的團隊，可以直接按 OpenConnector 部署指南準備環境，再完成 OAuth 應用設定。

選擇適合目前需求的起點。託管服務幫助你盡快完成業務，開源 OpenConnector 則讓你在需要時掌控連接服務的程式碼、憑證與執行環境。