Cal.com capability without the enterprise layer
Cal.diy is not a small calendar widget. It descends from Cal.com and retains a large scheduling application built with Next.js, React, tRPC, Prisma, PostgreSQL, Tailwind CSS, and an app-store model for integrations. Users can publish booking pages, define event types and availability, connect calendars, and add conferencing or business services through credentials they control. The attraction is clear: the whole community edition is MIT-licensed and requires no Cal.com account or license key.
The fork also draws a sharp boundary. Teams, Organizations, Insights, Workflows, SSO/SAML, and other enterprise-only features have been removed. There is no managed Cal.diy service. Most importantly, the README says to use it at your own risk and strictly recommends it for personal, non-production use. Commercial users are directed to hosted Cal.com or its enterprise on-premises offer.
That warning is not decorative legal text. Scheduling systems sit between public visitors, personal calendars, email, video providers, and often payments. A missed booking, broken OAuth callback, leaked database, or failed reminder has a real cost. Cal.diy gives an experienced operator the code and deployment pieces, but it does not promise the operational safety net a business buyer expects.
A friendly local start hides a large system
For development, the easiest command is yarn dx. It requires Docker and Compose, starts PostgreSQL, seeds several test accounts, and prints their credentials. The manual path needs Node.js 18 or newer, PostgreSQL 13 or newer, Yarn, two generated secrets, a database URL, Prisma migrations, and optional MailHog for email testing. Windows users get separate instructions for Git symlinks and environment handling.
The Docker Compose route is approachable on paper: clone recursively, copy the example environment file, generate NEXTAUTH_SECRET and the 32-byte encryption key, then start the stack. It can include PostgreSQL and Prisma Studio, and a first-run wizard creates the initial user. The README even explains how to skip the apparently required calendar step by navigating directly to the event-types page.
Public deployment is where the work multiplies. The application distinguishes settings needed while building from those supplied at runtime. Public URLs can be embedded in frontend assets, authentication must agree with the external domain, and push notifications need VAPID keys. A reverse proxy and TLS are still your job. SMTP, monitoring, backups, database upgrades, and recovery are not supplied by a Compose command.
Several open reports make this risk concrete. One describes an official image retaining a localhost public URL and sending login flows to the wrong place. Another reports an Outlook OAuth loop despite apparently correct runtime variables because the built URL remained localhost. A separate issue says the Docker Hub image named in the documentation was missing. These are user reports, not proof that every current image fails, but they justify testing the exact tag and domain configuration before migrating a real booking link.
Integrations are powerful and expensive to own
Calendar integration is the reason to run a scheduler instead of a static contact form. Cal.diy documents Google Calendar and Microsoft Graph credentials, along with Zoom, Daily, Basecamp, HubSpot, Webex, Zoho, Pipedrive, and other services. Each useful connection means creating an application with the provider, choosing scopes, protecting a client secret, and registering exact callback URLs. Providers can change their review rules and APIs independently of Cal.diy.
It is a poor fit for someone who wants every integration to work simply because its logo appears in the interface. The operator owns credential rotation and must verify that bookings create the expected remote event. An open v6.2 report says Google Meet links disappeared from booking metadata while the same setup worked on v6.1.16. Pin versions, rehearse upgrades, and test calendar and video creation end to end.
The stripped enterprise scope matters here too. A solo consultant may only need one user's event types, calendar connections, and booking pages. A company quickly asks for centralized teams, organization policy, SSO, reporting, and workflow automation, precisely the areas the README says were removed. Rebuilding them locally defeats the appeal of choosing a ready-made scheduler.
The codebase is active, but the queue is enormous
The last push was August 8, 2026, and issues and pull requests were still receiving updates on August 12. Stable v6.2.0 arrived on March 1 after a rapid run of v6.1 patch releases in January and February. A release tag being several months old does not indicate abandonment when code and issue activity remain current.
The scale of the queue is harder to dismiss. GitHub reported 1,402 open issues and pull requests, broken out by search as 1,107 issues and 295 pull requests. Much of that history comes from the large Cal.com lineage, and many entries concern features outside a personal installation. Even so, it makes issue discovery and upgrade assessment demanding. The activity is vigorous, but users must identify which fixes actually apply to Cal.diy and which old Cal.com assumptions no longer fit the fork.
Documentation is broad, covering local development, Docker, database migrations, upgrades, several deployment providers, content security policy, rate limiting, and many integrations. It also carries legacy names and a long accumulation of special cases. Read the environment-variable tables rather than copying a random Compose example from an issue or older guide.
A good personal project, a risky business dependency
Cal.diy's clean licensing and deep feature base are valuable. It lets a capable developer inspect every scheduling decision, keep data on chosen infrastructure, and modify behavior without an enterprise-code boundary. Few personal projects need this much application, but few alternatives offer as much source to work with.
The correct buying decision follows the README's warning. Use Cal.diy for a personal instance, a development lab, or as source material for a project whose team accepts full maintenance responsibility. Do not quietly turn that experiment into a production dependency because the booking screen looks polished. For revenue-critical scheduling, pay for an operated product or choose a smaller self-hosted system whose feature set and failure modes you can realistically own.