calcom/cal.diy

Cal.diy is best seen as a personal scheduling server: if you want Calendly-style booking pages without a hosted vendor or a license key, it is a credible starting point, but its own README says to treat it as non-production software.

The problem

A freelancer or small team wants a public booking link that reads their availability, writes a confirmed event and handles reminders, rather than trading emails about slots. Hosted schedulers solve this but put the calendar data and workflow under someone else's account, and Cal.com's self-hosted edition mixes open code with a commercial layer. Cal.diy changes that last step: you clone a fork in which enterprise code has been removed and run the whole scheduling stack on infrastructure you control, ending up with your own booking site and database. The setup work moves to you; follow the project instructions.

What's different

The mechanism is subtraction. Cal.diy is a fork of Cal.com with Teams, Organizations, Insights, Workflows, SSO/SAML and other EE-only features removed, so the codebase is fully MIT-licensed and needs no Cal.com account or license key. That matters if license purity or vendor avoidance is your reason for self-hosting: there is no feature gate you later hit, and no proprietary component to audit around. The trade-off is that the commercial edition's operational features are simply gone, not replaced by community equivalents.

The other difference is maintenance posture. Because it is a community fork with no hosted option, patching, database management and securing sensitive data sit with you; the README states this explicitly and recommends personal, non-production use. For a developer comfortable with Node.js and PostgreSQL, that is a manageable hobby deployment. For a team that expected a supported scheduling backend, that is the wrong frame.

Who should try it

A good fit is an individual who already manages a server and wants a personal booking link, integrations with their own calendar, and full control of the data: the Docker-based yarn dx quick start gives a local instance with seeded users for evaluation before any real deployment. A poor fit is a company needing shared team routing, SSO or analytics, since those features were removed, or one needing vendor support and an uptime commitment. Procurement-oriented teams should note that Cal.com's own README points commercial users to its sales channel rather than this fork. If the goal is only a booking link for one person, weigh whether the full Next.js/tRPC/Postgres stack is proportionate.

Requirements and limitations

The documented stack needs Node.js 18+, PostgreSQL 13+, and Yarn, with Docker and Docker Compose for yarn dx; integrations such as video conferencing may require additional third-party credentials. The larger constraint is ongoing: you own backups, upgrades, TLS, and the security of stored calendar and contact data, and the README explicitly recommends against production use. That warning is the key limitation to weigh. A Hacker News commenter on 2026-04-21 contrasted it with an earlier Cal.com post arguing on-premise deployments can be more secure, while a reply framed the current warning as a support-and-liability boundary rather than a technical block (see the discussion). Either way, you get no support commitment.

HotRepo's take

On the tracking board, Cal.diy was recorded at 49,307 stars on 2026-10-24 (+62) and 49,317 on 2026-10-25 (+64). That two-day sample supports a star snapshot only; with no earlier board history here, persistence cannot be judged. Before committing, check the repository's own warning and current release state, then decide whether a non-production, personally maintained scheduler matches your risk tolerance.