Deployments Overview

Purpose and Scope

This page orients self-hosters to the deployment choices documented for Cal.diy and helps decide whether to start with a button-driven cloud deployment or a manual infrastructure build. Cal.diy is presented as a community edition for people who want to run their own scheduling instance, not as a managed commercial service. The deployment documentation therefore assumes that the operator owns the infrastructure decisions: database hosting, environment variables, DNS, monitoring, upgrades, and secrets. The main decision is not simply which cloud provider to use, but how much of that operational work should be delegated to a platform template versus performed explicitly in a cloud account.

Sources: apps/docs/content/index.mdx, apps/docs/content/installation.mdx

The top-level documentation index lists deployment choices as a first-class part of the self-hosting guide, alongside installation, database migrations, upgrading, Docker, and app integrations. That placement is important because deployment is not an isolated final step. A successful hosted instance depends on the same baseline setup described in the installation guide: a copy of the repository, a PostgreSQL database, a completed environment file, a generated authentication secret, optional app-store configuration, and an understanding that database upgrades should happen before production builds. Treat the provider-specific pages as ways to place that baseline onto infrastructure rather than as replacements for the baseline.

Sources: apps/docs/content/index.mdx, apps/docs/content/installation.mdx

Relevant Source Files

• apps/docs/content/index.mdx — Defines the self-hosting documentation entry page, warning and commercial-use callouts, getting-started sequence, and deployment platform list.
• apps/docs/content/installation.mdx — Provides the common installation baseline used by manual deployments, including prerequisites, repository cloning, environment setup, production build commands, Vercel preview environment-variable note, and cron-job context.
• apps/docs/content/deployments/vercel.mdx — Documents Vercel-specific requirements, one-click deployment, local setup, Prisma database deployment, first-user creation through Prisma Studio, and the Vercel project build settings.
• apps/docs/content/deployments/aws.mdx — Documents the manual AWS flow, including account prerequisites, IAM, EC2 or Elastic Beanstalk, RDS for PostgreSQL, configuration, verification, DNS, monitoring, scaling, and security best practices.
• apps/docs/content/deployments/azure.mdx — Documents Azure one-click and manual deployment, including resource groups, App Service, Azure Database for PostgreSQL, networking, monitoring, DNS, and scaling.
• apps/docs/content/deployments/gcp.mdx — Documents Google Cloud one-click deployment and a manual VM-based Docker flow, including VM creation, networking, port 80, Docker installation, image pull, container run, and access verification.

Choosing a Deployment Path

Use a one-click deployment when you want the provider to create most of the application hosting shape for you and you are comfortable adapting the generated project afterward. The documentation shows explicit one-click entry points for Vercel, Azure, and Google Cloud. The index also points readers toward Elestio, Northflank, Railway, and Render as deployment destinations. A one-click flow is useful for evaluation, personal instances, or a fast proof of concept because it reduces the number of console steps before the app is visible. It does not remove the need to review secrets, database connectivity, URL configuration, app credentials, and ongoing maintenance.

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

Choose a manual deployment when you need to control the infrastructure boundary directly. The AWS and Azure guides use a classic cloud-operations shape: create an account, enter the provider console, provision compute and PostgreSQL resources, update configuration, deploy the application, verify it, then configure DNS and monitoring. The GCP manual guide is more concrete about a virtual machine path: create a project, create a VM instance, open network access, install Docker, pull the Cal.diy image, and run a container on port 80. Manual deployment is the better fit when you need to match an existing network, database policy, backup system, or monitoring setup.

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

The Vercel guide sits between these styles. It provides a one-click button, but its manual instructions also define local setup and project settings that matter for the platform. Vercel currently requires the Pro plan because of free-plan limits on the number of serverless functions. It also requires a PostgreSQL database hosted elsewhere, with Supabase and Heroku named as possible options. Manual Vercel deployment asks you to fork and clone the repository, copy the environment template for the web app, install packages, deploy the Prisma schema, optionally inspect the database with Prisma Studio, create the first user, and then import the project into Vercel with the correct root directory and build command.

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

Shared Deployment Baseline

