Cal.com on GKE Autopilot

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 GKE Autopilot on top of the App_GKE foundation, which provisions and manages the shared Google Cloud and Kubernetes 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 that are common to every GKE application — Workload Identity, ingress, autoscaling, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, backups, and the deployment lifecycle — refer to the App_GKE foundation guide rather than repeating them here.

1. Overview

Cal.com runs as a Next.js web workload. The deployment wires together a focused set of Google Cloud services:

Capability	Google Cloud service	Notes
Compute	GKE Autopilot	Next.js pods, 2 vCPU / 2 GiB by default, horizontally autoscaled
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 Load Balancing	External LoadBalancer Service, optional custom domain + managed certificate

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 the cluster service URL (set from GKE_SERVICE_URL at runtime); set webapp_url to the external LoadBalancer address or custom domain once known, or booking/OAuth links will be wrong.
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.
Session affinity is ClientIP by default, keeping a client's requests on the same pod for consistent UI/session behaviour.
The Cloud SQL Auth Proxy sidecar is used by default (enable_cloudsql_volume = true), giving Cal.com a loopback 127.0.0.1 PostgreSQL endpoint with plaintext (the proxy terminates 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 you have run gcloud container clusters get-credentials <cluster> --region <region> --project <project> and that PROJECT, REGION, and NAMESPACE are set. The namespace and other identifiers are reported in the deployment Outputs.

A. GKE Autopilot — the Cal.com workload

Cal.com pods are scheduled on Autopilot, which bills for the CPU/memory the pods actually request. Horizontal Pod Autoscaling sizes the deployment between the minimum and maximum replica counts.

Console: Kubernetes Engine → Workloads → select the Cal.com workload to see pods, revisions, and events. Kubernetes Engine → Services & Ingress shows the external IP.

CLI:

kubectl get pods,svc,hpa -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" deploy/<service-name> --tail=100
kubectl describe hpa -n "$NAMESPACE"          # current vs target utilisation

See App_GKE for how Autopilot, scaling, and the workload type (Deployment vs StatefulSet) are managed.

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. Pods reach it privately through the Cloud SQL Auth Proxy sidecar on 127.0.0.1; 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, and metrics.

CLI:

gcloud sql instances list --project "$PROJECT"
gcloud sql instances describe <instance-name> --project "$PROJECT"
# Open an interactive shell to inspect schema/data:
gcloud sql connect <instance-name> --user=<db-user> --database=<db-name> --project "$PROJECT"

The instance name, database name, user, and the Secret Manager secret holding the password are all surfaced in the Outputs. For the connection model, automated backups, and password rotation, see App_GKE.

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_GKE for CMEK options and GCS Fuse mounts.

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 pod:
kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep -i redis

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"

The database password secret name is in the Outputs. See App_GKE for the Secret Store CSI integration and rotation.

F. Networking & ingress

By default the workload is exposed through an external Cloud Load Balancing IP (service_type = LoadBalancer). A custom domain with a Google-managed certificate can be enabled (enable_custom_domain = true by default), and a static IP is reserved so the address survives redeploys. Set webapp_url to the resulting external URL so Cal.com's generated booking/OAuth links are correct.

Console: Network services → Load balancing; VPC network → IP addresses.

CLI:

kubectl get ingress,svc -n "$NAMESPACE"
gcloud compute addresses list --project "$PROJECT"

See App_GKE for custom domains, Cloud CDN, and static IP details.

G. Cloud Logging & Monitoring

Pod stdout/stderr flow to Cloud Logging; GKE and Cloud SQL metrics flow to Cloud Monitoring. Optional uptime checks and alert policies are available.

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

CLI:

gcloud logging read 'resource.type="k8s_container" AND resource.labels.namespace_name="'"$NAMESPACE"'"' \
  --project "$PROJECT" --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 pod 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 requires the external IP. NEXT_PUBLIC_WEBAPP_URL / NEXTAUTH_URL are set from GKE_SERVICE_URL at runtime. After the LoadBalancer IP (or custom domain) is assigned, set webapp_url to that address:
```
kubectl get svc <service-name> -n "$NAMESPACE" -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
```
Or set environment_variables/webapp_url in the module configuration before deploying.
First-run setup. Open the external 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.
Health path. Startup and liveness probes target /. The generous startup window (0-second initial delay, up to a 30×30s retry window ≈ 15 minutes) accommodates first-boot Prisma migrations.

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_GKE with its standard behaviour and defaults.