Self-hosted messaging for business: when your own server makes sense and when it doesn't

An article for business owners and sales leaders considering moving chat, voice calls, and client meetings onto their own infrastructure. We explain when a self-hosted business messenger is a sensible choice, what needs to be designed into it, and which risks to plan for from day one.

What a self-hosted messenger is and how it differs from Slack or Meet

A self-hosted communication platform is an app for chat, calls, and video conferencing running on a server the company manages (its own or a rented VPS). Messages, recordings, and transcripts stay in its own infrastructure, not in a SaaS vendor’s cloud.

The difference isn't just about where data is stored. With your own deployment, the company decides on recording retention, who has access to recordings, and which tools (e.g., AI models) may process them. With off-the-shelf services, the provider makes those decisions in its terms of service.

A self-hosted business messenger doesn't have to mean writing everything from scratch. A sensible implementation consists of mature open-source components (media server, database, queues) and a custom application layer that addresses the team's specific needs.

An alternative to Slack and Google Meet: when it's worth considering

For most companies, off-the-shelf tools are enough. A custom solution starts to make sense in three situations, which often occur together:

• client conversations are data you don't want to hand over (recordings, transcripts, sales notes),
• the team uses several tools in parallel and pays for each one per user,
• you want AI to work with your playbook and CRM data during the call, not just summarize it afterward.

In the implementation described above, the team worked with four tools: TeamSpeak for voice, Slack and Discord for chat, Google Meet for client meetings, and separate recording software. Four logins, four sets of notifications, and decisions got lost between them. JSONMeet replaced them with a single app.

Recording calls on your own server: requirements worth writing down

Before the first line of code is written, it’s worth writing down the business requirements. In the project described, they were: one app, a self-hosted server, clients join from a link without an account or installation, screen sharing good enough to show an interface in 4K, and recording with a clear notice to all participants.

This leads to specific features. A guest lands in a waiting room and doesn't connect to the media server until the host lets them in. Recording happens server-side to an MP4 file, and a “Recording” banner is visible throughout the call. The recordings list has a retention policy with automatic deletion, configurable from 7 days to unlimited.

This last point matters for GDPR. If the recordings are stored with you, you don't need another data processing agreement every time you want to transcribe or analyze them with a different tool.

Architecture: WebRTC, media server, and client firewalls

The core of every messaging app with video is an SFU media server, which receives streams from participants and forwards them on. In JSONMeet, this is a self-hosted open-source LiveKit: SFU for audio and video, Egress for recording, and Ingress for receiving the stream from the presenter’s app.

The most common risk with self-hosting WebRTC is a corporate firewall on the client's side. It needs to be planned for from the start. Here, the server has built-in TURN over TLS on port 5349 and a fallback TCP transport, and for the most restrictive networks there's a second IP address with TURN on port 443, which looks like ordinary HTTPS traffic to the firewall.

The second decision is video quality. The camera goes out in VP9 with three quality layers and screen sharing in H.264 simulcast, so a recipient with a weaker connection gets a lighter layer without degrading the picture for others. For studio presentations, a separate app encodes the video in hardware and sends it via WHIP with no server-side re-encoding. Presets go up to 4K30 and 1440p60.

AI prompter for sales reps: AI during the call, not after it

A meeting summary after the fact doesn’t help much a sales rep who hears an objection and has a few seconds to respond. That’s why, in the implementation described, the call transcript is fed live to a language model together with the company’s playbook: a matrix of 26 objections, price negotiation rules, and a company brief.

Before the call, the sales rep selects a lead from the CRM, and the prompter receives its context. During the call, it shows the detected objection, a suggested response, questions to ask, and a readiness-to-close score on a scale of 0 to 100. The client doesn't see this panel. After the call, analysis, a scorecard, and transcript search are available.

An important detail: transcription and the model run on in-house GPU servers connected to the application server over a private network. Conversation content never goes to an external AI provider. A single entry point to the model for all AI features means that switching models is just a configuration change.

Maintaining a self-hosted messenger without a DevOps team

A common question is: who will maintain it? The answer depends on how simply you design production. JSONMeet runs on a single VPS in Warsaw (8 vCPU, 16 GB RAM) with services under systemd, without Docker or an orchestrator. Deployment is a single script: archive from git, build, database migrations, service restart.

In testing, this server handled a room with about 30 participants, 10 of whom were sharing video, at under 50% CPU load. Ping from Poland is about 10 ms. The Electron desktop app pulls interface updates from the server, so there's no need to update it manually on each computer.

For companies that don't want to run a server themselves, a sensible option is an instance maintained by a technology partner. The data still stays in dedicated infrastructure, and responsibility for updates and security is set out in the contract.

Before deciding, it's worth calculating three things: how many people and tools the change will affect, how valuable call recordings are to you, and whether AI should work on your data. If the answers point toward control over your data, a self-hosted messenger for your company is worth considering.

We design similar systems as part of custom web applications, and features based on language models, such as the live prompter, as part of AI implementations; we describe connecting the messenger to a CRM in ERP and CRM integrations.