Open-source alternative to Slack Connect

Open-source alternative to Slack Connect: the short answer for shared channels

No single open-source product copies Slack Connect exactly. If you share channels with customers or partners today, the realistic options are Matrix federation between separate homeservers, Rocket.Chat federation with Matrix, or guest accounts in Mattermost. Each one gives outside people access to conversations without placing them in your main workspace, but each works differently in identity, permissions, retention and administration. Slack Connect channels also do not move with a Slack export. Mattermost's documented migration path, for example, does not carry them across, so replacing them is a design decision you make in advance, not a data move you run at cutover. The choice depends on who your external users are and how much control you need over the connection. Matrix federation links two independent homeservers, so each organization keeps its own user directory, retention settings and audit trail, and you can restrict traffic to listed domains through Synapse's federation_domain_whitelist setting or switch federation off entirely. Mattermost guest accounts keep everyone on one server, which simplifies administration but means outside users sit inside your deployment and need the same review as internal accounts. Rocket.Chat's Matrix federation sits between the two and depends on the Rocket.Chat plan and features you run.

Before you pick one, run a short review with your security and legal teams. List every external domain that needs access, decide who approves each one, and confirm how guest or federated accounts are created, deprovisioned and logged. Check whether the external party's own server needs to meet your retention rules, and ask the vendor or your own tests to confirm the exact federation, guest and audit behavior for the versions you plan to deploy. Document the decision, because the result shapes your identity setup, network rules and support load for as long as the shared channels exist.

How Slack Connect capabilities map to open-source options

This table compares the core Slack Connect capabilities with Matrix federation, Rocket.Chat federation and Mattermost guest accounts. Read each row as a question to put to the platform: where a cell says to confirm, the supplied research does not settle that point, so verify it against the current documentation and your own test environment before deciding.

Capability	Matrix federation (Synapse)	Rocket.Chat federation	Mattermost guest accounts
Cross-organization channels	Rooms can be shared between homeservers that federate, so a channel is hosted on one server and joined from another. Confirm room hosting and moderation behavior for your version.	Federation with Matrix is the documented route for connecting Rocket.Chat to other servers. Confirm which channel types federate and on which plan.	Guests are invited into channels on your own server. There is no documented connection to a separate Mattermost organization in the supplied research.
External user identity	Each user keeps an identity on their home server (for example @user:example.com), and server_name fixes how identities are named. Delegation can serve those IDs from another host.	External users sign in through their own home server, so identity depends on that server's policies. Confirm how external identities are displayed and audited.	Guests are accounts created on your server. Confirm how guest accounts map to an external identity provider on your plan.
Per-channel access control	Access to rooms is governed by room membership and power levels. Confirm which settings you can set per room and per server.	Confirm the role and permission model for federated rooms on your plan and version.	Guest access is limited to the channels they are added to. Confirm which guest restrictions require a paid edition.
Domain allow-listing	federation_domain_whitelist restricts federation to listed domains, and an empty list disables federation. The docs also recommend firewalling the federation listener.	Confirm whether a domain allow-list is available in the edition you deploy and how it is enforced.	Not applicable as a documented control in the supplied research. Restrict guest creation and sign-in at the identity provider and your network layer.
Message history for shared channels	History is stored on the server that hosts the room, so retention policy on each side decides what remains. Confirm retention behavior for remote history.	Retention is a configurable feature on Starter and paid plans. Confirm how it applies to content received from federated servers.	History stays on your server for channels your guests join. Confirm retention and export behavior for guest messages on your plan.
Admin visibility	Server administrators see their own users and rooms. Visibility into remote users' activity depends on the remote server, so confirm what logs and audit records you can obtain.	Paid plans list tamper-evident audit trails of messages, files and sessions. Confirm whether these cover federated activity.	Compliance export and related controls are in paid Enterprise plans. Confirm which guest activity appears in exports before relying on them.
Paid edition dependency	Synapse is AGPL-3.0 with commercial licenses from Element. Element Server Suite Pro and Sovereign add supported packages. Confirm which features need them.	Federation and the security features listed for paid plans need a Commercial, Government or Defense plan. Confirm the exact list for federation.	SSO, AD/LDAP sync and compliance export require Professional or higher. Guest features are not listed in the supplied research, so confirm the edition.
Security review needed	Review the federation listener, allow-list, TLS setup, and which remote servers your users can reach. Plan for upgrades, because Synapse upgrades can be difficult to roll back.	Review the federation configuration, the Matrix link, and the support window for your version. Upgrades are needed to keep security fixes.	Review guest account lifecycle, sign-in controls and channel membership. Confirm how guests are removed when a partner relationship ends.

