Skip to main content
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:
MAUPeak concurrent connections (PCC)vCPUsRAM
10k5003264 GiB
25k1,25064128 GiB
50k2,50096192 GiB
100k5,000156312 GiB
200k10,000272544 GiB
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:
MAUPeak concurrent connections (PCC)vCPUsRAM
10k1,0004896 GiB
25k2,50096192 GiB
50k5,000156312 GiB
100k10,000240480 GiB
200k20,000480960 GiB
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.