Cal.diy
The 100% MIT-licensed, community-driven scheduling platform — self-host your own booking infrastructure with no enterprise strings attached.
Cal.diy is the fully open-source, community-maintained fork of the Cal.com scheduling platform, with all commercial and enterprise-only code stripped out. It is designed for individuals and self-hosters who want a powerful, privacy-respecting booking system without depending on any vendor account, license key, or proprietary tier.
Every feature in Cal.diy works out of the box under the MIT license. There are no hidden EE-only gates, no call-home requirements, and no open-core split. You own your data, your branding, and your infrastructure — and the entire codebase is yours to read, modify, and redistribute freely.
Built on the T3 stack — Next.js 16, tRPC, Prisma, Tailwind CSS, and TypeScript — Cal.diy inherits a battle-tested monorepo architecture and a rich integration ecosystem. It connects to Google Calendar, Outlook, Daily.co for video calls, Stripe for payments, and dozens of other services through its modular app-store system.
Cal.diy ships with a Docker Compose setup for quick local development, a Prisma-managed PostgreSQL schema for reliable migrations, and a comprehensive test suite combining Vitest unit tests with Playwright end-to-end coverage. The community actively maintains it as an independent project, and contributions go directly into this repo rather than being gated behind a commercial roadmap.
What You Get
- Self-hostable booking platform - Run Cal.diy on your own server or VPS using Docker Compose; you control the data, the domain, and the deployment pipeline.
- Custom booking pages - Create personalized scheduling links with configurable availability windows, buffer times, and event durations that reflect your actual workflow.
- Calendar sync across providers - Connect Google Calendar, Apple Calendar, Outlook, and others so booked events appear in the right places without double-booking.
- Stripe payment integration - Collect payment at the time of booking for paid appointments, consultations, or coaching sessions directly through the booking flow.
- Video conferencing links - Automatically generate Daily.co, Zoom, or Google Meet links when a booking is confirmed, with no manual copy-pasting required.
- Routing forms - Route incoming booking requests to specific event types or team members based on answers to custom intake questions.
- Embeddable booking widget - Drop a React-based embed into any website or product so visitors can book without leaving your page.
- Webhook and API layer - Receive real-time booking events via webhooks and automate downstream workflows using the REST API.
- Availability schedules - Define complex recurring availability windows, date overrides, and minimum notice periods that the booking engine enforces automatically.
- 100% MIT-licensed codebase - Every file in the repository is under MIT; fork it, white-label it, or build a product on top without any legal ambiguity.
Common Use Cases
- Solo consultant booking page - A freelance designer sets up Cal.diy on a $5 VPS to let clients book 60-minute project discovery calls with automatic Stripe deposits and Daily.co video links.
- Privacy-first enterprise scheduling - A law firm deploys Cal.diy inside their private cloud so client meeting data never leaves their jurisdiction, satisfying data residency requirements Calendly cannot meet.
- White-label booking product - A SaaS developer forks Cal.diy and ships a branded scheduling feature to their own customers, making full use of the MIT license to distribute the product commercially.
- Developer portfolio scheduling - A job-seeking engineer runs Cal.diy locally and embeds the widget on their portfolio site so recruiters can book coffee chats without email back-and-forth.
- Community project contribution - An open-source contributor patches a scheduling edge case, opens a PR directly to cal.diy, and sees it merged without needing a Cal.com corporate account.
Under The Hood
Architecture Cal.diy uses a Turborepo-based monorepo that cleanly separates the Next.js frontend application, a versioned REST API app, shared feature packages, a Prisma database layer, and a modular app-store for third-party integrations. The web application mixes Next.js App Router server components with a tRPC layer that enforces end-to-end type safety from the database schema all the way to the React client. Business logic lives in discrete feature packages — bookings, calendars, availability, webhooks — rather than inside the web app itself, making the core schedulable independently of any UI framework. Redis handles session caching and distributed locks, while Trigger.dev manages background jobs such as reminder workflows and async email delivery.
Tech Stack The platform is built on Next.js 16 with React 18, backed by Prisma ORM against PostgreSQL and a Kysely query-builder layer generated directly from the Prisma schema for performance-sensitive queries. tRPC v11 provides the primary RPC layer with Zod schemas for runtime validation on every procedure. Tailwind CSS v3 handles styling with a shared design-system package. The test suite combines Vitest for unit and integration tests with Playwright for full end-to-end browser automation across the booking flow. Infrastructure-wise, the project ships a Docker Compose configuration with Postgres, Redis, and the application container, as well as a Procfile for Heroku-style deployments.
Code Quality The codebase enforces strong TypeScript throughout, with Zod schemas validating all tRPC procedure inputs and Prisma-generated types flowing into Kysely and application code without manual duplication. Biome serves as the unified linter and formatter across the entire monorepo, eliminating disagreements between ESLint and Prettier configurations. Tests use Vitest with extensive vi.mock() isolation to keep unit tests deterministic and fast, while Playwright e2e tests cover critical booking and authentication flows in a real browser. Error handling is explicit — HTTP errors, tRPC errors, and calendar-provider errors all have typed wrappers. The modular app-store architecture means adding or removing an integration does not touch the core booking engine.
What Makes It Unique Cal.diy’s most distinctive property is its commitment to being the only scheduling platform of this caliber that is fully MIT-licensed with no enterprise tier or open-core split — a deliberate departure from the original Cal.com, which moved commercial features behind a proprietary layer. The modular app-store treats every calendar provider, video conferencing tool, and payment processor as a plug-in with a consistent credential-management and OAuth interface, meaning the integration surface grows without bloating the core. The routing forms feature routes booking requests through conditional logic to different event types or hosts, which is unusual at the open-source level. The tRPC-plus-Zod combination provides the kind of compile-time API safety normally only found in generated GraphQL clients, but without a schema compilation step.
Self-Hosting
Cal.diy is released under the MIT License, which is one of the most permissive software licenses available. You may use it commercially, modify it, distribute it, and sublicense it — including in closed-source products — with no copyleft obligations. The only requirement is that the MIT copyright notice is included with any distribution of the software. There is no separate enterprise edition, no license key to purchase, and no code that is gated behind a paid tier. This is a deliberate design decision that distinguishes Cal.diy from its upstream parent, Cal.com, which now keeps commercial features proprietary.
Running Cal.diy yourself means you are responsible for the full operational stack: a PostgreSQL database with regular backups, a Redis instance for sessions and distributed locks, a Node.js host capable of running the Next.js application, and environment configuration for every integration you enable (Google OAuth credentials, Stripe keys, SMTP settings, and so on). The project ships a Docker Compose file that handles the database and Redis containers for development, but a production deployment requires you to set up SSL termination, a process manager, log aggregation, and a database backup strategy independently. The README explicitly warns that the project is intended for users comfortable with server administration, database management, and securing sensitive data.
Because Cal.diy explicitly removes the enterprise features that exist in Cal.com — including Teams, Organizations, SSO/SAML, booking insights dashboards, and workflow automation — you trade organizational management capabilities for full MIT freedom. Cal.com’s hosted service and its on-premise enterprise tier offer managed upgrades, SLAs, dedicated support, and the features that have been stripped from this fork. If you need those capabilities, the README directs you to Cal.com’s sales channel. For solo users and small teams who only need individual scheduling pages, calendar sync, and basic integrations, Cal.diy covers the use case completely while keeping every byte of code auditable and modifiable.