Is Cal.com Open Source? Cal.diy, GitHub and Self-Hosting in 2026

Is Cal.com still open source? The short answer

No. Cal.com, the commercial scheduler that runs on app.cal.com, has been closed source since April 2026. The company announced the move on April 14, 2026, after five years of building in the open, and on April 15 it moved the production codebase into a private repository ^[1]. What stayed public is a separate project called Cal.diy, released under the MIT license. If you search for the Cal.com GitHub page today, you land on Cal.diy: the old calcom/cal.com address now shows the calcom/cal.diy repository, described as a fork of Cal.com with all enterprise code taken out.

That split matters because a lot of Cal.com's own pages have not caught up. Comparison posts from 2025 and early 2026, the routing page and even an August 2026 article still describe the product as open source. Those pages are outdated. Cal.com's own file for AI agents now says plainly that the main product must not be described as open source, and that only Cal.diy should be. For a buyer, the practical meaning is simple. You can still self-host a free version of the scheduling engine, but it is not the product you would sign up for in the cloud, and it lacks most of the team features people pay for.

Why Cal.com closed its code

Cal.com gives one reason for the change: security. Its announcement argues that AI tools can now scan open source code for vulnerabilities at a speed and scale that make running production software in public too risky. Later posts repeat the point, describing AI-driven vulnerability scanning as the threat that tipped the decision. The company also says it hopes to return to open source one day, as the security landscape evolves. We read that as a statement of intent, not a commitment, since no date or condition is attached to it.

The closed-source move came with a technical gap that has kept growing. Cal.com says its production codebase had already diverged significantly from what became Cal.diy, including rewrites of authentication and data handling. A follow-up engineering post adds detail: security fixes were backported between the two repositories, such as dependency upgrades and CSRF protection on OAuth callbacks, and the private repository runs more automated workflows than the public one. For existing customers nothing changed in practice. The v6.4 release notes call it primarily a license change, with no change to anyone's access or account.

One more detail is worth knowing. The license itself changed too. The old public code was published under AGPL 3.0, which required derived works to stay open source. Cal.diy is MIT, which is far more permissive. An older FAQ answer that still cites AGPL v3 describes the pre-2026 setup. The Cal.diy README draws the line clearly: it is fully MIT with no commercial code, in contrast with Cal.com's open core model. Cal.com's terms, meanwhile, say commercial self-hosted Cal.com software exists only under an Order Form or a separate license.

What Cal.diy keeps, and what it leaves out

Cal.diy is not a stripped demo. Cal.com describes it as including the full scheduling engine, the app store framework and the booking infrastructure, and the feature comparison on the Cal.diy site bears that out. The project is also far from abandoned in public: the GitHub repository shows about 49.0k stars and 15.3k forks, with roughly 1.2k open issues. The table below summarizes the comparison page, last updated September 4, 2026 ^[2].

The parts that survive

Everything a single person needs to run a booking page is there. You get unlimited event types with recurring, seated and paid bookings through Stripe or PayPal, private hashed links, minimum notice and booking limits, travel schedules and out-of-office. Calendar support covers Google, Outlook and Office 365, Apple, CalDAV, Zoho, Exchange and ICS feeds. Conferencing includes Cal Video, Zoom, Meet, Teams, Webex and Jitsi. The connection layer is also intact: webhooks, Zapier, n8n, Pipedream, HubSpot, Salesforce and Close, plus analytics apps such as GA4 and PostHog. That is a capable personal scheduler.

The parts that were removed

The cuts fall almost entirely on collaboration and enterprise control. Teams, team availability and team booking flows are gone, and with them round robin, collective and managed event types. Organizations, permission controls, routing forms with their Salesforce routing, workflows for reminders and follow-ups, Insights dashboards, SAML SSO, SCIM, booking audit logs, admin impersonation, instant meetings and the Cal.ai phone agent are all Cal.com only. So is the legacy API v1, which Cal.diy never ships. If your use case needs more than one host, Cal.diy is the wrong starting point.

The warning that comes with Cal.diy

Cal.com is unusually blunt about how Cal.diy should be used. Its contributors guide says the edition is strictly recommended for personal, non-production use, and the Cal.diy site repeats the same line ^[3]. Cal.com, Inc. states that it does not guarantee the security or safety of Cal.diy, which is community maintained. The engineering post on the split adds that former Cal.com interns maintain it, while the company's engineers focus on the commercial product. Contributions to Cal.diy do not flow back into Cal.com's production platform.

That leaves a tension worth naming. The MIT license allows commercial use in a legal sense, yet the vendor tells you not to run Cal.diy in production. Both statements can be true at once. One is about what the license permits; the other is about what the company will stand behind. A business that books paying clients through Cal.diy is on its own for security patches, uptime and data protection. Read the warning as a support boundary.

The Cal.diy site also sets the skill bar. It says self-hosting requires advanced knowledge of server administration, database management and data security. There is no hosted or managed version of Cal.diy at all. You run it on your own infrastructure, or not at all. Being the admin also means owning settings the cloud handles for you. On a self-hosted instance, an administrator enables apps and stores their keys in the admin settings. Webhooks behave differently too: self-hosted instances accept plain HTTP and private IP addresses, which the cloud blocks. That flexibility is convenient for testing, and a risk if you forget about it.

