Moving to closed-source: the technical changes

What Cal.diy Is

Cal.diy is the open-source scheduling platform. It includes the full scheduling engine, the app store framework, and the booking infrastructure. It is everything that makes Cal.com powerful as a self-hosted solution for individuals.

Commercial and enterprise features that only apply to Cal.com as a managed service have been removed. All free features remain in Cal.diy.

What was removed

The separation between Cal.com and Cal.diy comes down to commercial and enterprise features. Here's what's no longer included in Cal.diy:

• Organizations and Teams: Multi-tenant organization management, team creation, team availability, team booking flows, org migration tooling, PBAC (permission-based access control), and all related API v2 endpoints

• Routing Forms: The full routing forms app-store package, including the route builder, form actions, test dialog, Salesforce routing integration, routing trace functionality, and queued response handling

• Workflows: Automated workflow engine (reminders, follow-ups, triggers) and all related references across API v2, platform libraries, and booking flows

• Instant Booking: Instant event types and all associated booking service code

• AI Phone: Cal.ai phone call execution and the AI phone event type tab

• Attributes and Segments: React Awesome Query Builder (RAQB), member attributes, segment-based filtering, and workspace platform settings

• SAML/SSO: Enterprise SAML/SSO signup flow

• Insights: Analytics and reporting dashboards

• API v1: The entire API v1 application was removed. Cal.diy ships with API v2 only

• Enterprise UI: License setup wizard, compliance document downloads, EE tips, premium username features, admin billing page, AI translation, buy-credits flow

• Booking Audit: Booking audit logging (enterprise observability feature)

• Impersonation: Admin user impersonation across booking and calendar sync flows

Everything else remains in Cal.diy: the core scheduling logic, the app store, the booking flows, and API v2.

Preparing the code for Cal.diy

To prep the calcom/cal.com repository for its transition to calcom/cal.diy, we maintained a separate branch in the private repository that stayed synced with the public repository's main branch. This branch was the reference point from which we identified and removed commercial features before the rename. By diffing against it, we could see exactly which code needed to be separated out so that when calcom/cal.com became calcom/cal.diy, only the open-source code remained.

We also used this branch to confirm that all GitHub checks were passing. We wanted the handoff of the repository to be clean, so before the rename went live, we made sure CI was green and the codebase was in a healthy state for the community to pick up from day one.

License change: AGPL 3.0 to MIT

We changed Cal.diy's license from AGPL 3.0 to MIT.

Cal.diy is a different product with a different purpose than Cal.com: giving the community the most permissive scheduling platform possible. MIT is a better fit for that goal.

Cal.diy maintainers

Cal.diy is maintained by former Cal.com interns who are now official maintainers of the repository.

These engineers spent time inside the Cal.com codebase. They understand the architecture, the patterns, and the product. They shipped real features during their internships, reviewed PRs, and debugged production issues.

The Cal.com engineering team focuses on the commercial product. The Cal.diy maintainers focus on the community.

Infrastructure changes

The public repository had years of CI/CD configuration, bot integrations, and DevOps automation. All of it needed to be rebuilt for the private repository.

GitHub actions

Cal.diy has 53 GitHub Action workflows. The private repository has 62. We touched nearly every existing workflow to update references to the old repo in checkout steps, API URLs, artifact paths, and deployment hooks.

Private repositories have different permission models. Several early PRs addressed CI failures because private repo checkout requires explicit contents: read permissions that public repos get implicitly.

Secrets and environment configuration

Most secrets carry over, but a few need to be provisioned fresh for the public repository, such as credentials for test suites that run against Google and Stripe. The new maintainers will be provisioning them soon and the test suites will automatically reactivate when they see the settings.

Security backporting

While the two repositories were maintained in parallel, security was a priority in both directions. Vulnerabilities were patched in whichever repo caught them first, then backported to the other. Sometimes a fix landed in the public repo and was cherry-picked into the private one. Sometimes it went the other way.

Examples include upgrading axios to 1.15.0 to fix critical CVEs, upgrading handlebars to 4.7.9 to resolve a critical vulnerability, blocking localhost and loopback addresses in SSRF protection, adding CSRF protection to OAuth callbacks via HMAC-signed nonces, preventing IDOR in tRPC endpoints, and resolving fast-xml-parser security audit failures.

Our goal was to hand Cal.diy to the community in a solid state from a security perspective. That meant treating the public repo as a production codebase, not an afterthought, even while the commercial product was being built in the private repo.