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.

What Cal.com costs on RAD, and how that compares

Cal.com on RAD's GKE Autopilot module costs about US$143 a month in your own Google Cloud project, with no extra licence fee — Cal.com is open source. In a project RAD manages for you, the same deployment is metered at 108 credits a day (about 3,240 a month, about US$324 at the top-up price). Or see the Cloud Run guide for the lower-cost option. If you only need Cal.com occasionally — studying, a demo, a short-lived project — a RAD-managed project can be deleted and restored within 30 days for a few credits, so that monthly figure becomes a few dollars instead. See Pause it for free, below.

What you pay on RAD

Cal.com is open source, so there is no licence fee. You pay for three things:

	In a Google Cloud project you own	In a project RAD manages for you
Module fee, once per deployment	110 credits (US$11 at the top-up price)	99 credits (10% lower)
Build time	A few credits per build (roughly 3–6 credits)	The same
Google Cloud running cost	Billed by Google to your own billing account, about US$143 a month for the default configuration (table below)	Metered hourly in credits; RAD publishes 108 credits a day, about 3,240 a month (about US$324 at the top-up price)
Who owns what	You own the project and its billing; RAD deploys and updates it	RAD owns the project, with guardrails, quotas and budget alerts; you get console access, and a minimum purchased balance is held in reserve

10 credits cost US$1 on a one-off top-up, and less on a monthly plan. In a project RAD manages, the database, file server and network are shared by every application in the project, so a second application does not add a second database.

Default running cost in your own project (us-central1, Google list prices):

Resource (module default)	Per month
GKE Autopilot pod, 2x vCPU / 2 GiB	US$72.16
Cloud SQL for PostgreSQL, 1 vCPU / 3.75 GB, zonal, 10 GB SSD	US$51.02
NFS/cache file server (small VM)	US$13.43
Cloud NAT and networking	US$5
Cloud Storage (add-ons, backups)	US$1
GKE cluster management fee	shared across every GKE app in the project; $0 if this is your only cluster, else ~73
Total (excluding the shared GKE cluster fee)	about US$143

Cloud SQL and Cloud Run/GKE pod pricing is the same in africa-south1 (Johannesburg); the small VM costs about 10% more there.

GKE Autopilot does not scale to zero. At least one pod always runs, so the cost above applies whether or not anyone is using the app; extra pods are added only under load.

How it compares, for a team of ten

Cal.com, the project this module deploys, sells its own hosted plans per user:

Option	Per month (10 users)	Notes
Cal.com Teams	US$120 (US$12/user)	Hosted by Cal.com
Cal.com Organizations	US$280 (US$28/user)	Hosted by Cal.com, adds org-wide admin
RAD, Cloud Run, your own project	About US$84, plus US$7.50 once per deployment	RAD's automation, in your project
RAD, Cloud Run, a RAD-managed project	About 960 credits (US$96)	RAD

Cal.com's hosted price grows with every seat; RAD's cost is the infrastructure, which a growing team only reaches the edge of when it needs more capacity. At ten users RAD's own-project running cost is already below a single month of the Teams plan.
A cheap server is cheap until something breaks. On RAD the database is Cloud SQL with automated backups, and secrets live in Secret Manager. On your own server, that is a job someone has to do.

Pause it for free: delete a RAD-managed project, restore it when you need it

If Cal.com runs in a project RAD manages for you, deleting the whole project — rather than deleting just this module — unlinks its billing first, then asks Google to delete the project outright. Google keeps it, recoverable, for 30 days, and because billing is already unlinked, nothing is charged while it waits. Unlike deleting one module, this does not tear down Cloud SQL, any VM or the compute resource one by one: the whole project simply stops.

Restoring is a check, not a rebuild. Within 30 days, the project's owner can ask Google to undelete the project and reattach its billing account, then run Update on each deployment to confirm everything came back. Because nothing was individually destroyed, that Update finds the same resources already there, and an Update never charges the module fee again. For a typical 2–3-deployment chain this costs only a handful of credits in total (roughly 5–10 credits, under US$1).
What this needs. You must own the project (not one RAD only manages billing for), restore it yourself within 30 days — after that Google deletes it for good — and clear the tier's admission floor again (100 credits for the sandbox tier most study/demo use fits). Google says most services are fully working again within 36 hours of a restore.
One real gap: nightly backups do not survive. Backups are written to a bucket inside the project, and that bucket has Cloud Storage's soft-delete turned off, so it is very likely gone as soon as the project is deleted — even though the project itself is recoverable for 30 days. Copy a backup out (to Google Drive, or a bucket outside the project) before deleting if there is anything in it worth keeping; for a default install with nothing irreplaceable, this does not matter.

Source: Delete and restore projects.

Pay only while you use it, the other way: delete and redeploy

In your own project, or once the 30-day restore window above has passed, the way to stop paying is to delete the deployment and deploy it again when you need it.

What a redeploy costs. The module fee again, plus the builds: about 114 credits (about US$11.40) at the top-up price, and roughly 15–20 minutes of build time (RAD's own platform average). Deleting saves money only once Cal.com would otherwise sit unused for about 2 days or more — in your own project that is about US$4.75 a day, and in a RAD-managed one it is 108 credits a day.
Most of the running cost here is usually the database and/or the shared file/cache VM or cluster. They stop only when nothing else in the project uses them, so deleting Cal.com while another application shares the project saves only Cal.com's own compute part.
Keep data first. Nightly backups go to a bucket inside the deployment and are deleted with it, so copy the latest backup out before deleting if you want to keep it.

Lab sessions and Managed Environments

Lab sessions, for training. A trainer runs a session for a class. Each participant gets the app in their own Google Cloud project for 15 minutes to 24 hours, within an allowance the trainer sets. Either the trainer funds every place, or each participant pays for their own. Everything is deleted when the session ends and unused credits go back to the trainer.
Managed Environments, for consultancies. A partner runs the app for a client from a ring-fenced wallet it funds, and settles with the client directly. If the wallet runs low, billing pauses and the data is kept, so nobody receives an unexpected charge. At the end the partner hands the project over and the deployments become the client's own.

Credits can be bought in more than 20 currencies, including XAF, XOF, NGN, GHS, KES and ZAR, by card, bank transfer or mobile money.

Sources (8 October 2026): Google Cloud list prices from the Cloud Billing Catalog API; RAD fees and the daily-credit estimate from radmodules.dev/pricing; Delete and restore projects for the pause/restore window and backup-bucket caveat; Cal.com pricing; prices change, check each source before relying on a figure.

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. The startup probe targets / (a 307 redirect, which the kubelet accepts); the liveness probe targets /api/auth/providers, which returns a literal 200. The liveness probe is mirrored into the Gateway health check, which requires 200, so pointing it at / leaves the Gateway serving 503. 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.