Cal.com on Google Cloud Run

Cal.com is an open-source, AGPL-licensed scheduling platform — the self-hosted Calendly alternative — built with Next.js and Prisma on PostgreSQL. This module deploys Cal.com on Cloud Run v2 on top of the App_CloudRun foundation, which provisions and manages the shared Google Cloud infrastructure.

This guide focuses on the cloud services Cal.com uses and how to explore and operate them from the Google Cloud Console and the command line. For the mechanics common to every Cloud Run application — service identity, ingress and load balancing, scaling and concurrency, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, backups, and the deployment lifecycle — refer to the App_CloudRun foundation guide rather than repeating them here.

1. Overview

Cal.com runs as a Next.js container on Cloud Run v2. The deployment wires together a focused set of Google Cloud services:

Capability	Google Cloud service	Notes
Compute	Cloud Run v2	Next.js service, 1 vCPU / 2 GiB by default, serverless autoscaling; scale-to-zero supported
Database	Cloud SQL for PostgreSQL 15	Required — Cal.com (Prisma/`pg`) targets PostgreSQL only
Object storage	Cloud Storage (none by default)	Cal.com stores all state in PostgreSQL; no uploads bucket is created
Cache	Redis (optional)	Off by default; used for caching / rate limiting
Secrets	Secret Manager	Auto-generated `NEXTAUTH_SECRET` and `CALENDSO_ENCRYPTION_KEY`; database password
Ingress	Cloud Run URL / Cloud Load Balancing	Default `run.app` URL; optional external HTTPS load balancer + custom domain

Sensible defaults worth knowing up front:

PostgreSQL 15 is mandatory. The database engine is fixed by the shared application layer; Cal.com's Prisma schema targets PostgreSQL only.
NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY are generated automatically and stored in Secret Manager. Never rotate them after first boot without a maintenance window — rotating CALENDSO_ENCRYPTION_KEY renders all stored calendar/OAuth credentials undecryptable, and rotating NEXTAUTH_SECRET invalidates all sessions.
The public URL is validated at startup. NEXT_PUBLIC_WEBAPP_URL / NEXTAUTH_URL default to this service's deterministic run.app URL; leaving them at the image's localhost:3000 default makes the server refuse to boot. Set webapp_url to a custom domain before sharing booking links.
The schema is created on boot, not by a migration job. The db-init job only provisions the empty database and role; Cal.com runs prisma migrate deploy on every start. Allow several minutes on the first boot.
Memory floor is 2 GiB. Cal.com (Next.js 16) OOM-crashes at startup below 2 GiB.
Scale-to-zero is enabled by default (min_instance_count = 0, max = 1, request-based billing). Cold starts add latency to the first request after idle; set min_instance_count = 1 to avoid them.
The Cloud SQL Auth Proxy socket is used by default (enable_cloudsql_volume = true). A direct private-IP TCP connection fails Prisma's server-certificate verification against Cloud SQL's untrusted CA — the socket avoids this (the proxy does the mTLS).
Redis is disabled by default. Enable it only for cache / rate-limit backing.

2. Google Cloud Services & How to Explore Them

All commands assume PROJECT and REGION are set. Service and resource names are reported in the deployment Outputs.

A. Cloud Run — the Cal.com service

Cal.com runs as a Cloud Run v2 service that autoscales by request load between the minimum and maximum instance counts. Each deployment creates an immutable revision; traffic can be split across revisions for safe rollouts.

Console: Cloud Run → select the service for revisions, traffic, logs, and metrics.

CLI:

gcloud run services list --project "$PROJECT" --region "$REGION"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"

See App_CloudRun for scaling, concurrency, execution environment, and traffic splitting.

B. Cloud SQL for PostgreSQL 15

Cal.com stores all application data (users, event types, bookings, connected calendar credentials) in a managed Cloud SQL for PostgreSQL 15 instance. The service connects privately through the Cloud SQL Auth Proxy over a Unix socket; no public IP is exposed. On first deploy an initialization Job creates the application database and role, and Cal.com applies its schema via Prisma on boot.

Console: SQL → select the instance for connections, backups, flags, metrics.

CLI:

gcloud sql instances list --project "$PROJECT"
gcloud sql instances describe <instance-name> --project "$PROJECT"
gcloud sql connect <instance-name> --user=<db-user> --database=<db-name> --project "$PROJECT"

The instance name, database, user, and password secret are in the Outputs. See App_CloudRun for the connection model, backups, and password rotation.

C. Cloud Storage

