Cal.diy: The Fork That Makes Cal.com Smaller, Cleaner, and Free to Self-Host

A close look at the subtractive fork that strips out enterprise bloat, preserves the scheduling core, and turns a commercial codebase into a practical DIY stack.

11 min read • View on GitHub • More from calcom

A wide editorial illustration of a large scheduling machine on a workbench while a technician removes bulky enterprise modules from its outer shell. The core mechanism beneath keeps ticking, with calendar cards and gears still aligned, showing how the fork preserves the booking engine while stripping away extra layers. — Cal.diy is less a new machine than a controlled removal of the parts that made the old one heavier.

Key Takeaways

Cal.diy is defined by subtraction: it keeps the scheduling core while removing the enterprise shell that made Cal.com heavier to self-host.
The hard part is not forking code, but cutting features cleanly enough that bookings, schema, and developer workflows still hold together.
Its value is lineage, not novelty, because it preserves the Cal.com mental model without the license gates and commercial dependencies.
For self-hosters, the fork is a governance choice as much as a technical one, because portability and continuity matter more than breadth.

Cal.diy is interesting because it does the rarest thing in software: it gets smaller on purpose. The fork takes Cal.com’s scheduling core and removes the enterprise layer that usually makes open core products feel conditional. What is left is not a stripped toy. It is a self-hostable, MIT-licensed system that tries to keep the useful center intact.

What Cal.diy Removes

The point of Cal.diy is not that it adds a better booking engine. It is that it removes the parts that turn a useful calendar stack into a commercial platform: Teams, Organizations, SSO or SAML, Insights, workflows, and license gating. That is why the fork feels unusual. Most forks try to widen a product. This one tries to make a complex product survivable by taking load off the system.

The interactive diagram shows the article’s central idea: the enterprise layers can come off without interrupting the booking path underneath.

A close-up editorial illustration of a transparent panel being lifted from a layered software stack. The top layer contains enterprise features being peeled away, while the lower strata stay aligned as API routes, service classes, Prisma migrations, and database tables. — The technical challenge is not removal itself. It is removing one layer without misaligning the others beneath it.

Why a Subtractive Fork Is Harder Than a Normal Fork

A normal fork can add a feature and call it differentiation. A subtractive fork has to do the opposite. It has to identify which modules are truly optional, which schema assumptions are shared, and which code paths are only pretending to be isolated. That means the real work happens in the seams: repository layers, migrations, API boundaries, and contributor conventions.

Project	Stack	Hosting model	Feature depth	Best fit
Cal.diy	Next.js, tRPC, Prisma, PostgreSQL	Self-hosted	High, but intentionally trimmed	People who want Cal.com lineage without the enterprise layer
Cal.com	Commercial platform lineage	Hosted or controlled distribution	High	Users who want the full product and managed service
Calnode	Go, SQLite	Self-hosted	Moderate	Users who want a lean single-binary alternative
Rallly	Web app, simpler scheduling model	Self-hosted or hosted	Lower	Teams that need polling rather than full scheduling infrastructure
Calendly	Proprietary SaaS	Hosted only	High	Users who want polish and do not need self-hosting

The comparison that matters most is Cal.diy versus Calnode. Calnode is lean by design. Cal.diy is lean by deletion. One chooses a lighter stack from the start. The other inherits a heavy monorepo and proves that selective removal can still leave a coherent product behind.

Inside the Monorepo

Cal.diy still looks like serious production software. It uses a Turborepo monorepo with Next.js in apps/web, a newer API surface in apps/api/v2, and shared packages for Prisma, tRPC, and embeds. The stack is TypeScript heavy, which matters because the project’s promise is not just that it works. It is that the same types, models, and contracts can survive the fork intact.

That architecture buys the fork a lot. It keeps client and server aligned through tRPC, centralizes data access in Prisma, and lets the team treat scheduling as a structured domain rather than a pile of routes. It also means the project carries the cost of a mature app. This is not a thin wrapper around a database. It is a real product surface with real dependency pressure.

How Cal.diy Keeps the Data Model Safe

Cal.diy is the core part of Cal.com that handles all of the scheduling and simply has all of the enterprise features stripped out.

Bailey Pumfleet, CEO of Cal.com · The New Stack interview

Scheduling software lives or dies on data integrity. Availability rules, timezone edges, recurring events, booking links, and reminders all interact with the database in ways that are easy to break and hard to notice quickly. That is why the repository treats Prisma migrations as high-risk changes and why the codebase leans on service and repository abstractions instead of letting routes talk directly to storage.

The result is a safer path for refactoring. The fork can remove feature modules without forcing every caller to rewrite how it reaches the database. That separation matters more in scheduling than in many apps because the bug surface is temporal. A broken UI is visible. A broken booking rule may only show up when a user misses a meeting.

The Developer Experience Is Part of the Product

Cal.diy tries to make local development boring in the best way. The repo includes Docker Compose support, seeded users, CI automation, and a dedicated yarn dx workflow that spins up a repeatable environment. That is not just convenience. It lowers the cost of joining a codebase that still carries the weight of a large monorepo.

yarn install

yarn dx

# starts the local stack with seeded users and the app services
# useful accounts often include admin and pro-style demo users

The contributor conventions matter too. Naming patterns for repositories and services, plus the presence of AI-assistant rules in the repo, suggest that maintainers are trying to keep the codebase legible even as it evolves. For a fork, that is a real strategic choice. Ease of contribution is how a community keeps a de-commercialized codebase alive.

Where Cal.diy Fits in the Scheduling Landscape

Cal.diy occupies a narrow but useful niche. It is for people who want the Cal.com mental model, the same general data shape, and a self-hosted path that feels familiar. It is not trying to beat Calendly on polish or Rallly on simplicity. It is trying to preserve continuity for users who value ownership more than breadth.

That is why the fork is more than a technical artifact. It is a migration path. If you already think in Cal.com terms, Cal.diy lowers the cost of staying in that world without accepting the commercial wrapper around it. If you are starting fresh, a leaner project may be easier. If you are preserving an existing workflow, lineage matters.

Question	Cal.diy	Calnode	Rallly	Calendly
Need Cal.com compatibility?	Yes	No	No	No
Want a lighter self-hosted stack?	Moderate	Yes	Yes	No
Need full scheduling infrastructure?	Yes	Yes, but leaner	No	Yes
Need zero vendor lock-in?	Yes	Yes	Yes	No
Prefer the easiest setup?	Medium	High	High	Very high, but hosted

Why This Fork Matters

Cal.diy argues that open source governance can be a product feature. When a platform becomes harder to trust, maintain, or self-host, a community fork can preserve the useful parts without inheriting every incentive of the original business. The win is not nostalgia. It is continuity.

That makes the project interesting even beyond scheduling. It shows that deletion can be an engineering skill, not just a cost-cutting move. If the fork is disciplined enough, removing features does not have to weaken the system. It can restore the reason people wanted it in the first place.