Cal.com Is No Longer Open Source: What Self-Hosted Teams Should Do Now

Cal.com closed its commercial codebase in April 2026. If you self-hosted Cal.com to get team scheduling without per-seat fees, that option is gone in any supported form, and the open-source replacement, Cal.diy, is explicitly not for production use. The good news: the realistic paths forward are clear, and for most teams the cost of the correct move is between $1,700 and $4,000 a year. This post lays out exactly what changed, what your self-hosted instance is now, and the four options worth considering with real numbers.

What actually changed in April 2026

On April 14, 2026, Cal.com announced it was moving its production codebase to closed source. The reason given was security: AI coding and analysis tools have made it dramatically easier to find and exploit vulnerabilities in publicly available code. The company pointed to a case where AI uncovered a 27-year-old vulnerability in the BSD kernel and generated working exploits within hours, and argued that keeping a codebase that handles sensitive booking data public had become an unacceptable risk. The company put it bluntly in the press release: "We want to be a scheduling company, not a cybersecurity company."

A day later, the engineering team published the technical details of the split:

• The public repository calcom/cal.com was renamed to calcom/cal.diy, now called Cal.diy.
• Cal.diy is licensed under MIT, replacing the previous AGPL 3.0, and is maintained by community maintainers (former Cal.com interns).
• The commercial Cal.com codebase, which has diverged significantly including rewrites of authentication and data handling, moved to a private repository.
• Existing Cal.com cloud customers saw no change. Teams self-hosting the enterprise edition received invites to the private repository, per the v6.4 changelog.

Whether closing source actually improves security is a legitimate debate. Open code allows independent researchers to audit it, and "security through obscurity" has a poor track record as a sole defense. But that debate is academic if you run a self-hosted instance: what matters to you is that upstream development and security fixes for the code you run have moved behind a wall.

What Cal.diy keeps and what it loses

Cal.diy is not Cal.com with a new name. It is Cal.com with the commercial feature set surgically removed. According to the engineering post and the repository README, here is what is gone:

• Teams and Organizations: multi-tenant organization management, team creation, team availability, team booking flows, permission-based access control, and the related API v2 endpoints.
• Workflows: the automation engine for reminders, follow-ups, and triggers.
• Routing Forms: the lead-qualification forms that route bookings to the right person, including the Salesforce routing integration.
• SAML/SSO: the enterprise single sign-on flow.
• Insights: analytics and reporting dashboards.
• Instant Booking, AI Phone, Attributes and Segments, Booking Audit, API v1 (Cal.diy ships API v2 only), and the enterprise admin UI.

What remains is the core scheduling engine, the app store framework, booking flows, and API v2. For one person scheduling their own meetings, Cal.diy is a complete, capable product. The README is direct about who it is for: it is "strictly recommended for personal, non-production use," and there is no hosted or managed version.

That warning deserves to be taken at face value. If your booking page touches client data, payments, or your team's calendars, Cal.diy is not the tool the people closest to the code would choose for you.

Can you keep running your existing self-hosted Cal.com

Legally, yes. The code you downloaded under AGPL 3.0 remains under AGPL 3.0. A license cannot be revoked retroactively, so you may keep running, modifying, and even forking the last public commit of the old codebase.

Practically, it is a deteriorating position:

• No upstream fixes. Commercial development now happens in the private repository. During the transition, Cal.com patched vulnerabilities in both repos and backported them, but going forward, fixes for the commercial product stay private.
• The attack surface is public and frozen. Cal.com's own argument for closing the source applies directly to your instance: the last public code is fully visible to every AI-assisted vulnerability scanner on the planet, and nobody is patching it for you anymore.
• Dependencies age. A Next.js, Prisma, and PostgreSQL stack needs routine dependency updates to stay safe. The Cal.diy maintainers will do some of this, but their mandate is a personal-use product, and the team features you rely on are the exact parts they removed.

Running frozen, publicly known code that stores names, email addresses, calendar contents, and sometimes payment details is a real liability. Under most data protection regimes, including Kenya's Data Protection Act, you are the data controller for that booking data, and "the vendor changed its license" is not a defense after a breach.

Your four options now

Option 1: Move to Cal.com cloud

This is the path Cal.com designed for you, and honestly, for most teams it is the right one. The feature set you self-hosted for, meaning teams, round-robin, workflows, and routing forms, is exactly what the paid cloud tiers sell.

Per the current pricing page, checked in October 2026:

• Free: one user, unlimited event types and calendars, Stripe and PayPal payments, two-way Salesforce and HubSpot sync. Fine for an individual, not a team.
• Teams at $12 per user per month billed yearly: round-robin, managed and collective event types, recurring events, routing forms, branding removal, custom APIs.
• Organizations at $28 per user per month billed yearly: SAML SSO and SCIM, SOC 2, HIPAA, and ISO 27001 compliance, unlimited sub-teams, a company subdomain, role-based permissions.

