How a Matrix WhatsApp, Signal or Telegram bridge reaches outside contacts
Staff who work in Matrix often still need to reach customers, partners and suppliers who stay on WhatsApp, Signal or Telegram. The supported method is to self-host the mautrix bridges on the same infrastructure as your homeserver, following the setup documentation at docs.mau.fi. Each bridge runs as its own service and connects Matrix rooms to one external network, so outside contacts keep their usual app and staff keep working in Matrix. The mautrix-whatsapp, mautrix-signal and mautrix-telegram projects are published on GitHub under AGPL-3.0, and mautrix-telegram also offers a relaybot mode. DeployOpen plans and runs this deployment inside your environment, in your cloud accounts, data centers or private networks.
The first decision is the bridge mode. In puppeting mode, the bridge signs in to a real external account, so messages in a bridged room appear to contacts as coming from that person's own account. Contacts get a normal one-to-one or group conversation, but the bridge then stores session credentials for that account, which makes access control and revocation a security question. Telegram's relaybot mode instead uses a bot identity to pass messages between Telegram chats and Matrix rooms, which changes who the contact sees as the sender and what history can be reached. Ask which mode fits each use case, and confirm in each project's documentation which features that mode supports in the version you plan to run.
The second set of decisions covers ownership and terms. Decide which staff members may link their own accounts, whether shared accounts are allowed, and who can revoke a session when someone leaves. Confirm where bridge session data and databases live, how they are encrypted, and how they are backed up and restored. Ask your legal team to review the network providers' terms on automated or bridged accounts, since these terms can change and bind your staff. Also have counsel review AGPL-3.0 obligations for any modified bridge code that users reach over a network, because those obligations apply even when you do not distribute the software.
Before go-live, check feature gaps against each project's roadmap. For example, the mautrix-whatsapp roadmap lists text, formatting, media, replies, reactions and typing notifications as bridged, but marks room name, avatar and topic changes from Matrix to WhatsApp as not supported. DeployOpen's work typically covers bridge installation, registration with the homeserver, network and secret handling, and a test plan run with dedicated test accounts on each network. Ask for a written list of supported and unsupported features for each network, a rollback procedure, and a named owner for account linking and session revocation after handover.
What you need in place before installing a bridge
Five items must be settled before any mautrix bridge is installed: the homeserver version and its platform floors, the application service registration, the bridge database, bridged media storage, and the accounts that will be linked. Each one decides whether the installation can start and what the operating team must maintain afterward. Work through them in this order, since the homeserver version limits which bridge releases you can run against it.
Homeserver version and platform floors
Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. The current release listed on the Synapse GitHub releases page is v1.163.0, published October 14, 2026. Check the version you run against its upgrade notes before choosing a bridge release, because those notes also warn that rolling back can be difficult after database schema changes.
Application service registration
Each mautrix bridge runs as an application service that the homeserver loads from a registration file. That file holds the bridge's tokens and the user and room namespaces it may claim. Someone with access to the homeserver configuration must add the file and restart Synapse, so confirm that your hosting model allows this before you plan the bridge. Managed hosts that do not expose the configuration may block the install. Confirm the exact registration steps in the setup documentation for the bridge version you intend to run.
Database for bridge state
Each bridge keeps its own state: mappings between Matrix rooms and external chats, profiles for bridged contacts, and the identifiers it needs to match messages across both networks. Plan a separate database for each bridge, with its own backups and a tested restore. Confirm which database engines the bridge version supports in its documentation. Keep the bridge database on the same backup schedule as the homeserver so that both restore to a consistent point.
Media storage for bridged files
Photos, voice notes, documents and stickers from WhatsApp, Signal and Telegram are typically uploaded to the homeserver's media store, so storage use grows with conversation activity. Decide where that media is stored, who can read it, and how long it is kept before the first bridged chat goes live. Erasure requests and retention rules must cover these copies as well as the message events. Confirm the bridge's media handling options and your homeserver's media retention settings.
Accounts and phone numbers to link
Puppeting bridges link to a person's own WhatsApp, Signal or Telegram account, and each link keeps a session that can read and send messages as that person. Decide which numbers and accounts will be linked, who approves each link, how a link is removed when someone changes roles or leaves, and who holds administrative control over the bridge. Check each network's terms for linked sessions and the bridge's login flow before you set a rollout date.
Why puppeting bridges log in as each user
The mautrix WhatsApp, Signal and Telegram bridges are puppeting bridges, which means each staff member links their own external account and the bridge then acts as that account inside Matrix. This is the decision that shapes everything else about the deployment. Nobody on the team is sharing a single bot identity with the outside network. Each person's messages leave the platform looking like they came from that person's phone or Telegram account, and replies from contacts arrive in the same person's Matrix rooms. Exact login steps for each platform, including how the device or account is linked, are in the setup documentation at docs.mau.fi, so this section focuses on the operating consequences.
Session credentials are held per user. Because the bridge stores the linked session on the bridge side, the bridge host becomes the custodian of a set of live external sessions, one for every staff member who links an account. Whoever can read the bridge database, its configuration or its encryption material can potentially act as those accounts. Plan the bridge's storage, backups, host access and logging as credential infrastructure, not as an application database. Confirm with the project documentation how each bridge stores session data, what must be backed up, and how a user's link is revoked when they leave.
Conversations appear per account. A puppeting bridge mirrors the conversations that each linked account can see. Private chats, group chats, communities and status broadcasts may therefore appear in Matrix for the person who linked the account, and not for colleagues. The mautrix-whatsapp roadmap lists which WhatsApp conversation types are bridged, and it also marks room name, avatar and topic changes from Matrix to WhatsApp as not supported, so teams should not promise those edits to users. Check the roadmap for the current state of each feature before setting expectations for the pilot group.
Telegram relaybot mode is a different model. mautrix-telegram also supports a relaybot mode, in which a bot account relays messages rather than each staff member acting as their own Telegram account. That changes who holds credentials, whose identity contacts see, and which conversations are reachable. The team has to choose between puppeting and relaybot for Telegram deliberately, and should record the choice with its data-handling rationale. Do not switch between the two after users have linked accounts without a planned migration and a conversation with those users.
Decisions to take before the pilot. Agree who is permitted to link accounts, where the bridge sessions will live, how a departing employee's links are removed, which Telegram mode applies, and how staff will be told that outside contacts see their own identity. Ask any implementation partner to confirm these points in writing as part of the scope.
What each bridge supports today
This table compares the features each bridge lists for WhatsApp, Signal and Telegram. Read the mautrix-whatsapp column against its published roadmap, which lists items as bridged in one or both directions. Signal and Telegram cells direct you to confirm their feature lists in the repositories and docs before you decide on a rollout.
| Capability | mautrix-whatsapp | mautrix-signal | mautrix-telegram |
|---|---|---|---|
| Text and formatting, Matrix to WhatsApp | Listed on roadmap as bridged | Confirm in repository and docs | Confirm in repository and docs |
| Media and files, Matrix to WhatsApp | Listed on roadmap as bridged | Confirm in repository and docs | Confirm in repository and docs |
| Location, Matrix to WhatsApp | Listed on roadmap as bridged | Confirm in repository and docs | Confirm in repository and docs |
| Replies, reactions and polls, Matrix to WhatsApp | Listed on roadmap as bridged | Confirm in repository and docs | Confirm in repository and docs |
| Read receipts and typing notifications, Matrix to WhatsApp | Listed on roadmap as bridged | Confirm in repository and docs | Confirm in repository and docs |
| Private and group chats, WhatsApp to Matrix | Listed on roadmap as bridged | Confirm in repository and docs | Confirm in repository and docs |
| Communities and status broadcasts, WhatsApp to Matrix | Listed on roadmap as bridged | Confirm in repository and docs | Confirm in repository and docs |
| Room name, avatar and topic changes, Matrix to WhatsApp | Marked not supported on roadmap | Confirm in repository and docs | Confirm in repository and docs |
Configuration sequence for the bridge deployment
This sequence takes a Matrix homeserver from a verified base to a working bridge for each messaging network. Each step ends with a check you can record, so a failed step is caught before the next one depends on it. The pilot user's test traffic is the final proof that the chain works end to end.
Confirm the homeserver and database
The platform team confirms that the Synapse homeserver runs on PostgreSQL, the production choice in the Synapse documentation, at a version that meets the floor for the release you run. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer. Fix the server_name now, because bridge identities and room addresses depend on it and changing it later is difficult to undo. Done when the homeserver answers client requests and an existing test account can log in.
Create a database and role per bridge
Each bridge gets its own PostgreSQL database and a dedicated role with rights only to that database, so a fault or compromise in one bridge cannot read the others' stored state. The bridges keep their own mapping of Matrix identities to external accounts and session data, so include these databases in your backup scope from the start. Confirm the connection string each bridge will use. Done when each role can connect to its own database and is denied access to the others.
Generate and register each appservice file
Run each bridge's registration generation step, following the setup documentation at docs.mau.fi, to produce an application service registration file for each network. The file carries tokens that authenticate the bridge to the homeserver and a namespace of user and room identifiers the bridge controls. Store the files with restricted file permissions, add their paths to the homeserver's application service configuration (confirm the key name against the Synapse configuration manual), and restart Synapse. Done when Synapse starts without errors.
Configure each bridge and its homeserver connection
Set each bridge's homeserver address and domain to match the server_name, point it at its database, and copy the tokens from its registration file exactly. Set the permissions that decide which Matrix users may use the bridge, and keep encryption and admin settings at their documented defaults until the pilot is complete. For Telegram, decide whether you need relaybot mode. Relaybot relays messages through a Telegram bot account, so no individual staff account is logged in, and the pilot checks in the steps below change accordingly. Done when each bridge starts with no configuration errors.
Start each bridge and check registration
Start each bridge process and confirm that the homeserver accepts its appservice registration. The bridge's bot user should appear on the homeserver, and an admin account should get a response when it sends the bridge's help command in a direct chat. Read the startup logs for token mismatches, database errors and homeserver connection failures, and resolve each one before moving on. Done when every bridge's bot responds and the logs show a completed connection to the homeserver for each bridge.
Have a pilot user link an external account
Choose one pilot user who holds a test account on each network, preferably one the organization owns rather than a personal account. The pilot runs the bridge's login command from the bot's direct chat. Each network uses its own linking flow, such as device linking or a phone-number login with a verification code, so confirm the current flow in the bridge documentation before the session. Done when the bridge reports a successful login and the pilot's external contacts appear in Matrix as rooms or direct chats.
Test messages in both directions
Send a plain text message from Matrix to a pilot contact on each network, then reply from the external app and confirm the reply arrives in the Matrix room. Next, test a formatted message, a file, a reply and a reaction, because the mautrix-whatsapp roadmap lists these as bridged from Matrix to WhatsApp. Also confirm that room name, avatar and topic changes do not carry across, since the roadmap marks those as unsupported. Record the result per network, and confirm the equivalent feature list for Signal and Telegram in their own bridge documentation. Done when text works in both directions on every network and the pilot has a written list of features that did not cross.
How Matrix identities and rooms map to external accounts
This table compares how each bridge links Matrix users and rooms to external accounts, and which message types and room details carry across. The WhatsApp column reflects the mautrix-whatsapp roadmap, which states feature status directly. Cells marked Verify depend on Signal and Telegram details to confirm in each bridge's documentation before you set staff expectations or plan workflows.
| Item | WhatsApp (mautrix-whatsapp) | Signal and Telegram |
|---|---|---|
| Matrix user to linked account | Each staff member links their own WhatsApp account, so the bridge acts as that user. Confirm the linking steps in the bridge setup docs. | Verify: whether each Matrix user links a personal Signal or Telegram account, and how the link is created and removed. |
| Puppet identities | The bridge represents WhatsApp contacts as Matrix users it controls. Confirm the naming pattern and how these users appear in your homeserver. | Verify: whether contacts appear as puppet users, how they are named, and whether Telegram relaybot mode creates different identities. |
| Bridged rooms and Matrix room IDs | Each bridged WhatsApp chat maps to a Matrix room with its own room ID. Record the mapping in your runbook for support and audit requests. | Verify: whether each Signal or Telegram chat maps to one Matrix room and where the room ID mapping is stored. |
| Message types from Matrix to WhatsApp | Text, formatting, media and files, location, replies, polls, reactions, read receipts and typing notifications are listed as bridged. | Verify: the supported message types for each direction, including media, replies and reactions. |
| Message types from WhatsApp to Matrix | Private chats, group chats, communities and status broadcasts are listed as bridged into Matrix. | Verify: which chat types and message types arrive in Matrix from each network. |
| Room name, avatar and topic changes from Matrix to WhatsApp | Not supported. Changes made in the Matrix room do not update the WhatsApp group, so staff must edit the group in WhatsApp. | Verify: whether room name, avatar or topic changes sync in either direction for each network. |
Hardening the bridge and its linked sessions
A mautrix bridge sits between your Matrix homeserver and external messaging networks, and it holds the session data that links those accounts. The controls below cover who can start a link, how the bridge's files and network paths are protected, and what happens to linked accounts when people leave.
Restricting who can start a login
Each mautrix bridge lets Matrix users link an external account from a bridge bot or command room. Decide which Matrix users, or which homeserver permission groups, may start a login, and confirm that the bridge's permissions configuration grants no broader access than that decision. Check the setting in your bridge version's documentation, because permission keys and their levels differ between WhatsApp, Signal and Telegram. Test with an account outside the allowed group to confirm it is refused.
Controlling access to bridge databases and config
The bridge database stores puppet records, message mappings and session material for each linked account, and the configuration file holds database credentials and homeserver settings. Restrict both to the bridge service account and to the named administrators, and remove read access for general server users. Confirm that backups of the database inherit the same restrictions. Ask your team which backup targets can read these files and who can restore them.
Protecting the registration file and tokens
The appservice registration file contains the access token and the homeserver token that let the bridge act on Matrix and let the homeserver trust the bridge. Anyone holding these values can impersonate bridge users or inject events, so store the file with restrictive permissions, keep it out of shared repositories, and place it in your secrets store where possible. Plan a rotation procedure that updates both the homeserver and the bridge together, and record who may trigger it.
Limiting network paths to the homeserver
The bridge needs a path to the homeserver's client-server and appservice endpoints, and it needs outbound connections to the external networks. Allow only those flows. Block other inbound access to the bridge's listener, and keep the bridge off any network segment that does not need to reach the homeserver. Document each allowed path in your firewall rules so reviewers can trace it to a business purpose.
Deciding where the bridge runs and who administers it
The bridge stores session data for linked WhatsApp, Signal and Telegram accounts, so the hosting location and administrator group are data-handling decisions. Choose infrastructure you control, name the team that operates the bridge, and record who can read its logs and databases. Confirm with each network's terms and your own data classification whether the stored session data can leave your environment, for example in a managed backup service.
Setting a policy for unlinking when staff leave
A linked account keeps working until someone unlinks it, so a departing employee's WhatsApp, Signal or Telegram session can stay active on the bridge. Write a procedure that ties unlinking to the offboarding checklist, names the person who performs it, and covers the Matrix account deactivation as well. Decide how shared or role-based accounts are reassigned. Ask your bridge vendor or partner to confirm how unlinking removes session data from the database and backups.
What bridging means for message content and retention
Bridging creates copies of conversations in more places than a native Matrix room does, so the first question is where each copy lives. The mautrix-whatsapp, mautrix-signal and mautrix-telegram bridges are puppeting bridges: each one signs in to an external account as a staff member, relays messages into Matrix rooms on your homeserver, and stores its own record of the mapping between platform messages and Matrix events in its database. Message content therefore sits in the homeserver database and media store, in the bridge database, and in the external platform itself. Before rollout, ask the team to document, for each bridge version you deploy, which tables or files hold message text, media, session credentials and contact details, and which database engines that version supports. A server administrator with database or host access can read bridged content in the same way they can read any unencrypted room. The bridge operator can also read the bridge database, which holds the linked account's session material, so that role carries high privilege over the staff member's external account. Assign these roles deliberately, separate homeserver administration from bridge administration where your team size allows, and record who holds shell, database and configuration access. Confirm whether a given bridge version supports end-to-end encryption for bridged rooms, because that choice determines whether a homeserver administrator can read the content. External contacts who are not on your homeserver appear in Matrix as bridge-created ghost users that mirror the name, avatar and identifier the external platform exposes. Those profile fields are copied into your homeserver database, and they can persist after the contact stops messaging. Ask the vendor or project documentation which identifiers are mirrored, how profile updates are propagated, and whether a ghost user can be removed without deleting the room history. Staff should also know that a contact who never joins Matrix still has their messages stored on your side once a staff member receives them.
Matrix retention and erasure settings apply to events on your homeserver, but they do not reach the external platform. Deleting or expiring a message in Matrix does not necessarily delete the copy held by WhatsApp, Signal or Telegram, and it may not delete the bridge's own record. Whether a redaction in Matrix is forwarded to the external platform depends on the bridge and the message type, so test each message type you plan to offer. Document the retention period you set for bridged rooms, the process for erasing a contact's ghost user and history, and the point at which the bridge database is purged. Confirm these steps with the bridge documentation and run them against a test account before you describe them to users. The mautrix bridges are published under AGPL-3.0, and the setup documentation is hosted on docs.mau.fi. Read the license and the version notes for the release you deploy, because data handling details can change between releases. Telegram's relaybot mode works differently from puppeting, since a bot account relays messages instead of a personal account. Treat the relaybot and puppeting setups as separate data-handling designs, each with its own review. External platform terms and local data protection obligations apply to the linked accounts and to the people who message through them. Those terms and obligations can restrict how a staff member may link an account, how contact data may be copied into a homeserver, and how long copies may be kept. Your organization's counsel and compliance team should review these questions before any account is linked. This section does not state legal conclusions, and nothing here should be read as a determination that a particular deployment is permitted.
Common failures when bridges go live
Most bridge problems at go-live trace back to a short list of causes: registration, database versions, linked sessions, media limits, feature scope and platform version floors. Each card names the likely cause, the check to run and the part of the bridge documentation to read. Confirm exact settings and versions against the documentation for the release you deploy.
Homeserver does not recognize the registration file
The homeserver loads a bridge only when its registration file is listed in the application service configuration and the Synapse process can read the file. Check that the path in the homeserver configuration matches the file on disk, that the bridge and homeserver tokens match the bridge configuration, and that the sender localpart is unique. Restart or reload Synapse after any change, then follow the registration steps in the setup documentation for the bridge you deploy. Confirm field names against the Synapse configuration manual for your release.
Database version mismatch after a Synapse upgrade
Synapse 1.143.0 and later require PostgreSQL 14 or newer, so an upgrade can fail when the database is older. Schema changes between releases also make rollback difficult, so take a database backup before each upgrade and read the upgrade notes for every version you cross. Check the PostgreSQL version and the bridge compatibility in staging first, then move production only after the staging run completes without errors.
Linked session drops and needs a fresh login
Each bridge keeps a linked session with the external platform, and that session can end when the phone, linked device or platform account changes state. The symptom is usually messages that stop crossing while the bridge bot remains online. Check the bridge logs for session state, confirm in the bridge documentation whether the primary device must stay connected, and re-link through the documented login flow. Treat re-linking as a routine operational task with a named owner.
Media failing to cross the bridge
Media can fail at the homeserver, at the bridge or on the external platform. Check the upload size limit configured on Synapse, the media settings in the bridge configuration and whether the file type appears in the bridge's supported list. The mautrix-whatsapp roadmap lists media and files as bridged from Matrix to WhatsApp, so confirm the direction and file type your staff need before they depend on it. Test each type with a small sample from both sides and record whether each failure comes from the homeserver or the bridge.
Features missing from the roadmap
Some expected behaviors are not available in every direction. The mautrix-whatsapp roadmap marks room name, avatar and topic changes from Matrix to WhatsApp as not supported, and other items appear only as planned work. Build a feature table from the features and roadmap page for the bridge version you deploy, mapped to the actions your teams actually take. Tell users which actions still happen in the native app, and review the table before each bridge upgrade.
Bridges stop after a platform floor change
A bridge can stop working when the external platform changes its protocol or client requirements. A bridge can also stop when the Synapse release you run drops support for a Python or PostgreSQL version that has reached upstream end of life. Check the bridge release notes and the Synapse upgrade notes before each change window, and confirm the Python and PostgreSQL versions on your hosts. Keep a staging copy of the bridge and homeserver for upgrade tests, and assign an owner to watch both release feeds.
Questions buyers ask before bridging WhatsApp, Signal or Telegram
How much does it cost to bridge WhatsApp, Signal or Telegram to Matrix?
Cost follows from the written scope, and no price is set on this page. The main drivers are the number of bridges, the state of your homeserver and database, the depth of the data review, the number of staff accounts used in testing, and how often you plan to upgrade. Setup work is one-time. Upgrades, monitoring, and bridge maintenance recur. When you request a quote, ask for each cost broken into these components, state which items are one-time and which are recurring, and confirm who pays for vendor licenses, hosting, and staff time on your side. A quote should list the bridges, the homeserver and database work, the data review, the test rounds, and the handover, so you can compare it with an internal estimate.
How long does a Matrix bridge project take to deliver?
Duration depends on scope and on your starting point. A project moves faster when Synapse already runs on PostgreSQL and meets the version floors, when the number of bridges is small, and when one person can make decisions for each bridge. It slows when the homeserver needs a database migration, when the data review involves legal or privacy sign-off, or when staff testing requires several rounds. No duration is given here, so ask for a timeline in writing as part of the fixed-scope agreement, and ask which milestones depend on your team's availability.
Can our own team set up mautrix bridges without an implementation partner?
Yes, a capable internal team can do it, provided it has the skills and time to run the work. The team needs experience operating Synapse, its configuration, and its upgrade notes, plus PostgreSQL administration. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer, so check your current versions first. The team also needs to handle the bridge software itself, its AGPL-3.0 licensing obligations, and the ongoing work of keeping each bridge current. Most in-house gaps show up during the first upgrade, so ask whether someone on your team has already completed one.
What does our organization need to provide for a bridging project?
The project needs admin access, named ownership, and early decisions from your side. Expect to provide administrative access to the homeserver, its database, the reverse proxy, and DNS records. Assign a named owner for each bridge who can approve changes and respond to incidents. Staff who will test the bridges need their own accounts on the external networks, and they must agree to use them in live conditions. You also need to decide between puppeting and relaybot modes where the bridge supports both, and to set a retention policy for bridged messages before go-live.
Should we use puppeting or a relaybot for Telegram?
Puppeting links each person's own Telegram account to Matrix, and a relaybot posts through a single bot account. The mautrix-telegram bridge supports both modes, and mautrix-whatsapp and mautrix-signal are puppeting bridges. Puppeting keeps messages attributed to the individual, but each staff member must link an account, and the bridge holds the session for that account. A relaybot avoids per-user logins, but messages appear through the bot, so attribution and access control must be designed around it. Decide this per bridge with your security and communications leads, and confirm current behavior in the setup documentation before testing.
Which WhatsApp features and room changes do not carry across the bridge?
Some features bridge in one direction only, and some room changes do not reach WhatsApp at all. The mautrix-whatsapp roadmap lists text, formatting, media and files, location, replies, polls, reactions, read receipts, and typing notifications as bridged from Matrix to WhatsApp, and private chats, group chats, communities, and status broadcasts from WhatsApp. The roadmap marks room name, avatar, and topic changes from Matrix to WhatsApp as not supported. Check the current roadmap before you write user guidance, because status changes between releases, and test each feature your staff depend on.
What does a fixed-scope bridging quote cover in practice?
A fixed-scope quote covers the work, deliverables, and timelines agreed in writing before the project starts. Most engagements list the bridges in scope, the homeserver and database changes, the data review, the testing rounds with staff accounts, documentation, and the handover to your operators. Changes that alter the agreed scope are handled through a written change request. Ongoing upgrades, monitoring, and continuous support are available as retainers, so ask whether post-launch upgrades are included in the quote or priced separately. Request the list of exclusions, such as work on other platforms or changes to the external networks themselves.
What data does a bridge store, and who can read it?
Bridges store message content, identifiers, media, and login sessions, and your retention settings decide how long Matrix copies remain. A puppeting bridge holds the session credentials for each linked account, so access to the bridge host and its database is sensitive. Bridged messages stored on the homeserver follow its retention and deletion settings, and media may be stored separately. Confirm with the bridge documentation how each network's encryption is handled on the external side, and have your data protection lead review what is stored, where, and for how long before go-live.
How DeployOpen scopes and supports a bridge deployment
DeployOpen plans and deploys self-hosted mautrix bridges for WhatsApp, Signal and Telegram inside infrastructure you control, connected to your Matrix homeserver. Each engagement starts from a written scope that covers which networks, which bridge features and which data-handling questions are in and out. The work is fixed-scope, with ongoing support available as a retainer.
How we scope
- The written scope names each network, WhatsApp, Signal or Telegram, and the bridge features expected on each.
- Scope records which features are not supported, such as room name, avatar and topic changes from Matrix to WhatsApp.
- We confirm the hosting, database, network and data-retention questions that bridging raises before any build starts.
How we build
- Bridges are deployed beside your homeserver in your infrastructure, with setup following the mautrix project documentation.
- Each bridge is tested with test accounts on each network for the scoped features, such as text, media and replies.
- Puppeting bridges link staff accounts, so the plan records which accounts are linked and who controls them.
How we hand over
- Handover documents the deployment, configuration, secrets locations, network paths and each bridge's restart and update steps.
- Runbooks cover how staff re-link accounts, rotate credentials and respond when a bridge stops relaying messages.
- Your team receives the written data-handling record, so retention and access decisions stay with your organization.
How we support
- Ongoing support is available as a retainer, covering bridge updates and reviews of the scoped features.
- Upgrades follow each project's release notes, and Synapse platform requirements are checked first.
- Changes to network paths, scoped features or data-handling rules go back through the written scope before work starts.
