Cal.diy：從 Cal.com 分叉的自託管 MIT 排程平台
cal.diy 打包了 Cal.com 的日程安排介面和日曆集成，用於個人、非生產自託管。
秒懂
- 它是什麼？
- 社群驅動的自託管排程平台，移除 Cal.com 商業程式碼與授權金鑰，要求使用者自行準備 Node.js、PostgreSQL、環境密鑰及部署安全措施。
- 適合誰用？
- Cal.diy 是一個 MIT 授權的分叉，移除了企業功能並要求自託管。README 提供了設定和部署指導，但沒有提供安全保證、效能基準或生產支援承諾。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
自託管的 Cal.com 社群版
根據 README，Cal.diy 是一個排程平台，是 Cal.com 的分叉，移除了所有企業和商業程式碼。它被描述為社群驅動且完全開源，採用 MIT 授權。README 明確說明 Cal.diy 用於個人、非生產用途，自託管需要伺服器管理、資料庫管理和保護敏感資料的進階知識。沒有託管或管理版本；你需在自己的基礎設施上執行。倉庫中繼資料列出該專案主要語言為 TypeScript，並報告 47,262 星和 14,668 個分叉。
與 Cal.com 的差異
根據 README，Cal.diy 移除了企業功能，包括 Teams、Organizations、Insights、Workflows 和 SSO/SAML。無需授權金鑰，無需 Cal.com 帳戶或授權即可開箱即用。整個程式碼庫基於 MIT 授權，沒有開放核心拆分。該專案由社群維護，貢獻直接進入此倉庫，而非 Cal.com 的生產平台。README 也指出 Cal.diy 是自託管專案，沒有託管產品。
技術棧和前置條件
README 列出了構建所用的技術：Next.js、tRPC、React.js、Tailwind CSS、Prisma 和 Daily.co。要在本機執行 Cal.diy，你需要 Node.js 18 或更高版本、PostgreSQL 13 或更高版本，並建議使用 Yarn。如果你想啟用整合，可能需要為每個整合取得額外憑證。README 沒有指定最低系統記憶體需求，但開發提示建議為較大建置增加 Node 的記憶體限制。
開發設定和快速啟動
README 提供了兩條本機開發路徑。第一種是使用 `yarn dx` 快速啟動，需要 Docker 和 Docker Compose，並會啟動一個本機 Postgres 執行個體和預置的測試使用者。第二種是手動設定：複製倉庫，使用 Yarn 安裝套件，將 `.env.example` 複製為 `.env`，使用 `openssl rand` 產生 `NEXTAUTH_SECRET` 和 `CALENDSO_ENCRYPTION_KEY`，並設定資料庫 URL。然後執行 `yarn workspace @calcom/prisma db-migrate` 進行開發環境遷移，或 `db-deploy` 用於生產環境。README 也涵蓋透過 Prisma Studio 或執行種子指令碼建立第一個使用者。對於 E2E 測試，它提到了 `yarn test-e2e` 和 Playwright。
Docker 部署和設定
Docker 映像在 Docker Hub 上可用，地址為 `calcom/cal.diy`。README 解釋了兩種部署方法：使用預建映像透過 Docker Compose，或從原始碼使用 Docker 建置。Compose 堆疊可包含本機 Postgres 資料庫、Web 應用程式和 Prisma Studio。執行時期需要多個環境變數，包括 `DATABASE_URL`、`NEXTAUTH_SECRET` 和 `CALENDSO_ENCRYPTION_KEY`。README 警告不要在生產環境中保留預設密鑰值。對於建置自己映像的使用者，還列出了建置時變數，如 `MAX_OLD_SPACE_SIZE` 和 `NEXT_PUBLIC_WEBAPP_URL`。首次執行會顯示設定精靈，用於定義你的第一個使用者。
整合和社群貢獻
README 提供了取得憑證和設定整合的逐步說明，包括 Google Calendar、Microsoft Graph、Zoom、Daily.co、Basecamp、HubSpot、Webex、ZohoCRM、Zoho Calendar、Zoho Bigin 和 Pipedrive。它也描述了使用 Unkey 的可選限流功能。在貢獻方面，專案歡迎程式碼、文件和翻譯方面的幫助。README 指出，貢獻不會回流到 Cal.com 的生產平台。新使用者有一份 help-wanted 問題清單。授權為 MIT，授權文字宣告軟體按「原樣」提供，不附帶任何保證。
針對 calcom-cal-diy，閱讀 README 時應把安裝入口和日常使用入口分開看。先確認文件點名的執行檔、套件管理器或容器命令，再對照專案要求的作業系統、執行時版本與外部服務。這些前置條件會直接決定首次啟動能否成功，不能用其他專案的慣例代替。
配置層面的重點在於找出 calcom-cal-diy 真正讀取的檔案與參數。若 README 提到環境變數、設定檔、資料目錄、插件或 provider，就應逐一記錄其名稱和預設值，並觀察啟動後產生的日誌與輸出。文檔沒有交代的默認行為，應視為未知，尤其不能自行推定安全性、持久化或相容性。
從維護角度看，calcom-cal-diy 的功能清單不等於完整的營運承諾。需要實際檢查 README 列出的版本、依賴、資料格式和錯誤處理，確認升級時哪些狀態會被保留，哪些整合需要額外憑證。若要放入團隊流程，還要先確認其授權文字對分發、修改和商業使用的具體限制。
最小驗證可以沿用 calcom-cal-diy 自己提供的命令與檔案：在乾淨目錄建立最小設定，執行文件中的初始化或啟動命令，再查看 README 指定的輸出、狀態頁、產物或日誌。測試至少涵蓋一次成功流程與一次缺少必要參數的失敗流程，這樣才能分辨功能存在與實際可操作之間的差距。
calcom-cal-diy 的實際價值還取決於它如何處理日常變更。可以先改動一個 README 明確列出的選項，觀察重載、重新建置、快取失效或資料更新是否符合說明，再恢復原設定確認狀態沒有留下難以察覺的副作用。對需要網路、資料庫、瀏覽器或模型服務的專案，這個步驟也能把程式本身的問題與外部依賴故障區分開。
若 calcom-cal-diy 要交給其他人使用，交接內容不能只包含安裝命令。還要記下入口命令的完整參數、需要提交的設定檔、敏感值的存放位置、失敗時應查看的日誌，以及 README 明確列出的不支援情況。這些資訊會影響排障時間，也能避免使用者把社群版、實驗性功能或本地限定能力誤當成穩定服務。
在 calcom-cal-diy 的評估中，輸入與輸出的可追蹤性比功能數量更值得核對。保留一次命令執行的參數、產生的檔案名稱和關鍵日誌，才能在重跑時知道差異來自設定、依賴還是資料。若 README 沒有給出某項能力的介面或結果格式，文章只把它列為未說明，不替專案補上承諾。
部署 calcom-cal-diy 前也要核對資源與權限邊界。把 README 寫明的資料庫、網路、檔案系統和第三方帳號需求列成清單，逐項確認最小權限是否足夠，並把失敗時的返回值與日誌保存下來。這樣才能判斷它適合個人試用、團隊內部流程，還是需要更完整的運維審查。
採用前可在 calcom-cal-diy 的工作目錄執行 README 所列入口，逐項核對輸入、產物與錯誤訊息；文檔沒有承諾的行為不應當作既定能力。
編輯結論
Cal.diy 是一個 MIT 授權的分叉，移除了企業功能並要求自託管。README 提供了設定和部署指導，但沒有提供安全保證、效能基準或生產支援承諾。 對這個專案的判斷應以 README 中的實際入口為準：先按文件執行專案命令，再檢查產生的設定、服務狀態或輸出是否符合預期；若核心依賴、平台條件或文件未涵蓋的部署細節不合適，就不應只因功能清單完整而採用。
社群筆記