--- author: OOMOL author_url: https://oomol.com/zh-tw/about/ datePublished: 2026-10-13 title: OpenConnector 自行部署還是 OOMOL 託管？先讓業務跑起來 description: 從 OAuth 應用設定、團隊權限與執行環境，選擇 OOMOL 託管或自行部署 OpenConnector，了解先託管、後遷移時可以沿用哪些部分。 lang: zh-TW canonical_url: https://oomol.com/zh-tw/blog/openconnector-hosted-or-self-hosted/ markdown_url: https://oomol.com/zh-tw/blog/openconnector-hosted-or-self-hosted.md --- ![OOMOL 託管與 OpenConnector 自行部署兩條應用串接路徑：先完成業務，再依需求掌控執行環境](/blog/openconnector-hosted-or-self-hosted/zh-tw-cover.webp) 準備將 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 官方說明](https://developers.google.com/identity/protocols/oauth2/web-server) 其他 OAuth 服務也有各自的設定與發布規則。只串接一個應用時，這些工作可能還容易處理；同時串接多個應用，就需要分別維護各家的用戶端設定、回呼網址、授權範圍與審核狀態。 內部測試與開放給大量客戶，要求也可能不同。有些服務允許先連接自己的帳號或測試使用者，有些情境需要管理員核准或額外審核。具體要求應以服務商的後台與文件為準。 OpenConnector 可以儲存 OAuth 設定、連接帳號與執行操作。使用自己的 OAuth 應用時，建立應用及符合服務商要求的工作仍由團隊負責。步驟請參考 [OAuth 應用設定指南](/zh-tw/docs/openconnector-oauth-apps/)。 ## 用託管版，把時間留給業務串接 如果目前的目標是讓一項功能上線，例如查詢行事曆、整理郵件或更新專案紀錄，通常可以先把業務需要的連線跑通。 對於支援託管 OAuth 應用的整合，OOMOL 可以減少逐家建立與維護 OAuth 應用的工作。你仍需連接自己的帳號、核准所需權限；使用 API key 或其他驗證方式的服務，也需要提供對應設定。 帳號連接完成後，OOMOL 託管服務負責儲存憑證、更新權杖與實際的應用呼叫。後端透過 SDK 選擇連線、提交參數並接收結果，不需要把第三方帳號的原始權杖放進業務程式碼或 Agent 提示詞。[託管 Connector 使用說明](/zh-tw/docs/connector/) ![業務後端透過同一個 SDK 套件連接 OOMOL 託管閘道或自行管理的 OpenConnector；各閘道管理憑證與連線，再存取第三方 API](/blog/openconnector-hosted-or-self-hosted/zh-tw-architecture.webp) *圖：兩種部署方式的呼叫關係。閘道位置與管理責任不同，存取外部應用仍受服務商授權與網路條件限制。* 多人使用時，託管版也提供團隊管理。管理員可以集中管理成員，設定每個連線允許執行的操作，再決定哪些成員可以使用。 例如，同一個信箱帳號可以建立兩個連線：一個只允許讀取郵件，分配給需要查閱資訊的成員；另一個允許寄送郵件，只分配給負責對外溝通的人員。成員使用獲准的操作，無需取得信箱的原始存取權杖。[團隊與連線權限說明](/zh-tw/docs/access-control/) 這些功能讓團隊在串接多個應用後，仍能管理誰可以使用什麼。特定資料能否存取，還受到原應用帳號權限與授權範圍的限制。 如果產品需要讓每位終端使用者連接自己的帳號，託管端應使用 [Connector for SaaS](/zh-tw/docs/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 自行部署指南](/zh-tw/docs/openconnector-self-hosting/)。 ## 可以先託管，準備好後再遷移 如果已計畫使用自己的 OAuth 應用，但仍在設定或等待審核，可以同時推進兩件事：用託管版驗證業務，並準備自行部署所需的應用憑證與執行環境。 託管與自行部署使用同一個 `@oomol-lab/connector` SDK 套件。它提供託管服務用的 `Connector`、產品終端使用者用的 `ProjectConnector`，以及自行部署執行環境用的 `OpenConnector`。這些用戶端共用操作型別與呼叫方式，但驗證方式、帳號邊界與可用方法不同。[TypeScript SDK 參考](/zh-tw/docs/connector-sdk/) 遷移時，已支援操作的識別碼、輸入參數與呼叫方式可以沿用。例如，搜尋郵件的業務邏輯可以保留相同操作名稱與查詢參數，改用連接自行部署環境的用戶端執行。 遷移準備包括： 1. 在新環境部署並保護 OpenConnector，設定自己的 OAuth 應用。 2. 建立帳號連線，確認所需授權範圍。 3. 調整 SDK 用戶端、服務網址、執行環境權杖與連線選擇。 4. 核對目標操作的執行支援，以及業務依賴的團隊、專案使用者與權限功能。 5. 先驗證一個常用操作，再逐步切換其他呼叫。 帳號連線與託管管理功能需要分別處理。共用 SDK 的便利在於保留既有操作呼叫與參數結構，減少重新串接各家 API 的工作。 遷移並非每個團隊的必經階段。如果託管版持續滿足業務與管理需求，可以繼續使用；當掌控執行環境成為明確需求時，再接管閘道。 ## 從一個真實操作開始 如果目前沒有必須自行部署的要求，先選一項希望上線的功能：讀取今天的行事曆、搜尋客戶郵件，或查詢專案進度。 在 [OOMOL Console 連接應用](https://console.oomol.com/connections)，完成授權後，按照 [SDK 串接指南](/zh-tw/docs/connector-client/)從後端呼叫操作。先確認業務能跑通，再設定團隊成員與連線權限。 已經明確需要自行部署的團隊，可以直接按 [OpenConnector 部署指南](/zh-tw/docs/openconnector-self-hosting/)準備環境，再完成 [OAuth 應用設定](/zh-tw/docs/openconnector-oauth-apps/)。 選擇適合目前需求的起點。託管服務幫助你盡快完成業務，開源 OpenConnector 則讓你在需要時掌控連接服務的程式碼、憑證與執行環境。