Operating

Operating

The full guide with all commands: operator guide.

Run it

• Docker Compose with the bot in mumpeer's network namespace (network_mode: "service:mumpeer"), so the API stays on loopback. See Getting started.
• systemd with the static binary: a ready unit with DynamicUser, StateDirectory, LoadCredential for the secret and CAP_NET_BIND_SERVICE for port 443 is in the operator guide.

mumpeer stops cleanly on SIGTERM.

Ports

Port	Protocol	Open to the internet?
443	UDP (QUIC)	yes
443	TCP (TLS)	yes
7480	TCP (bot API)	no, loopback only

A web server already on 443? A reverse proxy cannot terminate the relay's TLS (it needs the client certificate). Give the relay its own IP address, use another port, or pass connections through by ALPN mumpeer/1; details and caveats in port 443 and reverse proxies.

The relay identity

On first start mumpeer creates relay-key.pem and relay-cert.pem in data_dir and logs relay fingerprint (SHA-256): …. Clients pin that fingerprint. Keep and back up these two files; losing them means every user sees "The relay of this server changed".

Logs

At info: start summary, fingerprint, a totals line every 5 minutes and one session ended line per session (random id, transports, duration, bytes each way, dropped packets, reason). Warnings show only the /24 or /48 network of an address. Never logged: full IP addresses, full certificate hashes, tokens, the secret, packet contents.

Health and monitoring

• Liveness: nc -w 2 127.0.0.1 7480 </dev/null (a bare TCP connection to the API; no login).
• Manual status: curl -H "Authorization: Bearer $SECRET" http://127.0.0.1:7480/v1/status. Do not poll it automatically: every authenticated call counts as bot activity, and wrong secrets get the caller's address blocked. The response includes uses, the enabled features from [uses], and broadcast with max_viewers and max_camera. broadcast is absent when neither screen-share nor camera broadcasts are possible (each off in [uses] or with a limit of 0). media (the media profile version) is present whenever broadcast is. plugin_data (with max_kbps_per_sender) is present unless [uses] plugin_data = false.
• Load: totals and dropped in the log.

Broadcasts

A broadcast is one screen share or camera that the relay copies to many viewers, so the sharer uploads only once. Your bot creates and manages them through the bot API (/v1/broadcasts); you only set the limits, see Configuration.

• They do not count against max_sessions; screen shares have their own max_broadcasts, cameras max_camera_broadcasts. Watch your uplink instead: each viewer is one more copy leaving your server.
• When the bot removes a user (DELETE /v1/peers/{hash}), that user leaves every broadcast; if they were the sharer, the broadcast ends.
• With the media profile (0.3.0), the relay keeps the latest stream description of a broadcast so viewers who join late receive it; see Configuration.
• The relay forwards the sharer's video and audio to the admitted viewers. The stream stays end-to-end encrypted, so the relay cannot read it.

Upgrading

Read the changelog, switch the image tag or binary, restart. Two changes to watch for: since 0.2.1 [uses] plugin_data defaults to true (set it to false to keep plugin data off), and the config rejects unknown keys. Keep the data volume. Running sessions end and are set up again when needed; the bot re-announces after it sees the new boot_id.

Releases: GitHub releases and the image ghcr.io/mumcord/mumpeer:<version> (for example 0.3.0). Each release has mumpeer-<version>-linux-x86_64.tar.gz and …-linux-aarch64.tar.gz (static binaries) with SHA256SUMS, plus a software bill of materials (SBOM, CycloneDX JSON) for each binary (mumpeer-<version>-linux-<arch>.cdx.json) and each image platform (mumpeer-<version>-docker-<platform>.cdx.json), all listed in SHA256SUMS. Pin a version in production; latest follows the newest stable release.