Deploy on Google Cloud

Purpose and Scope

This page documents the repository-backed Google Cloud Platform deployment path for Cal.diy. The GCP guide is framed as a deployment of the Cal.diy application onto Google Cloud by creating a virtual machine, configuring network access, installing Docker, and running the published Docker image. It is a manual infrastructure path for operators who want direct control over the VM rather than using a managed one-click platform. The same deployments documentation set also lists AWS, Azure, Elestio, Northflank, Railway, Render, and Vercel, so GCP should be understood as one supported option inside a broader self-hosting deployment menu.

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

Choose this guide when you are comfortable managing a Google Cloud project, Compute Engine instance, firewall rules, operating-system packages, and container runtime lifecycle. The official GCP page explicitly says it covers virtual-machine creation, configuration, Docker installation, and application deployment. Unlike Azure, which includes one-click and manual sections, or Elestio and Northflank, which are presented as button-based deployments, the GCP manual flow is intentionally low-level: you provision the VM, expose HTTP traffic, SSH into the host, install Docker, pull the image, and start the container yourself.

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

Relevant Source Files

• apps/docs/content/deployments/gcp.mdx - Primary Google Cloud deployment guide; defines the one-click Cloud Run button and the manual VM, firewall, Docker, image pull, and container run sequence.
• apps/docs/content/deployments/_meta.ts - Deployment navigation metadata; shows GCP as a first-class deployment page next to AWS, Azure, Elestio, Northflank, Railway, Render, and Vercel.
• apps/docs/content/deployments/aws.mdx - Neighboring manual cloud deployment guide; useful for shared operational expectations such as source access, environment configuration, database setup, DNS, monitoring, and updates.
• apps/docs/content/deployments/azure.mdx - Neighboring cloud guide; documents the same broad stages of resource creation, database and networking setup, deployment verification, DNS configuration, monitoring, and scaling.
• apps/docs/content/deployments/elestio.mdx - One-click deployment reference; provides contrast with hosted button-driven deployment options.
• apps/docs/content/deployments/northflank.mdx - One-click deployment reference; provides contrast with platform-managed deployment options and links to a provider-specific guide.

Deployment Options on GCP

The GCP page exposes two paths. The first is a one-click deployment button labeled “Run on Google Cloud” that points at Google Cloud Run with the Cal.diy Git repository as input. That route is appropriate when you want the provider to guide the deployment from a Git source. The second path is the manual deployment described in the rest of the page. The manual path is more explicit and is the focus of this page because it shows the infrastructure assumptions: a Google Cloud project, a Compute Engine VM, an open HTTP port, Docker installed on the host, and a running calcom/cal.diy container.

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

The manual GCP flow is closer to the repository’s AWS and Azure manual guides than to the one-click pages. AWS describes creating cloud resources, updating the .env file with service details such as database endpoints, deploying the application, connecting the database, verifying the deployment, and then handling DNS plus monitoring. Azure follows a similar shape with a resource group, app service, PostgreSQL database, networking, monitoring, deployment verification, DNS, and scaling. The GCP page is narrower in the supplied source: it shows a VM plus Docker container path, so you should plan database, secrets, backups, HTTPS, and observability as operational work around that baseline.

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

Manual GCP Execution Flow

Start in the Google Cloud Console at https://console.cloud.google.com/. If you do not already have a project for this installation, create one from the project selector by choosing “New Project,” naming it, and creating it. The deployment guide then moves into Compute Engine: open the navigation menu, select Compute Engine, choose VM instances, and create a new virtual machine. The guide recommends selecting a machine type suited to your needs and notes that 2 vCPUs with 2-4 GB of RAM is ideally enough for this path.

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

During VM creation, configure networking. The GCP guide says to use the Networking tab, add a network, choose the Default network, and create the instance. After the instance exists, note its public IP address because that is the address you use to reach the deployment until DNS is configured. The next explicit configuration step is allowing traffic on port 80. From the VM details page, open the Firewalls tab, add a firewall rule, select “Allow all” for source and destination, set protocol to tcp, set the port to 80, and save the rule.

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