Which option fits which partner relationship

Each option connects your chat to outside organizations in a different way, and each one moves a different set of controls onto your team. The right choice depends on whether the partner runs its own server, whether they need a full Slack Connect style shared channel, and how much of the security review you are willing to own.

Matrix federation between Synapse servers

Two organizations each run a Synapse homeserver and federate over port 8448 by default, or through delegation that serves user IDs such as @user:example.com from another host on port 443. The server_name setting fixes how users and rooms are identified, so it cannot be changed casually after launch. Set federation_domain_whitelist to the partner domains only, and firewall the federation listener as the Synapse docs recommend. Confirm that the partner can run a compatible Synapse version and that both sides agree on retention and key handling.

Rocket.Chat Matrix federation

Rocket.Chat's core code outside its enterprise directories is MIT licensed, so teams can read and modify most of the platform without a commercial agreement. The free Starter plan allows up to 50 users and includes LDAP, SSO, MFA and retention, which suits a small pilot with one partner. Multi-instance and microservice designs for larger partner networks require a paid plan. Ask the vendor to confirm exactly which federation features sit in the enterprise directories before you commit to a design.

Mattermost guest accounts

Mattermost Team Edition is free, open source and aimed at teams under 250 users that do not need single sign-on, so guest access on this tier means your team manages each external account by hand. Partners sign in with local credentials that you create and remove, and you own the offboarding process. SSO through SAML, OIDC or OAuth and AD/LDAP sync are included from the Professional plan, and compliance export sits in the higher tiers. Confirm which guest features your chosen edition includes before promising access to a partner.

How domain allow-listing and federation limits control who gets in

The most direct control on Synapse federation is the federation_domain_whitelist setting in the homeserver configuration. It restricts federation to the domains listed there, and an empty list disables federation entirely. For a Slack Connect replacement, that makes each allowed domain a deliberate decision: a partner domain goes on the list when a contract, a shared project or a named set of users requires it, and it comes off when that relationship ends. The setting is only as strong as the network behind it, so the Synapse docs recommend also firewalling the federation listener. Treat the list and the firewall rule as two separate controls, record both in the change ticket, and test them together. Block a non-listed test domain from a test account on both sides, confirm the request fails at the listener, and confirm the list change takes effect in your own environment before any partner is told the channel is live.

The allow-list should map one to one onto the partner agreements your legal and security teams already keep. Each entry needs an owner, a contract reference and a review date, and the security review should ask which users on the partner side can reach which rooms. Choose server_name before the first install, because it fixes how user IDs such as @user:example.com and room identifiers are formed, and Synapse's federation docs describe it as the value that identifies users and rooms. Changing it later is not a routine edit, so confirm the value with your domain and delegation plan before you create accounts. Ask your Matrix team which identities and rooms remain on your server when a partner domain is removed, and test that on a copy of the environment. The Synapse documentation should be checked for the version you run, because behavior around existing remote users and room membership is the point to verify, not assume.

What each approach needs in a security review

Matrix federation links two separately operated homeservers, so every outside user's identity is verified by their own server, not yours. Your review has to decide which remote servers are trusted at all, what your side can see in shared rooms, and how the federation listener is exposed. Synapse allows you to restrict federation with an allow list, or disable it with an empty list, which turns a broad trust decision into a short, named set of domains.

Identity source for external users: Local accounts are authenticated by your Synapse instance through OpenID Connect (oidc_providers), SAML2 (saml2_config) or CAS. Confirm which identity provider vouches for your own staff and whether external users ever get local accounts at all.
Federation scope: Use federation_domain_whitelist to list only the partner domains approved in writing. The docs recommend also firewalling the federation listener, so review the port 8448 path and any delegation records as separate network items.
Data exposure in shared rooms: Anything posted to a federated room is copied to every participating server. Review which rooms are federated, who can invite remote users, and whether encrypted rooms are required for sensitive content.
Retention and export: Each homeserver keeps its own copy. Confirm retention on both sides, and agree in advance how the partner's copy is handled when the relationship ends.
Patch cadence: Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, and rolling back can be hard because of schema changes. Plan a tested upgrade path and a named owner for security releases.

Before approval, confirm the allow list, the identity provider settings and the federation firewall rules with your platform team.

How to move existing Slack Connect channels to a self-hosted setup

This sequence turns each shared Slack Connect channel into a planned, agreed move: you know who uses it, which server model each partner will use, and what history stays behind in Slack before anyone is invited.

