MediaMTX vs StreamableRun for IRL Streaming: Self-Hosted Media Router vs Managed Cloud OBS

The direct answer: a media router is not a Cloud OBS show layer

MediaMTX is a powerful self-hosted live media server and proxy. Its own documentation calls it a media router: it can accept a stream, make it available on another supported protocol, record it, play recordings back, proxy a source, and expose automation and monitoring hooks. That is excellent plumbing for a technically owned relay, a venue camera network, a protocol gateway, or a custom video product.

It is not, by itself, an IRLToolkit-style managed Cloud OBS alternative. MediaMTX routes media; it does not provide a managed production UI where a producer builds the viewer-facing program from scenes, browser sources, audio, main and backup sources, and a prepared safe screen. It also does not turn an incoming phone feed into a staffed recovery workflow or automatically give a team destination operations. You can build those layers around it with OBS, FFmpeg, dashboards, scripts, storage, and operators. That is a valid architecture, but it is your architecture to run.

StreamableRun is the better choice only when that verified managed-production layer is the requirement. It puts Cloud Hosted OBS, recovery scenes or clips, destination management, recording controls, and remote team operations beside the contribution ingest. MediaMTX is the better fit when protocol control, self-hosting, and custom routing are the actual job. Treating either tool as a lesser version of the other misses the decision.

MediaMTX and StreamableRun: what each layer owns

This is a workflow comparison checked against MediaMTX's official docs, its current GitHub release, and StreamableRun's public product surface on July 12, 2026. It is not an uptime or price ranking. Test the exact release, plan, encoder, destination, and network route you will actually use.

Where MediaMTX is genuinely strong

MediaMTX earns its place in an IRL stack when the awkward part is transport. A camera, mobile encoder, venue PTZ, or another server may speak a protocol that your next tool cannot consume directly. MediaMTX can give that source a named path and make it readable through another supported protocol. A hardware encoder publishing SRT can feed a local OBS confidence monitor through RTSP or a browser viewer through WebRTC or HLS, provided the codecs and network path are compatible. That flexibility is useful without pretending it is a scene switcher.

It is also a serious automation building block. The Control API can list active paths, and Prometheus-compatible metrics can expose per-path bytes, reader state, errors, and protocol session data. Hooks can run commands on connection, disconnect, initialization, publisher-ready, reader-ready, record-segment completion, and other events. A technical team can use those primitives to notify an operator, start a downstream process, publish an internal status page, or push an alert into its own tooling.

The current release state matters when you self-host. At this check, the official GitHub latest release is MediaMTX v1.19.2, released June 28, 2026. It includes fixes and improvements rather than a reason to update during an event. Pin a tested release or image version, read the release notes, stage upgrades privately, and keep the previous image or binary and configuration ready for rollback. The attractive part of self-hosting is control; surprise upgrades throw that control away.

The routing and conversion boundary matters more than the protocol list

MediaMTX automatically converts a stream from one supported protocol to another, but it is not a universal codec repair shop. The official re-encoding guide says to use FFmpeg or GStreamer with MediaMTX when you need to change format, codec, or compression. That is a crucial IRL detail. If a phone or backpack produces video that a browser cannot decode over WebRTC, or a destination expects an encoder profile you are not sending, the answer may be a controlled transcode lane. It is not safe to assume that a route will make every codec work everywhere.

WebRTC and HLS solve different viewing problems. MediaMTX documents WebRTC as a publish/read protocol, but browser codec support has limits: H.265 is not broadly readable, and H.264 with B-frames is outside the WebRTC specification. HLS is useful for broad browser playback, but it is segment-based delivery and is not a substitute for a low-latency confidence monitor. Measure glass-to-glass delay on the target device; do not borrow a latency number from an unrelated protocol test.

SRT and RTMP are contribution choices, not recovery plans. MediaMTX supports SRT publishing and reading, including standard stream-ID syntax for hardware that requires it. Its RTMP documentation covers RTMPS with a TLS certificate and warns that RTMPS is unsupported by most major players. Those are solid protocol options. They do not provide SRTLA aggregation, bond a phone's links, choose a backup camera, or keep a platform program alive when the last-mile source disappears. Assign each of those jobs to an actual layer.