You give up data residency control and per-seat pricing returns, but you get a maintained, patched product with the features intact. Migration is mostly re-creating event types and reconnecting calendars; booking history does not transfer automatically, so export what you need for records first.

Option 2: Enterprise on-prem through the private repository

If data residency or procurement rules genuinely require the application to run on your infrastructure, Cal.com's enterprise track is the only supported way to keep self-hosting. The v6.4 changelog confirms that self-hosters of the enterprise edition get access to the private GitHub repository, and the enterprise tier adds a dedicated database, SLA and uptime guarantees, and dedicated onboarding.

Pricing is custom and not published. Expect it to be meaningful money, and expect a conversation with their sales team rather than a checkout page. This option makes sense for regulated organizations that want Cal.com specifically. If you were self-hosting mainly to save money, the economics that justified your setup no longer exist.

Option 3: Stay on the frozen AGPL code, deliberately

There is a narrow case for this: your instance is internal-only, protected by a VPN or single sign-on through a tool like authentik, holds no client personal data, and you have the in-house skill to watch CVE feeds and patch dependencies yourself. In that case, keeping the last AGPL release running while you plan a migration is defensible for a defined period.

Treat it as a bridge with an end date, not a destination. Put it in writing: what the instance is allowed to store, who owns patching, and when it gets decommissioned or replaced. An unpatched booking system that everyone forgot about is how small companies end up in breach notifications. If you want the full operational picture before deciding, our guide to self-hosting Cal.com with Docker, including licensing and real costs covers what day-to-day ownership actually involves.

Option 4: Switch to Calendly or rebuild on other tools

Calendly never offered self-hosting, so it was never exposed to this problem. Per Calendly's pricing page, checked in October 2026: Standard is $10 per seat per month billed yearly, Teams is $16 per seat per month with round-robin and routing, and Enterprise starts at $15,000 per year with a 50-seat minimum. Since August 2026 there are also two Plus tiers, Standard Plus at $18 and Teams Plus at $24 per seat per month billed yearly, which bundle Calendly's AI Notetaker and the Callie scheduling assistant on top of the base plans, per this pricing breakdown. A 12-person team on Teams Plus would pay $3,456 a year; the base Teams tier is still the fair comparison with Cal.com Teams. One structural difference worth noting from an independent comparison: Calendly's SOC 2 Type II, SOC 3, ISO 27001, and PCI compliance apply across its tiers, while Cal.com gates its comparable certifications behind the $28 Organizations plan.

Other open-source schedulers exist, but be honest about scope. Easy!Appointments is a genuine open-source project, yet it is a much narrower PHP application without the team routing, workflows, and integration depth you had. There is currently no open-source product that reproduces what self-hosted Cal.com gave a team. That is the real shape of the loss.

What a 12-person team actually pays

Take a 12-person sales and customer-success team that was self-hosting Cal.com on a VPS for roughly $20 a month in server costs, plus whatever admin time the maintenance took. Annual costs under each option, using published prices with annual billing:

• Stay on frozen AGPL code: about $240 a year in hosting, plus rising security risk and your own patching labor. The cheap option on paper, the expensive one after an incident.
• Cal.com cloud Teams: 12 users times $12 times 12 months is $1,728 a year. Everything you used, maintained, for less than one day of an engineer's time per quarter.
• Cal.com cloud Organizations: 12 times $28 times 12 is $4,032 a year, and only worth it if you need SSO, SCIM, or the compliance certifications.
• Calendly Teams: 12 times $16 times 12 is $2,304 a year, $576 more than Cal.com Teams for a very similar feature set.
• Cal.com Enterprise on-prem: custom pricing; budget well above the cloud tiers and treat it as a procurement exercise, not a hosting decision.

The pattern: for a 12-person team, the "correct" answer costs somewhere between $1,700 and $4,000 a year. The old self-hosted arrangement was saving you roughly $1,500 a year in subscription fees while quietly accumulating security debt. That trade was defensible when upstream patches were flowing. It is not anymore.

Replacing what you lose: reminders and follow-ups without Workflows

One practical gap catches teams during migration. If you relied on self-hosted Cal.com workflows for SMS reminders, follow-up emails, or CRM updates, you need those automations rebuilt wherever you land. Cal.com cloud includes workflows on paid tiers, so moving to Teams or Organizations restores them natively.

If you want the automations to live outside your scheduling vendor, which is a reasonable instinct after watching a vendor change its license overnight, a workflow tool like n8n can own them instead. Cal.diy and Cal.com cloud both expose API v2 and webhooks, so a booking-created event can trigger an n8n workflow that sends the reminder sequence, updates the CRM record, and posts to your team chat. The advantage is that your automation logic survives any future change of scheduling vendor.

