Logo
← back to projects
Organizational chat inside the applications — Docker, Docker Compose, Nginx, MongoDB

Organizational chat inside the applications

Real-time rooms injected into the products people already use — messages stay on your document cluster, not in a public messenger.

Problem

Work happens inside internal apps. Conversation happens somewhere else. Teams leave the product to ask a question, lose context, and park decisions in a public messenger they do not control. Retention, identity, and access become someone else's policy. Building a chat stack from scratch — rooms, presence, history, files, search — is a product of its own.

The organization needed talk next to the work: the same login, the same screen, the same perimeter. Messages are documents. They belong on the document servers already running for other services, not on a rented inbox.

System Design

This project is a self-hosted chat layer, injected into the applications. A widget or embed sits in the product UI. Users do not open a second tool. Identity follows the organization: one account, rooms per team or per app.

The chat service writes rooms, messages, and attachments as documents on the existing non-relational cluster. That cluster already has replicas and failover; chat does not get a leftover single box. A reverse proxy terminates TLS and routes the embed and the API on the internal domain.

Deploy is a stack on your infrastructure. Apps only mount the embed and pass the current user. History stays inside the network.

Architecture Decisions

  • Embed in the product instead of a separate messenger tab
  • Self-hosted so transcripts never leave the organization
  • Document store for rooms and messages — flexible records, not a rigid mailbox schema
  • Persistence on the existing replica cluster, not a new single-node database
  • Reverse proxy so the embed is just another internal HTTPS path
  • Same identity as the apps so people do not keep a second password

Tradeoffs

  • You own uptime, upgrades, and storage growth of the transcript
  • An embed is only as good as the host app's layout and auth handoff
  • Chat load shares the document cluster — capacity planning must include it
  • Search and retention policies are yours to define; a public messenger would have done that for you
  • Real-time presence adds connections; the proxy and the cluster have to be sized for it

Production Behavior

Bring the chat stack up against the document cluster, put it behind HTTPS, and inject the embed into each application. People talk in the screen they already have. When a document node fails, the replica set keeps history available.

Back up the chat collections with the rest of the document data. Built for organizations that need conversation next to the work, on infrastructure they already operate.