calcom/cal.diy

Cal.diy 更适合看作个人预约服务器：如果你想要 Calendly 式的预约页面，又不想依赖托管厂商或许可证密钥，可以作为起点，但项目 README 明确说明它面向非生产环境。

解决什么问题

自由职业者或小团队希望有一个公开预约链接：读取自己的空闲时间、写入已确认的日程并处理提醒，而不是来回发邮件约时间。托管预约工具能解决这件事，但日历数据和工作流都放在别人账户里；Cal.com 的自托管版本又混有商业代码。Cal.diy 改的是最后这一步：克隆一个移除了企业代码的分支，把整套预约系统跑在自己控制的服务器上，最终得到自己的预约站点和数据库。代价是部署工作都落到你身上，具体步骤见项目说明。

有什么不同

核心机制是删减。Cal.diy 是 Cal.com 的分支，Teams、Organizations、Insights、Workflows、SSO/SAML 等仅企业版功能被移除，因此代码整体采用 MIT 许可，也不需要 Cal.com 账号或许可证密钥。如果你自托管的理由就是许可证干净或避开供应商，这一点很关键：不会用着用着撞上功能门禁，也没有专有组件需要绕开审计。代价是商业版的那些运维功能直接消失了，而不是有社区替代品。

另一个不同是维护方式。作为没有托管版本的社区分支，打补丁、管理数据库、保护敏感数据都由你负责，README 对此说得很直接，并建议仅用于个人、非生产用途。熟悉 Node.js 和 PostgreSQL 的开发者，把它当个人部署来维护是可控的；而期待一个受支持的预约后端的团队，就用错了框架。

谁值得试

适合已经有服务器、想要个人预约链接、并希望完全掌控数据的个人用户：带 Docker 的 yarn dx 快速启动会拉起本地实例和测试用户，可以在正式部署前先评估。需要共享团队排期、SSO 或统计的公司不适合，因为这些功能已被移除；需要厂商支持和可用性承诺的团队同样不适合。面向采购的团队还应注意，Cal.com 的 README 本身把商业用户引向销售渠道，而非这个分支。如果目标只是一个人的预约链接，还要衡量整套 Next.js/tRPC/Postgres 技术栈是否与需求相称。

使用条件与边界

文档中的技术栈需要 Node.js 18+、PostgreSQL 13+ 和 Yarn，yarn dx 还需要 Docker 与 Docker Compose；视频会议等集成可能额外需要第三方凭据。更大的限制在日常维护：备份、升级、TLS 以及已存日历和联系人数据的安全都由你负责，README 明确不建议用于生产。这个警告是最需要权衡的地方。2026-04-21 有 Hacker News 评论者把它与 Cal.com 早先一篇主张本地部署更安全的博客文章作对比，另一条回复则认为当前警告是支持与责任的边界，而不是技术上禁止使用（见讨论）。无论如何，这里没有支持承诺。

HotRepo 点评

在追踪榜单上，Cal.diy 于 2026-10-24 记录为 49,307 星（+62），2026-10-25 为 49,317 星（+64）。两天的样本只能说明当时的星数快照；这里没有更早的榜单历史，无法判断持久性。决定投入前，先核实仓库自己的警告和当前发布状态，再判断一个非生产、个人维护的预约系统是否符合你的风险承受能力。