Self-Hosting Introduction

Purpose and Scope

Cal.diy is the community edition of Cal.com for people who want to operate their own scheduling instance. The repository README describes it as a community-driven, fully open-source scheduling platform and as a fork of Cal.com with enterprise and commercial code removed. That framing matters because the project is not presented as a managed service replacement. It is a self-hosted application that you run, configure, secure, and maintain on your own infrastructure. The intended reader is therefore a self-hoster or contributor who wants control over the scheduling stack rather than a buyer looking for hosted commercial scheduling infrastructure.

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

The most important operational boundary is the warning repeated in both the README and the documentation index: use Cal.diy at your own risk, and treat it as personal, non-production software unless you are prepared to accept the responsibilities of self-hosting. The docs explicitly say that self-hosting requires advanced knowledge of server administration, database management, and securing sensitive data. In practical terms, the operator owns runtime secrets, database availability, backups, upgrades, network exposure, and integration credentials. Cal.diy can be powerful for learning, personal scheduling, and community deployment experiments, but it is not documented as the recommended path for commercial or enterprise-ready scheduling.

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

Relevant Source Files

• README.md — Defines the project identity, cautionary warning, intended self-hosting audience, MIT and open-source positioning, high-level differences from Cal.com, prerequisites, and the repository’s contributor-facing entry point.
• apps/docs/content/index.mdx — Provides the first-party self-hosting documentation landing page, warning and important callouts, getting-started navigation, deployment navigation, and the summarized Cal.diy versus Cal.com feature comparison.

Intended Audience and Responsibilities

Cal.diy is best approached as do-it-yourself infrastructure. The README says there is no hosted or managed version and that you run it on your own infrastructure. That statement shifts the support model from a hosted SaaS experience to an operator model. You should expect to understand how a web application, a PostgreSQL database, environment variables, third-party OAuth credentials, and deployment networking fit together. The documentation index reinforces this by asking readers to review installation and configuration steps carefully before proceeding. If those responsibilities are unfamiliar, the safer route is to use the commercial Cal.com product or build familiarity in a local, disposable environment first.

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

The project is still useful for a broad set of non-commercial scenarios. Individual users can run a private scheduler, developers can inspect how a Cal.com-derived scheduling product is assembled, and community maintainers can contribute directly to the open-source edition. The README emphasizes that the codebase is MIT-licensed, has no proprietary enterprise edition split, and welcomes contributions into the project. That combination makes Cal.diy attractive for learning and customization. The caution is not that the application cannot function; it is that security, uptime, compliance, and maintenance guarantees are outside the promise of this community edition.

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

Getting-Started Path

The documentation index organizes the first tasks around installation, migrations, upgrading, Docker, and apps. That sequence is a useful mental model even if you later choose a specific cloud deployment guide. Start by understanding installation because it establishes the baseline application and database requirements. Then learn database migrations because schema state is a recurring maintenance concern for any long-running instance. Review upgrading before you rely on the instance, since self-hosted software needs a repeatable way to move forward. Docker is presented as a deployment path, while the apps section covers third-party integrations such as calendar, video, payment, and communication providers.

Sources: apps/docs/content/index.mdx

For a first pass, keep the deployment simple and reversible. A local or personal server installation lets you verify that the web application starts, the database is reachable, and the setup wizard can create the first user. After the base application works, add integrations one at a time instead of configuring every provider up front. This staged approach matches the caution in the docs: each integration may introduce secrets, callback URLs, and provider-specific settings. If something fails, a small configuration surface is easier to inspect than a deployment that combines database migrations, reverse proxy settings, OAuth apps, and payment webhooks all at once.

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

Differences from Cal.com

The docs distinguish Cal.com and Cal.diy by product role, support expectations, and feature scope. Cal.com is the commercial application running at app.cal.com and is described as battle-tested for large organizations. Cal.diy is the open-source community edition spun out of Cal.com, recommended for personal non-production use, and community maintained. The README adds that Cal.diy removes enterprise and commercial code, requires no license key, and has no Cal.com account dependency for unlocking an enterprise edition. Those distinctions help readers avoid assuming that every Cal.com feature, support path, or operational guarantee exists in the self-hosted edition.

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

The feature comparison in the documentation index shows that core scheduling capabilities remain, while organization-oriented commercial features are removed. Event types, recurring event types, seated events, paid events, private links, booking management, availability schedules, date overrides, buffer times, booking limits, and travel schedules are shown as available in both products in the provided portion of the table. By contrast, teams, team event types, managed event types, instant meeting, and organizations are marked unavailable for Cal.diy and available for Cal.com. When planning a self-hosted instance, validate the exact feature you need against the Cal.diy docs rather than assuming parity with the commercial service.

Sources: apps/docs/content/index.mdx

Practical Decision Checklist

Choose Cal.diy when you specifically want a community-maintained, fully open-source scheduling application, are comfortable with personal-use risk, and can administer the supporting infrastructure. Choose Cal.com when the requirement is commercial readiness, enterprise support, hosted reliability, organization features, or on-prem enterprise access. The README and docs both point commercial and enterprise use toward Cal.com rather than Cal.diy. That is not just marketing language; it is part of the project’s operating contract. The self-hosted edition gives control, but control also means responsibility for hardening, monitoring, incident response, and keeping dependencies current.

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

A sensible next step is to read the installation and Docker pages before provisioning anything permanent, then review database migrations and upgrading so you understand lifecycle maintenance. If your intended use depends on calendar, video, payment, CRM, email, or messaging providers, continue into the apps documentation after the base instance is healthy. If you are comparing hosting targets, use the deployment pages to decide between manual cloud setup and one-click providers. Treat this introduction as the boundary-setting page: it tells you who Cal.diy is for, what risks you accept, and when the commercial Cal.com path is the better fit.

Sources: apps/docs/content/index.mdx