Four real IRL architectures, from a phone to a venue

Phone relay lab: phone app → SRT or RTMP → MediaMTX on a VPS → local OBS reads the named path → local OBS sends the finished program to a platform. This is a good controlled lab if the team wants to inspect transport, experiment with a source path, or bridge a protocol to local OBS. The cost is that local OBS, the host, platform output, source reconnect behavior, and the person watching them are all separate failure domains.

Backpack or hardware encoder: encoder → SRT → MediaMTX → a read path for confidence monitoring or an FFmpeg forwarder → the chosen downstream system. This can be a tidy bridge when a camera backpack needs a controlled handoff or multiple technical consumers need the same source. Confirm the encoder's caller/listener mode, port exposure, stream ID, passphrase, bitrate, codec, and which side reconnects. Never paste the production URL or passphrase into a public monitor page.

Venue gateway: cameras or a production switcher → MediaMTX paths → RTSP/WebRTC/HLS confidence viewers, record segments, or a downstream program encoder. This is where MediaMTX's named paths, hooks, metrics, and self-hosted control are especially appealing. It is a media-network project. A venue should still decide who owns the network, power, firewall, recording disk, and incident response before calling the stack live-ready.

Producer-led IRL show: Moblin, IRL Pro, local OBS, or an encoder → StreamableRun ingest → Cloud Hosted OBS with main, backup, BRB, privacy, and clips scenes → Twitch, Kick, YouTube, or custom RTMP destinations. This is the better default for a serious public show where the streamer is mobile and a producer needs to protect the output. The person in the field can work on the source while someone else keeps the audience on a deliberate scene.

What MediaMTX does not do by itself on show day

Do not buy yourself a false sense of redundancy by counting MediaMTX paths as a recovery plan. A path can make a source reachable; it does not decide what viewers see. If a phone stalls, MediaMTX can log the event, a hook can call a script, and a downstream reader can notice. Somebody or something still has to choose a fallback scene, protect a privacy moment, keep the platform session valid, and cut back when audio and video are healthy.

The same distinction applies to recording. MediaMTX can record paths to disk in fMP4 or MPEG-TS and expose recorded timespans through a playback service. Its documentation also notes that the final recording part can be lost in a system failure; the configured part duration is the recovery-point objective. Remote upload uses an additional tool such as rclone via hooks. That is useful and transparent, but it is not a managed archive policy or a producer-friendly recording control surface unless you build one.

A config reload is useful, not a blanket change window. MediaMTX can detect configuration-file changes and apply them without disconnecting existing clients whenever possible. That wording matters. Treat port changes, credentials, codec paths, external commands, and destination changes as changes to rehearse rather than edits to make while a sponsor segment is live. A hot-reload feature lowers friction; it does not remove change risk.

Self-hosting is a security and operations commitment

MediaMTX can use internal credentials, an external HTTP authentication service, or an external JWT provider. Its permissions distinguish publishing, reading, playback, API, metrics, and profiling. That is a capable security model, but it means the owner must decide which identities may do each job and keep secrets out of configs, screenshots, logs, and shared chat. The Control API defaults to localhost-only; exposing it needs an intentional network and authentication design.

Docker makes deployment repeatable, not maintenance-free. MediaMTX's install documentation recommends the Docker image for isolated, deterministic production deployments and shows that WebRTC, RTMP, HLS, SRT UDP, and other services may need their respective ports mapped. A real deployment also needs a host update policy, image pinning, firewall rules, TLS and reverse-proxy decisions, alert routing, persistent recordings, tested backups, and someone who can access the machine when the stream is live.

