Deploy on Vercel

Purpose and Scope

This page explains how to deploy Cal.diy to Vercel using the repository’s first-party deployment guide. It is intended for self-hosters who want the convenience of Vercel’s project import and serverless build pipeline while still managing the database, environment variables, and initial application data themselves. The Vercel page is one entry in the deployments documentation set, alongside cloud and one-click alternatives such as AWS, Azure, Google Cloud, and Elestio. The important distinction is that Vercel handles the web application deployment, but it does not remove the need to prepare a hosted Postgres database or configure Cal.diy-specific secrets correctly.

Sources: apps/docs/content/deployments/vercel.mdx, apps/docs/content/deployments/_meta.ts

The documented Vercel path has two modes. The first is a one-click deployment button that starts from the Cal.diy repository URL and asks Vercel to clone and create the project. The second is a manual flow where you fork the repository, configure local settings, apply the Prisma schema to a Postgres database, create the first user through Prisma Studio, and then import the fork into Vercel. Treat the one-click button as a project creation shortcut, not a full replacement for the operational checklist. The manual steps show the same assumptions the deployed application will have at runtime.

Sources: apps/docs/content/deployments/vercel.mdx

Relevant Source Files

• apps/docs/content/deployments/vercel.mdx — Primary Vercel guide covering requirements, one-click deployment, local setup, database preparation, first-user creation, and Vercel project settings.
• apps/docs/content/deployments/_meta.ts — Deployment navigation metadata that registers the Vercel page together with AWS, Azure, Elestio, GCP, Northflank, Railway, and Render.
• apps/docs/content/deployments/aws.mdx — Neighboring manual cloud deployment guide used for comparison with Vercel’s database, configuration, verification, DNS, and monitoring responsibilities.
• apps/docs/content/deployments/azure.mdx — Neighboring Azure guide showing the same broad deployment shape: source access, cloud resources, environment configuration, database setup, verification, DNS, and monitoring.
• apps/docs/content/deployments/elestio.mdx — Minimal one-click deployment page that illustrates how the deployments section also includes provider-hosted shortcut flows.
• apps/docs/content/deployments/gcp.mdx — Neighboring Google Cloud guide showing the VM and Docker-oriented deployment alternative when Vercel is not the desired runtime.

Requirements and Deployment Choice

The Vercel guide states that a Vercel Pro plan is currently required because the application exceeds the serverless function limits of the free plan. This requirement is a deployment constraint, not an optional optimization, so verify the account plan before spending time debugging failed builds or missing functions. The same requirements section also says that Cal.diy needs a hosted Postgres database. The examples name Supabase as a free option and Heroku as a low-cost option, but the underlying requirement is simply that the deployed web application can reach a Postgres database whose connection values are provided through environment variables.

Sources: apps/docs/content/deployments/vercel.mdx

Choose Vercel when you want the web application hosted as a Vercel project and are comfortable providing database hosting separately. The surrounding deployment docs show other shapes: AWS and Azure focus on creating cloud resources such as compute services and managed PostgreSQL, while the Google Cloud guide walks through a virtual machine, networking, Docker installation, and container execution. Elestio is presented as a button-based provider deployment. This comparison matters because troubleshooting changes by platform. On Vercel, the critical settings are usually the imported repository, project root, environment variables, build command, install behavior, and database connection rather than VM firewall rules or Docker daemon setup.

Sources: apps/docs/content/deployments/aws.mdx, apps/docs/content/deployments/azure.mdx, apps/docs/content/deployments/elestio.mdx, apps/docs/content/deployments/gcp.mdx

One-Click Deployment

The one-click path is the shortest documented Vercel entry point. The Vercel page exposes a deploy button whose target clones the Cal.diy repository into Vercel’s new-project flow. Use it when you are starting from the upstream repository and want Vercel to bootstrap the project configuration screen for you. After the project exists, still review the same settings required by the manual deployment section: environment variables must be set, the project must build from the web application directory, and the database must already be prepared. A button can create a project quickly, but it cannot decide your secrets, database endpoint, OAuth credentials, or first-user data.

Sources: apps/docs/content/deployments/vercel.mdx

The one-click flow is also useful as a reference for what Vercel should import: the Cal.diy repository itself. If you need custom patches, private configuration, or a controlled upgrade process, prefer forking first and importing your fork manually. That gives you a stable deployment source, lets you review changes before they reach the hosted project, and matches the local settings workflow documented later on the page. In either case, avoid treating deployment as complete until you can sign in with a user record and verify that the application reaches the configured database from the Vercel runtime.

Sources: apps/docs/content/deployments/vercel.mdx

Manual Local Preparation

