servchan/docker-compose.prod.yml
jmcqueen c2e98d105e Initial commit: ServChan Webex bot for ServiceChannel work orders.
ServiceChannel webhook processor, proposal approval cards, attachment auto-post,
CollabSupport commands, and Docker deployment configuration.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-24 15:12:08 -04:00

74 lines
2.5 KiB
YAML

# docker-compose.prod.yml
#
# Production override / standalone compose file for ServChan.
#
# Usage (recommended - merges with base for any common settings):
# docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build
#
# Or standalone (also works):
# docker compose -f docker-compose.prod.yml up -d --build
#
# Key differences from dev:
# - Uses the production stage of the Dockerfile (optimized, non-root, no dev deps/watch)
# - NO full source bind mount (code is baked into the image at build time)
# - Dedicated persistent volume for logs (separate from any source tree)
# - NODE_ENV=production
# - Suitable for long-running detached production use
#
# Prerequisites:
# - .env must contain all required secrets (WEBEX_BOT_TOKEN, SC_*, XAI_TOKEN, etc.)
# - ./data and ./logs directories will be created on the host as needed
# - For best security, ensure config/config.json contains NO real credentials
# (the code now loads secrets exclusively from environment variables)
#
# After first run you can drop --build: docker compose -f ... up -d
services:
bot:
build:
context: .
target: production
container_name: servchan-bot
restart: unless-stopped
ports:
- "1458:1458"
env_file:
- .env
volumes:
# Persistent storage for the SQLite database (the "sacred" production DB).
# The exact file referenced by DB_PATH in .env must never be moved or renamed.
- ./data:/app/data
# Persistent logs (written by both legacy and structured loggers).
# Separate volume so logs survive container recreation without source mount.
- ./logs:/app/logs
environment:
- NODE_ENV=production
- CS_API_BASE_INTERNAL=http://collabfinder:1800
networks:
- default
- collabnet
# Healthcheck hits /health so DB connectivity is part of the signal.
# /healthz still exists as a pure liveness probe if you want to fall back.
healthcheck:
test: ["CMD-SHELL", "node -e \"require('http').get('http://localhost:1458/health', (r) => process.exit(r.statusCode === 200 ? 0 : 1)).on('error', () => process.exit(1))\""]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
# Example production resource constraints (uncomment and tune):
# deploy:
# resources:
# limits:
# cpus: '1.0'
# memory: 512M
# reservations:
# cpus: '0.25'
# memory: 128M
networks:
collabnet:
external: true
name: collabfinder_collabnet