Inventory every Slack Connect channel and its members
List each Slack Connect channel in your workspace, the external organizations connected to it, the internal owners, and the purpose of the channel. Mark which channels carry contracts, incident traffic or customer support, since those need the most care. Slack Connect channels are not included in Mattermost's documented Slack migration, so this list is the only record of what must be rebuilt by hand. Done means a table with one row per channel and a named internal owner for each, reviewed by the business leads who depend on them.
Confirm your Slack plan and what you can export
Check which Slack plan the workspace is on. Slack's export documentation says every plan can export public channel messages, but private channels and direct messages need a Business+ or Enterprise plan, and custom exports by member or conversation are Enterprise-only. Ask your Slack administrator whether the export you need is available, and if not, what the approval process requires. Done means a written note stating which conversation types you can export, so the history decision in a later step rests on facts rather than assumptions.
Agree the partner's server or guest model
For each partner, decide whether they will join your self-hosted server as a guest account, operate their own homeserver and federate with yours, or use a separate workspace in the same product. Matrix federation between separate homeservers, Rocket.Chat's Matrix federation and Mattermost guest accounts each carry different identity, moderation and security review requirements, so record the choice per partner. Ask each partner what their security team permits. Done means a signed-off decision per partner, with the partner's technical contact named.
Stand up the chosen server and identity setup
Install the server you selected in your own infrastructure, using the vendor's deployment guidance for database, file storage and backups. Connect single sign-on or directory sync if your policy requires it, noting that some of these features sit in paid editions of Mattermost and Rocket.Chat. For Synapse, the federation_domain_whitelist setting restricts federation to listed domains, and an empty list disables it. Done means a test user can sign in, the server name is final, and the admin team has documented the configuration.
Configure allow-listing and review the security model
Restrict federation or guest access to the partner domains you approved in the previous step, and block everything else at the network layer as well as in the application. The Synapse documentation recommends firewalling the federation listener in addition to the configuration setting. Have your security team review the guest or federation permissions, what external users can see, and how accounts are removed when a partnership ends. Done means a written allow-list and a completed security review, with any open risks accepted by a named owner.
Invite partners and recreate each channel
Create the channels on the new server with the same purpose and membership as the Slack originals, and invite each partner's named users under the access model agreed earlier. Recreate pinned resources, such as links and reference documents, and re-create any Slack Connect integrations or bots by hand, because Slack Connect channels and integrations do not move through the documented migration path. Done means each partner confirms in writing that they can post and read in their channel, and the internal owner signs off on membership.
Decide what history stays in Slack and agree cutover dates
For each channel, decide whether history is exported, kept read-only in Slack, or left to expire under the plan rules. On Slack's Free plan, older content is limited to 90 days of visible history and content older than one year is permanently deleted, so export or retain anything you must keep before that point. Because partners also change systems, agree a cutover date with each one and set a date after which Slack Connect posting stops. Done means a dated cutover record per partner and an archived copy of any history you chose to keep.

Questions buyers ask before replacing Slack Connect

Does a self-hosted option match Slack Connect exactly?

No open-source option reproduces Slack Connect one for one, so treat the replacement as a set of separate choices. Matrix federation links two separate homeservers, Rocket.Chat can federate with Matrix, and Mattermost handles outside people as guest accounts on your own server. Each path gives you different controls over who can join, which rooms are shared and where message history lives. Slack Connect channels are also not carried over in a Slack migration, so shared channels need to be rebuilt deliberately. Confirm each option's behavior for your exact collaboration pattern in a proof of concept before you commit.

What drives the effort of replacing shared channels?

Three factors dominate: the number of partner organizations, how their identities are federated, and how deep the security review must go. Each new partner adds a domain to allow-list, a trust decision and a set of accounts to govern. Identity federation through SAML, OpenID Connect or directory sync is usually the largest single piece, because it determines who can sign in and how access is removed. A deeper review of federation settings, retention and data handling adds time at the start and recurring checks later. Ask any provider to scope these three factors separately in the written proposal.

Can our own team run a self-hosted partner chat?

Yes, if you have people who already run Linux servers, a PostgreSQL database and a reverse proxy, and who can own the identity and network decisions. Mattermost runs as a single Linux binary with PostgreSQL, so a small team can start with a basic deployment. Matrix federation and Rocket.Chat's MongoDB replica set add operational work that is easier to staff with experienced administrators. Be honest about on-call coverage, because an outage affects every partner at once. Many organizations split the work, keeping day-to-day administration in-house and bringing in outside help for the initial design and the security review.

