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.

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

Cal.com on RAD's Cloud Run module costs about US$84 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 32 credits a day (about 960 a month, about US$96 at the top-up price). Or see the GKE guide for always-on capacity across pods. 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	75 credits (US$7.50 at the top-up price)	67.5 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$84 a month for the default configuration (table below)	Metered hourly in credits; RAD publishes 32 credits a day, about 960 a month (about US$96 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
Cloud Run, 1x vCPU / 2 GiB (scaleToZero)	US$13.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
Total	about US$84

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

Scale-to-zero is the default on Cloud Run. The figure above assumes modest daily use; set min_instance_count ≥ 1 to keep it always warm (and avoid cold starts), which raises the Cloud Run line but not the rest of the table.

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 79 credits (about US$7.90) 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 3 days or more — in your own project that is about US$2.79 a day, and in a RAD-managed one it is 32 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 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.