When Mattermost Calls with RTCD becomes the right architecture
Add RTCD when your self-hosted Mattermost Calls deployment moves past a pilot and has to hold up for daily meetings. The Mattermost Calls deployment guide recommends the RTCD service for deployments of 50 or more users, because it offloads media processing from the Mattermost server and supports production reliability. Consider a team that started Calls for a few working groups on one Mattermost server, then saw call quality slip as more people joined each meeting. For most organizations at that size, a separate RTCD tier should be planned before the user count arrives, not after the first complaint.
In plain terms, RTCD is a separate media service. The Mattermost server keeps handling chat, channel state and the Calls plugin, while RTCD carries the audio and video traffic for calls. Setting it up requires an Enterprise license, so confirm your plan before you design the architecture around it. Size the service from concurrent calls and participants per call, not from total licensed users. Ask Mattermost to review your expected peak load and network path in writing, and record the answer as an input to your infrastructure plan.
The calls-offloader is a different kind of dependency. It is the component that Calls needs for call recording, transcription and live captions. If your requirements include any of these, the offloader is part of the design regardless of user count. Recording and transcription are Enterprise and Enterprise Advanced features. The supplied material does not confirm the plan level for live captions, so get that answer from Mattermost before you promise captions to your users. Decide early where recordings and transcripts will be stored and who can access them, because those choices affect retention and compliance work later.
The practical decision is therefore two-part: whether you need RTCD for scale and reliability, and whether you need the calls-offloader for recording, transcription or captions. Teams with small, informal calls may not need either yet. Teams with a larger user base or a recording requirement should plan both together, and test them against the Mattermost server release they run. Confirm that the Calls plugin, RTCD and calls-offloader versions are compatible with each other and with your server upgrade schedule. Include the Enterprise license terms in your quote request so the cost of these components is clear before build work starts.
Which Calls components to deploy for each requirement
This table compares three Mattermost Calls configurations by user count, recording and caption needs, license requirement, ports and operational load. Read each column as the minimum set of services for that requirement, and add the next component only when its trigger applies. The main takeaway is that RTCD requires an Enterprise license and the calls-offloader is needed for recording, transcription and captions, so confirm plan level before you size the deployment.
| Requirement | Calls on the server alone | Calls with RTCD | Calls with RTCD and calls-offloader |
|---|---|---|---|
| Typical trigger | Smaller deployments below the 50-user threshold in the deployment guide | 50 or more users, or production reliability requirements | Recording, transcription or live captions needed, on top of RTCD |
| Recording, transcription or captions | Not available in this configuration | Not available without the offloader | Supported, as the offloader is required for these features |
| License requirement | Confirm the plan that includes Calls for your server version | Enterprise license required for RTCD setup | Enterprise or Enterprise Advanced for recording and transcription; confirm captions |
| Services to run | Mattermost server with the Calls plugin, which handles media | Mattermost server plus one or more RTCD services | Mattermost server, RTCD services and the calls-offloader service |
| Ports to open | UDP and TCP 8443 to the Mattermost instance | UDP and TCP 8443 to RTCD, with the RTCD API on TCP 8045 | Same media and RTCD API ports; confirm offloader paths in the guide |
| Operational trade-off | Least to deploy and monitor, but media load shares server capacity | Another service to deploy, patch and monitor, with media load moved off the server | Adds a service to monitor, plus recording and transcript storage and retention decisions |
Setting up RTCD and the calls offloader in order
This sequence takes a self-hosted Mattermost deployment from a licensed server to Calls that run media through RTCD, with recording and transcription added only where they are needed. Each step closes with a check so the team knows the layer works before the next one is built.
Confirm the Enterprise license and scope
The Mattermost administrator confirms that the server runs a license that covers RTCD, which requires an Enterprise license, and that recording and transcription are needed, since both are Enterprise and Enterprise Advanced features. The team also checks the Calls deployment guide for the Calls plugin version that matches the RTCD release it plans to install, and records the expected concurrent user count, because the guide recommends RTCD for 50 or more users and for production reliability. The step is done when the license is active in the System Console and the scope document lists which Calls features are in use.
Plan network placement and DNS
The network team decides which host runs RTCD and where it sits relative to the Mattermost server and the client networks. Media uses port 8443 over UDP and TCP to the Mattermost instance or RTCD, the RTCD API listens on TCP 8045 for the Calls plugin, and STUN on UDP 3478 is optional, so the team decides whether STUN is needed for its client paths. DNS names and the certificate for the RTCD endpoint are agreed at this stage. The step is done when a signed-off diagram shows each flow, its port and its direction.
Open the documented ports
The network and security teams open only the ports in the approved diagram: UDP and TCP 8443 for media, TCP 8045 for the RTCD API used by the Calls plugin, and UDP 3478 only if STUN was chosen. Rules are added on host firewalls and on any load balancer or perimeter device in the path. The team then tests reachability from the client network and from the Mattermost server, and confirms that the ports are closed for other sources. The step is done when each test passes from the expected source and no other source can reach the RTCD host on these ports.
Deploy the RTCD service
The platform team installs RTCD on the host chosen in the plan, following the RTCD setup and configuration documentation for Mattermost. Configuration sets the API listener on TCP 8045, the media listener on port 8443 and the DNS name and certificate agreed earlier. Once the service starts, the team checks that the process runs under its service manager and that the expected ports are listening on the host, without any other process bound to them. The step is done when the service starts cleanly, stays up through a restart and listens on the planned ports only.
Connect the Calls plugin to RTCD
A Mattermost administrator enters the RTCD API address in the Calls plugin settings in the System Console, using the name and port that the plugin can reach from the Mattermost server. After saving, the administrator confirms that the plugin reports a healthy connection to RTCD. Then two test accounts start a call on different client networks, and the team checks the RTCD logs and the host connection state to confirm that media is handled by RTCD rather than the Mattermost server. The step is done when the test call appears in RTCD and the plugin shows the connection as healthy.
Add calls-offloader for recording and transcription
The team installs calls-offloader only if recording, transcription or live captions are in scope, because the Calls deployment guide requires it for those features. The service is configured according to the guide and then linked to the Calls plugin settings, with storage locations and retention agreed with the compliance owner before the first recording. The team then records a short test call, confirms that the recording file is created and that processing finishes, and checks transcription output if it is enabled. The step is done when a test recording and transcript complete end to end and the storage location matches the approved design.
Run acceptance tests and document the build
The team runs a multi-participant test across the networks where users will join, including a remote connection that crosses the perimeter, and confirms that audio and video are stable for the full call. It also confirms the failure behavior with the vendor documentation, which tells the team what Calls users see if RTCD becomes unreachable, and records that result in the runbook. Finally, the configuration, firewall rules, port list and test evidence are stored with the change record. The step is done when the acceptance test results, runbook and change record are signed off by the owner of the Mattermost service.
Which ports to open for Mattermost Calls media
Mattermost Calls needs a small set of network paths between clients, the Mattermost instance, RTCD and the Calls plugin. Each card below covers one port or one control that shapes how those paths are opened, load balanced and restricted.
UDP 8443 for call media
Calls media travels over port 8443 using UDP, and the same port is also used over TCP as a fallback. Clients send media to the Mattermost instance or to RTCD, depending on whether RTCD is deployed. Confirm that UDP 8443 is allowed from user networks to the media host, because a firewall that permits only TCP will still let calls connect but may degrade audio and video quality. Check this path with a test call from each network segment that matters to you.
TCP 8443 as media fallback
The same port 8443 is used over TCP, which gives clients a route when UDP is blocked by a corporate proxy, a strict egress policy or a guest network. Open TCP 8443 in the same rule set as the UDP path so that both transports reach the same destination. Load balancers in front of Mattermost or RTCD must pass TCP 8443 to the media listener without terminating or rewriting the connection, so confirm the listener and target group settings with your load balancer documentation.
TCP 8045 for the RTCD API
The RTCD API listens on TCP 8045 and is called by the Calls plugin running inside the Mattermost server. This is an internal control path, not a user path, so it should never be published to the internet or to general user subnets. Restrict source addresses to the Mattermost application nodes, and confirm that any host firewall on the RTCD server allows only those sources to reach this port.
Limit the RTCD API exposure
Because the RTCD API controls media sessions, exposing it wider than the plugin needs gives other systems a way to request or disrupt calls. Treat it as a service-to-service interface: place RTCD on a segment reachable from the Mattermost nodes, use security groups or network policies that name those nodes, and log denied connection attempts to 8045. Revisit these rules after each Mattermost or RTCD upgrade, since the required callers can change between versions.
UDP 3478 for optional STUN
STUN on UDP 3478 helps clients discover their public address so that media can traverse NAT. It is optional, so decide whether your users are behind NAT or networks that need it before you open the port. If you run a STUN service, expose UDP 3478 only to the networks that require it, and confirm whether your deployment needs a TURN relay as well, since STUN alone does not relay media for every network topology.
Firewall and load balancer changes
Each port in this set changes what your firewall, load balancer and cloud security groups must allow, and some of these devices inspect or proxy traffic in ways that break media. Before go-live, document every rule with its source, destination, protocol and port, have the network team review UDP handling on each device, and test calls through the same path your users will take. Ask Mattermost for the rules that match your version, and confirm them in the RTCD setup documentation before you approve the change.
How high availability plans affect call design
The Mattermost plan you buy decides whether high availability is open to you, so settle that before you fix the Calls architecture. Mattermost high availability, which consists of redundant application servers, redundant database servers and redundant load balancers, is available only on the Enterprise and Enterprise Advanced plans. RTCD setup also requires an Enterprise license, and the calls-offloader's recording, transcription and captions features are Enterprise and Enterprise Advanced features. A team that wants a clustered server with media offloading and recording is therefore buying one plan for several components. Ask your Mattermost account team to confirm in writing which plan covers the cluster, RTCD and each calls-offloader feature you intend to run.
Shared file storage is the prerequisite that changes the call design most. Every node in a high availability cluster must mount the same storage, which Mattermost documents as Amazon S3, an S3-compatible service or a NAS. Local file system storage will not work correctly and risks corrupting files. Any file written during or after a call, including a recording if you enable one, follows the same path, so storage latency and availability become part of the call design. Confirm with the storage team that the backend is supported for your Mattermost version, and test an upload from each node before go-live.
Database read replicas help with scale, but they do not remove the primary database from the write path. Mattermost supports database read replicas and search replicas to scale concurrent users and reduce latency, distributing reads across replicas while sending writes to the primary. Calls depend on the server for sessions and state, so the primary database remains a dependency during a call. Plan the database failover path separately from the application cluster, and ask Mattermost how an in-progress call behaves during a database failover before you commit to an uptime expectation for meetings.
The facts do not show how RTCD itself is made redundant, so do not assume that clustering the Mattermost servers makes the media path redundant. Mattermost recommends RTCD for deployments of 50 or more users and for production reliability, because it offloads media processing from the Mattermost server. Confirm with Mattermost whether RTCD supports multiple instances, how the Calls plugin selects an instance, and how the RTCD API on TCP 8045 and media on UDP and TCP 8443 should sit behind your load balancers. Ask the same questions for the calls-offloader, and write a runbook that covers call outages separately from general Mattermost outages.
Questions teams ask before deploying Calls with RTCD
How much does it cost to deploy Mattermost Calls with RTCD?
Mattermost sets the license fees, and DeployOpen's fee follows from a written scope, so no single figure applies to every team. Mattermost sells Professional, Enterprise and Enterprise Advanced plans as prepaid annual subscriptions priced by seat licenses. Its pricing page lists no public prices, so ask Mattermost sales for a quote. Recurring costs include the subscription, the hosts or cloud resources for the Mattermost server, RTCD and calls-offloader, storage for recordings, and ongoing support time. One-time costs cover planning, configuration, firewall and DNS changes, testing and handover. Costs rise with concurrent users, the number of network zones, recording and transcription volume, and any high availability design. Ask the DeployOpen quote to list each work package, the environments covered, the assumptions about your network, and what your team must provide.
How long does it take to deploy Calls with RTCD?
Duration depends on scope and environment, and the schedule follows from a written plan agreed before work starts. Much of the elapsed time often sits outside the Mattermost configuration itself: firewall change approvals, DNS and certificate issuance, storage provisioning, and access to the hosts that will run RTCD and calls-offloader. A single-region deployment for one internal team with clear network paths moves faster than a multi-site rollout that passes through several security zones. Recording and transcription add validation steps, and a pilot with real users before general rollout adds time that is worth planning for. Ask for milestones with named dependencies, the change windows you must meet, and the test cases that define completion. DeployOpen sets these out in the written scope so your team sees each dependency before the schedule is fixed.
What do we need to provide for an RTCD deployment?
Your team provides network access, DNS, certificates, storage, licensing and named owners, and the plan records each item. Network access includes hosts for the Mattermost server, RTCD and calls-offloader, plus firewall rules that allow UDP and TCP 8443 for media, TCP 8045 from the Calls plugin to the RTCD API, and UDP 3478 only if your design uses STUN. DNS records must resolve the names that users and clients reach, and TLS certificates must cover those names. Storage is needed for recordings and transcription output, sized to your retention rules. The plan must include an Enterprise license for RTCD, and Enterprise or Enterprise Advanced if you record or transcribe. Name an owner for network, identity and the database, because those approvals often decide the start date.
Can our own team deploy Calls with RTCD alone?
Yes, if your team can operate one more service, and many teams deploy it without a partner. RTCD runs as a separate process with its own configuration, TLS and host sizing, and it must be kept in step with the Mattermost server version. Confirm the compatibility rule in the Mattermost documentation before you schedule upgrades. calls-offloader adds another component for recording, transcription and captions, with its own storage and logs. Your team needs Linux administration, reverse proxy and firewall skills, and a monitoring plan for both services. RTCD requires an Enterprise license, so confirm licensing before you build. If your team lacks capacity for the first rollout or for upgrades that follow monthly server releases, a partner can plan and implement the work, then hand over runbooks. DeployOpen runs fixed-scope engagements and offers retainers for ongoing support and upgrades.
Which Mattermost plan includes RTCD, recording and transcription?
RTCD setup requires an Enterprise license, and call recording and transcription are Enterprise and Enterprise Advanced features. The Mattermost pricing page includes high availability clustering and FIPS 140-3 compliance from Enterprise, and air-gapped deployment in Enterprise Advanced. SSO and AD/LDAP user sync start at Professional, so they do not decide the RTCD question on their own. Plans are prepaid annual subscriptions based on seat licenses, and the pricing page lists no public prices, so confirm the tier with Mattermost sales before you design the deployment. Confirm with Mattermost which tier covers live captions, since captions depend on calls-offloader. Record the plan decision in the written quote, because it determines what the design can include.
When should we add RTCD to Mattermost Calls?
Mattermost recommends RTCD for deployments of 50 or more users and for production reliability. The Mattermost Calls deployment guide positions RTCD as the way to offload media processing from the Mattermost server. That moves call load and server load into separate components that can be sized and scaled on their own. The 50-user figure is a guide from that documentation, so treat it as a starting point for the decision. Consider RTCD sooner if you hold large calls, run calls across several sites, or need production-grade reliability for calls that carry operational work. Confirm expected concurrent call load as well as total users before you decide. Put that sizing in the written scope so the architecture follows measured need.
Which ports must be open for Mattermost Calls with RTCD?
Open UDP and TCP 8443 for Mattermost Calls media, TCP 8045 for the RTCD API, and UDP 3478 for STUN only if you use it. Port 8443 carries media between clients and either the Mattermost instance or RTCD, depending on your topology. Keep TCP 8045 limited to the path between the Calls plugin and the RTCD API, and keep it internal to your network. Confirm the exact flows for your topology in the Mattermost RTCD setup documentation before you request firewall changes. Test from representative client networks, including those behind NAT and corporate proxies, because a rule that works from the data center can fail for a branch or remote user. Log denied connections during the pilot. Document each rule with source, destination, protocol and port so security reviewers can trace it.
What happens if calls-offloader is not deployed?
Call recording, transcription and live captions depend on calls-offloader, so those features will not work without it. Calls can run without it, but the features that need it are unavailable until it is installed and reachable. Before you enable recording, verify that calls-offloader is installed, can reach the components it needs, and has writable storage for its output. Check its logs during a test call and confirm that a recording completes and that any transcript appears where you expect. Storage growth follows recording volume and retention, so set a retention policy before users start recording. In regulated environments, confirm with your compliance owner who can access recordings and how they are deleted. DeployOpen can build these checks into the test plan and the runbook, while the policy decisions stay with your organization.
Official Mattermost Calls documentation
Start with the two official Mattermost documents for this topic before you size hardware or open firewall rules: the Mattermost Calls Deployment Guide and the RTCD Setup and Configuration page. Together they are the reference for which components to install, how they connect to the Mattermost server and the Calls plugin, and which ports each one expects. This page explains the design decisions around those documents. It does not replace them, and where the two sources differ in detail, follow the one that matches your Mattermost release.
Check the version alignment first. Mattermost ships new server versions in binary form on the 16th of each month and publishes Extended Support Releases on a longer cycle, so the Calls plugin, the RTCD service and the calls-offloader may each have version expectations tied to your server version. Confirm in the documentation which plugin and service versions match your current Mattermost release, and record that pairing in your change plan. If you run an Extended Support Release, check whether the documented component versions still apply to that line before you adopt a newer release of any companion service.
Read the port tables with the network team, not after the fact. The documents describe media traffic on UDP and TCP port 8443 to the Mattermost instance or RTCD, a TCP API port used by the Calls plugin, and an optional STUN port on UDP 3478. Confirm the exact numbers for your release, then map each one to a firewall rule, a load balancer listener, and any reverse proxy or ingress that sits in front of Mattermost. Note which flows cross your network boundary and which stay on internal segments, because WebRTC media paths are the most common place where a call works in a lab and fails in production.
Confirm licensing before you commit to an architecture. The documentation states that RTCD setup requires an Enterprise license, and that call recording and transcription are Enterprise and Enterprise Advanced features. Ask Mattermost to confirm the plan that covers each component you intend to run, and ask whether any part of the design changes if you move between plans. Keep that confirmation with the written scope so the team does not discover a licensing gap after the infrastructure is built.
Use the official documents as the baseline for your runbook, then add your own decisions: hostnames, certificate sources, the addresses that clients and RTCD will use, and who owns each port rule. Ask DeployOpen to reconcile the documented steps with your release, your network design and your change process, and to record any deviation with its reason so an auditor or future engineer can trace it.
How DeployOpen scopes and delivers Mattermost Calls
DeployOpen plans, implements, hardens and supports self-hosted Mattermost Calls with RTCD and the calls offloader inside your own cloud accounts, data centers or air-gapped networks. We start from a written scope that fixes what is built, tested and handed over before work begins. The sections below show how that scope, build, handover and support sequence applies to this topic.
How we scope
- The written scope names which Mattermost Calls components are in: the Calls plugin, RTCD, the calls offloader or a combination.
- Scope records the expected concurrent user count, since Mattermost recommends RTCD from 50 or more users.
- Scope also confirms the Enterprise license needed for RTCD, call recording and transcription, and the ports to open.
How we build
- Build plans the network path for port 8443 over UDP and TCP, plus the RTCD API on TCP 8045.
- The calls offloader is installed and tested against recording, transcription and live caption features before handover.
- Storage, retention and access for call recordings are configured to match the written scope and your policies.
How we hand over
- Handover documents ports, service layout, configuration files and the upgrade steps for each Calls component.
- Test records cover joining calls across your networks, recording, transcription and caption checks, with results in writing.
- Runbooks name who restarts RTCD, the offloader and the Mattermost server when a call fails.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade planning covers Mattermost's monthly server releases and confirms Calls component compatibility before each change.
- Ask us to confirm which retainer activities cover Calls changes, port reviews and recording checks before you sign.
