Self-hosted live chat: a practical guide

Self-hosting is not “install a chat room on a box”. Run every candidate (open source or commercial) through these seven checks — a miss on any one turns into an incident or a rewrite in production:

• Delivery guarantees: ACKs, retries, ordering — “occasionally drops a message” is not acceptable
• Fan-out throughput: measured numbers for broadcast scenarios, not marketing claims
• Agent workspace: queueing, assignment, transfer and human↔AI collaboration are the daily surface
• AI: can it plug into your own model and knowledge base; are answers grounded
• Client SDKs: coverage and customization depth across web widgets and mobile (Flutter / React Native, etc.)
• Deployment footprint: minimum viable single node, and a scale-out path that does not touch clients
• Licensing: open source ≠ free for production; check which capabilities sit behind paid editions

SaaS live chat (Intercom, MeiQia et al.) bills per seat — fast, but the vendor holds both your data and your cost curve. Open-source assembly (Chatwoot-class plus a self-built messaging layer) looks free until you price delivery guarantees and mobile SDKs. Commercial self-hosted engines (IMCore-class) are buyout-oriented and ship the full server plus clients — the line-by-line comparison lives on the comparison pages.

Using IMCore as the example: pull the one-command local stack (PostgreSQL + Redis + server) first and verify messaging plus the agent workbench; then follow the production Compose guide onto a VPS — automatic HTTPS via Caddy, database and Redis never exposed; finally embed the web widget and mint JWTs from your backend. Scaling to a cluster later touches no client code.

Capacity reference: one 4C8G node measured at 10,000 concurrent connections, ~40k fan-out messages per second, p99 153 ms — far beyond the support traffic of most sites.