Should I self-host Calendly?
Cal.com self-hosted does the booking-page job, but it's the heaviest app in our index and the setup is configuration, not compose. Worth it if you're a team with a server habit; a solo calendar link is cheaper to rent.
Managed Google/Microsoft OAuth — self-host means registering your own apps with both, which is most of the real setup time
Their deliverability for reminder emails
booking pages · calendar conflict checking (Google/Outlook) · reminders/emails · team round-robin
* Percent of the subscription price. Your time is priced at the slider's rate — $0/h ("my homelab time is free and I love it") is a legitimate position. Every number is derived from the record, never hand-written. Price source, checked 2026-08-05.
Runs comfortably on a real VPS (2 GB+).
Image is enormous — the pull dominated boot time even on a fast link
Boots healthy without calendar OAuth configured, but the product doesn't do its job until you register apps with Google/Microsoft — budget the weekend for that, not the compose
# Cal.com — scheduling infrastructure (replaces Calendly). The heaviest single app in our
# index: big image, wants real RAM, and most of the setup time is configuration, not boot.
# Secrets are throwaway test values: openssl rand -base64 32
services:
calcom:
image: calcom/cal.com:latest
container_name: calcom
restart: unless-stopped
depends_on:
calcom-db:
condition: service_healthy
environment:
NEXT_PUBLIC_WEBAPP_URL: http://localhost:3003
NEXTAUTH_SECRET: 8Yz1kR9nQ2wX5vB7mC4tL6pJ3sD0fG8hK1aN5uE9rT2Y=
CALENDSO_ENCRYPTION_KEY: 2FduT8qM7xW3kV9zB5nC1sL4pR6jD0gH8fK2aQ5uE7rY=
DATABASE_URL: postgresql://calcom:calcom@calcom-db:5432/calcom
DATABASE_DIRECT_URL: postgresql://calcom:calcom@calcom-db:5432/calcom
ports:
- "3003:3000"
healthcheck:
test: ["CMD-SHELL", "node -e \"fetch('http://localhost:3000/auth/login').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))\""]
interval: 10s
timeout: 10s
retries: 60
start_period: 120s
calcom-db:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_USER: calcom
POSTGRES_PASSWORD: calcom
POSTGRES_DB: calcom
volumes:
- calcom-pg:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U calcom"]
interval: 5s
timeout: 5s
retries: 12
volumes:
calcom-pg:
Want a guided install instead? caniselfhostit.com/calendly has AI-agent prompts that assume a bare machine — that's their half of the stool, and it's good.
FULL TIMED LOG
# Timed setup log: Calendly → calcom **Protocol:** v1 · **Verified by:** zernonia · **Date:** 2026-08-10 **Assistant:** claude-code · **Environment:** containerized runner, 2 vCPU class, Docker 29.3 / Compose v5.1 ## Timeline | Step | Time | |---|---| | Read upstream docs, draft compose with healthcheck | ~50 min | | **Boot: all services healthy in 195 s (measured, `compose up --wait`)** | — | | Endpoint-level workflow check (login/health/API serve) + re-run from clean volumes | ~50 min | | **Total: ~150 min** | | Boot and endpoint checks are machine-verified; `setup_min` is the wall-clock total for this session including authoring, diagnosis and re-runs. Endpoint-level ≠ full human UI workflow — dispute anything that doesn't reproduce (CONTRIBUTING.md). ## What broke - Image is enormous — the pull dominated boot time even on a fast link - Boots healthy without calendar OAuth configured, but the product doesn't do its job until you register apps with Google/Microsoft — budget the weekend for that, not the compose ## Verdict-relevant notes - Setup ceiling is why this is KINDA, not YES: >2h to a genuinely working booking flow.