Publication

Self-host or hosted: how to choose a corporate messenger model

A breakdown of two deployment models for a messenger on Matrix and Element: who owns the server and data, areas of responsibility, updates, backups, and selection criteria.

Rollout 4 min
Infographic of choosing between a self-host and hosted corporate messenger model

A corporate messenger on Matrix and Element can be deployed two ways: on the company’s own server or in infrastructure held by KMVSG. This choice determines who owns the server, the domain, and the data.

The question is not which model is “better in general,” but which fits a specific team in terms of responsibility, updates, and backups. The open protocol does not lock you to a single vendor and lets you change the scheme later.

Deployment model

How to choose between self-host and hosted

  1. 01Data ownership
  2. 02Areas of responsibility
  3. 03Updates and backups
  4. 04Final decision
  • In self-host the company itself owns the server and data
  • In hosted KMVSG holds the infrastructure
  • The open protocol does not lock you to a single vendor

Who owns the server and data

In the self-host model the company owns the server, domain, and data directly: everything is stored in its perimeter and access to the infrastructure stays inside. This is maximum control, but also maximum responsibility.

In the hosted model KMVSG holds the infrastructure and the company gets a ready-made work environment. Deployment can be arranged so that the data stays in Russia, which matters for many B2B scenarios.

  • self-host: the server and data are with the company
  • hosted: KMVSG holds the infrastructure
  • the domain can stay with the company in either model
  • no lock-in to a single vendor

Where the areas of responsibility lie

The main difference between the models is who is responsible for uptime. In self-host the team takes on server administration, monitoring, and incident response, usually with support from KMVSG.

In hosted the routine operations fall to KMVSG, and the company focuses on communications, roles, and processes. This lowers the requirements for an in-house technical team.

Updates and backups

A messenger lives a long time, so what matters is not a one-off installation but updates and the backing up of important discussions. In self-host the company plans them; in hosted, KMVSG does, on an agreed schedule.

In either case it is best to agree in advance on how often updates are applied, how backups are made, and who is responsible for recovery. Without this, even a reliable installation gradually becomes unmanageable.

Which model is for whom

Self-host is usually chosen where there is in-house infrastructure, a requirement to keep everything in your own perimeter, and a team ready for operations. Hosted fits companies that care more about a quick start and predictable support.

Because Matrix is an open protocol without vendor lock-in, a hybrid is also possible: a closed server, federation, or a combined scheme. The model can be revisited as you grow, without rewriting communications from scratch.

Quick checklist

  • Decide whether the server must be in your own perimeter
  • Assess your team for operations
  • Agree on the update schedule
  • Define the backup and recovery procedure
  • Establish where the data is hosted

What to do next

KMVSG helps choose between self-host and hosted, design the deployment of a messenger on Matrix and Element, and take on the updates and support.

Discuss your task