The problem it addresses
Team messaging is where most organisations do their real thinking, and for many of them every word of it sits in a third party’s database, in a jurisdiction they did not choose, on terms that change when the vendor’s pricing strategy does.
For a lot of teams that trade-off is fine. For teams handling client confidences, regulated data, or work that simply should not be a bargaining chip in someone else’s renewal negotiation, it is not — and the usual alternatives are either heavyweight enterprise suites or self-hosted projects that are a maintenance burden in their own right.
ChatForge is a middle path: a messaging platform that behaves like the tools people already know, that a small team can actually stand up and run, and that keeps every message on infrastructure you control.
What it does
Direct and group conversations, threaded replies, reactions, read receipts, live presence, mentions, file attachments and full-text search across history — the set of things that make a messaging tool usable rather than merely functional.
It is built to be operated, not just installed:
- One command to run it. The whole stack comes up together, applies its own database migrations at startup, and is ready to use.
- Scales down as well as up. It runs on a single modest server for a small team. Add the optional cache layer and it runs across multiple instances with shared presence — but nothing forces that complexity on a team that does not need it.
- Hardened by default rather than as an afterthought. Content security policy, request rate limiting per route, and properly hashed credentials are on out of the box, not documented as recommended hardening steps.
- Your data stays yours. A standard PostgreSQL database you can back up, query, export and audit with ordinary tools.
Where it actually stands
ChatForge is Phase 1: a real, working foundation — implemented, tested and running end to end, not a prototype.
What Phase 1 deliberately does not include: encryption between participants, so the server can read message content; voice and video calling; push notifications; offline use; and native mobile apps. Those are scoped for later phases, and we have mapped in detail what closing each gap actually costs.
We list them because “team messaging foundation” and “private messenger” are different products, and a buyer deserves to know which one they are looking at before the evaluation rather than after it.
Talk to us about
Self-hosted collaboration platforms, real-time application architecture, moving a team off a SaaS tool onto infrastructure you control, or extending an existing messaging system with the parts it is missing.