Overview

Purpose and Scope

Cal.diy is the community-driven, fully open-source scheduling platform for people who want to run their own scheduling infrastructure. The repository positions it as a fork of Cal.com with enterprise and commercial code removed, rather than as a managed hosted product. That distinction matters for readers because the project is about operating an instance yourself: installing dependencies, managing a database, configuring integrations, securing secrets, and keeping the deployment current. This overview is the front door for those tasks. It explains what Cal.diy is, what responsibilities come with using it, where the main repository entry points live, and how the rest of this OpenWiki is organized for self-hosters and contributors.

Sources: README.md, apps/docs/content/index.mdx, package.json

The README describes Cal.diy as a scheduling platform built for individuals and self-hosters who want control without commercial dependencies. It also states that the codebase is MIT licensed and that there is no hosted or managed Cal.diy version. In practical terms, Cal.diy gives you application code and operational building blocks, but it does not remove the need to understand web deployment. You are expected to provide infrastructure, configure services, and choose whether to run from source, with Docker, or through a cloud deployment pattern. The rest of the documentation should be read with that operational ownership in mind.

Warning Scope and Intended Audience

The strongest reader-facing signal in both the README and the documentation index is the warning to use Cal.diy at your own risk. The project is described as the open source community edition of Cal.com, intended for users who want to self-host their own instance, and strictly recommended for personal, non-production use. That warning is not decorative. It frames the whole project as a do-it-yourself system where server administration, database management, secret handling, and security hardening are the operator's responsibility. If you are evaluating Cal.diy for a hobby deployment, lab environment, or personal calendar workflow, the documentation path is appropriate. If you are evaluating scheduling infrastructure for a company, the docs explicitly direct commercial and enterprise use toward Cal.com.

Sources: README.md, apps/docs/content/index.mdx

This scope affects how you should interpret feature lists and setup guides. Cal.diy includes core scheduling capabilities, integrations, and source packages, but the README calls out that enterprise-only concepts such as teams, organizations, insights, workflows, SSO or SAML, and other commercial features have been removed. The docs index reinforces that Cal.com is the commercial application and that Cal.diy is community maintained. When a guide later discusses deployment, upgrades, apps, or database migrations, it is documenting an operator-managed community edition rather than a supported hosted service. The safest mental model is to treat Cal.diy as software you own and operate, not as a turnkey SaaS substitute.

Relevant Source Files

README.md — introduces the repository, the risk warning, the project identity, the Cal.diy versus Cal.com positioning, basic prerequisites, and the technologies used by the application.
apps/docs/content/index.mdx — provides the first-party self-hosting documentation homepage, including the warning callouts, getting-started links, deployment links, and feature-difference framing.
package.json — defines the monorepo workspace boundaries and top-level scripts that act as repository entry points for building, developing, starting, database operations, app-store tooling, embeds, linting, formatting, and tests.

Repository Entry Points

The repository entry points begin with the root README for product context and the root package file for contributor and operator commands. The package manifest declares a private monorepo named calcom-monorepo and lists workspaces across apps, API apps, packages, embedded packages, feature packages, app-store packages, platform packages, and example applications. That workspace list is a map of how the codebase is divided: application surfaces live under app workspaces, reusable implementation lives under package workspaces, integrations live under app-store areas, and platform atoms and examples have their own package scope. Readers who are new to the repository should use the package manifest as the source of truth for how Yarn and Turbo address each subsystem.

Sources: package.json, README.md

The most important scripts show the common operational and development flows. The root build script runs a Turbo build filtered to the web application, while the root start script starts the web workspace. Development scripts focus on the web app by default and expand to API proxy, console, website, swagger, AI, or trigger workers when a task needs those services. Database tasks are exposed through scripts for deploy, seed, and Prisma Studio. The app-store scripts provide commands for creating, editing, deleting, watching, and templating app integrations. Embed publishing has its own script path, and testing entry points cover unit-style watch mode, Playwright end-to-end runs, app-store tests, and embed tests. These scripts are not just conveniences; they reveal the repository's main operational seams.

