[!WARNING]
Use at your own risk. Cal.diy is the open source community edition of Cal.com and it is intended for users who want to self-host their own Cal.diy instance. It is strictly recommended for personal, non-production use. Please review all installation and configuration steps carefully. Self-hosting requires advanced knowledge of server administration, database management, and securing sensitive data. Proceed only if you are comfortable with these responsibilities.

[!TIP] For any commercial and enterprise-ready scheduling infrastructure, use Cal.com, not Cal.diy; hosted by us or get invited to on-prem enterprise access here: https://cal.com/sales

Cal.diy

The community-driven, open-source scheduling platform.
GitHub
Issues · Contributing

About Cal.diy

Cal.diy is the community-driven, fully open-source scheduling platform — a fork of Cal.com with all enterprise/commercial code removed.

Cal.diy is 100% MIT-licensed with no proprietary "Enterprise Edition" features. It's designed for individuals and self-hosters who want full control over their scheduling infrastructure without any commercial dependencies.

What's different from Cal.com?

• No enterprise features — Teams, Organizations, Insights, Workflows, SSO/SAML, and other EE-only features have been removed
• No license key required — Everything works out of the box, no Cal.com account or license needed
• 100% open source — The entire codebase is licensed under MIT, no "Open Core" split
• Community-maintained — Contributions are welcome and go directly into this project (see CONTRIBUTING.md)

Note: Cal.diy is a self-hosted project. There is no hosted/managed version. You run it on your own infrastructure.

Built With

• Next.js
• tRPC
• React.js
• Tailwind CSS
• Prisma.io
• Daily.co

Getting Started

To get a local copy up and running, please follow these simple steps.

Prerequisites

Here’s what you need to run Cal.diy.

• Node.js (Version: >=18.x)
• PostgreSQL (Version: >=13.x)
• Yarn (recommended)

If you want to enable any of the available integrations, you may want to obtain additional credentials for each one. More details on this can be found below under the integrations section.

Development

Setup

1. Clone the repo (or fork https://github.com/calcom/cal.diy/fork)

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

   If you are on Windows, run the following command in Git Bash with admin privileges: git clone -c core.symlinks=true https://github.com/calcom/cal.diy.git

2. Go to the project folder

   cd cal.diy
   

3. Install packages with yarn

   yarn
   

4. Set up your .env file

   • Duplicate .env.example to .env
   • Use openssl rand -base64 32 to generate a key and add it under NEXTAUTH_SECRET in the .env file.
   • Use openssl rand -base64 24 to generate a key and add it under CALENDSO_ENCRYPTION_KEY in the .env file.

Windows users: Replace the packages/prisma/.env symlink with a real copy to avoid a Prisma error (unexpected character / in variable name):

# Git Bash / WSL
rm packages/prisma/.env && cp .env packages/prisma/.env

5. Set up Node If your Node version does not meet the project's requirements as instructed by the docs, "nvm" (Node Version Manager) allows using Node at the version required by the project:

   nvm use
   

   You first might need to install the specific version and then use it:

   nvm install && nvm use
   

   You can install nvm from here.

Quick start with yarn dx

• Requires Docker and Docker Compose to be installed
• Will start a local Postgres instance with a few test users - the credentials will be logged in the console

yarn dx

Default credentials created:

You can use any of these credentials to sign in at http://localhost:3000

Tip: To view the full list of seeded users and their details, run yarn db-studio and visit http://localhost:5555

Development tip

1. Add export NODE_OPTI to your shell script to increase the memory limit for the node process. Alternatively, you can run this in your terminal before running the app. Replace 16384 with the amount of RAM you want to allocate to the node process.

2. Add NEXT_PUBLIC_LOGGER_LEVEL={level} to your .env file to control the logging verbosity for all tRPC queries and mutations.
   Where {level} can be one of the following:

   0 for silly
   1 for trace
   2 for debug
   3 for info
   4 for warn
   5 for error
   6 for fatal

   When you set NEXT_PUBLIC_LOGGER_LEVEL={level} in your .env file, it enables logging at that level and higher. Here's how it works:

   The logger will include all logs that are at the specified level or higher. For example: \

   • If you set NEXT_PUBLIC_LOGGER_LEVEL=2, it will log from level 2 (debug) upwards, meaning levels 2 (debug), 3 (info), 4 (warn), 5 (error), and 6 (fatal) will be logged. \
   • If you set NEXT_PUBLIC_LOGGER_LEVEL=3, it will log from level 3 (info) upwards, meaning levels 3 (info), 4 (warn), 5 (error), and 6 (fatal) will be logged, but level 2 (debug) and level 1 (trace) will be ignored. \

echo 'NEXT_PUBLIC_LOGGER_LEVEL=3' >> .env

for Logger level to be set at info, for example.

Gitpod Setup

1. Click the button below to open this project in Gitpod.

2. This will open a fully configured workspace in your browser with all the necessary dependencies already installed.

Manual setup

1. Configure environment variables in the .env file. Replace , , , and with their applicable values

   DATABASE_URL='postgresql://:@:'