Cal.com Went Closed-Source in 2026: What's Actually Left in Cal.diy, and Should You Still Self-Host It?
A licence change from AGPL to MIT looks like liberation. In this case it was a divorce settlement: the company kept the product, and the community got the engine.
For five years, Cal.com was the standard answer to "what is the open-source Calendly?" Roughly 45,000 GitHub stars, AGPL-3.0, self-hostable, white-label by design, with team scheduling, routing forms, workflows, and Stripe payments. It was the rare open-source project that was also a genuinely good product, and a lot of companies built their booking flow on it.
Then, in
mid-April 2026, the company moved its production codebase into a private repository. The public repository was renamed from
calcom/cal.com to
calcom/cal.diy and relicensed from
AGPL-3.0 to MIT. Enterprise features — Teams, Organizations, Workflows, Routing Forms, SAML/SSO, Insights, and the entire API v1 — were removed before the handoff. What remained was, in the company's own framing, "the most permissive scheduling platform possible."
If you self-host Cal.com today, you are running
Cal.diy, a different product with a different scope, maintained by former Cal.com interns. Your contributions will not flow into the commercial product, because they are now separate codebases.
This matters well beyond one company, and it is worth taking seriously rather than treating as drama. It is the clearest test yet of what happens to open-source companies when AI-assisted vulnerability scanning changes the cost-benefit of publishing source. This is a deep-dive on what exactly changed, what is still in the open-source edition, whether the stated reasoning holds up, what it costs to run, and — importantly — what to do if you are one of the people who built something on the old Cal.com.
1. What Happened
The sequence, as documented in Cal.com's own engineering blog and changelog:
1. The company maintained
a branch in a private repository that stayed synced with the public repository's main branch. This was the reference point for identifying commercial code.
2. Commercial and enterprise features were
removed from the public branch by diffing against that reference.
3. CI was confirmed green before the handoff, so the community would receive a healthy codebase on day one.
Cal.diy has 53 GitHub Action workflows; the private repository has 62.
4. The public repository was
renamed to calcom/cal.diy and the licence changed from AGPL-3.0 to
MIT.
5. The commercial product's codebase became private. Customers self-hosting the enterprise edition were invited to the private repository.
6.
Cal.diy maintenance was handed to former Cal.com interns who are now official maintainers of the repository.
The company was methodical about it. This was not an angry rug-pull; the repository was handed over in good technical condition, the removal was documented in detail, and the licence chosen for the community edition is the most permissive available. Credit where it is due.
It is still a fundamental change in what "open-source Cal.com" means.
2. Why Scheduling Data Is More Sensitive Than It Looks
Before evaluating the options, it is worth being clear about what a scheduling platform actually holds, because most people file it under "utility" and it does not belong there.
Who you meet with. A calendar is a map of your professional relationships. For a founder, it shows investors in chronological order during a raise. For a recruiter, it shows candidates and hiring managers. For a lawyer or a therapist or a doctor, it shows clients. For a journalist, it shows sources.
When and how often. A recurring weekly meeting with a company you have not announced a relationship with is a signal. So is the sudden appearance of six external interviews in one week.
What it is about. Event type names, booking form responses, and notes attached to bookings frequently contain the actual substance — "Series A diligence call," "MRI results review," "exit interview."
Contact details of everyone involved. Names, email addresses, phone numbers, timezones.
Now consider that Calendly, the market default, holds all of that on its infrastructure, for every person who has ever booked time with you — including people who never agreed to Calendly's terms and have no relationship with the company at all.
This is why self-hosted scheduling is not a hobbyist concern. For a clinic, a law firm, a recruitment agency, or a company in a sensitive negotiation, the booking metadata is arguably the most revealing dataset in the building after the email itself.
3. The Two Products Now
Understanding the current landscape requires separating two things that used to be one:
Cal.com — the company's commercial cloud and enterprise product.
Now closed source. Previously "source-available," now private. If you are a Cal.com customer, nothing changed about your access or your account; this is a licensing and distribution change.
Cal.diy — the MIT-licensed, community-maintained, self-hostable edition. This is what you deploy. It carries the scheduling engine, the app store framework, the booking flows, and API v2. It needs no licence key and runs out of the box.
The critical structural fact:
contributions to Cal.diy do not flow back to Cal.com's production platform. They are separate codebases with separate futures. A bug fixed in the community edition is not necessarily fixed in the product the company sells, and vice versa.
During the parallel-maintenance period, security fixes were patched in whichever repository caught them first and backported to the other. Whether that discipline survives indefinitely, with different maintainers on each side, is an open question worth watching.
4. What Was Removed From Cal.diy
This is the list that decides whether Cal.diy works for you, so here it is in full, per the company's own technical writeup:
- Organizations and Teams — multi-tenant org management, team creation, team availability, team booking flows, org migration tooling, permission-based access control, and all related API v2 endpoints.
- Routing Forms — the full routing forms app-store package: route builder, form actions, test dialog, Salesforce routing integration, routing trace, and queued response handling.
- Workflows — the automation engine for reminders, follow-ups, and triggers, plus all references across API v2, platform libraries, and booking flows.
- Instant Booking — instant event types and associated booking service code.
- AI Phone — Cal.ai phone call execution and the AI phone event type.
- Attributes and Segments — the query builder, member attributes, segment-based filtering, and workspace platform settings.
- SAML/SSO — the enterprise SAML/SSO signup flow.
- Insights — analytics and reporting dashboards.
- API v1 — the entire v1 application was removed. Cal.diy ships with API v2 only.
- Enterprise UI — licence setup wizard, compliance document downloads, EE tips, premium username features, admin billing page, AI translation, buy-credits flow.
- Booking Audit — enterprise observability logging.
- Impersonation — admin user impersonation across booking and calendar sync flows.
Read that list again and notice the shape of it.
Almost everything removed is a multi-user or enterprise feature. What remains is a very good
individual scheduling product.
That is the crux: if you were self-hosting Cal.com for a solo consultant's booking page, Cal.diy does what you need. If you were running it for a twenty-person sales team with round-robin routing, workflow reminders, and SSO, the open-source edition no longer does the job.
5. What Remains
What is left is not a husk. The retained functionality is substantial:
- The core scheduling engine — availability calculation, buffers, minimum notice, timezone handling, conflict prevention.
- Event types and booking pages — unlimited types with durations, buffers, and availability rules.
- Calendar integrations — two-way sync with Google Calendar and Outlook/Office 365, CalDAV support, and automatic creation of Zoom or Google Meet links.
- The app store framework — the extensibility architecture, with a large catalogue of integrations.
- Payments — Stripe integration for paid bookings.
- API v2 — the modern API surface, plus embeds and white-labelling.
- Cal Video — built-in video, powered by Daily.co.
For an individual or a small practice, that is a complete product. The scheduling engine is the hard part — timezone arithmetic and free/busy reconciliation are where naïve implementations fall apart — and that is exactly what was retained.
6. The Licence Change: Why "More Permissive" Is Not "More Free"
The change from
AGPL-3.0 to MIT reads, on its face, as the company giving the community more freedom. MIT is the most permissive licence in common use: do anything, no obligation to publish changes.
And in a narrow sense that is true. If you want to fork Cal.diy, embed it in a commercial product, modify it, and ship it closed, MIT lets you do that cleanly where AGPL would have forced disclosure. For some users, that is a genuine improvement.
But the framing obscures the actual trade:
AGPL-3.0 was doing work. It guaranteed that improvements made by anyone offering the software over a network would flow back. It was the mechanism by which the company's own contributions to the public codebase stayed public. Removing it removes that guarantee — and the same change that liberates your fork also liberates anyone else's, including a competitor who takes the code, adds nothing, and sells it.
The licence got more permissive at the same moment the product got smaller. These are not independent events. MIT is described by the company as "a better fit" for Cal.diy because Cal.diy is "a different product with a different purpose." That is accurate and also convenient: you cannot open-source features you have removed.
The practical effect is a downgrade in what the community can enforce. Under AGPL, a company running a modified Cal.com as a service owed you their modifications. Under MIT plus a closed commercial codebase, the company owes the community nothing, and the community has no leverage over the product most users actually use.
The honest summary: the licence change is genuinely permissive and also genuinely less protective. Both are true. If your interest is "I want to build a commercial product on this code with no obligations," MIT is better. If your interest is "I want this project to stay open and reciprocal," AGPL was better, and it is gone.
7. The Stated Reasoning, and the Pushback
The company's argument, stated by CEO Bailey Pumfleet, is a security one. AI coding assistants have made it dramatically cheaper to find vulnerabilities in source code. Publishing your production codebase is, in his words, "basically like handing out the blueprint to a bank vault." A critical authentication vulnerability,
CVE-2026-23478, discovered prior to v6.0.7, was cited as evidence of the urgency.
There is a real argument here. Automated vulnerability discovery is genuinely better than it was, and public code is easier to scan than private code. That much is not controversial.
The pushback, notably from Simon Willison in a widely-read Hacker News discussion, gets to the heart of it: if the answer to "AI makes finding vulnerabilities easier" is "hide the code," then the message to customers is
"we are no longer confident in our own ability to secure your data." Security by obscurity has a poor historical record, and the vulnerabilities that matter most in a scheduling platform — broken access control on booking endpoints, for instance — are typically found by testing behaviour, not by reading source.
Both sides have a point, and the honest position is somewhere in the middle. Publishing source does increase exposure. It also produces the public scrutiny that finds and fixes vulnerabilities. Which effect dominates depends on how much external scrutiny the project actually receives, and for a project with 45,000 stars it receives quite a lot.
What is not really arguable is the outcome:
the community edition is now strictly less capable than the commercial one, permanently, by design. Whatever you think of the reasoning, plan around that.
8. What This Means If You Already Self-Host
If you deployed Cal.com before April 2026, here is the practical situation.
Your instance keeps working. Nothing was remotely disabled. You are running code you already have.
Do not blindly upgrade to Cal.diy without reading the removal list. If you depend on Teams, Workflows, Routing Forms, or API v1, upgrading will remove functionality you rely on. Audit which features you actually use before you pull a new image.
If you use API v1, you have a migration project. It is gone from Cal.diy. Moving to API v2 is real work, not a find-and-replace.
If you depend on enterprise features, you have three options: stay on your current version and accept that it will not receive upstream fixes; move to Cal.com's hosted or private-repository enterprise offering; or migrate to a different product.
The option people forget: staying put is legitimate for a while. A scheduling engine is not a high-attack-surface internet-facing service in the way a web server is, and if your deployment works, the risk of standing still for a few months is low. But it is not a permanent strategy, and you should have a plan.
Can the Community Build the Missing Features Back?
The obvious question after a stripping like this is whether the community can reimplement what was removed. MIT is permissive enough that nothing prevents it, and the removed features are not cryptographically withheld — they were simply deleted from this codebase.
The realistic answer is that it depends entirely on which feature.
Small things, yes. A reminder-email system, a simple insights dashboard, custom UI touches — these are the kind of thing a motivated contributor or a company with a specific need can rebuild against API v2 and the app store framework. The architecture supports extension; that was retained.
Teams and Organizations, probably not, and not quickly. Multi-tenant organisation management with permission-based access control is not a feature, it is a cross-cutting architectural concern touching the data model, every query, the booking flows, and the entire permission surface. Rebuilding it against a codebase that was structured around it and then restructured to remove it is a very large project, and it is the kind of work that needs funded coordination rather than volunteer enthusiasm.
There is also a structural disincentive. Anyone who successfully rebuilds enterprise scheduling features on top of Cal.diy is doing work that Cal.com has already done and sells. That is a hard thing to sustain as a volunteer project, and it is worth being honest about rather than assuming community momentum will fill the gap.
The pragmatic reading: expect Cal.diy to be maintained and to improve at the margins, and do not plan around enterprise features returning. If you need them, that is a product decision, not a roadmap you can wait out.
9. The Alternatives Worth Considering
If Cal.diy no longer covers your use case, the self-hosted scheduling field is thinner than you would hope but not empty:
Easy!Appointments — GPL-3.0, roughly 4,300 stars. PHP and MySQL with an official Docker image. The best fit for service businesses with multiple providers: hairdressers, clinics, repair shops. Less of a general "share your link" product.
Rallly — AGPL-3.0, roughly 5,200 stars. Not a booking page; a Doodle-style group poll for finding a time that works for everyone. Different problem, solved well. Note that a paid licence is required above one user in some configurations.
Thunderbird Appointment — MPL-2.0, a few hundred stars. A Python API plus Vue UI, CalDAV-native. Interesting if you want scheduling that speaks CalDAV rather than proprietary calendar APIs.
Tymeslot — AGPL-3.0, small but modern; a single container with Postgres bundled.
Calnode — Apache-2.0, tiny. A single Go binary with SQLite in a 58 MB image. Minimal, API-driven, and the right shape if you want something small and boring.
CloudMeet — MIT, runs on Cloudflare Workers and D1. No server at all.
Nextcloud Calendar — AGPL-3.0, if you already run Nextcloud. Appointment scheduling is not its primary purpose, but for an organisation already on Nextcloud it is often the least-new-infrastructure answer.
None of these matches the depth of what Cal.com was. That is the real cost of the change, and it is worth naming: the self-hosted scheduling category lost its flagship, and the remaining options are all narrower.
10. Self-Hosting Cal.diy: What It Needs
The stack is
Next.js and TypeScript on Node, with
PostgreSQL for persistence and
Redis for caching and queueing.
Minimum requirements, per the project's own documentation:
- Node.js 18+ (20+ recommended)
- PostgreSQL 13+
- 1 vCPU and 1 GB RAM minimum; 2 vCPU and 2 GB recommended
- 1 GB storage minimum; 5 GB recommended
The Node memory note is real:
MAX_OLD_SPACE_SIZE=4096 is recommended because the Next.js build and Prisma operations need heap room at startup. Under-provisioning memory produces build failures that look like dependency errors.
Required environment variables worth knowing:
``
bash
NEXT_PUBLIC_WEBAPP_URL=https://cal.example.com
NEXTAUTH_URL=https://cal.example.com
NEXTAUTH_SECRET=<openssl rand -base64 32>
CALENDSO_ENCRYPTION_KEY=<openssl rand -base64 24>
DATABASE_URL=postgresql://user:pass@host:5432/cal
MAX_OLD_SPACE_SIZE=4096
CALCOM_TELEMETRY_DISABLED=1
`
CALENDSO_ENCRYPTION_KEY
is the important one. It encrypts your stored CalDAV credentials. Lose it and every connected calendar has to be re-authorised. Generate it properly and back it up.
CALCOM_TELEMETRY_DISABLED=1
turns off anonymous telemetry. If you are self-hosting for sovereignty reasons, set it.
11. The Docker Image Situation
Here is a practical wrinkle that catches people: the Docker image situation is community-maintained, and there is no official prebuilt image in the sense most people expect. The historical calcom/cal.com:latest
image and the community Compose files continue to exist, but the rename means you need to check which repository and which image you are actually pulling, and whether it tracks Cal.diy.
In practice this means you may be building from source. That is a heavier lift than docker compose up
: you need Node, Yarn, and a build step, and the build is memory-hungry.
This is a meaningful change in the deployment story. "Self-host Cal.com in ten minutes" used to be accurate. Self-hosting Cal.diy is closer to "deploy a Next.js application from source," which is a different skill level and a different maintenance commitment.
If that is not something you want to own, the honest advice is to look at Easy!Appointments (official Docker image) or Calnode (single binary) instead.
12. Configuration: Calendars, Video, Payments
Once it is running:
Calendar connections are the core. Two-way sync with Google Calendar and Outlook means the booking page shows your real availability and confirmed bookings land in your calendar. Getting OAuth credentials right — correct redirect URIs, correct scopes — is the fiddliest part of the setup and the source of most "it booked me twice" complaints.
Video links are auto-created per booking, via Cal Video (Daily.co powered), Zoom, or Google Meet. Note the sovereignty implication: Cal Video routes through Daily.co, which is a third party. If your reason for self-hosting is that no third party should see your meetings, use your own Jitsi instance and configure the link accordingly.
Stripe integration enables paid bookings, which is what makes this a viable product for consultants and coaches, not just a convenience.
Webhooks fire on booking lifecycle events, which is how you connect scheduling to the rest of your tooling.
13. Where Your Data Goes
Self-hosted Cal.diy: bookings, event types, availability, and booking-form responses live in your Postgres database on your server. Encrypted CalDAV credentials are protected by your encryption key. Telemetry can be disabled.
The third parties that remain in the loop:
- Google and Microsoft, if you connect those calendars. This is unavoidable — the whole point is reading your real availability from the calendar you actually use.
- Stripe, if you take payments.
- Daily.co, if you use Cal Video for the meeting link.
- Your email provider, for booking notifications.
That is a short and reasonable list, and the important property holds: the booking data itself, the part that maps who met whom and why, stays with you. That is the thing Calendly holds and the thing worth self-hosting for.
With Calendly, by contrast, the vendor holds the entire booking graph for you and for every person who has ever booked with you, including people who never signed up for anything.
14. What It Costs
| Component | Calendly | Cal.diy self-hosted |
|---|---|---|
| Licence | $10/seat/mo Standard, $16 Teams (annual) | $0 (MIT) |
| Infrastructure | $0 | ~$10–20/mo VPS + Postgres |
| Build & maintenance | None | Build from source, upgrades |
| Teams/Orgs | Included in Teams tier | Removed from Cal.diy |
| SSO/SAML | Enterprise tier | Removed from Cal.diy |
| Workflows/reminders | Included | Removed from Cal.diy |
The arithmetic depends entirely on which column you are in. For a solo consultant, self-hosting Cal.diy replaces a $10–15/month subscription with a $10–20/month VPS — a wash on money, a clear win on control, and a clear loss on convenience, given the build-from-source requirement.
For a team, the comparison has changed fundamentally. Cal.diy does not do teams. You would be comparing a product that removed the feature to one that charges for it, and the answer is that the open-source option no longer competes at that tier.
The honest conclusion: for a solo practitioner or a small practice that wants booking data on its own infrastructure, Cal.diy remains worth it. For a team that needs routing, workflows, and SSO, the self-hosted path now means choosing a different product.
15. Cal.diy vs the Alternatives
Calendly is the default and is excellent at being a product: it works, it integrates with everything, and it costs per seat. Choose it if scheduling is a utility and the metadata sensitivity does not bother you.
Easy!Appointments is the better self-hosted choice for service businesses with multiple providers, and it has an official Docker image — which, after the Cal.diy change, is a genuine advantage.
Rallly solves the adjacent problem of finding a time for a group, not booking slots from your availability.
Nextcloud Calendar is the right answer if you already run Nextcloud and want no new infrastructure.
Cal.diy's remaining position is the deepest scheduling engine available under a permissive licence, with the largest integration catalogue, for single-user and small-practice deployment. That is still a real position. It is just much narrower than it was a year ago.
16. Honest Limitations
The production codebase is closed. The product most users think of when they hear "Cal.com" is not open source.
Teams, Organizations, Workflows, Routing Forms, SSO, Insights, and API v1 are gone from the open-source edition. This is the single biggest functional constraint.
No official prebuilt Docker image — expect to build from source.
Maintenance is by former interns, who know the codebase well but are not the company's engineering team. This may be fine; it is not the same as being maintained by the people building the commercial product.
Contributions do not flow upstream to the commercial product. Two codebases, diverging futures.
Your existing Cal.com deployment has a migration decision that you cannot defer indefinitely.
Resource requirements are non-trivial for a scheduling page — Next.js plus Postgres plus Redis is a real stack for what looks like a simple tool.
Cal Video routes through Daily.co, a third party, unless you configure otherwise.
The name is confusing and will stay confusing. The product is called Cal.com, the open-source edition is Cal.diy, the Docker image historically used the old name, and documentation across the web refers to all three interchangeably. Expect to spend time working out which thing a given page is actually describing.
17. Security Considerations
The company cited CVE-2026-23478, a critical authentication vulnerability fixed before v6.0.7, as motivation. Two takeaways for anyone running either product:
Patch promptly. Whatever you think of the licensing argument, the underlying point about authentication flaws in scheduling software is well taken. Access control on booking endpoints is where the serious bugs live, and this class of software handles personal data.
Isolate the deployment. A scheduling application does not need broad network access. Give it a database, an outbound internet path for calendar APIs, and nothing else.
Protect the encryption key. CALENDSO_ENCRYPTION_KEY
guards stored calendar credentials. Treat it like the credential it is.
Watch the security backporting arrangement. While both repositories were maintained in parallel, fixes went both ways. Confirm, over time, that security patches continue to reach Cal.diy. This is the thing most likely to quietly degrade.
18. Performance and Sizing
A scheduling application is not a heavy workload. Most of the time it serves a booking page and occasionally computes availability.
The resource peaks are:
- Build time, which is memory-hungry — hence
MAX_OLD_SPACE_SIZE=4096
.
Availability computation, which fans out to connected calendar APIs and can be slow if a user has many calendars connected.
Notification bursts, when many bookings are created at once.
Practical sizing: 2 vCPU and 2 GB RAM is comfortable for an individual or small practice. Redis matters more as usage grows than it does at the start. Database size grows with booking history and is modest.
One thing that surprises people who have only run single-binary self-hosted tools: this is a three-service stack for what looks like a booking page. Next.js application, Postgres, and Redis, where something like ntfy or AdGuard Home is a single binary you copy. That is not a criticism — it is what a modern web application looks like — but it is a real difference in what you are signing up to operate, and it is worth weighing against tools like Calnode or Easy!Appointments that have a much smaller footprint for a similar job.
19. Troubleshooting
"Double bookings happen." Calendar sync is failing or lagging. Check the OAuth credentials and whether the calendar connection is still authorised.
"Build fails with out-of-memory." Increase MAX_OLD_SPACE_SIZE
. This is the most common build failure by a wide margin.
"Availability shows as fully booked." The connected calendar is returning busy for everything, usually a permissions or wrong-calendar problem.
"Teams/Workflows menu is missing." Removed from Cal.diy. Not a bug.
"API returns 404 on v1 endpoints." API v1 was removed. Migrate to v2.
"Notifications are not sending." Email configuration, or a webhook that is failing silently.
"Calendar credentials stopped working after an upgrade." The encryption key changed. Restore the original key.
20. Backup and Upgrades
The backup surface:
- PostgreSQL — bookings, users, event types, availability rules. The important one.
- Environment variables and secrets — especially
NEXTAUTH_SECRET
and CALENDSO_ENCRYPTION_KEY
. Losing the latter means reconnecting every calendar.
Redis — transient; cache and queue state. Not worth backing up.
Upgrades need care now, more than before. Because the repository was renamed and stripped, an upgrade is not simply a newer version of the same thing — it is potentially a smaller product. Read the release notes and the removal list before upgrading, and take a database backup first, every time.
For the cautious: pin to a known-good version and upgrade deliberately rather than tracking latest
. After April 2026, latest` means something different than it did.
21. Who Should Still Self-Host It, and Who Shouldn't
Still worth it if you are an individual or small practice; your reason for self-hosting is booking-data sovereignty; you want a permissive licence you can fork and modify; and you are comfortable deploying a Next.js application from source.
Look elsewhere if you need teams, routing, workflows, or SSO — those are gone, and Easy!Appointments or a hosted product will serve you better; if you want a one-command Docker deployment, because that is no longer the story; or if you are not prepared to own a build pipeline.
Reconsider the whole category if what you actually need is group scheduling rather than booking pages — in which case Rallly is the better tool and always was.
22. The Verdict
Cal.com's move to closed source is the most significant open-source licensing event of 2026, and the correct reaction is neither outrage nor applause. It is a clear-eyed inventory of what you now have.
What you have is
Cal.diy: MIT-licensed, roughly 45,000 stars, carrying the scheduling engine, booking flows, app store, and API v2. For an individual who wants their booking data on their own server, it remains the most capable open-source option available. That is not nothing.
What you no longer have is the thing most organisations were actually using Cal.com for.
Teams, Organizations, Workflows, Routing Forms, SSO, Insights, and API v1 were removed. The licence got more permissive and the product got smaller, in the same commit, and those two facts are not separable.
The security argument for closing the source is real but incomplete. AI-assisted vulnerability discovery is genuinely easier on public code; it is also true that public scrutiny finds the vulnerabilities that matter, and that "hide the code" is a poor answer to "we found an authentication bug."
The practical advice is unglamorous. If you self-host Cal.com today,
audit which features you depend on before you upgrade. If you use only the individual booking flows, you are fine. If you use teams, routing, or API v1, you have a migration project, and you should start it now rather than the day an upgrade breaks something.
And if you were choosing this stack for sovereignty reasons, the core claim still holds. Self-hosted Cal.diy keeps the booking graph — who met whom, when, and about what — on infrastructure you control. Calendly keeps it on theirs, for you and for every person who ever booked time with you. That difference did not change in April 2026. What changed is how much of the product you can have alongside it.
Related
Comments (0)
No comments yet. Be the first to comment!