The repository guide then has you connect to the VM and install Docker. It supports connecting with the Google Cloud CLI over SSH or using web-based SSH. The documented CLI form is parameterized by project, zone, and instance name, which makes it suitable for repeatable runbooks as long as those values are recorded alongside your deployment. Once connected, update the package list, install the Docker package from the operating system repositories, and start the Docker service. At that point the VM is prepared to run the Cal.diy container.

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

gcloud ssh --project=[PROJECT_ID] --zone=[ZONE] [INSTANCE_NAME]
sudo apt-get update
sudo apt-get install docker.io
sudo systemctl start docker

With Docker running, pull the published Cal.diy image and start it detached, mapping host port 80 to container port 80. The repository command is docker pull calcom/cal.diy followed by docker run -d -p 80:80 calcom/cal.diy. The guide explains that this port mapping exposes the application outside the container. It then tells you to open a browser and navigate to http://localhost; on a remote GCP VM, use the instance’s public IP or the DNS name that resolves to that VM rather than your local workstation’s loopback address.

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

docker pull calcom/cal.diy
docker run -d -p 80:80 calcom/cal.diy

System-to-Code Mapping

The mapping matters because the GCP guide intentionally provides a minimal runnable path, not a full production architecture. Its concrete commands get a container listening on HTTP, but the broader deployments folder shows recurring operational themes across providers: configure cloud resources, update Cal.diy environment values, connect PostgreSQL, verify the deployment, point DNS at the deployment, and monitor or scale the environment. Use those recurring concerns as a checklist when hardening the GCP VM beyond the simple container run command.

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

Configuration and Operational Notes

The documented GCP command starts the container without any environment variables, external database connection string, restart policy, volume mounts, reverse proxy, or TLS termination. That is enough to describe the repository’s baseline Docker-on-VM flow, but most persistent self-hosted installations will need additional container configuration. The AWS and Azure deployment docs explicitly mention updating .env or configuration files with cloud resource details, including database connection strings, and connecting PostgreSQL services. Treat the plain GCP command as the smallest bootstrapping example, then adapt it to your Cal.diy environment values and database plan.

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

Network exposure is also intentionally simple in the source guide: it opens TCP port 80. That makes first access easy, but it does not by itself provide HTTPS, certificate renewal, host-based routing, or a reverse proxy. After confirming that Cal.diy loads from the VM’s public IP, decide how DNS should point to the instance and how TLS should terminate. AWS and Azure both include post-deployment DNS configuration, and Azure also names monitoring and scaling. Those same post-deployment ideas apply to the GCP VM even though the GCP page stops after the browser access check.

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

The one-click GCP Cloud Run button and the manual VM path represent different operating models. Cloud Run starts from the repository and leans toward provider-managed deployment. The VM path gives you direct shell access and explicit Docker commands, which can be easier to inspect and customize but also leaves patching, service restarts, firewall hygiene, backups, and monitoring in your hands. If you are evaluating deployment surfaces, compare this page with the shorter Elestio and Northflank button-based pages and the more expansive AWS and Azure manual cloud guides.

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

Validation Checklist and Next Steps

After starting the container, verify the deployment in layers. First, confirm the VM is running and has a public IP in the GCP Console. Second, confirm the firewall rule allows inbound TCP traffic on port 80. Third, SSH into the VM and verify that Docker is installed, the Docker service is started, and the calcom/cal.diy image was pulled successfully. Fourth, inspect the running container and open the application through the VM public address. Finally, plan the provider-agnostic follow-up work: database configuration, environment variables, DNS, HTTPS, monitoring, scaling, backups, and regular updates.

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

Read the Docker configuration and troubleshooting pages next if you need to add runtime variables, diagnose container startup failures, or update the image over time. Read the environment and URL pages before moving from a public IP to a domain name, because redirect URLs and host configuration often determine whether authentication and integrations work correctly. If you prefer a managed deployment entry point rather than VM administration, compare the GCP Cloud Run button with the one-click deployment pages for Elestio and Northflank and the provider-specific deployment pages for AWS, Azure, Vercel, Railway, and Render.

Sources: apps/docs/content/deployments/_meta.ts, apps/docs/content/deployments/gcp.mdx, apps/docs/content/deployments/elestio.mdx, apps/docs/content/deployments/northflank.mdx