VK WorkSpace Federation Enables Secure Multi-Organization On-Premise Messaging Without Infrastructure Merge

VK Tech has introduced federation support for VK WorkSpace that links separate On-Premise installations while ensuring each organization retains complete sovereignty over its servers, databases, and security policies.

The solution addresses the common requirement for project teams to communicate with contractors, partners, and subsidiary companies without moving work conversations to public services. In the initial November 2025 pilot, two installations could exchange messages after one side issued an invitation and the other confirmed the trust relationship. The July 2026 release 26.2 removed the pairwise limitation, allowing a single group chat to include participants from multiple independent On-Premise environments.

Access is governed at two levels. First, a mutual trust is established between installations. Second, each administrator explicitly grants external-communication rights to selected employees for that specific trust. Only approved users see external contacts and can initiate dialogues or join federated group chats. The corporate directory is not replicated; only minimal profile data—name, work email, and organization flag—is shared.

Three architectural approaches were evaluated. A single-host model with proxy access was rejected because loss of the host would break history availability for all other parties. Adoption of the open Matrix protocol was also declined because it would have required extensive remapping of existing entities, rights, and APIs. The chosen design replicates only federation-related objects and events at the application layer so that each installation stores its own copy of permitted messages and files.

This local-replication model delivers several security and operational benefits: data remains under each organization’s control, local DLP, audit, and retention policies continue to apply, and no user session is created in a foreign environment. When a trust is revoked, already-received history stays in the local instance.

Client applications continue to connect exclusively to their own installation. A dedicated federation layer intercepts relevant operations, forwards them through secure gateways, and replays them via the local messenger API on the receiving side. The core messenger logic remains unchanged, although every new feature must still be validated for multi-party federation compatibility.

Extensive dogfooding on internal test stands helped refine both the protocol and the user interface, particularly the hiding of unsupported actions to prevent user errors. The feature is now deployed in production On-Premise environments at several customer sites.