# cal.diy ships a compose file with unicorn_user in it, and says do not use it in production

> A community fork of Cal.com with the enterprise code stripped out, fully MIT licensed and requiring no licence key. The repository opens with a warning that it is for personal, non-production use, and its default configuration contains example database credentials you must change before anything else.

**calcom/cal.diy** — cal.diy packages Cal.com's scheduling interface and calendar integrations for personal, non-production self-hosting.

- Repository: https://github.com/calcom/cal.diy
- Website: https://cal.diy
- Stars: 48,732 · Forks: 15,244
- Language: TypeScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/calcom-cal-diy

## The first block on the page is a warning not to use it in production

Before any feature is described, the project states its own limits and they are unusually direct. It says to use it at your own risk, that cal.diy is the open source community edition of Cal.com, and that it is strictly recommended for personal, non-production use. It asks readers to review all installation and configuration steps carefully, and it says self-hosting requires advanced knowledge of server administration, database management and securing sensitive data, and to proceed only if comfortable with those responsibilities. A second block immediately after points anyone wanting commercial or enterprise-ready scheduling infrastructure at Cal.com itself, hosted or on-prem. So the boundary is drawn by the project rather than inferred by a reader, and the answer to whether this is production software is in the first paragraph, not in a support forum.

## It is a fork with the enterprise code deleted, not a feature-flagged build

The mechanism matters for what you can expect. Cal.diy is described as a fork of Cal.com with all enterprise and commercial code removed, and the list of what is gone is specific: Teams, Organizations, Insights, Workflows, SSO/SAML and other EE-only features. That is a different artefact from a build where enterprise features are present but disabled, because the code is not there to enable. The rest of the positioning is about what you gain in exchange, namely that the whole codebase is MIT licensed with no open-core split, that no licence key or Cal.com account is required, and that contributions go directly into this project. The stack underneath is named as Next.js, tRPC, React, Tailwind, Prisma and Daily.co, so you are running a familiar application framework with a scheduling domain model.

## Clone, install, and generate two secrets by hand

The setup is four commands and then an environment file:

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

Prerequisites are Node.js at version 18 or newer, PostgreSQL at 13 or newer, and Yarn, which is recommended rather than required. The environment file is a copy of .env.example renamed to .env, and two of its values must be generated rather than invented:

```sh
openssl rand -base64 32
openssl rand -base64 24
```

The 32-byte output goes under NEXTAUTH_SECRET and the 24-byte output under CALENDSO_ENCRYPTION_KEY. Windows has a documented extra step, because the repository relies on a symlink at packages/prisma/.env that Git for Windows will not create, and Prisma fails with unexpected character / in variable name unless you replace it with a real copy. Yarn is not incidental either, since a .yarnrc.yml and .yarn directory sit at the root.

## yarn dx hands you five accounts with published passwords

The quick start is a single command, and it is a development shortcut rather than a deployment path:

```sh
yarn dx
```

It requires Docker and Docker Compose, and it starts a local Postgres with several seeded test users whose credentials are printed to the console. Those accounts are fixed and published: free@example.com with password free, pro@example.com with pro, trial@example.com with trial, an admin at admin@example.com with ADMINadmin2022!, and an onboarding account whose onboarding is deliberately left incomplete. You then sign in at localhost on port 3000. Nothing here is secret, which is the point while developing, and it is also why this command has no place in a deployment, since the same seed data is what a database restored from a development backup will contain.

## The compose file and the Dockerfile both ship placeholder secrets

Two files in the repository contain credentials that must be changed, and neither marks them loudly. docker-compose.yml sets POSTGRES_USER to unicorn_user and POSTGRES_PASSWORD to magical_password for the database service, with the database named calendso, and it runs a redis alongside it on a configurable port that defaults to 6379. The Dockerfile is worse in a quieter way, because its build arguments for NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY both default to the literal string secret, so a build that does not pass those arguments produces an image with a known signing key rather than a broken one. Given that the project asks readers to review configuration carefully, these two defaults are the first thing to check after a deployment fails to come up, and they are the first thing to change before it succeeds.

## The monorepo is upstream's, and the tooling shows it

The tree is a large Next.js monorepo and the package manifest is named calcom-monorepo at version 0.0.0 with private set to true, which is the convention for a workspace root rather than a published package. The workspace globs span apps, apps/api, packages, several package subpaths including embeds, features, app-store and platform, and example-apps, and the scripts are all routed through turbo, with build, clean, db-deploy, db-seed, db-studio, deploy and dev targets. Testing and quality tooling is broad rather than minimal, covering Playwright, Vitest, Biome, checkly and husky. The root also carries AGENTS.md, CLAUDE.md, a .claude directory, a .cursor directory and a .opencode directory, which is a signal that the fork is maintained with AI coding assistants in the loop, and a PERMISSIONS.md that a reader distributing a modified instance should look at.

## v6.2.0 shipped in March, the branch moved in September

The repository is not archived and the last push was on 2026-09-26, so the branch is receiving work. The releases tell a different story about the version you would deploy. The newest tag is v6.2.0, published on 2026-03-01, preceded by v6.1.16 and v6.1.15, both on 2026-02-12. So roughly seven months of commits on the default branch sit outside the newest published release, which means anyone who installs by tag and anyone who builds from main are running different code, and the gap widens with every commit. For a project whose own warning tells you to review configuration carefully, that is the second thing to pin down after the credentials: decide deliberately whether you are tracking a release or the branch, because the repository does not make that choice for you.

## Conclusion

Adopt cal.diy if you want a self-hosted booking page for yourself or a small group and are willing to own the administration, since there is no hosted version and no support beyond the community. Do not adopt it as a team scheduling platform, because Teams, Organizations, Insights, Workflows and SSO/SAML were all removed from the fork, and the project itself points commercial users at the upstream product. Verify first that you have replaced the example database credentials in docker-compose.yml and passed real values for NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY at build time, because the Dockerfile will otherwise fall back to the literal default of secret.

## FAQ

### what is cal diy

A community-driven, fully open-source fork of Cal.com with all enterprise and commercial code removed, MIT licensed throughout and requiring no licence key. It is a self-hosted project for personal use, with no hosted or managed version offered.

### What is the difference between cal.diy and Cal.com?

Cal.diy is the fork and Cal.com is the upstream product. The fork removes Teams, Organizations, Insights, Workflows and SSO/SAML entirely, and in exchange has no open-core split and no licence key, while the project directs commercial and enterprise use back to Cal.com.

### Can I run cal.diy in production?

The project states it is strictly recommended for personal, non-production use and tells commercial users to use Cal.com instead. It also says self-hosting requires advanced knowledge of server administration, database management and securing sensitive data.

### What are the default login credentials for cal.diy?

The yarn dx quick start seeds fixed accounts including free@example.com with password free and an admin at admin@example.com with ADMINadmin2022!. These are published development credentials and must not survive into a deployment.

## Sources

- [Official documentation](https://cal.diy)
- [Official README](https://github.com/calcom/cal.diy#readme)
- [Project repository](https://github.com/calcom/cal.diy)
- [Release notes](https://github.com/calcom/cal.diy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/calcom-cal-diy