What you need to run it yourself

The Cal.diy repository lists three prerequisites: Node.js 18.x or newer, PostgreSQL 13.x or newer, and Yarn, which is recommended rather than required. The app is built with Next.js, tRPC, React, Tailwind CSS and Prisma, and uses Daily.co for video. Outbound email goes through SMTP settings in your environment file. Cal.diy does not need a license key or a Cal.com account to run. The README also documents how to set up your own credentials for Google, Microsoft, Zoom, Daily, HubSpot, Webex, Zoho and Pipedrive, since none of those connections come pre-wired.

Docker, Windows and the small surprises

Docker is supported, with a caveat. Docker files moved into the main monorepo in November 2025 and became officially maintained, but Cal.com supports the files, not your installation, so troubleshooting is yours. The package announced then included a production Dockerfile for AMD64 and ARM and a docker-compose stack with PostgreSQL, Redis and optional Prisma Studio. The Cal.diy image is published on DockerHub as calcom/cal.diy, with tags ending in -arm for ARM machines. Windows users can hit a known snag: symbolic links are off by default, which can break Prisma environment variables until you clone with symlinks enabled.

A few defaults deserve a look before launch. Cal.diy collects anonymous usage telemetry unless you set CALCOM_TELEMETRY_DISABLED to 1. New users on a self-hosted instance default to a TRIAL plan, which you change in the Prisma schema. Rate limiting through Unkey is optional. And recording Cal Video calls on a self-hosted instance requires a Daily Scale Plan, a cost outside Cal.diy itself.

Where to deploy: Railway, Vercel and the rest

The documented deployment targets for Cal.diy are AWS, Azure, Elestio, GCP, Northflank, Railway, Render and Vercel, plus Docker. Railway has the smoothest path on paper. Cal.com announced a partnership with Railway in September 2025 for one-click self-hosted deployment, started from the self-hosting documentation, and both Railway and Northflank have published their own deployment write-ups. That partnership predates the license change, so check that the template you pick points at the Cal.diy repository rather than the old one.

Vercel comes with a plan requirement. The Cal.diy README says a Vercel deployment needs the Vercel Pro plan, because the free plan's serverless function limits are too tight for the app. Budget for that before choosing it. Whichever host you pick, Cal.com's own guidance is that self-hosting Cal.diy is free as software but carries infrastructure and maintenance costs. Your hosting bill, database backups, email delivery and the hours spent on updates are the real price of the free edition.

License keys, enterprise features and commercial self-hosting

The enterprise side works differently from Cal.diy. Cal.com's local development docs say enterprise features show a warning when you run the full codebase locally, because they require a purchased license in production. Running API v2 in a local instance of that codebase needs a license key in CALCOM_LICENSE_KEY, and the docs publish a staging key for testing only. Cal.com added license key purchase to self-hosted onboarding in July 2025, before the code went private.

Since April 2026, commercial self-hosting has a single route: enterprise on-premises hosting arranged through sales. The v6.4 release notes say self-hosters of the enterprise edition receive invites to the private GitHub repository, and the Cal.diy site describes on-prem enterprise access as invite-only. One comparison post goes further and calls enterprise self-hosting a managed deployment by the Cal.com team, not a self-serve download. Enterprise pricing is custom and annual. If your reason for self-hosting is compliance or data residency, this is the path Cal.com intends for you, not Cal.diy.

Large deployments of this kind exist. Cal.com cites Booz Allen Hamilton, which self-hosted Cal.com on AWS GovCloud for 350,000 users, although that setup predates the closed-source move. Be careful with older marketing pages here. A January 2026 comparison still claims both hosted and self-hosted options, while a May 2026 comparison table marks self-hosting as unavailable. Neither describes today's split well. The current rule is simple: Cal.diy for personal use, enterprise on-prem for businesses, and the cloud for everyone in between.

Self-host or use the cloud: who fits which

Who should self-host Cal.diy

Cal.diy suits a developer or hobbyist who wants a personal booking page on their own server, enjoys running the stack and accepts the vendor's non-production warning. It also suits someone building or testing an integration against API v2 who wants a local sandbox. Cal.com's own API comparison post points free users toward Cal.diy for API access, since that post says the hosted Free plan does not include it. If you value full control of a single-user scheduler over support, it is a reasonable choice.

Who should use the cloud instead

Almost everyone else. Cal.com's hosted Free plan already gives one user unlimited event types, calendars and bookings at $0, with no server to maintain. Any team that needs round robin, collective events, routing forms or workflows has to be on the cloud, where those start on the Teams plan at $12 per user a month billed yearly. Regulated businesses that need SSO, audit logs or a HIPAA agreement belong on Organizations or Enterprise, or on the enterprise on-prem route through sales. Our full Cal.com review covers those plans in depth, and developers weighing the hosted API should read our Cal.com API guide.

The bottom line

Cal.com is no longer open source, and treating it as such will mislead you. The open code now lives in Cal.diy, an MIT-licensed community edition that keeps the full personal scheduling engine, API v2 and webhooks but drops every team, routing, workflow and enterprise feature. Cal.com tells you to keep it out of production and does not stand behind its security. Self-host it if you are a developer who wants a personal instance or a test bed. For a business, the free cloud plan or a paid tier is the safer choice, and enterprise on-prem is a sales conversation.