Monibuca v5: a Go streaming server framework you assemble from plugins

What Monibuca is for, and who ends up using it

A general streaming server gives you a binary and a configuration file. Monibuca gives you a Go module named m7s.live/v5 and a plugin system. The README describes it as "a highly scalable high-performance streaming server development framework developed purely in Go", and the repository layout backs that up: server.go, plugin.go, publisher.go, subscriber.go and transformer.go sit at the top level, with the actual protocols under plugin/ and pkg/.

The intended user is a Go developer who needs streaming behaviour that no off-the-shelf server exposes. The README lists the cases it has in mind: stream aliases, WebHook subscriptions to stream lifecycle events, gRPC remote calls for cross-language integration, custom private protocols, and an inference engine with ONNX model support. Those are not configuration switches on a product. They are extension points, and using them means writing Go against the framework.

If your requirement is "accept RTMP and republish as HLS", you are not the target reader. If your requirement is "accept RTMP, run a per-stream hook that rejects certain publishers, and re-encode a subset of streams", the framework shape starts to pay for itself.

The plugin model is the architecture

Monibuca does not ship one server with everything compiled in. The README's own framing is "Load on demand, unlimited extensibility", and the build tags table is where that becomes concrete. Build tags select what the binary contains: sqlite, sqliteCGO, mysql, postgres and duckdb choose the database backend, fasthttp swaps net/http for fasthttp, enable_buddy turns on buddy memory pre-allocation, and disable_rm turns the memory pool off.

That means the same source tree produces quite different binaries. A build with sqlite and a build with postgres are not the same artifact, and a build without disable_rm carries a memory pool that a debugging build would not. The repository also carries Dockerfile and DockerfileLite, which reflects the same split: a full image and a lighter one.

Protocol support follows the same pattern. The README lists RTMP, RTSP, HTTP-FLV, WS-FLV, HLS, WebRTC, GB28181, ONVIF and SRT among the supported protocols, and the topics list adds relay, record, mp4, ts, webrtc, websocket and webtransport. Nothing in the README states that all of these are present in every build. The plugin guide at plugin/README.md is where the project points for how plugins are written, and the architecture document at doc/arch/index.md is where it points for design. Both are in the repository rather than the README, which is a fair signal about where the real information lives.

Running the default example

The README's prerequisites are Go 1.23 or higher and "basic understanding of streaming protocols". The go.mod file declares go 1.24 with toolchain go1.24.10, so in practice you want a Go toolchain at or above that, or Go will fetch the declared toolchain for you.

The documented first run is the default example. From the repository root:

cd example/default
go run -tags sqlite main.go

The sqlite build tag is not optional decoration here. Without a database tag the default example has no storage backend selected, and the tag is what the README pairs with this command. Expect the first run to take a while, since go run compiles the framework and its dependencies before anything listens.

The web UI is a separate download. The README says to place the admin.zip file, unzipped, in the same directory as your configuration file, then visit http://localhost:8080. The Dockerfile shows the same file being copied into the image alongside example/default/config.yaml, so the container path is: admin.zip and config.yaml in the same working directory, and the binary started with -c pointing at the config. The README does not say where to obtain admin.zip, which is the first thing you will have to solve.

For monitoring, the README gives a Prometheus scrape configuration pointing at /api/metrics on port 8080:

scrape_configs:
  - job_name: "monibuca"
    metrics_path: "/api/metrics"
    static_configs:
      - targets: ["localhost:8080"]

The Dockerfile exports a wider port set than 8080: 6000, 8080, 8443, 1935, 554, 5060, 9000-20000, plus 5060/udp and 44944/udp. If you run the container, plan the port mapping before you start, because the range 9000-20000 is not something you want to discover after the fact.

Where the documentation runs out

The README is a landing page, not an operations manual. It tells you the project exists, lists capabilities, and hands you one command. It does not document configuration keys, it does not explain what each plugin does beyond a one-line description, and it does not describe what happens when a publisher disconnects mid-stream or when a database backend is unreachable.

The admin.zip dependency is the sharpest example. The README instructs you to place it next to your configuration file and does not say where it comes from. The Dockerfile copies it from the build context, with a comment noting that the GitHub Actions workflow prepares the binaries in the context root. That tells you the release pipeline produces it, but a reader following the README alone has no documented path to the file.

Versioning is a second gap. The default branch is v5, the latest release listed is v5.1.6, and the repository contains RELEASE_NOTES_5.0.x_CN.md, which is in Chinese. If your team does not read Chinese, upgrade notes for the 5.0.x line are effectively unavailable in English. The README itself links a Chinese README_CN.md, so the project's primary documentation language is not English. That is a real adoption cost for an English-speaking team, and it is not mentioned anywhere in the README's own feature list.

The AGPL-3.0 question

Monibuca is distributed under AGPL-3.0, and the README says so plainly: "Distributed under the AGPL License. See LICENSE for more information." The README's own badge block, however, links an MIT License shield, which is inconsistent with the text and with the stated licence. Treat the LICENSE file as the authority and read it before you build anything, because the badge is wrong.

AGPL-3.0 matters more for a streaming server than for a library. If you run a modified Monibuca as a network service, the licence's network clause is the part your legal team will want to read. Embedding the framework inside a product you distribute raises a different question again. The project does offer a commercial contact address, [email protected], which suggests dual licensing is available, but the README does not describe commercial terms, pricing or what a commercial licence covers. This is not legal advice; the point is that the licence choice is a first-order adoption decision here, not a footnote.

On maintenance, the last push to the repository was on 2026-09-22 and the latest release is v5.1.6, so the project is being worked on. That says nothing about whether a given plugin is complete.

How it differs from a fixed streaming server

The obvious comparison is a prebuilt media server such as SRS or mediamtx, which you download, configure and run. The difference is not protocol coverage; several of these projects speak RTMP, RTSP, SRT and WebRTC too. The difference is where your customisation lives.

With a prebuilt server, custom behaviour goes outside the process: a sidecar that watches the API, a proxy that inspects streams, a fork you maintain against upstream. With Monibuca, that behaviour goes inside the process as a plugin, written against the framework's own publisher, subscriber and transformer types. The README's third-party plugins section lists one example, https://github.com/cuteLittleDevil/m7s-jt1078, which is a JT1078 plugin. That is the shape: a protocol the core team never intended to support, added by someone else without a fork.

The trade is maintenance surface. A prebuilt server is one artifact to upgrade. A Monibuca deployment is a Go module plus whichever plugins you enabled plus your own plugin code, and every framework upgrade is a compile. If your team has no Go developers, the framework's main advantage is unreachable and the plugin model is pure overhead.

Frequently asked questions

The questions below cover the points that come up before a first build: what the framework actually is, how it relates to the protocols it supports, and what the licence requires of you.

On WebRTC versus RTMP, the README lists both as supported protocols without ranking them, and it makes no latency claim for either. The project's own low-latency statement is about the forwarding path, not about a protocol comparison.

On the meaning of "streaming server", Monibuca is a framework for building one rather than a finished product. The README's phrase is "streaming server development framework", and the plugin guide is the part you read once the default example runs.

Editorial conclusion

Adopt Monibuca if you are a Go team that needs a streaming core you can extend in-process, and you accept AGPL-3.0 obligations or plan to buy a commercial licence. Do not adopt it if you want a prebuilt binary with a documented operations manual and a fixed protocol set. Before committing, verify three things in the repository: which plugin directories hold the protocols you need, how the admin.zip asset is obtained for your build, and whether the documentation covers the failure path you care about, because the README does not.

Frequently asked questions

Official sources

1. langhuihui/monibuca on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases