Choose Doodle or Cal.diy for booking pages: when each fits
Doodle fits teams that want a hosted booking service with Team features and little operating work. Cal.diy fits teams that have server administration skills and want booking pages and calendar links served from their own infrastructure. The decision turns on three questions: whether the booking workload is production-critical, which Team features the organization relies on, and who will run the instance day to day. Start with the third question, because it sets the real cost. Cal.diy's README says self-hosting is at your own risk, strictly recommended for personal, non-production use, and requires advanced knowledge of server administration, database management and securing sensitive data. If no named person owns patching, backups and the database, a hosted service is the safer default.
Cal.diy removes the Teams, Organizations, Insights, Workflows, SSO and SAML features that Cal.com reserves for paid tiers, so it does not replicate Doodle's Team or Enterprise administration. Doodle's Team plan and Enterprise plan add capabilities such as SSO over SAML or OIDC on Enterprise, and admin controls that a single-user or personal deployment does not provide. Before you commit, list every Team feature your staff use, such as shared team booking pages, central admin management and single sign-on, and confirm each one against the Cal.diy README and the current Doodle premium page. Any feature that does not appear in the README should be treated as missing until you test it in a staging instance.
Cal.diy's README directs commercial and enterprise scheduling users to Cal.com, and enterprise on-premises access goes through Cal.com sales. If your booking workload is customer-facing, revenue-linked or subject to uptime commitments, ask Cal.com whether its hosted or licensed options fit before you take on the operating burden yourself. If the workload is internal 1:1s and a small set of personal booking pages, a self-hosted Cal.diy instance may fit, provided you test calendar connections (Google Calendar, Microsoft Graph, Zoom, Daily.co, Webex) and budget for ongoing patching of its Node.js, PostgreSQL and Prisma stack.
Which option fits which scenario
This table matches five common situations to the better fit between Cal.diy and Doodle's paid team plans. Read each row against your own headcount, data rules and support needs, then check the reason column before choosing. The main takeaway is that Cal.diy suits personal or lightly shared booking pages run by a team that can administer its own server, while commercial and enterprise needs point toward Cal.com or Doodle.
| Scenario | Better fit | Why |
|---|---|---|
| A solo consultant with personal event types | Cal.diy | Personal event types, calendar connections and video integrations cover one person's booking page. The README recommends self-hosting for personal, non-production use, so a single operator who accepts that risk fits the design. |
| A team needing shared booking pages with admin controls | Doodle Team or Cal.com Teams | Cal.diy removes Teams and Organizations features, so shared pages with central admin control fall outside its scope. Confirm current plan contents on each vendor's pricing page before deciding. |
| A regulated team that must keep invitee data on its own servers | Cal.diy, with a documented risk review | Self-hosting keeps calendars and invitee details inside your infrastructure. Cal.diy is not recommended for production by its maintainers, so the control, hardening and backup work falls on your team and needs formal sign-off. |
| A team without in-house server administration | Doodle or Cal.com hosted | Cal.diy requires advanced knowledge of server administration, database management and securing sensitive data. Without that skill, a hosted service or a implementation partner should carry the operating load. |
| A team that needs enterprise support | Cal.com (Organizations or Enterprise) or Doodle Enterprise | Cal.diy has no enterprise features such as SSO, SAML or SCIM, and the README directs commercial and enterprise users to Cal.com. Ask each vendor what support, SLA and on-premises options its contract includes. |
How the fit changes by environment
A personal laptop or single virtual machine is the setting the Cal.diy README has in mind. The project states that self-hosting is at your own risk and strictly recommended for personal, non-production use. Running it this way is a good way to learn the event types, calendar connections and video integrations before you commit to anything, because nobody else's invitee data needs protecting yet.
- Stack to install: Cal.diy is built with Next.js, Prisma and PostgreSQL 13 or later, and it requires Node.js 18 or later. A Docker image is published on Docker Hub if you prefer containers.
- Skills required: The README says self-hosting requires advanced knowledge of server administration and database management. A trial still needs someone who can rotate secrets and restore a database.
- What Doodle handles instead: Doodle's hosted free tier removes patching, backups and TLS from your task list, and it exposes one booking page on the free plan.
- Calendar connections: Test Google Calendar or Microsoft Graph (Office 365) against a test account, not a live executive calendar.
Before leaving the trial, confirm with the current README and the GitHub releases page which version you are testing, since the latest release is v6.2.0 as of March 1, 2026.
A small internal deployment used by a few staff is where the README's caveat matters most. The project does not present itself as production-supported for this use, so the organization owns every operational duty: uptime, upgrades, backups, monitoring and vulnerability response. Doodle's hosted model carries these duties for the vendor, which is the main trade-off to weigh.
- Operations ownership: Someone must own patching for Node.js, the database and the application, and watch the release notes for breaking changes.
- Database duties: PostgreSQL needs scheduled backups, tested restores and capacity planning as booking volume grows.
- Identity and access: Cal.diy removes SSO and SAML from the open code, so staff sign in with local accounts unless you add a separate identity layer. Confirm this with the README before you plan.
- Support path: Ask whether your internal team, a consultant or a retainer will answer when a booking fails at 8 a.m.
- Cost drivers: Hosting, storage, staff time and any retainer recur monthly, while setup is one-time. Doodle's per-seat fee is the recurring comparison point.
Ask your implementation partner for a written support scope before any staff depend on the instance.
In a regulated environment, the question shifts from whether Cal.diy works to whether your organization can evidence how it is operated. Cal.diy's own README directs commercial and enterprise scheduling users to Cal.com, and enterprise on-premises access is handled through Cal.com sales, so a regulated buyer should treat the community fork as a poor fit for production controls unless a qualified team takes responsibility for them.
- Enterprise features absent: Teams, Organizations, Insights, Workflows, SSO and SAML are removed from Cal.diy, so access control, audit visibility and centralized user management need compensating controls.
- Evidence: Auditors will ask for change records, backup tests, access reviews and vulnerability handling. DeployOpen prepares systems and evidence for assessments, but it does not issue audit reports or certifications, and independent auditors do.
- Data location: Hosted Cal.com offers US or EU hosting choices, while a self-hosted Cal.diy keeps invitee data on your own servers. Confirm which controls your regulator expects.
- Hosting options: Ask whether an enterprise license or on-premises arrangement from Cal.com fits the requirement better than running the fork.
- Vendor check: Doodle's Enterprise tier lists SSO over SAML or OIDC, so compare it against your identity requirements.
Confirm your regulator's expectations and the Cal.com enterprise terms in writing before choosing a deployment model.
What Cal.diy's personal event types and calendar connections replace
Cal.diy's personal event types replace the part of Doodle that most individuals use: a booking page where an invitee picks a slot from your availability and the meeting lands on both calendars. In Cal.diy, each event type holds a duration, a location (for example, a video link or a phone number), a booking link and its own rules, so one event type can stand in for each Doodle 1:1 link you currently share. Availability rules, such as working hours, buffers between meetings and the days you accept bookings, are the settings to map first. Before cutover, list every Doodle booking page and sign-up sheet in use, note which ones are simple 1:1 slots, and confirm that Cal.diy can express the same hours and buffers. Sign-up sheets for groups have no direct equivalent in this product and need a separate decision.
Calendar connections are where the open standards matter. Cal.diy reads busy time from connected calendars so that double bookings are avoided, and writes new bookings back to them. Google Calendar and Microsoft Graph (Office 365) are the documented connections, and the README also lists Zoom, Daily.co and Webex for video. Under the hood, calendar data is exchanged as iCalendar objects defined in RFC 5545, and servers that speak CalDAV, defined in RFC 4791, can share that data in a standard way. This is useful if your organization runs its own calendar server, but the connection path you choose changes what must be tested. Confirm each integration in your own environment before relying on it: test a booking end to end, check that the invitee receives a correct invite, confirm that cancellations and reschedules update both calendars, and verify that time zones and daylight saving changes behave as expected for your staff and invitees.
Where invitee data and calendars live under each option
Booking pages collect invitee names, email addresses, answers to intake questions and calendar free and busy data, so where that information is stored and who controls it decides much of the migration risk. The cards below compare Doodle's hosted model with a self-hosted Cal.diy deployment and name the duties that move to your team.
Where invitee records are stored
Doodle holds booking pages, invitee details and poll data on its own servers, so your records sit under its hosting, retention and sub-processor terms. A self-hosted Cal.diy instance keeps bookings, event types and invitee fields in a PostgreSQL database you operate, version 13 or later according to the README. Confirm which region and which database host will hold personal data before you choose a deployment site.
Identity and SSO scope
Doodle's Enterprise plan includes single sign-on over SAML or OIDC, and Cal.com places SAML SSO on its Organizations tier. Cal.diy removes SSO and SAML, so staff accounts on a self-hosted instance are local logins unless you add identity features another way. Ask your identity team whether a local-account model meets your access policy before any invitee or host data is moved.
Calendar connection tokens
Each host connects Google Calendar or Microsoft Graph accounts, and those connections store OAuth tokens that can read and write free and busy data. On a self-hosted deployment, the token store and the encryption key become your responsibility to protect and rotate. Document which accounts connect, who can revoke them, and how a departing host's connections are removed.
Evidence that compliance assessors need
Assessors will ask for evidence of access reviews, encryption settings, change records, logging of booking data access and vendor due diligence. DeployOpen can prepare the controls, configuration baselines and evidence packages for these reviews, but it does not issue audit reports, attestations or certifications. Only independent auditors and certification bodies can give those opinions, so agree the evidence list with your auditor first.
Backup and restore ownership
Under Doodle, the vendor runs backups and restores of your booking data, and you rely on exports for your own copies. With Cal.diy, your team owns database backups, restore tests and retention deletion of invitee records. Set a recovery objective with the business owner and test a restore on a schedule, because the README describes self-hosting as being at your own risk.
Administrator and access control ownership
Doodle's admin console and the Cal.com Organizations tier handle administrator roles and member management for you. On Cal.diy, your team defines who can administer the instance, reviews server and database access, and manages secrets for the Node.js and Prisma services. Confirm the access model with your security team and record who holds database credentials.
How the cost of a Cal.diy deployment compares with Doodle per-seat plans
Doodle charges per seat, while Cal.diy carries no license fee, so the comparison is between a recurring subscription and the cost of running the software yourself. The supplied pricing shows Doodle at USD 11 for Pro and USD 16 for Team per seat per month billed annually, with Enterprise starting at USD 15k and SSO over SAML or OIDC. Those figures scale with headcount. Cal.diy is MIT licensed, so the software itself is free, but the organization pays for everything around it: a server or cloud account, a PostgreSQL database (version 13 or later), outbound email, patching, backups, monitoring and the staff hours to keep booking pages working for invitees. Ask your team to estimate those components in its own environment before comparing totals with a Doodle renewal.
Some costs are one-time and others recur. One-time work includes the initial deployment, configuring the Google Calendar or Microsoft Graph connection, setting up Zoom or Daily.co video links, and testing event types and availability with real calendars. Recurring work includes hosting, database storage, certificate renewal, applying Cal.diy and Node.js updates, security patching, backup restore tests and answering user questions. Cost rises when you need high availability, more environments for staging, a larger number of connected calendars, or a support contract with an outside provider. The README says self-hosting is at your own risk and requires advanced server administration, database management and data security skills, so the labor line is usually the largest unknown. Cal.diy is also not positioned for production use by its own README, which means a team that needs production-grade booking may face a different cost decision than the licence comparison suggests.
When requesting a quote from an implementation partner, ask for a fixed-scope breakdown that separates one-time deployment, integration and testing from monthly or annual hosting, patching and support. Ask which Cal.diy version and release process the quote assumes, how upgrades are tested before they reach users, who owns backups and restore testing, and what happens when a calendar provider changes its API. Ask for the number of event types, calendars and users in scope, and whether pricing includes a retainer for ongoing support. Also confirm which Doodle features your team actually uses, because Doodle Team and Enterprise plans include capabilities that a Cal.diy deployment does not replace. Compare the two totals over the same period and include the staff time for both options.
What moving booking pages from Doodle to Cal.diy involves
The sequence moves Doodle booking pages and 1:1 links onto a self-hosted Cal.diy instance that your team tests before any invitee is sent a new link. The output is a verified, non-production setup and a documented cutover plan.
Confirm scope and hosting environment
List every Doodle booking page, 1:1 link and sign-up sheet in use, along with the calendars, video tools and invitee groups behind each one. Decide where the instance will run and who administers it, since the Cal.diy README says self-hosting requires advanced knowledge of server administration, database management and securing sensitive data. Confirm with your security team whether a non-production setup is acceptable for the first phase, because the README strictly recommends Cal.diy for personal, non-production use. The step is done when you have a written inventory and a named owner for the instance.
Archive Doodle booking and 1:1 records by hand
Doodle's data export is limited, so do not assume a full export will cover booking pages, 1:1 settings or sign-up sheet records. Check which plan your account is on and what it lets you download, then copy booking page titles, durations, availability rules, questions asked of invitees and confirmation text into your own archive. Save screenshots or PDFs of any page whose configuration you cannot export. The step is done when every item in the inventory has an archived copy stored in a location you control.
Deploy Cal.diy with PostgreSQL in a non-production setting
Deploy Cal.diy from the calcom/cal.com repository or its Docker image, with PostgreSQL 13 or later and Node.js 18 or later for source builds. Keep the instance on a separate hostname and keep it off the production calendar links that invitees already use. Confirm the release you install against the latest release notes before you start, since the most recent release listed is v6.2.0. The step is done when the instance starts, the administrator can sign in, and the database backup routine has been tested once.
Reconnect calendars and video tools
From the Settings and Integrations page, connect each calendar account that holds availability, such as Google Calendar or Microsoft Graph for Office 365. Then connect the video services your meetings use, such as Zoom, Daily.co or Webex, and confirm each connection creates a meeting link on a test booking. Check that busy times from every connected calendar block slots as expected. The step is done when a test event shows correct free and busy times and a working video link.
Recreate event types from the archive
Rebuild each Doodle booking page and 1:1 as a Cal.diy event type using the archived settings: duration, buffers, availability windows, booking questions and confirmation text. Assign the right calendars and video integration to each event type. Keep a mapping sheet that pairs each old Doodle link with its new Cal.diy link. The step is done when every inventory item has a matching event type and the mapping sheet is complete.
Test invitee flows end to end
Book each event type from an outside account that is not signed in to your organization, and check the confirmation email, calendar invitation, reminders, rescheduling and cancellation. Test from more than one browser and mobile device, and confirm invitee time zones display correctly. Ask a small group of colleagues who regularly use Doodle to run the same bookings and record any confusion. The step is done when each flow passes and the test results are recorded with the fixes applied.
Cut over links and communicate the change
Publish the new Cal.diy links and update signatures, website pages, calendar invitations and documents that point to Doodle. Keep the old Doodle pages reachable for a period you agree internally, and tell regular invitees where the new link lives. Monitor the first live bookings for failures in calendar sync or invitation delivery. The step is done when all known references point to Cal.diy and no live bookings fail for an open period you agreed.
Retire the Doodle plan
Once the cutover is stable and your archive is verified, cancel or downgrade the Doodle subscription and confirm the billing change in writing. Remove stored Doodle connections to calendars and remove team members who no longer need access. Keep the archive and the mapping sheet under your normal records policy. The step is done when the Doodle subscription status is confirmed and the archive is stored where your records team can find it.
Questions buyers ask before switching from Doodle to Cal.diy
Can Cal.diy run in production for our booking pages?
Not as the project presents it. The Cal.diy README says self-hosting is at your own risk and strictly recommended for personal, non-production use. It also states that running it requires advanced knowledge of server administration, database management and securing sensitive data. If your booking pages carry live client or employee traffic, treat Cal.diy as a candidate for a pilot or internal use case, and confirm the maintainers' current guidance before you commit. Organizations that need a supported production path are directed by the same README to Cal.com, with enterprise on-premises access handled through Cal.com sales.
What does our team need in place to run Cal.diy?
Cal.diy is built with Next.js, tRPC, React, Tailwind CSS and Prisma. It requires Node.js 18 or later and PostgreSQL 13 or later, and a Docker image is published on Docker Hub. Calendar connections use Google Calendar or Microsoft Graph for Office 365, and video links can come from Zoom, Daily.co or Webex. You will need people who can operate a web application, back up PostgreSQL, manage TLS and secrets, and apply upgrades. Confirm who owns each of those tasks before the pilot starts, because the README places that responsibility on the operator.
How long does a move from Doodle to Cal.diy take?
No duration is published for this move, so treat any number you hear as an estimate to verify. The timeline depends on how many booking pages and event types you run, how many calendars and video accounts you connect, whether you migrate historical bookings or only start fresh, and how much of the work your own staff can absorb. Ask for a written scope that lists each event type, each integration and the cutover steps, then compare the schedule against those items rather than a general figure.
Can we run the migration without outside help?
Possibly, if you have an engineer comfortable with Node.js, PostgreSQL and container operations, and someone who owns the booking configuration. The fork removes enterprise features, so the setup is simpler than a full Cal.com deployment, but it still needs hardening, backup testing and monitoring. Many teams choose a fixed-scope implementation for the initial build and then a retainer for upgrades. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts.
Which cost components should we ask for in a quote?
Ask for each component separately so you can compare it with your Doodle spend. Doodle bills per seat, with Pro at USD 11 and Team at USD 16 per seat per month billed annually, according to Doodle's premium page as read in October 2026. For Cal.diy, the recurring items are server hosting, PostgreSQL, backups, monitoring, email delivery, staff time for upgrades and any video or calendar provider accounts you already pay for. The one-time items are initial setup, integration configuration, hardening and documentation. Request line items for each, plus the upgrade and support model after launch.
Which Doodle Team features does Cal.diy leave out?
Cal.diy removes the Teams, Organizations, Insights, Workflows, SSO and SAML features that Cal.com treats as Enterprise-only. That means team-level scheduling, organization administration, reporting and single sign-on are not in the fork. Doodle's Team plan and Enterprise tier include administrative capabilities such as SSO over SAML or OIDC on Enterprise. Before you decide, list the Doodle Team features your admins use today, such as shared booking management, centralized user administration and reporting, and confirm with the project which of them are available in the version you plan to run.
When should we choose Cal.com instead of Cal.diy?
Choose Cal.com when you need team scheduling, organization controls, SSO or SCIM provisioning, or vendor-backed support for production use. Cal.com's hosted pricing, as read in October 2026, lists Free for one user, Teams at $12 and Organizations at $28 per user per month on yearly billing, with SAML SSO and SCIM on Organizations and US or EU hosting choices. Cal.com also offers custom Enterprise pricing. Cal.diy fits a narrower case, such as a technical team testing self-hosted booking for personal or internal non-production use. Compare the Cal.com quote against your Doodle Team cost and your own operating cost before deciding.
How DeployOpen helps evaluate, implement or migrate booking pages
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Doodle vs Cal.diy, that means deciding whether a self-hosted Cal.diy instance fits your booking pages, calendar connections and video integrations, and then building it in your cloud account, data center or air-gapped network.
How we scope
- Inventory the Doodle booking pages, 1:1 links and sign-up sheets your teams actually use today
- Map each feature to Cal.diy personal event types, calendar connections or video integrations, and flag gaps
- Record which Doodle Team or Enterprise features you need, such as SSO or admin controls, and confirm they sit outside Cal.diy
- Agree deliverables, scope and timelines in writing before any work starts, since engagements are fixed-scope
How we build
- Deploy Cal.diy with its documented stack of Node.js, PostgreSQL and Prisma inside your own environment
- Connect Google Calendar, Microsoft Graph, Zoom or other chosen integrations from the Settings, Integrations page and test each one
- Test booking flows, invitee notifications, time zone handling and access controls before users rely on them
- Document the architecture, data locations and hardening steps so your administrators can run the instance
How we hand over
- Hand over runbooks for server administration, database backups, upgrades and secret rotation
- Provide evidence of configuration and testing that your compliance or security reviewers can inspect
- Walk your administrators through creating event types, managing calendars and handling user offboarding
- Agree a cutover plan with your team, including how existing Doodle links are retired and communicated
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Track upstream Cal.diy releases and plan upgrades on a schedule agreed with your team
- Keep backups and restore procedures tested so booking data can be recovered if the server fails
- Confirm with us in writing which operational responsibilities stay with your team and which move to a retainer
