This guide covers deploying the CodeChunking system in production environments.
CodeChunking is designed for production deployment with:
- High-performance NATS JetStream messaging (305,358+ msg/sec)
- Advanced health monitoring with 23.5µs response times
- Circuit breaker patterns for resilience
- Comprehensive security validation
- Structured logging with correlation tracking
- PostgreSQL 16+ with pgvector extension
- NATS JetStream 2.10+
- Google Gemini API access
- Container Runtime (Docker/Kubernetes)
See .env.example in the repository root for all available environment variables with examples.
Required Variables:
CODECHUNK_DATABASE_HOST=your-postgres-host
CODECHUNK_DATABASE_PASSWORD=your-secure-password
CODECHUNK_NATS_URL=nats://your-nats-host:4222
CODECHUNK_GEMINI_API_KEY=your-gemini-api-keyThe repository includes production-ready configuration files:
- Base config:
configs/config.yaml - Development:
configs/config.dev.yaml - Production:
configs/config.prod.yaml
Review and customize configs/config.prod.yaml for your production environment.
The repository includes production-ready Docker configurations:
Dockerfile: See docker/Dockerfile in the repository
Docker Compose: Use the provided docker-compose.yml
# Copy and customize environment
cp .env.example .env
# Edit .env with your production values
# Deploy with Docker Compose
docker-compose -f docker-compose.yml up -d- Database Setup: Use the init script at
docker/postgres/init.sql - Migrations: Run
make migrate-upor use the migrate command - SSL/TLS: Configure your reverse proxy for SSL termination
While the repository doesn't currently include Kubernetes manifests, you can create them based on the Docker Compose configuration in docker-compose.yml.
Key points from the compose file:
- PostgreSQL uses
pgvector/pgvector:pg16image - NATS uses
nats:2.10-alpinewith JetStream enabled (-jsflag) - Application expects config at
/root/configs/ - Health check endpoint is available at
/health
Use the repository's migration system:
# In your init container or job
./codechunking migrate up --config configs/config.prod.yamlMigration files are located in /migrations/ directory.
The system provides comprehensive health monitoring at /health:
curl https://your-api-host/healthHealth check features (see internal/adapter/inbound/api/health_handler.go):
- Database connectivity checking
- NATS JetStream status with detailed metrics
- Circuit breaker status
- Response time tracking with custom headers
- 5-second caching for performance (23.5µs average response time)
All components use structured JSON logging with correlation IDs. See the logging implementation in:
internal/application/common/logging/internal/adapter/inbound/api/middleware/logging_middleware.go
Log format includes:
- Correlation IDs for request tracing
- Performance metrics
- Component identification
- Error context and stack traces
The system includes comprehensive security validation (see internal/application/common/security/):
- XSS prevention with HTML entity escaping
- SQL injection protection with parameterized queries
- URL validation with Git provider whitelist
- Unicode attack prevention
- Input sanitization with fuzzing test coverage
- Use TLS for all external communications
- Implement network policies in Kubernetes
- Restrict database access to application components only
- Review the security middleware in
internal/adapter/inbound/api/security_middleware.go
- Store API keys securely (never in version control)
- Use external secret management systems
- The
.env.examplefile shows which values need to be secured
Use the provided Makefile for deployment tasks:
make build- Build production binarymake build-docker- Build Docker imagemake migrate-up- Apply database migrationsmake test-integration- Run integration tests before deployment
The system uses Viper configuration with this priority:
- Command-line flags (highest)
- Environment variables (with
CODECHUNK_prefix) - Config files (
config.prod.yaml) - Defaults (lowest)
See internal/config/config.go for the complete configuration structure.
Based on the test suite results:
- NATS Throughput: 305,358+ messages/second
- Health Check Response: 23.5µs average response time
- Health Check Caching: 5-second TTL with memory optimization
See the migration files in /migrations/ for optimized indexes:
- HNSW vector indexes for pgvector
- Unique constraints for duplicate prevention
- Performance indexes on frequently queried fields
Configure worker concurrency using:
./codechunking worker --concurrency 10Or set via environment variable:
CODECHUNK_WORKER_CONCURRENCY=10Refer to the main README.md troubleshooting section for common deployment issues including:
- pgvector extension problems
- NATS connection issues
- Migration failures
Use the enhanced health endpoint for troubleshooting:
curl -v https://your-api-host/healthCheck response headers:
X-Health-Check-Duration: Response time diagnosticsX-NATS-Connection-Status: NATS connectivityX-JetStream-Enabled: JetStream availability
Review structured logs for:
- Correlation IDs to trace requests across components
- Performance metrics for bottleneck identification
- Security validation events
- Circuit breaker state changes
For detailed implementation and configuration examples:
- Configuration:
/configs/directory - Docker:
/docker/directory anddocker-compose.yml - Database:
/migrations/directory - Health Monitoring:
/internal/adapter/inbound/api/health_handler.go - Security:
/internal/application/common/security/ - Logging:
/internal/application/common/logging/ - Environment Variables:
.env.example
For deployment issues:
- Review the troubleshooting section in README.md
- Check the test files for configuration examples
- Examine the Docker Compose setup for service dependencies