Prerequisites

This guide outlines the infrastructure, software, and network requirements for deploying CometChat on-premise. Proper capacity planning ensures optimal performance, cost efficiency, and scalability as your user base grows. Planning Considerations:

• Hardware Sizing: Select appropriate compute and storage resources based on expected monthly active users (MAU) and peak concurrent connections (PCC)
• Operating System: Choose enterprise-grade Linux distributions with long-term support
• Network Architecture: Plan for secure network segmentation and firewall configurations
• Storage Strategy: Account for data retention policies, backup requirements, and growth projections

​

Supported operating systems

CometChat on-premise is tested and supported on enterprise Linux distributions with long-term support (LTS) and security updates:

• Ubuntu 20.04 / 22.04 / 24.04 LTS: Recommended for most deployments with 5-year support lifecycle
• RedHat Enterprise Linux 8+: Ideal for enterprises requiring commercial support and compliance certifications

Why these distributions:

• Long-term security updates and kernel patches
• Docker and container runtime compatibility
• Enterprise support availability
• Proven stability in production environments

​

Required software

Ensure these software dependencies are installed before deployment:

• Docker Engine >= 24: Container runtime for service orchestration
• Docker Compose v2: Required for local development and non-Swarm workflows
• Git: Version control for deployment scripts and configuration management
• OpenSSL >= 1.1: TLS/SSL certificate generation and cryptographic operations
• jq, curl, net-tools: Command-line utilities for configuration, API testing, and network diagnostics

Installation Note: The quick start guide includes automated installation scripts for Docker and Docker Compose on Ubuntu systems.

​

Minimum hardware (testing / QA)

For development, testing, and proof-of-concept environments:

• 8 vCPUs: Sufficient for running all services with light load
• 16 GB RAM: Minimum memory for core services and data stores
• 100 GB SSD: Base storage for application data and logs (scale up based on workload and storage needs)

Important: This configuration is not suitable for production workloads or performance testing at scale.

​

Production hardware

Production sizing is based on two key metrics: Monthly Active Users (MAU) and Peak Concurrent Connections (PCC). Choose the sizing model that matches your expected usage patterns. Important: The values below represent total cluster capacity and can be distributed across multiple nodes.

​

Baseline sizing

Recommended for standard usage patterns where peak concurrent connections are approximately 5% of MAU: Storage guidance: Start at 100 GB SSD and scale to 500 GB to 2 TB SSD depending on workload and data retention policies.

​

High-concurrency sizing

Recommended for applications with sustained high concurrency where peak connections reach 10% or more of MAU: Storage guidance: Expect to exceed 100 GB SSD; plan 500 GB to 2 TB SSD as concurrency and data volume grow.

​

Storage planning considerations

Factors affecting storage requirements:

• Message retention: Longer retention periods require more storage
• Media attachments: Images, videos, and files significantly increase storage needs
• Backup strategy: Plan for 2-3x storage capacity to accommodate backups
• Log retention: Compliance requirements may mandate extended log retention (30-90 days or more)
• Growth buffer: Allocate 30-50% additional capacity for unexpected growth

Storage performance: Use SSD or NVMe storage for all production deployments to ensure optimal database and Kafka performance.

​

Required ports

Configure firewall rules to allow traffic on these ports:

• 80 / 443: HTTP and HTTPS traffic to NGINX (public-facing). Port 80 should be used only for HTTP-to-HTTPS redirection.

Network security recommendations:

• Restrict ports 80/443 to known IP ranges when possible
• Use TLS/SSL certificates for all HTTPS traffic
• Keep all backend services (databases, Kafka, Redis) on private networks without public exposure
• Implement rate limiting and DDoS protection at the load balancer level

Additional ports for internal communication: All inter-service communication occurs on Docker Swarm’s private overlay network and does not require external firewall rules. Services communicate securely within the cluster using Docker’s encrypted overlay networking.