Cal.diy
- title
- Cal.diy
- type
- toolbox
- summary
- Open-source community edition of Cal.com, spun out in April 2026 as a personal-use-only self-hosted fork
- tags
- scheduling, self-hosted, typescript, open-core
- language
- TypeScript
- license
- AGPLv3 (inherited from Cal.com)
- created
- 2026-04-22
- updated
- 2026-04-22
Cal.diy is the open-source community edition of Cal.com, spun out as a standalone project in April 2026. The positioning is unusual: Cal.com explicitly disclaims production use of Cal.diy and directs commercial users to their hosted or enterprise on-prem offerings. Cal.diy exists as an "if you want to self-host, here's the code, you're on your own" release valve.
The feature split
Cal.com publishes a feature-by-feature comparison on cal.diy's docs homepage. Roughly:
In both: event types (including recurring, seated, paid via Stripe/PayPal, hashed URLs), booking management, all availability features (schedules, date overrides, buffer times, travel schedules, OOO), most calendar integrations (Google, Outlook, Apple, CalDAV, Lark, Feishu, Zoho, Exchange, ICS), most video platforms (Cal Video, Zoom, Meet, Teams, Webex, Jitsi), standard auth (email, Google OAuth, Azure AD), webhooks, Zapier, n8n/Make/Pipedream, CRM integrations, messaging integrations, AI agent integrations, embeds, API v2.
Cal.com only: Teams and team event types (round-robin, collective, managed), instant meetings, Organizations, SAML SSO, SCIM, impersonation, Workflows, Routing Forms, API v1 legacy, Insights dashboard, Attributes & Segments, Delegation, Workspace Platform, Admin Panel, Cal.com Video Recordings.
So Cal.diy is "single-user scheduling done right" while Cal.com holds everything multi-tenant, enterprise, and analytics-grade.
Deployment
Deployment docs cover AWS, Azure, Elestio, GCP, Northflank, Railway, Render, and Vercel. The install process is standard Next.js app with Postgres โ database migrations are documented separately.
Why this matters
The pattern is worth noting: rather than running the npmx route (community builds an alternative frontend to force the incumbent to respond), Cal.com preempted the demand by shipping an explicitly diminished open-source edition themselves. Users get the core scheduling primitives; the company keeps the multi-tenant/enterprise parts behind the commercial gate. It's a clean example of the open-core split done deliberately and documented openly.
The non-production disclaimer is the interesting friction. Cal.com can't stop anyone from deploying Cal.diy commercially (AGPLv3), but the messaging steers the self-hoster community away from treating it as an enterprise substitute, which protects the commercial narrative while keeping the OSS badge.
Repo
Docs: https://www.cal.diy โ installation, deployments, apps, database migrations, upgrading. Source lives on GitHub under the Cal.com org. Last updated April 14, 2026.
Related
- alternative-frontend-pattern โ the opposite strategy (community-driven alt-frontend); Cal.com avoided this by shipping their own cut-down version