What work do we need from our own staff?

Your staff must supply decisions and access that only you can provide. Identity owners decide who is a partner user, how sign-in is federated and how accounts are removed. Network staff open the federation port, configure DNS and delegation, and restrict outbound traffic to approved domains. Data owners set retention, legal hold expectations and what may be shared with an external party. Ask for a named owner for each of these before work begins, because most delays come from waiting on those decisions rather than from the technical build.

How long does the work take, and what changes the timeline?

The timeline depends on scope, and no fixed duration applies to every organization. A single pilot with one partner and existing identity federation is far shorter than a multi-partner rollout with new federation, retention rules and a formal security review. Scope drivers include the number of partners, the number of identity providers, whether you need a phased cutover from Slack and how many integrations must be rebuilt. Ask each provider to give a timeline tied to a written scope with named milestones, and to state which assumptions the timeline depends on.

What recurring work follows the initial build?

Plan for regular upgrades, because the server software changes on a fixed cadence. Mattermost publishes a new server version in binary form on the 16th of each month, and its extended support releases have defined end dates, so your team must track which line it runs. Synapse requires a supported PostgreSQL and Python version, and its upgrade notes warn that rolling back can be difficult because of database schema changes. Test every upgrade in a copy of production first and take a database backup before you start. Recurring security reviews of allow-listed domains and guest accounts also belong in the operating calendar.

When should we ask for a fixed-scope quote?

Ask for a fixed-scope quote once you can name the platform, the number of partner organizations, the identity provider and the security review depth you need. DeployOpen does not publish a price list, and a quote follows from the written scope, which covers scope, deliverables and timelines agreed before work starts. Bring your current Slack Connect inventory, the list of partner domains and your data retention requirements so the proposal reflects real conditions. Ongoing upgrades and continuous testing can be scoped separately as a retainer.

What partners need to participate

Each partner's obligation depends on which of the three models you choose. With Matrix federation, the partner runs its own homeserver, so it must operate, patch and back up that server under its own policies, and it must agree with you on the domains each side allows. With Rocket.Chat's Matrix federation, the partner also needs a server it controls. With Mattermost guest accounts, the partner usually needs no server at all: it receives accounts on your instance and accepts your policies, including sign-in rules, retention and acceptable use. Before choosing, confirm with each vendor whether federation or guest access works between a self-hosted server and a partner running a different distribution or edition, and which features (such as Mattermost guest roles or Rocket.Chat federation options) need a paid edition.

Settle ownership of shared history before any channel is opened. Decide in writing who owns messages posted in a shared room, who can export them, and who can delete them. In a federated Matrix room, each homeserver keeps its own copy of the events it has received, so deleting a message on your server does not automatically remove copies held by the partner's server. In a guest-account model, the messages sit only on your server, which gives you control but gives the partner no independent record. Also settle how retention applies in each organization, because a retention period set by your policy may conflict with the partner's legal hold or records obligations. Have legal and compliance review these terms, and confirm with each vendor how retention and deletion propagate across servers.

Put the partner obligations into the contract and the security review. Your agreement should name who may invite external users, how guest or partner accounts are approved and removed, which identity provider authenticates them, and how quickly access is revoked when a project ends. For federated partners, require evidence that their homeserver is patched, that its database and media storage are backed up, and that they accept your domain allow-listing decision. Treat a partner's server as part of your trust boundary for any data shared in those rooms. Keep the review qualitative and use each partner's answers to decide whether a shared channel is appropriate for the data involved.

How DeployOpen scopes and delivers shared-channel replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the federation or guest access model you choose for partner channels. We start from a written scope that names each external organization, the domains involved and the security review that must pass before any partner connects.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names which shared-channel model applies: Matrix federation, Rocket.Chat federation or Mattermost guest accounts.
Scope lists each partner domain, the allow-list policy and the data each external party may see.

How we build

We deploy the chosen platform in your cloud accounts, data centers or air-gapped network.
We configure domain allow-listing, or disable federation, and firewall the federation listener as the platform documentation recommends.
We test external access paths and document the security review evidence for your assessors.

How we hand over

Handover includes runbooks for adding and removing partner domains, guest accounts and access revocation.
We document the configuration, backup procedure and upgrade path for the server components in scope.
Your team receives the review records so audit and security stakeholders can check the controls independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover patching of federated servers and periodic review of the partner domain list.
Ask any provider, including us, to confirm the support window, upgrade cadence and response terms in writing.

Open-source alternative to Slack Connect