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 plenty of teams that trade-off is fine. For teams handling client confidences, regulated data, or work that simply should not become 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 become a maintenance burden of their own.
What it does
Direct and group conversations, replies, emoji reactions, read state and unread counts, live presence, typing indicators, file attachments with image thumbnails, message editing and deletion, pinning, archiving and muting. Enough to run a team on, delivered in real time over websockets.
How it is built
The system is verifiable end to end on a laptop before any commitment is made.
docker compose up brings up PostgreSQL, Redis, the API and an nginx-served
client, applies its own migrations, seeds itself, and gives you working
real-time messaging between two browsers with no configuration and no cloud
dependency.
npm test exercises the production SQL against a real PostgreSQL engine running
in-process — the same migrations, the same queries, no database installed on the
machine. Coverage concentrates where the risk is: session lifecycle, access
control on every conversation operation, unread-count semantics, authorship
checks on edit and delete, and rejection of non-members.
Underneath that:
- Layering that holds. Routes delegate to services, services to a single data layer; all SQL lives in one place. Every mutating input is schema-validated and rejected with a proper error rather than reaching the database.
- Security treated as default, not hardening. Login performs constant work even for accounts that do not exist, so response timing cannot enumerate users. The expected baseline — password hashing, rate limiting, content-security policy, upload validation, secret-redacted logs — is applied throughout rather than listed as a feature.
- An append-only audit log written from every mutating operation.
- Graceful degradation. Redis is optional — add it and presence and rate limiting work across multiple instances; leave it out and the app runs on one modest server and says so in the logs rather than failing.
- Your data stays ordinary. A standard PostgreSQL schema with foreign keys and constraints, which you can back up, query, export and audit with tools you already have.
Its trust model
ChatForge protects messages by keeping them on infrastructure you control and by hardening the server — not by end-to-end encryption. The server you operate can read message content, which is precisely what keeps history searchable, exportable and auditable with ordinary tooling.
That makes it a sovereign team-messaging platform rather than a private messenger. If your threat model requires that the operator cannot read messages, this is the wrong tool today and we will tell you so in the first conversation.
Phase 1 scope is real-time text collaboration. The roadmap beyond it is mapped and costed, and we walk evaluating teams through 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.