Core Primitives

At a high level, Cal.diy is composed of a web scheduling application, a database layer, integration packages, platform and embed surfaces, shared UI and configuration packages, and documentation. The README names the primary technology stack as Next.js, tRPC, React, Tailwind CSS, Prisma, and Daily.co. For a self-hoster, those names translate into a few practical primitives: a Next.js web application serves the product, Prisma connects the application to PostgreSQL, tRPC provides typed internal API flows, React and Tailwind shape the user interface, and integration packages connect external services such as calendars, video providers, payments, and communications. The package manifest then shows how those primitives are split into workspaces rather than kept in one flat application folder.

Sources: README.md, package.json

The basic runtime prerequisites in the README are Node.js version eighteen or newer, PostgreSQL version thirteen or newer, and Yarn as the recommended package manager. Those prerequisites match the monorepo script model: package scripts assume a Yarn workspace environment and Turbo is used to run tasks across filtered packages. PostgreSQL is not optional for a real instance because scheduling data, users, bookings, event types, credentials, and configuration need persistent storage. Integrations add another layer of responsibility because enabling providers usually means creating credentials outside Cal.diy, storing secrets locally or in deployment infrastructure, and matching redirect URLs to the instance's public address. Later pages in this wiki expand each of those areas instead of treating installation as a single command.

Documentation Map

The first-party documentation index organizes the self-hosting journey into getting started, deployments, and differences from Cal.com. The getting-started group points readers to installation, database migrations, upgrading, Docker, and apps. That is a sensible order for most operators: first learn how the application is installed, then understand how schema changes are managed, then learn the upgrade path, then decide whether Docker is a better packaging model, and finally configure third-party integrations. The OpenWiki mirrors that spine with pages for installation requirements, production build and local setup, API server setup, cron jobs and app-store seeding, upgrading, Docker configuration, database migrations, environment URLs, reverse proxies, and troubleshooting.

Sources: apps/docs/content/index.mdx

Deployment documentation is grouped by platform because the operational work changes depending on where the instance runs. The index lists AWS, Azure, Elestio, Google Cloud, Northflank, Railway, Render, and Vercel. In this OpenWiki, those deployment pages are separated so readers can focus on the platform they are actually using rather than mixing cloud-specific steps. The repository also contains deeper developer-oriented surfaces that are outside the first quick-start path, including API v2, embeds, platform atoms, app-store tooling, email templates, UI packages, shared configuration, internationalization, and testing. Those pages are most useful after an operator has a running instance or when a contributor is trying to extend Cal.diy rather than merely deploy it.

Cal.diy Compared with Cal.com

The documentation index includes a summarized feature comparison that begins with scheduling and booking capabilities. It indicates that common booking primitives such as event types, recurring event types, seated events, paid events, private links, booking management, availability schedules, date overrides, buffer times, notice limits, and travel schedules are part of the shared scheduling foundation. It also marks team and organization-oriented capabilities as Cal.com features rather than Cal.diy features. The README states the same distinction more directly: Cal.diy removes enterprise and commercial code and has no license key requirement. For readers, the practical conclusion is to check whether the workflow depends on personal scheduling primitives or on organization-scale administration before choosing Cal.diy.

Sources: README.md, apps/docs/content/index.mdx

This distinction is also important when reading older Cal.com knowledge or examples. Because Cal.diy was spun out of Cal.com, some architecture and technology choices remain familiar, but product expectations should not be copied blindly from the hosted commercial service. A self-hosted Cal.diy instance does not come with managed uptime, managed security, hosted support, or enterprise access controls. It is better to start from the Cal.diy docs index and repository scripts, then use code-level pages in this wiki to inspect the actual package surfaces present here. When a feature depends on removed enterprise concepts, the safest assumption is that it should not be expected unless the Cal.diy sources and docs explicitly support it.

Overview

Purpose and Scope

Warning Scope and Intended Audience

Relevant Source Files

Repository Entry Points

Core Primitives

Documentation Map

Cal.diy Compared with Cal.com

Suggested Reading Path