When staying self-hosted is the wrong choice

Be suspicious of your own setup if any of these are true:

• Your booking page is public and takes client details. Names, emails, and meeting topics are personal data. Frozen public code plus personal data is the worst cell in the matrix.
• Nobody has patched it since April 2026. If you cannot name the person who owns updates, there is no owner.
• You self-hosted to avoid per-seat fees, full stop. The savings were real but modest, and they now come bundled with unbounded downside.
• You need certifications. If a client or regulator asks for SOC 2 or ISO 27001, a self-hosted community edition cannot answer that question. Calendly includes its certifications across tiers; Cal.com answers it on the Organizations plan.

The honest framing: self-hosting scheduling stopped being a cost optimization in April 2026 and became a security commitment. Only sign up for that commitment with your eyes open and a named owner.

Common mistakes teams are making right now

• Assuming Cal.diy is a drop-in upgrade. It is not. Teams, workflows, routing forms, and SSO are gone. Pointing your production DNS at a Cal.diy install removes the features your team uses daily.
• Doing nothing because "it still works." It does work. It will keep working right up until it is the reason you are writing a breach disclosure. Unpatched public code fails silently before it fails loudly.
• Paying for Organizations when Teams would do. The jump from $12 to $28 per user is only justified by SSO, SCIM, or compliance needs. A 12-person team that does not need those wastes $2,304 a year on the wrong tier.
• Migrating booking data blindly. Historical bookings usually do not transfer cleanly between platforms. Export attendee records and booking logs for your retention requirements before you shut the old instance down, then delete the old data deliberately rather than leaving it on a forgotten server.
• Forking the AGPL code as a "quick fix." Maintaining a private fork of a large Next.js application is a part-time engineering job. If you do not have that capacity, the fork becomes tomorrow's frozen instance with extra steps.

A decision checklist

Work through these in order:

1. Is this a personal booking page with no team features? Use Cal.diy or the Cal.com free tier. Either is fine.
2. Does a team book meetings through it? Self-hosting is over. Go to the next question.
3. Must the data stay on infrastructure you control for legal or policy reasons? Talk to Cal.com about enterprise on-prem access to the private repository. There is no supported open-source alternative with team features.
4. Otherwise, which cloud? Cal.com Teams at $12 per user is the value pick and the shortest migration. Calendly Teams at $16 per seat buys you compliance certifications on every tier and the most recognizable booking link in sales. Our Cal.com vs Calendly cost breakdown runs the feature-by-feature comparison.
5. Do you need SSO, SCIM, SOC 2, HIPAA, or ISO 27001 from Cal.com? Then it is the Organizations tier at $28 per user, or Calendly, which bundles its certifications more cheaply at this scale.
6. Whatever you choose, set a 30-day decommission date for the old instance and export what your retention policy requires first.

Frequently asked questions

Is Cal.com still open source? No. In April 2026 the commercial Cal.com codebase moved to a private repository. The public code continues as Cal.diy, a separate MIT-licensed community project for personal, non-production self-hosting. Cal.com cloud customers were unaffected.

Can I legally keep running my old self-hosted Cal.com? Yes. Code released under AGPL 3.0 stays under AGPL 3.0, so you may run and modify the last public release indefinitely. The problem is practical, not legal: commercial development and security fixes have moved to a private repo, so your instance will drift further from a patched state every month.

Is Cal.diy safe to use for my business? The maintainers say no, and you should believe them. The repository README recommends it strictly for personal, non-production use, and the team features most businesses need, including teams, workflows, routing forms, and SSO, were removed. For a personal booking page, it is a solid tool.

What does Cal.com cost for a team now? As of October 2026, the Teams plan is $12 per user per month billed yearly, and the Organizations plan with SSO and SOC 2, HIPAA, and ISO 27001 compliance is $28 per user per month billed yearly. Enterprise self-hosting with access to the private repository is custom-priced through their sales team.

Did other open-source scheduling tools fill the gap? Not really. Projects like Easy!Appointments are genuinely open source but far narrower, without team routing, workflow automation, or a comparable integration ecosystem. If team scheduling must be open source and self-hosted today, there is no full replacement for what Cal.com used to offer.

Where to go from here

The Cal.com license change is a good moment to audit the whole stack, not just the scheduler. Every self-hosted tool you run carries the same question: who patches this, and what is the plan if upstream changes its mind? We deploy and operate the open-source business stack, including scheduling, CRM, support, and analytics, as a managed open-source stack service, which means license changes, updates, and migrations are our problem rather than yours. If your immediate need is rebuilding the reminder and follow-up automations you lost with the old Workflows feature, our business automation team builds those on n8n so they are not hostage to any single vendor. Either way, do not leave the frozen instance running without a decision and a date.

Related reading

• Cal.com Routing Forms and Round Robin Scheduling Guide