CloudMeet：把會議預約系統自架到 Cloudflare 的開源工具

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

CloudMeet 是一套開源的會議預約系統，做的事和 Calendly 同一類：你設好自己有空的時段，產生一個預約頁面，對方在上面挑時間、填資料，系統自動在兩邊的行事曆建立約會，順便把視訊會議連結掛上去。差別在於它整包可以自己架在 Cloudflare 的免費額度上，不用每個月付訂閱費，預約資料落在你自己的 Cloudflare 帳號，而不是進 Calendly 的伺服器。它適合會一點 Cloudflare 操作的個人工作者，例如接案者、顧問、線上教學老師，想擁有一個屬於自己的預約頁，又不想把客戶名單交給第三方排程服務。

這篇文章的基礎，是我把專案的 GitHub 原始碼、授權條款、資料庫結構、依賴清單和官方 demo 頁都讀過一遍，並沒有實際部署跑起來。所以下面講的是這套工具在設計與架構上做什麼，以及原始碼透露出哪些會影響你判斷的事實，而不是部署後的載入速度或穩定度評測。如果你要的是實測結果，這篇給不了。

它其實是一個跑在 Cloudflare 上的 SvelteKit 應用

很多人看到「跑在 Cloudflare 免費額度」會直覺想成一段簡單的靜態網頁加一點函式。實際讀過 package.json 會發現它是一個完整的 SvelteKit 應用，用 @sveltejs/adapter-cloudflare 這個轉接器部署上去，前後端是同一個專案。資料存在 Cloudflare 的 D1 資料庫（Cloudflare 提供的 SQLite），定時提醒郵件則交給 Cloudflare Workers 每五分鐘巡一次。也就是說，你架起來的不只是一個網頁，而是一套有資料庫、有排程、有後端邏輯的完整應用，只是這些基礎設施全部借住在你自己的 Cloudflare 帳號裡。

從資料庫結構可以看出它的資料落地方式。D1 的 schema 裡有 users、event_types、availability_rules、bookings 等好幾張表，其中 users 表存放了 google_refresh_token 和 outlook_refresh_token 兩個欄位，用來持續同步你的 Google 和 Outlook 行事曆。這代表你的行事曆授權憑證會跟預約資料一起放在 Cloudflare 的 D1 裡。好處是授權憑證與預約資料集中在你自己掌握的 D1，代價是整套系統綁在 Cloudflare 的基礎設施上，Cloudflare 一旦調整免費額度或服務條款，你的預約系統也會跟著受影響。這種「自己架但借住在大廠免費額度上」的模式，和 SubsTracker 訂閱管理工具、wxpush 微信推播工具、movecar 車輛通知工具 是同一類做法，便於免費上線，但穩定性綁在 Cloudflare 這個平台上。

預約頁與後台長什麼樣子

README 提供了一張預約頁的官方截圖，畫面上是訪客看到的預約介面：選擇會議類型、挑日期和時段、填姓名和郵件。官方 demo 站台也確實上線，網址是 meet.klappe.dev/cloudmeet，實際打開能看到一個可運作的預約頁，流程和截圖一致。這證明工具本身跑得起來、預約介面真實存在。

Pin

不過截圖和 demo 能證明的只到這裡。預約流程在實際使用中碰上時區轉換、跨日預約、大量同時預約這些邊界情境時會不會出錯，郵件提醒會不會準時送達，這些只有你自己部署之後用真實流量測過才知道。README 沒有提供這類負載或極端情境的測試資料。

怎麼定義自己有空的時段

排程工具的核心不在預約頁長相，而在它怎麼決定你哪時候能被約。從 D1 的 schema 可以看出 CloudMeet 用兩層結構處理這件事。一層是 availability_rules，讓你針對星期一到星期日各自設一段固定的上班時間，例如平日早上九點到下午五點；另一層是 availability_overrides，處理特定日期的例外，你可以把某一天整個封鎖不開放預約，也可以反過來在某個週末額外開放幾個小時。這種「循環時段加日期覆寫」的設計，和你直接在 Google 行事曆上手動擋時間相比，好處是對方看到的是已經算好的可用時段，不必在信件往返裡橋會議時間。