Scale follows the workload. MediaMTX says that, without re-encoding, the usual large-reader bottleneck is bandwidth and documents horizontal read replicas behind a load balancer. If you add FFmpeg transcoding, those processes bring their own CPU or GPU capacity and restart behavior. Load-test source publishers, concurrent readers, recording writes, and any transcode lanes together. A single clean SRT test says almost nothing about a show with multiple viewers, recording, metrics scraping, and an operator dashboard open.

A combined MediaMTX and StreamableRun deployment can make sense

The clean combined pattern is to make the boundary explicit. Use MediaMTX before StreamableRun when a site needs a self-owned gateway: venue encoder or camera network → MediaMTX for named paths, protocol access, metrics, or a controlled relay → a tested contribution into StreamableRun → Cloud Hosted OBS program → public destinations. MediaMTX owns the technical source gateway; StreamableRun owns the viewer-facing program and team recovery controls.

The reverse pattern is also possible when the team needs a downstream technical consumer: field source → StreamableRun Cloud OBS program → a configured custom output → MediaMTX for an internal monitor, a protocol-specific reader, or a recorded technical feed. Do not build this because more arrows look professional. Build it only when a real reader, protocol, or ownership requirement cannot be met in the simpler path.

Write the handoff down. Name the owner of every ingest URL, SRT passphrase, server, recording disk, scene collection, platform account, and alert. Put the exact probe a producer uses beside the exact metric an infrastructure owner checks. When something fails, decide whether the incident is field connectivity, MediaMTX gateway health, program composition, destination ingest, or viewer delivery before making changes. That stops one bad phone link from turning into five random restarts.

Migration, private soak tests, and a troubleshooting matrix

Migrate one responsibility at a time. First, keep MediaMTX in a private test and route one known source through it. Then prove the downstream reader or StreamableRun contribution path sees stable video and correct audio. Next, add recording and verify files open after a controlled source disconnect. Only then add automation, another reader, or a public destination. A migration that changes transport, codecs, switcher, destination, and monitoring at once has no useful rollback signal.

• SRT publisher connects but no program appears: verify caller/listener roles, UDP port reachability, path or stream ID, credentials, codec support, and the exact reader URL. Check MediaMTX paths and logs before changing bitrate.
• MediaMTX path is healthy but the browser viewer is blank: test the WebRTC or HLS reader separately, then check browser codec limits. If a codec conversion is needed, add and load-test the explicit FFmpeg or GStreamer lane instead of expecting routing to transcode.
• Packets or frames drop: start with physical network capacity. MediaMTX says its real-time routing drops late packets under congestion; lower bitrate or fix the link before adding more moving pieces.
• Recording is missing after a crash: inspect the configured part duration and storage path, then test the backup or remote-upload workflow. The last unfinalized recording part can be lost by design.
• The field source dies during a public StreamableRun show: move the program to the rehearsed safe or backup scene, have the field operator reconnect, then return only after audio and picture are confirmed on a real destination viewer.
• A platform output fails while the program is intact: inspect that destination alone, preserve the program and other destinations, and avoid restarting MediaMTX or the field encoder until evidence points there.

Estimate cost without inventing a price

Do not compare an open-source binary with a managed service by calling one free and the other expensive. For MediaMTX, list the monthly host, attached disk, snapshots or backups, outbound bandwidth, static IP or load balancer, object storage, CDN if used, monitoring, and every FFmpeg or GPU worker. Then add the hourly burden: provisioning, patching, security review, release testing, alert response, incident recovery, and the rehearsal hours needed to prove the stack. Multiply each by your own provider rate or internal cost; do not use somebody else's VPS number.

For StreamableRun, compare the current plan cost against the operating work it replaces for this show: Cloud Hosted OBS, scene and fallback operation, destinations, team access, and the managed production surface. Then test the limits that affect you—inputs, outputs, recordings, duration, region, and support path—before an event. The useful comparison is total show cost at your risk level, not a fake universal price.

Other resources

Use these first-party references to validate a MediaMTX configuration, release, deployment, and protocol decision. Use the StreamableRun guides to rehearse the Cloud OBS production and recovery side. Both tools reward a private test more than a confident feature table.