Manual deployment starts locally by forking and cloning the repository. The guide uses a clone command that points at your fork, which is important because Vercel will later import from that same fork. Next, copy the example environment file from the web application directory, rename it to the local environment file, and fill in values using the manual setup and Google API credential guidance referenced by the Vercel document. This local environment step is not just for development convenience. It helps validate the configuration model before the same kinds of values are entered into Vercel’s Environment Variables screen.

Sources: apps/docs/content/deployments/vercel.mdx

git clone https://github.com/<<your-fork>>/cal.diy.git

After cloning and configuring the environment, install dependencies with Yarn and apply the database schema through the Prisma workspace command. The Vercel guide identifies the schema location as the Prisma schema under the Prisma package and then runs the workspace deployment command. That command is the database preparation step that makes the hosted Postgres database match the application’s expected schema. Run it before relying on the deployed app, because a successful Vercel build does not by itself prove that the database tables, indexes, and model shape required by Cal.diy have been created.

Sources: apps/docs/content/deployments/vercel.mdx

yarn install
yarn workspace @calcom/prisma db-deploy

First User and Prisma Studio

The documented local setup includes opening Prisma Studio to inspect or modify database content. In this flow, Prisma Studio is used to create the first user record manually. Open the User model, add a new record, encrypt the password with BCrypt before saving, and then log in through the local web application on port 3000. This step is easy to overlook when focusing only on cloud deployment, but it is the practical bridge between an empty database and a usable self-hosted instance. Without a valid user row, deployment may appear healthy while leaving you unable to access the application as an administrator.

Sources: apps/docs/content/deployments/vercel.mdx

yarn db-studio

This first-user procedure also gives you an early validation point for environment and database connectivity. If Prisma Studio cannot open the database or the User model is unavailable, fix the database connection and schema deployment before moving on to Vercel. If the user can be created but login fails locally, check the password hashing step and the web application environment before copying settings into Vercel. Local verification narrows the problem space: once the local setup works against the same hosted Postgres database, remaining Vercel issues are more likely to be project configuration, build command, install behavior, or runtime environment variable scope.

Sources: apps/docs/content/deployments/vercel.mdx

Vercel Project Configuration

The deployment section has a concise but specific checklist. Create a new Vercel project, import it from the forked repository, set the environment variables, set the root directory to the web application directory, override the build command, and deploy. The root directory setting is especially important in this monorepo because the web application is not at the repository root. The build command compensates by changing back to the monorepo root and running the build with dependency handling flags. If the root directory and build command disagree, Vercel may run the wrong command from the wrong working directory.

Sources: apps/docs/content/deployments/vercel.mdx

cd ../.. && yarn build --include-dependencies --no-deps

The guide also documents an install-command workaround for cases where Yarn install fails during deployment on Vercel. In that situation, set the install command so immutable installs are disabled. Use this as a targeted compatibility fix rather than as the first thing to change. Start with the documented normal install and only switch when Vercel’s build logs indicate that the install phase is the failure point. This keeps troubleshooting clear: dependency installation, application build, environment loading, and database access are separate phases, and each produces different signals in the Vercel dashboard and runtime logs.

Sources: apps/docs/content/deployments/vercel.mdx

YARN_ENABLE_IMMUTABLE_INSTALLS=false yarn install

Operational Checks and Next Steps

After deployment, verify more than the final Vercel success state. Confirm that the deployed URL loads the Cal.diy web application, that authentication works with the first user, and that the instance can read and write data in the configured Postgres database. The neighboring cloud deployment pages emphasize verification, DNS setup, monitoring, and scaling after an application is reachable. Those concerns still apply on Vercel, even though Vercel abstracts away servers. Point the desired domain at the deployment, monitor build and runtime behavior, and keep the fork updated with Cal.diy changes according to your upgrade process.

Sources: apps/docs/content/deployments/aws.mdx, apps/docs/content/deployments/azure.mdx, apps/docs/content/deployments/vercel.mdx

If Vercel is not a fit because of plan requirements, serverless limits, or a preference for container control, compare this page with the Docker and cloud deployment guides. Google Cloud’s documented path is VM plus Docker, while AWS and Azure are framed around manual cloud resources and managed database setup. If you continue with Vercel, the next useful topics are environment and URL configuration, database migrations, Google integration setup, and troubleshooting API or database startup issues. Those pages cover the configuration details that usually determine whether a deployed scheduling instance behaves correctly beyond the first successful build.

Sources: apps/docs/content/deployments/_meta.ts, apps/docs/content/deployments/gcp.mdx, apps/docs/content/deployments/aws.mdx, apps/docs/content/deployments/azure.mdx