Cal.com keeps all state in PostgreSQL, so no data bucket is created by default (storage_buckets is empty). Additional buckets can still be declared via storage_buckets if needed for custom integrations.

Console: Cloud Storage → Buckets.

CLI:

gcloud storage buckets list --project "$PROJECT"

See App_CloudRun for GCS Fuse and CMEK options.

D. Redis (optional cache)

Redis is disabled by default (enable_redis = false). When enabled, Cal.com uses it as a cache / rate-limit backend. When redis_host is left empty and enable_nfs is true, the NFS server VM's IP is used as the Redis endpoint.

Console: Memorystore → Redis (if using a managed instance).

CLI:

redis-cli -h <redis-host> ping
redis-cli -h <redis-host> info keyspace
# Confirm env injected into the running revision:
gcloud run services describe <service-name> --region "$REGION" \
  --format='value(spec.template.spec.containers[0].env)'

E. Secret Manager

Two cryptographic secrets are generated automatically and stored in Secret Manager: NEXTAUTH_SECRET (signs NextAuth.js session tokens) and CALENDSO_ENCRYPTION_KEY (encrypts stored calendar/OAuth credentials). The database password is managed separately by the foundation.

Console: Security → Secret Manager.

CLI:

gcloud secrets list --project "$PROJECT"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

See App_CloudRun for injection and rotation details.

F. Networking & ingress

The service is reachable at its run.app URL by default (ingress_settings = "all"). An external HTTPS load balancer with a custom domain, Cloud CDN, and Cloud Armor can be layered on; ingress settings and VPC egress control connectivity. Because Cal.com bakes its public URL into generated booking and OAuth links, set webapp_url to the final domain before going live.

Console: Cloud Run (service URL); Network services → Load balancing.

CLI:

gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
gcloud compute addresses list --project "$PROJECT"

See App_CloudRun.

G. Cloud Logging & Monitoring

Container logs flow to Cloud Logging; Cloud Run and Cloud SQL metrics flow to Cloud Monitoring, with optional uptime checks and alert policies.

Console: Logging → Logs Explorer; Monitoring → Dashboards / Alerting.

CLI:

gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. Cal.com Application Behaviour

First-deploy database setup. An initialization Job runs db-init.sh using postgres:15-alpine. It connects through the Cloud SQL Auth Proxy and idempotently creates the application role and database and grants privileges on the public schema. It does not create the application schema — that is Cal.com's job.
Schema migrations on boot. The image's start script runs prisma migrate deploy on every start, creating the schema on first boot and applying new migrations on version upgrades — no separate migration step. Budget several minutes for the first boot before the service becomes Ready.
NEXTAUTH_SECRET and CALENDSO_ENCRYPTION_KEY are immutable after first boot. Changing CALENDSO_ENCRYPTION_KEY makes all stored calendar/OAuth credentials undecryptable (every integration must be re-authorised); changing NEXTAUTH_SECRET logs out every user. Only rotate during a planned maintenance window.
Public URL is validated at startup. NEXT_PUBLIC_WEBAPP_URL / NEXTAUTH_URL default to the deterministic run.app URL and are corrected at runtime from CLOUDRUN_SERVICE_URL. Verify the deployed value:
```
gcloud run services describe <service-name> \
  --region "$REGION" --project "$PROJECT" --format='value(status.url)'
```
First-run setup. Open the service URL and complete the Cal.com onboarding to create the initial administrator/owner account, then configure at least one connected calendar. Self-hosted Cal.com allows self-service sign-up by default — restrict it (or front the service with IAP) if the instance should not be public.
Startup probe is TCP, not HTTP. The / endpoint only returns 2xx once Cal.com reports FULL readiness (DB + Redis + deps), which never passed an HTTP startup probe even though Next.js was already listening on the port — so the default probe is a 30 s-delay TCP check (20 s period, 30 failure retries ≈ 10 minutes) that succeeds as soon as the app binds the port. The liveness probe is disabled by default for the same reason: Cloud Run liveness can't use a TCP socket, and the HTTP / endpoint would restart-loop an otherwise-healthy container while it's still reaching full readiness.

Inspect job execution:

gcloud run jobs list --project "$PROJECT" --region "$REGION"
gcloud run jobs executions list --job <job-name> --project "$PROJECT" --region "$REGION"

4. Configuration Variables

Variables are grouped exactly as they appear on the deployment platform. Only settings specific to or notable for Cal.com are listed; every other input is inherited from App_CloudRun with its standard behaviour.