Before comparing providers, confirm the shared runtime requirements. The installation guide describes Cal.diy as relatively lightweight once running, with the build phase being the more intensive part. It states that the project works across Windows, Mac, Linux, and BSD because it needs JavaScript execution, while recommending Linux as the ideal production platform. The required components are Node.js, yarn, Git, and PostgreSQL, and the documentation specifically recommends Node.js version 18 for the development environment. Prisma is part of the database maintenance story, so database schema setup and migration commands belong in the deployment plan rather than being postponed until after the app is public.

Sources: apps/docs/content/installation.mdx

Environment configuration is another shared concern. The source-based setup copies the example environment file into an active environment file and then fills in settings from the comments. It calls out generating a random secret and placing it under the authentication secret setting, and it also points to the app-store environment file for integration keys. Vercel preview deployments have a special warning: several public URL and authentication URL variables should be left empty in that preview context. This means deployment plans should distinguish between local, preview, and final public URLs, because incorrect URL values often surface later as login, callback, or client-fetch failures.

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

Production deployment is tied to build and database order. The installation guide instructs operators to run the production build and start commands only after paying attention to end-to-end testing and database upgrading, and it warns to upgrade the database before building for production. The Vercel guide makes the schema step explicit with the Prisma workspace database deploy command before using Prisma Studio to inspect or modify records. For cloud deployments, the practical sequence is therefore: provision PostgreSQL, populate environment values, deploy or migrate the schema, build the web application, create or verify administrative access, and only then place DNS and public traffic in front of the instance.

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

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

Platform Map

The provider map should be read as a responsibility matrix. Vercel abstracts much of the compute layer but still requires an external database and monorepo-aware project configuration. AWS and Azure emphasize provider-native resources, which gives more control over permissions, networking, scaling, and monitoring but requires more console work. GCP’s manual documentation uses a VM and Docker, which is easy to reason about because the container is the deployable unit and the firewall rule directly controls web access. The right choice depends on the operator’s familiarity with the provider, desired control over infrastructure, and willingness to maintain upgrades and database operations.

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

Execution Flow for a New Deployment

A practical new-deployment flow starts by deciding whether the instance is only for personal use or whether the requirement really belongs on Cal.com or an enterprise on-prem offering. The self-hosting index repeatedly frames Cal.diy as use-at-your-own-risk and recommended for personal, non-production use, with commercial and enterprise scheduling infrastructure directed to Cal.com. After that decision, pick the platform that matches the operational model: Vercel for a managed application platform with monorepo settings, AWS or Azure for cloud-native resource ownership, or GCP for either Cloud Run one-click or a VM-based Docker deployment.

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

Next, prepare the configuration before exposing the service. Clone or fork the repository when the provider flow expects source access. Create or attach PostgreSQL, then fill the environment file with provider-specific database endpoints and application settings. Generate a strong authentication secret, and decide whether app integrations require values in the app-store environment file. On Vercel, use the documented monorepo settings by selecting the web app root and overriding the build command so the build runs from the repository root while targeting the web application. On VM and Docker paths, verify that the container port and firewall rules line up with the public entry point.

Sources: apps/docs/content/installation.mdx, apps/docs/content/deployments/vercel.mdx, apps/docs/content/deployments/gcp.mdx

Finally, verify the application as an operator rather than stopping at a successful deploy button. The Vercel guide includes a database inspection path through Prisma Studio and describes creating a first user record with an encrypted password before logging in locally. The AWS and Azure guides both end with operational tasks such as DNS setup, monitoring, and scaling. The GCP guide ends by browsing to the deployed service after running the container. These verification steps are where configuration mistakes become visible, so keep the installation, database migration, URL configuration, and troubleshooting pages close while bringing the first public instance online.

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

yarn workspace @calcom/prisma db-deploy
yarn db-studio
cd ../.. && yarn build --include-dependencies --no-deps
docker pull calcom/cal.diy
docker run -d -p 80:80 calcom/cal.diy

Next Steps

If you are still choosing a provider, read the detailed page for the platform closest to your operating model: Vercel for a serverless-style managed deployment, AWS or Azure for manually assembled cloud resources, or GCP for the documented VM and Docker approach. If you already have an instance running, continue with database migrations, upgrading, Docker configuration, environment and URL troubleshooting, and app integration setup. Deployment is only the start of self-hosting Cal.diy; the long-term tasks are keeping the database current, securing secrets, maintaining integrations, and monitoring the infrastructure you selected.

Sources: apps/docs/content/index.mdx, apps/docs/content/installation.mdx