Cal.diy: A Self-Hosted Scheduling Fork Without the Enterprise Bloat
cal.diy packages Cal.com's scheduling interface and calendar integrations for personal, non-production self-hosting.
At a glance
- What is it?
- Cal.diy strips Cal.com down to its MIT-licensed core for personal, non-production use. This review covers what it removes, how to run it, and the trade-offs of choosing it over the upstream product.
- Who is it for?
- 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.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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. Those are the only two required secrets mentioned. For a quick start, yarn dx will spin up a local Postgres instance via Docker and seed test users. The default credentials are listed: free@example.com, pro@example.com, trial@example.com, admin@example.com, and onboarding@example.com, 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 is 16 GB of RAM just for the Node process, which is a strong hint that the build and dev server are 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 that needs 16 GB of Node heap is 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 Hard Limitation: Personal, Non-Production Use Only
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. The consequence is that you should not run this for a business or a public-facing service with real users. 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. There is no mention of an upgrade path or migration guide in the README. That means you will need to track upstream changes and manually merge or rebase your fork 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 license is MIT, so you can modify and redistribute the code without restrictions, but you must handle your 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 does not promise any long-term support, 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.
Community notes