每一種會議類型（event_types）可以單獨設定時長、緩衝時間、地點類型和適用的行事曆。例如你可以開一個三十分鐘的線上諮詢、一個一小時的深度訪談，分別綁不同的行事曆或不同的開放時段。緩衝時間的設計尤其實用，它能在兩場會議之間強制留一段空檔，讓你有時間收尾上一場、準備下一場，而不是被排到一場接著一場、沒有喘息空間。時長、緩衝這些欄位在 schema 裡都有對應的欄位（duration_minutes、buffer_minutes），不是寫死的常數，部署之後能在後台調整，不必改程式碼。

支援哪些日曆與會議軟體

根據 README 的說法，CloudMeet 支援 Google 行事曆和 Microsoft Outlook 行事曆的雙向同步，你可以只用 Google、只用 Outlook，或兩個一起接，它會跨兩邊行事曆檢查你有沒有空。會議連結則宣稱會自動建立 Google Meet 或 Microsoft Teams 的視訊會議，一起塞進行事曆事件裡。這部分從 D1 的 users 表確實能看到對應的授權欄位，整合機制是存在的。

資料庫結構同時透露了一些 README 沒有特別強調的細節。event_types 表的 location_type 欄位除了 google_meet 之外，註解還寫了 zoom、phone、in_person 這幾個選項，代表它的設計預留了 Zoom 會議、電話會議、實體見面這幾種地點類型。這不表示 Zoom 整合現在就能直接用，畢竟 README 通篇只提 Google Meet 和 Teams，沒有 Zoom 的設定教學，但至少說明它的會議類型不只有這兩種，後續有可能再擴充。

想接 Outlook 的人要多走一段路。README 的 Outlook 設定段寫得很明確：你得先到 Azure 入口網站註冊一個應用程式，拿到用戶端編號和密碼，再勾好 Microsoft Graph 的 Calendars.ReadWrite、User.Read、OnlineMeetings.ReadWrite 這幾個委派權限，Teams 會議連結才建得起來。有管理員權限的話可以直接同意這些權限，沒有的話就由每個使用者在第一次登入時自己同意。換句話說，Google 整合和 Outlook 整合的設定成本並不對稱，前者在 Google Cloud Console 申請 OAuth 就行，後者還多了一層 Azure 應用程式註冊。

免費的邊界在哪裡

CloudMeet 對外主打跑在 Cloudflare 免費額度、不用伺服器，這句話在「不用租 VPS」的意義上是對的，但把它理解成完全免費、一鍵就能用就太樂觀了。

最關鍵的一點在郵件。預約的確認信、取消通知、會議前提醒這些郵件，並不是 Cloudflare 原生服務在發，而是綁一個叫 Emailit 的第三方郵件服務。README 的設定清單裡 EMAILIT_API_KEY 雖然標成選用，但你不設這個值，預約通知郵件這塊功能等於沒有。對照 package.json 的依賴清單，裡面完全沒有任何寄信用的套件，這也佐證了寄信是直接呼叫 Emailit 的 HTTP API，不是工具自己發。CloudMeet 的免費其實有條件：網頁和資料庫那層確實落在 Cloudflare 免費額度，但郵件這層的額度和定價要去 Emailit 那邊另外算清楚。提醒郵件的觸發走的是 Cloudflare Workers 每五分鐘巡一次，會在會議前二十四小時和一小時各發一次，README 雖然把 CRON_SECRET 列成選用，但同時提醒不設的話這個觸發端點會是公開的，任何人都能呼叫，這在安全上建議補上。

帳號設計是另一個會影響判斷的點。後台登入是靠 ADMIN_EMAIL 這個設定值鎖定，只有這個郵件帳號能登入管理預約頁。從 users 表的單一個人 slug 結構也能印證，它本質上是一個給單一主持人用的排程器，而不是那種可以開很多業務員帳號、每人一組預約頁的團隊排程平台。如果你的需求是整個業務團隊共用一套排程系統，這套工具的設計並不對應。

如果你想讓預約頁掛在自己擁有的網域（例如 book.你的網域），而不是用 Cloudflare 預設的 pages.dev 子網域，README 也有提供路徑：在 Cloudflare Pages 後台把自訂網域綁上來，把 APP_URL 這個機密變數改成新網域，再回 Google Cloud Console 把 OAuth 的回傳網址新增一組對應的位址，重新部署一次就行。寄件人位址則透過 EMAIL_FROM 這個變數設定，例如 noreply@你的網域，這對經營個人品牌的顧問或講師來說很重要，因為預約確認信從自己的網域寄出，比從一個陌生第三方位址寄出更不容易被對方的郵件信箱擋下來或漏進垃圾郵件。

初始設定也有一定門檻。要把它架起來，至少要在 Cloudflare 開好 API 權杖（而且要勾到 D1 的編輯權限）和帳號 ID、在 Google Cloud Console 申請 OAuth 憑證並把回傳網址設成你的 Pages 網域、在 GitHub 用範本建立倉庫並填好將近十個機密變數，然後靠 GitHub Actions 一鍵部署。想接 Outlook 還要再到 Azure 註冊應用、設定 Microsoft Graph 的權限。這些都是開發者取向的操作，對沒碰過 OAuth 或 Cloudflare 的人會有一段學習曲線。如果你只想先在本機試試看能不能跑，README 也提供了本地開發流程：複製 .env.example 成 .dev.vars、填好憑證、跑 npm install 和 npm run db:init 初始化資料庫、再 npm run dev 起本地伺服器。

專案還在動，但沒有版本號

從 GitHub 的資料來看，這個專案是 2025 年 12 月初建立的，到現在累積了五百多個 star、六十幾個 fork，七個未關閉的 issue。最後一次程式碼提交落在 2026 年 7 月初，中間也有 dependabot 自動更新相依套件的紀錄，看得出來作者還在維護、不是丟著不管。整個專案用 TypeScript 寫成，不是那種只放 README 沒有原始碼的展示倉庫。

Pin

不過它到現在沒有任何一個正式的版本發布，release 和 tag 都是空的。整個專案是用 GitHub 範本的形式提供，你用它建立自己的倉庫之後，更新的方式是靠 README 提供的 Sync and Deploy 工作流，把上游範本的最新內容同步進來再重新部署。這種做法的好處是更新很直接，缺點是沒有版本號可以釘，什麼時候升級、升級改了什麼，得自己盯著上游的提交紀錄看，不能用「我現在跑的是哪個版本」這種方式管理。同步過程偶爾會遇到權限錯誤，README 的說明是另外建一個有 Contents 和 Workflows 權限的個人存取權杖來解。

誰該用、誰先跳過

把上面的條件綜合起來，CloudMeet 的甜蜜點很明確：你是一個會一點 Cloudflare 和 GitHub 操作的個人工作者，想擁有一個完全屬於自己的預約頁，預約資料不交給第三方排程服務，而且願意自己搞定 Google OAuth 和 Emailit 郵件設定。接案設計師、顧問、線上家教、自由撰稿人這類角色，只要約會量大到開始在意 Calendly 月費，又具備基本部署能力，CloudMeet 是一個值得花一個下午架起來的選擇。

反過來說，如果你要的是現成可用、不想碰任何設定畫面，那付費的 Calendly 這類服務還是省事得多；如果你要給整個團隊每人一組帳號一起用，這套單一管理員的設計也不適合。要動手的話，第一步是開好 Cloudflare 帳號並建立一個有 D1 編輯權限的 API 權杖，同時在 Google Cloud Console 申請一組 OAuth 用戶端憑證，這兩個動作做完之後，剩下的就是照著 README 的範本部署流程走。授權方面它是標準的 MIT，商業使用沒有模糊空間，可以放心包進自己對外的服務。