Cal.diy Is the Open-Source Scheduling Fork That Cal.com Made Necessary by Going Private

What it is

Cal.diy is the MIT-licensed, self-hostable community edition of Cal.com, released in April 2026 after Cal.com moved its production codebase to a private repository. The public repository is now github.com/calcom/cal.diy. The distribution includes the full scheduling engine, the app store framework, and the booking infrastructure. There is no managed hosted version; if you want Cal.com as a service, that is a separate closed-source product with its own pricing and SLA. Cal.diy is free.

What's interesting

The backstory is the interesting part. Cal.com's own announcement post explains the decision to close the main production repository as a response to "AI-driven security threats", specifically the ease with which LLMs can now scan open-source code for exploitable patterns at scale. Whether you accept that framing or read it as standard open-core monetization with a novel rationale, the MIT relicensing of the scheduling engine under Cal.diy is real and the code under that license is permissive enough for any commercial self-host. Cal.com's v6.4 changelog documents the license change alongside a 20x performance improvement landing in the same window.

The product surface itself is what Cal.com users have been running for years. GitHub's calcom/cal.diy repo confirms the full scheduling engine, app store framework, and booking infrastructure ship together. That is meaningful because competing self-hostable Calendly alternatives do not offer the same completeness. Implicator's 2026 self-hosted Calendly alternatives roundup lists Rallly and Easy!Appointments as the remaining viable options alongside Cal.diy, noting that the open-source scheduling market is narrowing overall. Cal.diy's differentiation inside that narrowing cohort is feature depth (app store integrations, multi-tenant workspaces) inherited from the Cal.com codebase.

The FOSS community is not uniformly happy. FOSS Force and It's FOSS both read the broader Cal.com move as a loss for the open-source scheduling space, with Cal.diy framed as a consolation rather than a full continuation. The Hacker News thread reflects the same split: some commenters appreciate the MIT license explicitly; others view the overall arc as an open-core bait-and-switch regardless of the naming.

What's missing or unverified

The biggest flag is in Cal.diy's own documentation. The cal.diy site states that the project is "strictly recommended for personal, non-production use". Commercial features that many teams actually need (SSO, team billing, paid SLA support, enterprise deployment templates) are not in Cal.diy; they only exist on the managed Cal.com service. If you were running production Cal.com self-hosted with a deployment plan, the upgrade path from that to Cal.diy is not the same as the path to the closed Cal.com managed service.

Long-run signal on whether Cal.com will keep upstream-merging improvements from the closed repository back to Cal.diy is the other open question. Cal.com's blog post commits to the MIT license and ongoing releases but not to parity, which is the commitment that actually matters for the sustainability of the community edition.

Who it's for

Self-host Cal.diy if you are a developer or small team with the operational discipline to run your own scheduling service, you want MIT licensing explicitly, and you do not need SSO or enterprise support. Teams replacing Calendly where the data-residency or cost calculus favors self-host are the core fit. Pass if you need SSO or SLA support, if your team needs audited enterprise deployment, or if you want a hosted service with vendor accountability. In the last case, evaluate the Cal.com managed product directly rather than treating Cal.diy as its equivalent.

Verdict

59/100. Cal.diy is a credible permissive fork of a proven scheduling engine, but the non-production disclaimer and the ongoing-parity question both matter. Use it for personal or small-team deployments today; wait for concrete community-edition-versus-managed version parity data before betting production workloads on it.