Cal.diy: self-hosting Cal.com's scheduling stack without the enterprise tier

The problem Cal.diy solves: a scheduling page you own, with no license key

Cal.com is an open core product. The hosted version and the enterprise tier are the commercial side, and the self-hosted codebase carries an enterprise edition split. Cal.diy takes the opposite position: it is a fork of Cal.com with, in the README's words, "all enterprise/commercial code removed." The result is a single MIT-licensed codebase with no proprietary Enterprise Edition features and no license key to obtain or validate.

The audience is narrow and stated plainly. The README opens with a warning that Cal.diy "is strictly recommended for personal, non-production use" and that self-hosting "requires advanced knowledge of server administration, database management, and securing sensitive data." That is not boilerplate caution. A scheduling tool holds calendar credentials, booking data and, depending on which integrations you enable, tokens for third-party services. Running it yourself means you own that surface.

If you want scheduling infrastructure with a support contract, the same README points elsewhere: for "commercial and enterprise-ready scheduling infrastructure, use Cal.com, not Cal.diy." Treat that as the project's own boundary rather than a marketing line.

How Cal.diy is put together: a Turborepo monorepo over Next.js, tRPC and Prisma

The repository is a Yarn workspaces monorepo. The root package.json is named calcom-monorepo, is marked private, and lists workspaces covering apps/*, apps/api/*, packages/*, packages/embeds/*, packages/features/*, packages/app-store and its subpackages, packages/platform/*, and example-apps/*. Build orchestration runs through turbo, and the README names the stack as Next.js, tRPC, React, Tailwind CSS, Prisma and Daily.co.

Data flow follows that stack. Prisma talks to PostgreSQL, tRPC carries typed queries and mutations between the Next.js app and the server, and the app-store packages hold the calendar and video integrations. The Dockerfile shows how the pieces are pruned for a production image: it runs npx turbo prune --scope=@calcom/web --scope=@calcom/trpc --docker, then yarn install, then builds the embed library into the web app's public/embed folder. So the embeddable booking widget ships from the same image as the web app rather than as a separate service.

The docker-compose.yml defines three services on a shared network named stack: database (image postgres, database calendso), redis (image redis:latest, host port ${REDIS_PORT:-6379}), and calcom, which builds from the repository Dockerfile and maps port 3000. The database service uses POSTGRES_USER=unicorn_user, POSTGRES_PASSWORD=magical_password and POSTGRES_DB=calendso. Those are development credentials sitting in a file people copy into production, which is worth noticing before you expose anything.

Installing Cal.diy locally and booking your first event

The README lists Node.js >=18.x, PostgreSQL >=13.x and Yarn as prerequisites. Clone the repository and move into it:

git clone https://github.com/calcom/cal.diy.git
cd cal.diy

Install dependencies with Yarn, then create your environment file by duplicating .env.example to .env. Two secrets have to be generated, and the README gives the exact commands:

openssl rand -base64 32
openssl rand -base64 24

The first value goes into NEXTAUTH_SECRET, the second into CALENDSO_ENCRYPTION_KEY. The README also notes a Windows-specific fix: replace the packages/prisma/.env symlink with a real copy to avoid a Prisma error reading "unexpected character / in variable name."

The fastest path to a running instance is the Docker-backed quick start. It needs Docker and Docker Compose, and it starts a local Postgres with seeded test users whose credentials are logged to the console:

yarn dx

After it starts, sign in at http://localhost:3000 with one of the seeded accounts, for example [email protected] with password free, or [email protected] with password ADMINadmin2022!. From there you create an event type, connect a calendar, and share the booking link. To inspect the seeded data directly, run yarn db-studio and open http://localhost:5555.

If you would rather run the stack from Compose, the repository ships a docker-compose.yml. It reads configuration from .env via env_file, builds the image from the local Dockerfile, and expects NEXT_PUBLIC_WEBAPP_URL, DATABASE_URL, NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY among its build arguments. The image reference in that file is calcom.docker.scarf.sh/calcom/cal.diy, with a local build fallback.

What was removed, and why that is the main limitation

The README is explicit about the deletions: Teams, Organizations, Insights, Workflows and SSO/SAML are enterprise-only features that have been removed from this fork. That single decision defines who should not use Cal.diy. If your requirement is a shared round-robin queue across a sales team, or a SAML login backed by your identity provider, or workflow automations that fire on booking events, this codebase does not contain them.

The .env.example file is a useful check on that. It still carries SAML_DATABASE_URL and SAML_ADMINS entries, commented out, with a pointer to packages/features/ee. The variables survive in the template even though the feature set is described as removed. Do not read their presence as an endorsement that SAML works here; the README's feature list is the authoritative statement.

There is a second, quieter limitation. The project describes itself as community-maintained, and the last push to the default branch was on 2026-03-01, the same date as the v6.2.0 release. That is roughly six months before today. Recent releases exist (v6.2.0, v6.1.16 and v6.1.15 all landed in February and March 2026), but the cadence is not continuous, and the README does not document a rollback path or an upgrade procedure for self-hosted instances. If you need a migration story between versions, you will be reading Prisma migration files rather than a guide.

Finally, the development notes hint at resource weight. The README suggests raising the Node heap with export NODE_OPTIONS="--max-old-space-size=16384", and the Dockerfile defaults MAX_OLD_SPACE_SIZE to 6144. A build that wants several gigabytes of heap is not a small VPS workload.

Cal.diy compared with running Cal.com's own self-hosted image

The obvious alternative is Cal.com itself. The difference is not cosmetic. Cal.com's self-hosted distribution is an open core build where the enterprise features exist behind a license; Cal.diy is a fork in which that code has been stripped out, which is why the README can say no license key is required and the whole codebase is MIT. Choosing Cal.diy means choosing a smaller feature surface in exchange for removing the license negotiation and the commercial dependency entirely.

The trade-off runs in both directions. With Cal.diy you get a codebase you can read end to end without hitting a proprietary boundary, and contributions go to this project rather than upstream. What you give up is the enterprise feature set and any expectation of commercial support. The README routes commercial and enterprise needs to cal.com/sales, which is an honest division of labour rather than a hedge.

A second alternative, for people who only need a booking link and nothing else, is not to self-host at all. The README states there is no hosted or managed version of Cal.diy; you run it on your own infrastructure. If you are not prepared to run PostgreSQL, manage secrets and patch a server, the fork's own documentation tells you to look at Cal.com's hosted offering instead.

Licence, maintenance and what an upgrade actually costs

The repository is MIT-licensed, and the .env.example header repeats that: "Cal.diy is fully open source, no license key is required." For most adopters that means you can run, modify and redistribute the code under the MIT terms, and there is no per-seat or per-instance licence to renew. This is a description of the licence text, not legal advice; if you plan to redistribute a modified version or bundle it into a product, read the LICENSE file and take your own counsel.

Upgrade cost is where the fork asks for patience. The project uses Changesets (.changeset/ is a top-level entry) and Turborepo, so version bumps and release notes are generated rather than hand-written. The practical consequence for a self-hoster is that you depend on Prisma migrations being applied cleanly against your database. The README documents db-deploy and db-seed as scripts, and DATABASE_DIRECT_URL exists specifically for running migrations behind a connection pooler such as PgBouncer. What the README does not document is a rollback procedure, a supported version matrix, or a tested upgrade path from one minor release to the next. Budget time for reading migration files before you apply them.

On support: the README offers none beyond the issue tracker and CONTRIBUTING.md. SECURITY.md exists in the repository root, which is the right place to look before reporting a vulnerability, but there is no stated security response commitment in the README.

Editorial conclusion

Cal.diy is for one person or a small group who wants a scheduling page on their own server and accepts the operational load that comes with it. It is not for teams that need organizations, SSO/SAML, insights or workflows, since those enterprise features are removed from this fork, and it is not for anyone who needs a supported production system. Before committing, verify that your Node and PostgreSQL versions meet the stated minimums, that NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY are generated and stored somewhere you can recover them, and that you have read the warning at the top of the README about server administration and securing sensitive data.

Frequently asked questions

Official sources

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