cometchat-self-host
Ground truth: deployment detail is FETCHED from the live on-premise docs —
{DOCS_BASE}/on-premise-deployment/docker/overview,/docker/prerequisites,/docker/production-deployment,/docker/security,/docker/persistence-and-backup,/docker/configuration-reference,/docker/air-gapped-deployment, and/kubernetes/overview(DOCS_BASE = https://www.cometchat.com/docs; append.md). On-prem is a licensed enterprise offering — contact CometChat sales for the images, license, and support. The exact client host-override field is in the on-prem client/configuration docs — fetch it there; do not guess a setting name.
Use this skill when
The customer needs the chat backend inside their own perimeter: data sovereignty, an offline/air-gapped network, a regulated industry, a residency clause the SaaS regions can't meet, or fixed-cost infrastructure instead of per-MAU SaaS pricing. Self-hosting (on-premise deployment) is a CometChat enterprise offering — position it as a differentiator, but don't assert what specific competitors do or don't offer without checking their current docs.
Why self-host (vs the SaaS regions)
- Data sovereignty — all data (messages, media, backups) stays on infrastructure you control, which supports your GDPR/HIPAA/SOC 2 and residency obligations (compliance is the customer's to certify; self-hosting removes the SaaS data-location constraint). (Region selection in SaaS is
cometchat-compliance; self-host is the stronger step.) - Air-gapped / private network — deploy with no public internet dependency (
/docker/air-gapped-deployment). - Predictable economics — fixed infra cost, no per-user SaaS pricing.
- Operational control — your monitoring, your security perimeter, direct component access.
Deployment models (pick by scale)
| Model | Target | Use when |
|---|---|---|
| Docker Swarm | ~10k–200k MAU, ~20k peak concurrent | most on-prem deployments; lower operational overhead (/docker/overview) |
| Kubernetes | 200k+ MAU, multi-region active-active, autoscaling | large scale or multi-region (/kubernetes/overview) |
| Air-gapped | offline / isolated networks | export images, transfer, run from a local registry (/docker/air-gapped-deployment) |
The platform is microservices (WebSocket gateway · Chat API · Moderation · Notifications · Webhooks) over a Kafka event bus, with TiDB (distributed SQL) + MongoDB + Redis and optional S3-compatible object storage. You don't wire these by hand — the deployment scripts do — but size the hosts for them (/docker/prerequisites).