A new chapter for Federation at Rocket.Chat: The shift to a native solution

At Rocket.Chat, our mission has always been clear: empowering organizations with secure, flexible, and open communications. From day one, we set out to build more than just another messaging tool. We aimed to create a platform that connects people and systems without borders—across teams, organizations, and external stakeholders.

One important part of this mission has been federation - the ability to communicate across different systems and instances without being tied to a single vendor. Federation is a critical enabler of flexibility and openness, which are values we hold close.

But as Rocket.Chat grows, so have the demands around this capability. We’ve had to reassess how federation serves our users today, and how it needs to evolve.

Today, we are announcing an important shift in our approach: we will be transitioning from the Matrix home server dependency model to an internal native implementation of Matrix compatible federation solution.

This isn’t a decision we take lightly. It’s the result of listening carefully to our users and learning from real-world deployments. I’d like to walk you through why we’ve chosen this path.

Reflecting on the journey: Why change course

A few years back we chose to integrate with Matrix, a protocol we respect for its commitment to decentralization and interoperability. Using Synapse, Matrix’s open-source home server, felt like a natural fit to support communication across federated Rocket.Chat servers and any Matrix compatible platforms. 

While it was a great starting point and learning exercise, the reality of deploying and scaling this approach has surfaced some limitations.

Performance and stability: Where Synapse fell short

For some of our customers, Synapse struggled to deliver production-grade performance at scale. Even with our best efforts to optimize, performance bottlenecks and stability issues persisted.

Maintaining two separate databases—PostgreSQL for Synapse and MongoDB for Rocket.Chat—added operational complexity. Syncing issues, increased infrastructure costs, and deployment overhead became common friction points.

Federation, but only within Rocket.Chat

While Matrix compliance helped us meet some RFP requirements, actual usage told a different story. The broader Matrix ecosystem hasn’t seen the traction we expected in our user base. In practice, federation was almost entirely Rocket.Chat-to-Rocket.Chat. Our customers were not connecting broadly across other Matrix clients. 

These insights have led us to reevaluate our approach to federation.

A way forward: Aligning with open principles, innovating for our users

Federation at Rocket.Chat has never been just a checkbox—it’s about breaking down silos while giving organizations control over their communication ecosystems.

Our commitment to open principles such as interoperability, data ownership, and freedom of choice remains unchanged. But delivering these values means providing a federation model that is reliable, scalable, and aligned with how our customers work. That’s why we’re building federation natively into Rocket.Chat. 

It's important to note that  this is not a rejection of open standards or the ideals behind the Matrix. If anything, this is an evolution of those principles—adapting them to better serve Rocket.Chat users. 

What’s next: Building native federation solution

We are deprecating the external home server model in favor of our native federation, planned for launch in August 2025. The native solution will deliver feature parity with the current federation model but with better performance, stability, and ease of deployment.

Key benefits:

✅ No external home server deployments required - federation comes built-in and ready to use.

✅ MongoDB as the unified data store, eliminating the need for a separate PostgreSQL database, removing sync issues, and simplifying operations.

✅ Maintains compatibility with Matrix protocol for cross-platform communication.

✅ Unlocks new opportunities for advanced federation features, tailored to how our customers use Rocket.Chat today, including cross-workspace federation and integration with other protocols like XMPP.

Support FAQ for existing customers

What will happen to the current Matrix-based federation?

We are deprecating it immediately, with removal upon the native federation launch, planned for August 2025. 

Will I lose any functionality during the transition?

No. The native federation will launch with feature parity to the current Matrix-based system. Over time, it will also introduce new capabilities.

Will Rocket.Chat still be compatible with Matrix?

The native federation will maintain compatibility with Matrix protocol, though it will be implemented natively within Rocket.Chat’s architecture. While we won’t be running Synapse, we remain aligned with the principles of open standards and interoperability.

Do I need to prepare my infrastructure for the new federation engine?

No additional infrastructure is required. Unlike the current model, which relies on separate Synapse servers and a PostgreSQL database, the native federation engine is fully embedded in Rocket.Chat and uses MongoDB exclusively. This simplifies deployment and reduces operational overhead.

Can I test the native federation before the official release?

Your feedback has guided this journey and it will continue to shape what comes next. If you’re interested in testing the new model in your environment and providing feedback, we encourage you to reach out to your Customer Success Manager or contact us here. Your insights will continue to shape the final solution. 

🚀 Watch our roadmap reveal webinar recording for a closer look at what’s coming next and stay tuned for more updates.