Add Cal.com API v2 service and Redis to Docker Compose

[percymamedy]

Summary

This PR adds a new calcom-api service for running the Cal.com API v2 instance alongside the existing Cal.com web application, and introduces a Redis service for caching and session management.

Changes Made

New Services Added

• Redis Service: Added redis service with persistent volume storage for caching and session management
• Cal.com API v2 Service: Added calcom-api service running on port 80 (mapped to host port 80)

Service Configuration

• Port Mapping: API v2 service runs on port 80 (container) mapped to host port 80
• Build Context: Uses ./calcom context with apps/api/v2/Dockerfile
• Dependencies: Properly configured to depend on both database and Redis services

Environment Variables

• Database Connections: Configured all required database URLs (read/write/direct)
• Redis Integration: Added REDIS_URL pointing to the Redis service
• API Configuration: Set appropriate API settings including port, URL, and key prefix
• Authentication: Configured NEXTAUTH_SECRET and JWT_SECRET
• Stripe Integration: Added all required Stripe environment variables for payment processing
• VAPID Keys: Included web push notification keys for service worker functionality
• Feature Flags: Set appropriate defaults for team billing and API v2 prefix rewriting

Build Optimization

• Minimal Build Args: Reduced build arguments to only essential database connection strings
• Efficient Build: API v2 service only receives necessary build-time variables

Benefits

1. Complete API Stack: Provides both web application and API v2 services
2. Redis Caching: Improves performance with Redis-based caching
3. Proper Isolation: Services run independently with correct dependencies
4. Production Ready: Configured with appropriate production settings
5. Maintainable: Clean, organized service configuration

Testing

• All services start successfully with proper dependency order
• API v2 accessible on configured port
• Redis persistence working correctly
• Environment variables properly configured

Notes

• Requires appropriate environment variables in .env file
• Redis data persists across container restarts
• API v2 service includes all necessary environment variables for full functionality

[krumware]

Thanks for this and the extra detail.

@dcharles525 @hadams95 please consider this in the work you're doing for the helm chart, and related to the API v2 container image reqs. https://github.com/calcom/cal.com/blob/main/apps/api/v2/Dockerfile

Also more context: calcom/cal.com#21804

[dcharles525]

The calcom api won't start properly without the VAPID keys set as environment variables, this should be added to the env.example and the configuration section of the README as well.

Otherwise looks good to me.

[percymamedy]

The calcom api won't start properly without the VAPID keys set as environment variables, this should be added to the env.example and the configuration section of the README as well.

Otherwise looks good to me.

Thank you for the feedback @dcharles525, I've added the requested missing elements to the .env.exmaple and README.md files.

[dcharles525]

Thanks for the PR! LGTM!

[krumware]

I'd like to request making sure all env vars can pick up .env vars (if available). For example, API_KEY_PREFIX can be changed, but it's hardcoded in the docker-compose changes. IS_E2E doesn't match the exact .env example, but it could, via IS_E2E=${NEXT_PUBLIC_IS_E2E:-false}

[percymamedy]

I'd like to request making sure all env vars can pick up .env vars (if available). For example, API_KEY_PREFIX can be changed, but it's hardcoded in the docker-compose changes. IS_E2E doesn't match the exact .env example, but it could, via IS_E2E=${NEXT_PUBLIC_IS_E2E:-false}

Thank you for the feedback @krumware, that actually makes sense and allows greater flexibility in configuring the API service indeed. I've made the requested updates see the latest the commit: 267a27b

[krumware]

@percymamedy sorry to be a bother. This is a good chance for me to enforce parity with all of the .env.examples.
I couldn't find REDIS_URL in api/v2's env example https://github.com/calcom/cal.com/blob/main/apps/api/v2/.env.example .
Is this a good chance to update that too?
Also, should NEXT_PUBLIC_API_V2_KEY_PREFIX be changed to API_KEY_PREFIX (and any other related differences)?

(You'll know the env vars better than me, but my preferred goal would be to allow a user to reuse their calcom/cal.com .env's directly with the docker images with few changes)

[percymamedy]

@percymamedy sorry to be a bother. This is a good chance for me to enforce parity with all of the .env.examples. I couldn't find REDIS_URL in api/v2's env example https://github.com/calcom/cal.com/blob/main/apps/api/v2/.env.example . Is this a good chance to update that too? Also, should NEXT_PUBLIC_API_V2_KEY_PREFIX be changed to API_KEY_PREFIX (and any other related differences)?

(You'll know the env vars better than me, but my preferred goal would be to allow a user to reuse their calcom/cal.com .env's directly with the docker images with few changes)

@krumware yes REDIS_URL is not in the .env.example of the api v2 but it's used in the code in multiple instances example here: https://github.com/calcom/cal.com/blob/main/apps/api/v2/src/env.ts#L16 and here https://github.com/calcom/cal.com/blob/main/apps/api/v2/src/config/app.ts#L25. During my testing I found out that the API Container will not start without it, so I think it might be some oversight in the calcom/cal.com main repo.

As for the parity between the other env vars, I'll push a change and match them as close as possible, I did not know initially which convention to follow and saw NEXT_PUBLIC_ prefix in multiple instances in the envs so I went with that but I can change it to more closely match the .env.example from the api.

[percymamedy]

@krumware I've made changes to ensure to match env vars as close as possible with the env vars in the api v2 .env.example ensuring consistency and parity.

[krumware]

lgtm

[krumware]

@krumware I've made changes to ensure to match env vars as close as possible with the env vars in the api v2 .env.example ensuring consistency and parity.

thank you!

[krumware]

@dcharles525 @hadams95 Please withhold merging until the apiv2 image is published