Cal.diy: A Self-Hosted Scheduling Fork Without the Enterprise Bloat

What Cal.diy Actually Removes From Cal.com

Cal.diy is a fork of Cal.com with the enterprise and commercial code stripped out. The README lists what is gone: Teams, Organizations, Insights, Workflows, SSO/SAML, and other EE-only features. That means you get the core scheduling interface and calendar integrations, but none of the multi-tenant or organizational machinery. The project is 100% MIT-licensed, so there is no Open Core split and no license key requirement. You do not need a Cal.com account to run it. This is a deliberate narrowing of scope. The target user is someone who wants a personal scheduler and is willing to run it themselves. If you need team calendars or enterprise identity management, this fork is not for you, and the README says so directly by pointing you to Cal.com for commercial use.

The Architecture: Next.js, tRPC, Prisma, and Daily.co

The stack is visible from the README's Built With section: Next.js, tRPC, React, Tailwind CSS, Prisma, and Daily.co. That means the app is a server-rendered React front end with tRPC handling API calls between the client and server, and Prisma as the ORM talking to PostgreSQL. Daily.co is listed, which suggests video call integration is part of the scheduling flow, though the README does not detail how deep that integration goes. The data flow is typical for a Cal.com-style app: users create event types, share booking links, and invitees pick slots that get written to the database. Because tRPC is used, the API surface is tightly coupled to the TypeScript types, which can be a maintenance burden if you fork the code further. The architecture is not unusual, but it is heavy for a personal scheduling tool, so expect a real deployment footprint.

Getting It Running: Commands and Config Keys

The README gives a clear path. Clone the repo, run yarn to install, then set up your .env file. You need to generate two keys: NEXTAUTH_SECRET with openssl rand -base64 32 and CALENDSO_ENCRYPTION_KEY with openssl rand -base64 24. For a quick start, yarn dx will spin up a local Postgres instance via Docker and seed test users. The default credentials are listed: [email protected], [email protected], [email protected], [email protected], and [email protected], with passwords like 'free' and 'pro'. You can then sign in at localhost:3000. There is also a note about Windows: you must replace the packages/prisma/.env symlink with a real copy to avoid a Prisma error. That is a concrete gotcha that will trip up anyone on Windows who skips it.

The Development Workflow: Memory Limits and Logging Levels

The README includes two development tips that reveal the resource appetite of this project. First, it suggests setting NODE_OPTIONS="--max-old-space-size=16384" to increase the Node memory limit. That raises the Node memory limit to 16 GB, and the README says to replace 16384 with the amount of RAM you want to allocate, which hints that the build and dev server can be memory-hungry. Second, you can control tRPC logging verbosity with NEXT_PUBLIC_LOGGER_LEVEL, where 0 is silly and 6 is fatal. Setting it to 3 logs info and above. These are useful for debugging, but they also show that this is not a lightweight app. A personal scheduling tool whose README suggests such a high Node memory limit may be a heavy lift for a small VPS or a home server. If you are on a constrained machine, you will need to tune that value down or accept slower builds.

The Project Recommends Personal, Non-Production Use

The README is blunt: it is strictly recommended for personal, non-production use. The warning says self-hosting requires advanced knowledge of server administration, database management, and securing sensitive data. That is not a soft disclaimer; it is the core of the project's positioning. Treat that as the project's deployment recommendation and evaluate operational readiness and security before using it for real users; it is not itself a licence restriction. There is no hosted version, so you are responsible for backups, uptime, and security patches. The removal of enterprise features means you cannot scale to teams or organizations without rebuilding those features yourself. If you need a production scheduler, the README explicitly points you to Cal.com, either hosted or on-prem enterprise access. This is a fork for tinkerers, not for operations teams.

The Alternative: Cal.com Itself

The obvious alternative is the upstream Cal.com project. The README itself recommends it for commercial and enterprise-ready scheduling infrastructure. The difference in approach is that Cal.com is Open Core: it has a community edition but also proprietary Enterprise Edition features like Teams, Organizations, Insights, Workflows, and SSO/SAML. Cal.diy removes all of that to stay 100% MIT. So the choice is between a richer feature set with a license key requirement and a commercial dependency, versus a leaner fork with no license key but no enterprise features. If you need SSO or team management, Cal.com is the way. If you want a fully open source codebase that you can audit and modify without any commercial strings, Cal.diy is the pick. The trade-off is real: you gain full licensing freedom but lose the features that make Cal.com useful beyond a single person.

Maintenance and Upgrade Cost

The repository shows recent releases: v6.2.0 in March 2026, v6.1.16 and v6.1.15 in February 2026. That suggests active maintenance, but the project is community-maintained, so the release cadence depends on volunteer effort. If you fork it, you will need to track upstream changes and manually merge or rebase if you want to stay current. The removal of enterprise features also means you cannot simply drop in Cal.com's official releases; you are on your own fork. The MIT licence permits modification and redistribution subject to its notice and other terms; operators must also handle their own security patches. Before adopting, check the issue tracker for open bugs and verify that the latest release works with your Node and PostgreSQL versions. The README warns to use it at your own risk, so treat this as a rolling, self-managed dependency.

Editorial conclusion

Adopt Cal.diy if you are an individual or small team comfortable with server administration, database management, and securing your own data, and you need a scheduling tool without commercial dependencies. Do not use it if you require enterprise features like Teams, Organizations, Insights, Workflows, or SSO/SAML, or if you need production-grade support. Before deploying, verify your Node.js version (>=18.x), PostgreSQL (>=13.x), and that you have generated both NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY with openssl. Also check the Windows symlink workaround for packages/prisma/.env if you are on that OS. The project explicitly warns it is for personal, non-production use, so treat any public deployment as a risk you must manage yourself.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes