Calendly vs Cal.diy: when a self-hosted personal booking page fits
A renewal, a per-seat bill that keeps growing, or a rule that invitee data must stay in your own data center is usually what sends a team to look at Cal.diy. The fit question comes first: Cal.diy suits an individual or a small group using it for non-production scheduling, with in-house server skills, while Calendly suits teams that need routing, SSO and an operator who runs the service for them. Cal.diy has no team scheduling, no routing workflows and no SSO, because those features were removed from the Enterprise-only code it was forked from. If your booking process depends on any of them, Cal.diy is not a like-for-like replacement, whatever the license says.
Cost is different in kind. Calendly bills per seat on its published plans, and Cal.diy carries no license fee. What you pay instead is the server, the database, calendar API setup and the staff time to run them, including patching and backups. The Cal.diy README requires PostgreSQL 13 or later and Node.js 18 or later, and it calls for advanced knowledge of server administration, database management and securing sensitive data. Ask whether someone on your team can own those tasks through upgrades, not just the first install. The Cal.diy repository lists the current requirements and release notes.
The decision turns on three questions. Do you need team scheduling or SSO? Who will run and secure the server day to day? And is the maintainers' advice that self-hosting is strictly recommended for personal, non-production use acceptable for the bookings you plan to take? If the answer to the last question is no, check the paid Cal.com plans or the Calendly tiers, and compare total ownership cost with the fixed-scope support options before committing.
Which option fits which scenario
This table matches common buyer situations to the option that fits better, based on what Cal.diy removed and what its README asks of self-hosters. Read each row as a starting point: where the scenario depends on your own server skills or compliance duties, the cell says what to confirm before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Solo consultant wanting a self-hosted booking page | Cal.diy | Personal event types, availability and calendar connections are kept, so one person can run a booking page on their own server if they accept the non-production guidance. |
| Team needing round-robin routing | Calendly or Cal.com hosted | Cal.diy removed Teams and routing workflows, so team scheduling has no supported path in the fork. Cal.diy's README directs commercial and team users to Cal.com. |
| Organization requiring SSO | Cal.com Organizations or another identity-aware tool | Cal.diy removed SSO and SAML as Enterprise-only features. Confirm the SSO requirement with Cal.com sales before assuming any self-hosted path exists. |
| Company keeping invitee data on its own servers | Cal.diy, with a production-grade hosting plan | Bookings and invitee details stay on infrastructure you control. Cal.diy's README says self-hosting is at your own risk, so budget for database security and backups before go-live. |
| Team with no server administration capacity | Calendly or a managed Cal.com plan | Cal.diy requires advanced knowledge of server administration, database management and securing sensitive data. Without that skill set in-house, a managed service or an implementation partner is the safer route. |
| Commercial or enterprise scheduling deployment | Cal.com | The Cal.diy README points commercial and enterprise scheduling users to Cal.com, including enterprise on-premises access through Cal.com sales. |
Licensing and editions: what Cal.diy and Cal.com each offer
Calendly is a hosted service sold in tiers. Its pricing page, as read in October 2026, lists a Free plan, a Standard plan at $10 and a Teams plan at $16 per seat per month billed yearly, and an Enterprise plan starting at $15k per year with a 50-seat minimum. Your cost scales with the number of people who need scheduling, and the controls you need often sit in the higher tiers.
- Per-seat billing: Standard and Teams are priced per seat, so each person who manages event types adds a recurring charge.
- Enterprise minimum: The Enterprise tier starts at $15k per year and requires at least 50 seats, which matters for smaller organizations.
- Recurring cost: All paid plans renew on a subscription, so the cost continues for as long as you use the service.
- Feature gating: Routing, team features and enterprise controls depend on the tier you buy, so confirm which tier includes each feature you use today.
- Hosting: Calendly runs the service, and your invitee and calendar data sits in its environment.
Before comparing, confirm the current tier contents, seat counts and billing terms directly with Calendly, since the pricing page can change.
Cal.diy is a community fork of Cal.com. Its repository describes it as 100% MIT licensed, with all enterprise and commercial code removed and no proprietary Enterprise Edition features. You can run, modify and redistribute it under the MIT terms, but you take on the operating work that a hosted vendor would normally do. The maintainers state that self-hosting is at your own risk and strictly recommended for personal, non-production use.
- License terms: The MIT license imposes no per-seat or per-instance fee for the software itself.
- Removed features: Teams, Organizations, Insights, Workflows, SSO and SAML are not part of Cal.diy.
- Stack: Cal.diy is built with Next.js, tRPC, React, Tailwind CSS and Prisma, requires Node.js 18 or later and PostgreSQL 13 or later, and is published as a Docker image.
- Integrations: The README documents Google Calendar, Microsoft Graph (Office 365), Zoom and other connections, added from the Settings and Integrations page.
- Operating burden: The README notes that self-hosting requires advanced knowledge of server administration, database management and securing sensitive data.
Check the current README and your own legal team's reading of the MIT terms before deployment, and confirm which integrations you need still work on the release you plan to run.
Cal.com is the commercial company behind the upstream project. Its hosted pricing, as read in October 2026, lists a Free plan for 1 user, a Teams plan at $12 and an Organizations plan at $28 per user per month on yearly billing, with custom Enterprise pricing on request. The Organizations tier includes SAML SSO and SCIM, and hosting choices include US or EU regions. Cal.com is a different product from Cal.diy, and its feature set and terms are its own.
- Per-user pricing: Teams and Organizations are billed per user per month, so cost grows with headcount.
- Identity features: SAML SSO and SCIM are listed on the Organizations plan, not on the lower tiers.
- Hosting regions: Cal.com lists US or EU hosting choices for its hosted service.
- Enterprise terms: Custom Enterprise pricing is negotiated separately, so you need a written quote for on-premises or enterprise needs.
- Recurring cost: Hosted plans are subscriptions, so the cost recurs for as long as you subscribe.
Ask Cal.com for written confirmation of what each tier includes, the hosting region options, and the data processing terms that apply to your organization.
Cal.diy is intended for individual, non-production use, and its README directs commercial and enterprise scheduling users to Cal.com. Enterprise on-premises access is handled through Cal.com sales rather than through the community fork. If your organization needs team scheduling, routing, SSO or enterprise support, the README treats that as a separate conversation with the commercial vendor.
- Intended use: Cal.diy is positioned for personal and non-production use, not as a commercial scheduling product.
- Team and routing needs: Features for teams, routing and workflows are not in Cal.diy, so they require a different edition.
- Identity needs: SSO and SAML are removed from Cal.diy, which affects how staff sign in.
- Enterprise on-premises: The README points to Cal.com sales for enterprise on-premises access, so ask that vendor directly what is available.
- Support boundary: Community support is not a service commitment, so plan your own operations if you stay on Cal.diy.
Decide early whether your use is personal or commercial, because the answer determines whether Cal.diy is a candidate at all. Ask Cal.com to confirm in writing which edition and terms apply to your planned deployment.
Why Cal.diy's maintainers advise non-production use
The Cal.diy README says self-hosting is at your own risk and is strictly recommended for personal, non-production use. It also states that running the software requires advanced knowledge of server administration, database management and securing sensitive data. Those are the maintainers' own words about who should run this code, and a buyer should treat them as a scope limit rather than a footnote. The fork has removed Teams, Organizations, Workflows and SSO, so the maintainers are not offering it as a team-grade or enterprise-grade booking system.
For a buyer who would put invitee names, email addresses, meeting notes and calendar data into Cal.diy, the practical meaning is that the organization becomes the operator of record. Someone must patch the Next.js, Prisma and Node.js stack, keep the PostgreSQL database backed up and encrypted, rotate the Google or Microsoft 365 OAuth credentials, manage TLS and access controls, and respond to security issues in a codebase that the maintainers describe as not production-ready. Ask who on your team owns each of those duties, and whether that owner has written runbooks, monitoring and a tested restore.
This is the reason this page does not recommend Cal.diy for regulated or customer-facing production use. If your booking page handles client, patient or citizen data, or if your audit scope covers it, the maintainers' guidance points you toward a commercial edition or toward a self-hosted product that its authors position for production, such as Easy!Appointments, which is covered in its own comparison. Confirm the current README wording directly in the repository before you decide, because the fork's status may change between releases.
Where booking data lives and who controls it
Calendly is a hosted service that holds your event types, invitee details and calendar connections on its infrastructure. Cal.diy moves those records, and the credentials that reach your calendars, onto servers you operate, which shifts backups, access control and evidence work to your team.
Data location and hosting
With Calendly, booking records sit in the vendor's hosted service and you rely on its terms for where they are stored. With Cal.diy, event types, availability, invitee names, emails and meeting notes live in the PostgreSQL database you deploy, in the region and data center you choose. Ask which hosts will run the Next.js app and database, who can reach them, and whether any booking data leaves your network through integrations such as Zoom or Daily.co.
Google and Microsoft calendar credentials
Cal.diy connects to Google Calendar and Microsoft Graph through OAuth applications that you register and keep in your own tenant or Google Cloud project. The client secrets and refresh tokens it stores can read and write calendar events for every connected user, so they become sensitive assets. Confirm who owns the app registrations, how secrets are rotated, and what scopes the consent screen requests.
PostgreSQL database and encryption
Cal.diy requires PostgreSQL 13 or later through Prisma, and that database becomes the primary store for personal data about bookers. Calendly's internal storage is not visible to you, so you take on database hardening, encryption at rest, network isolation and patch cadence. Document the version you run, the backup encryption keys and who holds them.
Identity and SSO gaps
Cal.diy removes the SSO, SAML and Enterprise-only features found in Cal.com, so it has no built-in SAML or SCIM provisioning for staff accounts. Logins rely on the accounts the application manages itself. Decide how administrator and host accounts are created, removed and protected with multi-factor authentication, and whether an external identity layer must sit in front of the application.
Backups and recovery ownership
Calendly keeps its own copies of scheduling data, and recovery of that service is the vendor's responsibility. Under Cal.diy, backups of the PostgreSQL database, uploaded assets and configuration are yours to design, test and restore. Set a restore test schedule, store copies off the application host, and confirm how calendar links and OAuth tokens are rebuilt after a restore.
Compliance evidence and who issues it
Hosting Cal.diy in your own infrastructure gives you control over the configuration and logs that compliance reviews ask for, such as access reviews, change records and backup test results. DeployOpen can prepare these systems, controls and evidence, but audit reports, attestations and certifications are issued by independent auditors and certification bodies. Do not assume either product holds a certification unless you verify that with the vendor and the assessor.
What a self-hosted Cal.diy really costs to run
Calendly's largest cost is recurring and per seat. The published plans on the Calendly pricing page list Standard at $10 and Teams at $16 per seat per month billed yearly, with Enterprise starting at $15k per year and a 50-seat minimum. Those figures are as published when we read the page in October 2026, so confirm them on the pricing page before you build a budget. Under Calendly, the vendor carries hosting, updates and calendar connectors, and your cost grows with each host who needs a booking page. Self-hosting Cal.diy swaps that subscription for costs you control. The license fee is zero, because Cal.diy is MIT licensed, but you pay for a Node.js application server, a PostgreSQL 13 or later database, backups, TLS certificates and the staff time to run them. Google Calendar and Microsoft Graph connections need your own OAuth client credentials, and those credentials are tied to your tenant and must be renewed and monitored. Ask who will own the Google Cloud and Microsoft Entra app registrations after launch, because a lapsed credential stops every booking page that depends on it.
The largest variable is administration time. Plan for upgrades, since Cal.diy releases move with the upstream repository (the latest release on the calcom/cal.com repository was v6.2.0, published March 1, 2026), and each upgrade needs a tested database migration and a rollback plan. Ask any implementation partner for a written scope that states who applies security patches, who restores from backup and how often restores are tested. Paid installation or support is a one-time or retainer cost that depends on how many calendars, domains and integrations you connect. The cost drops when booking is limited to one team with few integrations and rises when you add shared calendars, several domains or compliance evidence requirements. Before you compare totals, remember that Cal.diy's README says self-hosting is at your own risk and is strictly recommended for personal, non-production use. If your scheduling is for a team or a customer-facing business, the production-grade features you may need, such as Teams, Organizations and SSO, sit in the commercial edition. Price that gap explicitly, since the Cal.com pricing page lists its hosted Teams and Organizations plans, and compare those figures with the in-house cost of the controls you still need.
Cost components: one-time and recurring on each side
Calendly bills per seat, so its cost is recurring and scales with headcount. Self-hosting Cal.diy moves the cost into infrastructure, calendar credentials and people who run the server, with fewer line items that repeat on a fixed schedule. The cards below separate one-time setup from recurring operations so you can build a like-for-like comparison.
Subscription fees
Calendly charges per seat on its paid tiers, so the fee recurs every billing period and grows with each user who needs a booking page. Cal.diy has no license fee because it is MIT licensed, but that is the only cost it removes from this line. Ask Calendly for the seat count, billing period and any Enterprise minimum that would apply to your organization. Cal.com's hosted plans, which list Teams at $12 and Organizations at $28 per user per month on yearly billing, are a reference point only if you want a hosted fallback, since Cal.diy is not the same product.
Hosting and compute
On the self-hosted side, you pay a cloud account or data center for the application server and database that run Cal.diy. This is recurring and scales with the number of bookings, the number of users and your availability target. Confirm with your infrastructure team whether you need a second node for redundancy, and whether the hosting is inside a region that matches your data residency requirements. Calendly's cost does not include this line because Calendly runs the service.
Database and storage
Cal.diy requires PostgreSQL 13 or later, so you pay for a managed or self-run database service, its storage, and its backups. The database holds event types, availability and booking records, so its size grows with booking volume over time. Ask whether your team will run PostgreSQL yourselves or buy a managed instance, since that choice changes both the one-time setup and the recurring fee.
Calendar API setup
Connecting Google Calendar, Microsoft Graph for Office 365 and video tools such as Zoom requires you to register OAuth applications with each provider. This is a one-time setup with recurring credential rotation, consent review and occasional re-authorization. Calendly handles these connections for you inside its subscription. Check which providers your users need before you scope the work, because each one adds its own registration and testing.
Installation and migration
Initial installation, configuration, event type rebuilding and cutover of booking links are one-time costs. On the Calendly side there is no installation cost, but you still spend time rebuilding event types and updating links on your website. If you hire an implementation partner, the fee follows from a written, fixed scope with deliverables and timelines agreed before work starts. DeployOpen does not publish prices, so request a quote against a defined scope.
Administration, upgrades and backups
Ongoing administration covers user management, patching the Node.js and PostgreSQL stack, applying Cal.diy releases, monitoring and backups. These are recurring costs paid as staff time or as a support retainer, and they are the largest item most teams underestimate. Cal.diy's README says self-hosting needs advanced server administration and database skills, and it is at your own risk for production use. Calendly carries these tasks in its subscription, so ask who on your team will own them and how many hours per month that represents.
Support and risk
Calendly includes vendor support in its paid plans, which you can compare against the internal or retained support you would need for Cal.diy. The Cal.diy README recommends it for personal, non-production use and directs commercial and enterprise scheduling users to Cal.com. Teams, routing and SSO are not in Cal.diy, so if you need them, the cost moves to a different product. Ask any provider for a written statement of what support, uptime commitment and security responsibility they accept.
What moving personal booking pages from Calendly involves
The sequence turns Calendly personal booking pages into a self-hosted Cal.diy instance that your team tests, connects to its calendars, and points your public links at, with a clear decision made on the team features Cal.diy does not provide.
Inventory event types and availability
Start by listing every Calendly event type, its duration, location, buffers, questions asked of invitees, and the weekly availability and date overrides attached to it. Note which calendars each host checks for conflicts and which links, email signatures and website widgets point to each booking page. The output is a single inventory sheet that you can check off during the rebuild. Confirm with each host whether any event type depends on routing, team pools or payments, because those features are handled differently or not at all in Cal.diy.
Stand up Cal.diy on a pilot server
Deploy Cal.diy on a non-production server in your own infrastructure, using the published Docker image or a Node.js build, with PostgreSQL 13 or later as the database. The project's README is explicit that self-hosting is at your own risk and strongly recommended for personal, non-production use, so treat this instance as a pilot until your team has confirmed the operational and security controls it needs. The step is complete when a test user can sign in, and the database, secrets and TLS settings are documented by the person who will run the service.
Connect Google or Microsoft 365 calendars
From the Settings and Integrations pages, connect each host's Google Calendar or Microsoft Graph (Office 365) calendar. This requires creating OAuth credentials in the relevant provider's developer console and registering the redirect URL of your instance, which is the part most likely to need your identity or cloud team. Confirm that busy times from every connected calendar block slots, and that new events appear on the correct calendar. The step is done when a test booking shows up on the host's calendar and an existing meeting blocks the matching slot.
Connect Zoom and other conferencing tools
Add the conferencing integrations your hosts use, such as Zoom, from the same integrations area, and confirm the account type and permissions each one requires. Decide whether meeting links should be generated automatically for each event type or entered manually for particular types. The check is that a test booking produces a working meeting link in the invitation and on the host's calendar entry. Where a tool your hosts rely on is not in the documented list, record it as a gap to resolve before cutover rather than assuming it works.
Recreate event types and test invitee flows
Rebuild each event type from your inventory, including duration, buffers, location, invitee questions, reminders and confirmation messages. Then run an end-to-end test as an invitee on a desktop and a phone: pick a slot, confirm, receive the email, reschedule and cancel. Compare each result with the Calendly version you recorded, and fix any difference in wording, time zone handling or calendar blocking. The step is complete when every event type has a signed-off test booking and each host has reviewed their own confirmation emails.
Replace links on websites and email signatures
Update the booking links on your website, email signatures, proposals, and any third-party tools that embed a Calendly widget or link. Keep the Calendly page active during this period so that links already sent to clients still work. Remove or redirect the old links only after you have checked each place where they appeared, because some are hard to find in older documents and automated sequences. The step is done when a sample of published pages and signatures resolves to the Cal.diy booking page.
Decide on team routing and SSO
Cal.diy removes the Teams, Organizations, routing workflows and SSO features that Cal.com reserves for its commercial editions, so any Calendly team routing, round-robin assignment or single sign-on requirement needs an explicit decision. Options include keeping these workflows on Calendly for teams that need them, moving team scheduling to a different self-hosted tool, or asking Cal.com for its commercial options if your organization needs them. Confirm the decision with your security and procurement leads and record it, because it determines whether the personal Cal.diy migration can be completed on its own.
Cut over and retire the Calendly account
Once test bookings, calendar blocking and links are verified, announce the cutover to the people who book with your hosts, and keep the Calendly account available for a short overlap period you set with your team. Export the meeting history and contact data you need for your records before you cancel any subscription. The sibling migration page covers the exact export steps. The step is complete when bookings flow through Cal.diy only and the export is stored under your retention policy.
Questions buyers ask before choosing Cal.diy
Can Cal.diy replace Calendly for a whole team?
Not as a direct swap. Cal.diy is the MIT-licensed fork of Cal.com with enterprise code removed, and its removed features include Teams, Organizations, Workflows, SSO and SAML. Calendly's Standard and Teams plans rely on per-user scheduling, routing and integrations that Cal.diy does not provide in the same form. Individuals who need personal booking pages, event types and Google or Microsoft calendar connections are the natural fit. Teams with shared routing or central admin should map each Calendly feature they use and confirm the gap with the Cal.diy repository and Cal.com sales before planning the move.
What does running Cal.diy cost compared with Calendly's per-seat plans?
Calendly bills per seat: the pricing page lists Standard at $10 and Teams at $16 per seat per month billed yearly, with Enterprise starting at $15k per year and a 50-seat minimum. Cal.diy has no license fee, so your cost is the server, database, backups, domain, email delivery and the time to maintain it, plus any calendar API setup. Those costs recur and scale with hosting and staff time rather than seat count. Ask any vendor or partner for a written quote that separates one-time setup from recurring hosting and maintenance, and compare it with your own Calendly invoices for the same number of users.
How much time and skill does self-hosting Cal.diy need?
The Cal.diy README says self-hosting requires advanced knowledge of server administration, database management and securing sensitive data. The stack is Next.js, tRPC, React, Tailwind CSS and Prisma, which needs Node.js 18 or later and PostgreSQL 13 or later, and the project publishes a Docker image on Docker Hub. Someone must own upgrades, certificates, backups, database patching and monitoring. Before committing, confirm which of these your team already runs and how many hours a month the on-call owner can give, since the repository does not state an effort figure.
Is Cal.diy safe to use in production?
The Cal.diy README says self-hosting is at your own risk and strictly recommended for personal, non-production use. That is the maintainers' stated position and should set your expectations. Business or customer-facing scheduling is directed to Cal.com, which offers hosted plans and enterprise on-premises access through sales. If you still want to run Cal.diy for a business workload, document the risk acceptance, test restores, harden the server and check the release status of the repository, where the latest release listed is v6.2.0 published on March 1, 2026.
Does Cal.diy include SSO, routing or team workflows?
No. Cal.diy removes SSO and SAML along with Teams, Organizations, Insights and Workflows, which were enterprise-only in Cal.com. Calendly's routing and enterprise controls therefore have no direct equivalent in Cal.diy. If you need single sign-on or team routing, the paid Cal.com Organizations plan lists SAML SSO and SCIM at $28 per user per month on yearly billing, and Enterprise is priced custom. Confirm current feature lists directly with Cal.com before you decide, because these terms change.
Which calendar and video integrations does Cal.diy support?
The README documents Google Calendar, Microsoft Graph for Office 365, Zoom, Daily.co, Webex, HubSpot, Zoho and Pipedrive. You add them from the Settings, Integrations page, and each one needs its own credentials from the provider. Verify the exact OAuth scopes, token storage and redirect URLs for your domain during testing, because calendar connections are where most setup problems appear.
When should we bring in DeployOpen for Cal.diy?
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. It is a good fit when you want a production-grade deployment, a documented backup and restore plan, or help moving existing Calendly event types. DeployOpen does not publish prices, so a quote follows from the written scope.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. For a Calendly to Cal.diy decision, that usually starts with an evaluation of what you actually use: personal booking pages and event types, the Google or Microsoft 365 calendars behind them, and whether any team scheduling, routing or SSO depends on features Cal.diy does not include. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.
Implementation work typically covers the database and application stack (Cal.diy is built on Node.js and PostgreSQL), the calendar integrations configured from the Settings, Integrations page, the hardening of the server and its administrative access, backups, and the documentation your team needs to operate the service after handover. Because the Cal.diy README describes self-hosting as suitable for personal, non-production use and requires server administration and database skills, the question to settle early is who will patch, back up and monitor the instance once it is live. DeployOpen can run that work under a retainer for ongoing support, upgrades and continuous testing, or hand it to your own team with documentation. Ask for the retainer terms and the upgrade approach in writing, not just the one-time install.
Where your organization needs compliance evidence, DeployOpen prepares the systems, controls and records that an assessor will review, such as configuration baselines, access logs and backup test results. It does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, so confirm with your assessor which evidence they expect before the work is scoped. If your review concludes that Cal.diy is not suitable for production booking, DeployOpen can also scope a plan for a different self-hosted option, and that evaluation is useful to document either way.
