The most honest answer for 2026 changed this year: Cal.com — long the default open-source Calendly alternative — moved its production codebase closed-source in April 2026. The genuinely open-source, self-hostable path now runs through Cal.diy, the MIT-licensed community fork, alongside the final AGPL-3.0 release of Cal.com you can still host yourself.
Short answer
The best open-source, self-hostable Calendly alternative in 2026 is Cal.diy — the MIT-licensed community fork born after Cal.com went closed-source in April 2026. Cal.diy gives you a fast single booking page with calendar sync, timezone detection and video links, fully self-hosted with no per-seat fee. For teams and workflows, self-host the last AGPL-3.0 Cal.com release instead.
I implement open-source business software for a living, so I care about which fork is actually maintained and actually open — not which brand had the loudest launch. I am Manoj, an ERPNext and Frappe implementation consultant at Mith Tech in Bengaluru, and my team self-hosts scheduling, CRM and ERP for Indian SMBs every week.
Honest take: this space got messier in 2026, not cleaner. "Open source" is now a moving target here, so picking the right project matters more than picking the right feature list.
What happened to Cal.com's open-source status in 2026?
Cal.com moved its production codebase from a public repository to a private one in April 2026, ending roughly five years as an open-source project. Management framed the decision around AI-driven security threats — the argument being that AI now finds and weaponises vulnerabilities in exposed source code faster than teams can patch them.
That single change reshaped the whole "open-source Calendly alternative" question. The Cal.com you sign up for today is a proprietary managed service. The code that made it the community darling did not vanish, though — it was re-released, trimmed down, as a separate community project. So the honest 2026 position is: Cal.com the company went closed; Cal.com the open-source lineage continues under a new name.
Skimmable summary: Cal.com went closed-source in April 2026, so the hosted product is no longer the open-source answer — the open lineage moved elsewhere.
Is there still a genuinely open-source, self-hostable Calendly alternative?
Yes — Cal.diy is the open-source, self-hostable scheduling platform that carries the lineage forward. Released under the permissive MIT licence (Cal.com's code had been AGPL-3.0), Cal.diy is maintained as a community project with no proprietary "enterprise edition" mixed in. Every line is under the same open licence, and it needs no licence key.
Cal.diy is built on the same modern stack the original project used: Next.js, React and TypeScript on the front, PostgreSQL with Prisma for data, tRPC for the API layer and Tailwind for styling. That matters if you plan to fork or extend it — the codebase is familiar to any web team, and Docker deployment is supported out of the box.
There is a second, quieter option too. The final AGPL-3.0 release of Cal.com (the v4.x line, the last version published before the switch) is still out there and still self-hostable. It carries the fuller feature set, but it is a frozen snapshot: no future open-source releases flow from it. Treat it as a fork point you maintain yourself, not a living upstream.
Skimmable summary: Cal.diy (MIT) is the living open-source option; the frozen AGPL-3.0 Cal.com v4.x is a heavier fallback you maintain yourself.
What does Cal.diy actually do — and what did it drop?
Cal.diy focuses on one job done well: a single, fast public booking page for an individual. Core scheduling is intact — availability rules, automatic timezone detection, calendar sync, confirmation emails and video-meeting links — which covers what most solo consultants and freelancers actually need from a Calendly replacement.
What it deliberately leaves out are the commercial and multi-tenant features that only made sense for Cal.com's managed platform. Those moved to the closed-source product.
| Capability | In Cal.diy (open source) | Moved to closed-source Cal.com |
|---|---|---|
| Single public booking page | Yes | — |
| Availability + timezone detection | Yes | — |
| Calendar sync (Google, Outlook/Microsoft, plus Zoom) | Yes | — |
| Video links (Cal Video / Daily.co) | Yes | — |
| Confirmation emails | Yes | — |
| Organizations & Teams | No | Yes |
| Routing Forms | No | Yes |
| Automated Workflows (reminders, follow-ups) | No | Yes |
| SAML / SSO, Analytics / Insights | No | Yes |
One caveat worth stating plainly: the Cal.diy project positions itself toward personal and self-hoster use rather than heavy production deployments. If you need team round-robin, routing logic and automated reminders as open-source, self-hosted features, the honest path is the frozen AGPL-3.0 Cal.com v4.x — with the maintenance burden that a frozen codebase implies.
Skimmable summary: Cal.diy nails the solo booking page; Teams, Routing Forms and Workflows are not in it — they live in the closed product now.
How do you self-host Cal.diy?
Self-hosting Cal.diy is a moderately technical job — plan for an evening of setup, not five minutes. The stack is standard, but the integration credentials take the most time because each calendar and video provider needs its own OAuth app that you create and own.
Provision the server and dependencies
Stand up a Linux host with Node.js 18+ and PostgreSQL 13+ (a managed Postgres works too). Docker is supported if you prefer containerised deployment.
Clone Cal.diy and set environment variables
Pull the calcom/cal.diy repository, copy the example environment file, and set your database URL, app URL and an encryption secret.
Create your own OAuth apps
Register a Google Cloud project for Google Calendar (Calendar API scope) and an Azure app for Outlook/Microsoft. Add Zoom credentials if you want Zoom links. These are your credentials — no shared keys.
Configure email delivery
Point Cal.diy at your SMTP or transactional-email provider so booking confirmations and reminders actually send.
Build, migrate and go live
Run the database migration, build the app, put it behind a reverse proxy with HTTPS, and test a real booking end to end before you share the link.
Self-hosting is real ownership — and real responsibility
Once you host it, backups, updates and security patches are yours. That is the deal with any self-hosted tool: you gain control and drop the per-seat meter, but the uptime is on you or your implementation partner.
Skimmable summary: Standard Node + PostgreSQL setup; the slow part is creating your own Google, Microsoft and Zoom OAuth apps.
How does Cal.diy compare to Calendly and to closed Cal.com?
Cal.diy competes with Calendly on ownership and licence model, not on managed convenience. Calendly is proprietary SaaS billed per seat with a free tier; you never touch the code or the servers. Cal.diy is free, open-source software you run yourself — no per-seat fee, full data control, and full responsibility for hosting.
| Factor | Cal.diy (open source) | AGPL-3.0 Cal.com v4.x (frozen) | Calendly (proprietary SaaS) |
|---|---|---|---|
| Licence model | MIT, fully open | AGPL-3.0, frozen snapshot | Proprietary; per-seat subscription |
| Self-hostable | Yes | Yes | No |
| Data location | Your infrastructure | Your infrastructure | Vendor cloud |
| Teams / Workflows / Routing | No | Yes (unmaintained) | Yes (managed) |
| Future open-source updates | Yes (community) | No | N/A |
| Best for | Solo booking page, self-hosters | Teams wanting one-time self-host | Zero-maintenance managed use |
For cost specifics on any managed edition, check the vendor's official page — figures move around and edition tiers change, so a number in a blog post ages badly.
Skimmable summary: Cal.diy wins on licence and data ownership; Calendly wins on zero-maintenance convenience; the frozen v4.x sits in between for teams who accept the upkeep.
Who should self-host, and who should not?
Self-host when data ownership, no per-seat billing, or deep customisation matter more than convenience — and when you have someone who can run a Node and PostgreSQL app. Independent consultants, agencies embedding booking into their own product, and privacy-sensitive Indian SMBs are the natural fit for Cal.diy.
Stay on managed SaaS if scheduling is peripheral, your team is non-technical, and an hour of setup plus ongoing patching is not worth the licence savings. There is no shame in that trade — a booking page is not where most SMBs should spend their engineering evenings.
If you already run open-source infrastructure, though, adding a self-hosted scheduler is a small marginal step. That is the pattern I see most: teams who already self-host their ERP, CRM or support desk simply fold scheduling into the same stack. If you are mapping that broader move, my directory of open-source SaaS alternatives covers the categories around scheduling — CRM, marketing, support and more.
Skimmable summary: Self-host if ownership and no per-seat billing matter and you have technical hands; stay managed if scheduling is peripheral and your team is non-technical.
Where does scheduling fit alongside your ERP?
Scheduling rarely lives alone — a booking usually needs to become a lead, a project task or an invoice somewhere. That is where a self-hosted scheduler pays off: because you own the data and the server, wiring bookings into the rest of your open-source stack is a plumbing job, not a vendor negotiation.
For Indian SMBs, the anchor of that stack is often ERPNext, which is free and open source under the GPLv3 licence and runs on the Frappe framework. A booking captured in Cal.diy can flow into ERPNext as a lead or an appointment, keeping sales, projects and accounting in one system you control end to end. If you want the managed-hosting angle on the scheduler itself, we cover it on our Cal.com implementation page.
Skimmable summary: A self-hosted scheduler becomes far more valuable when its bookings flow into an open-source ERP like ERPNext that you already own.
Frequently asked questions
Is Cal.com still open source in 2026?
No. In April 2026, Cal.com moved its production codebase from a public repository to a private one, citing AI-driven security risk. The current Cal.com product is proprietary. The open-source lineage continues separately as Cal.diy, and the final AGPL-3.0 Cal.com release remains available to self-host.
What is Cal.diy and how is it different from Cal.com?
Cal.diy is the community-maintained, MIT-licensed fork created after Cal.com went closed-source. It keeps the core scheduling engine and a single booking page but drops enterprise features like Teams, Routing Forms and Workflows. Cal.com is now the proprietary managed service; Cal.diy is the open-source, self-hostable option.
Can I self-host a scheduler with team scheduling and automated reminders as open source?
Yes, but with a caveat. Cal.diy focuses on a single booking page and does not include Teams or Workflows. For those features as self-hosted open source, use the last AGPL-3.0 Cal.com release (the v4.x line). It carries the fuller feature set but is a frozen snapshot you maintain yourself, without future open-source updates.
Which calendar and video integrations does Cal.diy support?
Cal.diy syncs with Google Calendar and Outlook/Microsoft calendars and supports Zoom links plus built-in Cal Video (Daily.co). You create and own the OAuth credentials for each provider during setup, so the integrations run through your own apps rather than shared keys.
How hard is Cal.diy to self-host?
Moderately technical. You need a server with Node.js 18+ and PostgreSQL 13+, and you register your own OAuth apps for each calendar and video provider. Plan for an evening rather than a few minutes. Docker deployment is supported. After launch, backups, updates and security are your responsibility.
Is Cal.diy free compared to Calendly?
Cal.diy is free and open source under the MIT licence — there is no per-seat fee and no licence key. Calendly is proprietary SaaS billed per seat with a free tier. The real difference is the model: self-hosting removes the per-user meter but adds hosting and maintenance effort. For managed-edition costs, check each vendor's official page.
About the author
I am Manoj, an ERPNext and Frappe implementation consultant at Mith Tech, an independent open-source implementation studio in Bengaluru. My team self-hosts and integrates open-source business tools — ERP, CRM, scheduling and more — for Indian SMBs that want to own their data and avoid per-seat licensing lock-in. I write from what we actually deploy, not from vendor decks.