# galaxy-s10/billd-live: a Vue 3 live streaming front end in a seven repository family

> Billd-Live is an open source Chinese live streaming platform built on Vue 3, WebRTC, Node and SRS, with a Flutter mobile app, an admin console and a paid closed source Pro edition. The README itself warns that the open version has not reached a stable release and is not recommended for production, which is the first thing to read before evaluating it.

**galaxy-s10/billd-live** — 基于Vue3 + WebRTC + Nodejs + SRS搭建的直播间

- Repository: https://github.com/galaxy-s10/billd-live
- Website: https://live.hsslive.cn
- Stars: 1,738 · Forks: 353
- Language: Vue
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/galaxy-s10-billd-live

## One front end of a seven repository family

Billd-Live is a live streaming platform in the shape of Bilibili's web live, where an owner publishes a stream and other people enter the room to watch, and any viewer can also become an owner. The project description gives the stack plainly: Vue 3, WebRTC, Node and SRS, with FFmpeg in the pipeline.

This repository is the web front end. The ecosystem table in the README lists the rest of the family, and the shape of it tells you how serious the project is about being a product rather than a demo. There is the server, `billd-live-server`, the admin console, `billd-live-admin`, a Flutter mobile app, a React Native mobile app, a Kotlin mobile app, an Electron desktop client, and this Vue repository, each with its own deployment address under the hsslive.cn domain.

So the front end here is one slice of a system whose other parts have their own licences, their own release cycles and their own deployment targets. That matters for anyone considering adoption, because running the whole thing means running a Node backend, a media server and a database as well as this code.

The topic list gives the shape of the infrastructure the design assumes: SRS for the media server, RTMP, HLS, HTTP-FLV and WebRTC for the delivery formats, FFmpeg for transcoding, coturn for the TURN server, Redis and MySQL for the state and the data, Koa 2 for the backend, and in the browser a mixture of canvas, Web Audio, web workers and Vue 3 with TypeScript.

## Three ways into the stream, four ways out

The feature list describes the ingest and egress paths in enough detail to be useful, and this is the part of the project that is genuinely instructive.

On the publish side there are three routes. The first is native WebRTC push and pull, which is the lowest latency path and needs no transcoding. The second is publishing through SRS over WebRTC, with the audience then able to pull over `http-flv`, `hls`, `webrtc` or `rtmp`. The third is publishing through MSR, with FFmpeg performing the transcoding, and the same four pull formats available afterwards.

So the delivery format is decoupled from the ingest protocol, which is the correct architecture for a platform whose viewers are split between modern browsers and players that understand FLV or HLS but not WebRTC. The consequence for an operator is that you run SRS and FFmpeg in the chain, and the latency a viewer experiences depends on which pull format their client negotiated.

The project also supports OBS and FFmpeg as publishing tools, which is what any real streamer uses, and it provides both push authentication and pull authentication, so a stream URL can be signed and a viewer can be required to present a token. That pair of features is what makes a public streaming service possible, since without them anyone with the URL can restream your content.

## PK battles, gifts and an order pipeline

The rest of the feature list describes the parts of a live streaming business that are not about video at all, and they are the reason the project is interesting to read.

The PK feature comes in three shapes: one to one, one to many and many to many, which is the collaborative live format popular in Chinese streaming. There is multi-platform restreaming to other services, named as Bilibili and Huya, and there is front end mixing, which is the practice of compositing multiple video streams in the browser rather than on the server, and that is the piece that keeps the server's transcoding cost down for a multi guest room.

Around that sit the commercial modules. There is a user module with QQ login, a payment module using Alipay's face to face payment, an order module, a product module and a gift module, and a live administration console behind them. The pages are responsive, the interface is internationalised with i18n, and the mobile client is Flutter.

Two entries in the list are not done. The Electron desktop client is unchecked in the feature list, and the integration with Tencent Cloud's TRTC real time audio and video service is also unchecked, while the separate integration with Tencent Cloud's cloud live product is done. The private deployment capability is marked as done, which matters for anyone whose users are in a region where the hosted service is not a good fit.

## The warning at the top of the README

The README opens with a caution that is worth quoting in substance: BilldLive has not yet published a stable version, and developers are not recommended to use it in a production environment.

Right next to it there is a second product, BilldLivePro, described as more stable, stronger in performance, with better code readability and more frequent updates. It is also stated to have no effect on ordinary users and to remain free for them, and to be aimed mainly at developers, with source code that is not open and a paid subscription model.

That combination is unusual and worth thinking about carefully. The open repository is the demonstration, the reference implementation and the community's playground, and the paid edition is the version the author stands behind for real use. Whether that is a good deal depends on what you need. If you want to learn how this class of system is built, the open code is there to read, and it is unusually complete. If you want something you can run in production with a support relationship, the open repository's own warning tells you the author does not recommend it.

So the honest framing is that this is a very complete reference implementation with an explicit caveat attached, not a product you can adopt as it stands. That is not a criticism of the project, which is unusually upfront about the arrangement, but it is the fact that has to shape the decision.

## The front end build: webpack, Windi, husky and standard-version

The tooling tells you what era and what conventions this front end follows. The `package.json` declares the project as `billd-live` at version 0.0.1, and the build runs through webpack with a shared configuration in `script/config/webpack.common.ts`:

```json
"build": "webpack --config ./script/config/webpack.common.ts --env production",
"start": "cross-env webpack serve --config ./script/config/webpack.common.ts --env development",
"typecheck": "tsc -p ./tsconfig.json --noEmit"
```

There is a separate start script per environment, `start:beta`, `start:preview` and `start:prod`, each setting `VUE_APP_RELEASE_PROJECT_ENV` and `VUE_APP_RELEASE_PROJECT_NAME` through cross-env, and a `start:stats` variant that turns on the webpack analyzer.

The quality tooling is thorough for a front end. ESLint runs over `.js`, `.jsx`, `.ts`, `.tsx` and `.vue` with a cache and a `lint:fix` counterpart, Prettier formats the tree, husky installs itself through the `prepare` script, and lint-staged is configured through `.lintstagedrc.js`. Commit messages are handled by commitizen with the `cz` convention, and releases are cut by `standard-version` with the version bump driven by `versionrc.js`, which means the changelog and the version number are derived from the commit history rather than typed by hand.

There is also a `windi.config.ts`, which is the utility CSS engine the styles are built on, a `pnpm-lock.yaml` for reproducible installs, a `static-build.sh` for a static build, and a `handleGiteeJenkins.js` script that the `copy` npm script runs, which is the piece that mirrors the build artefacts to the Gitee CI environment.

## Where this is the wrong project

The wrong case is obvious enough to state first. If you need a live streaming platform you can run in production today, this is not it, by the author's own statement. The alternative, the paid Pro edition, has different terms and closed source, and the open repository remains a reference.

The second wrong case is a team that only needs to publish a video and watch it. This project carries a full commerce stack, gifts, orders, payments, PK battles, an admin console and a multi platform restream pipeline. If your requirement is a handful of people talking over video, that is a different problem with a much smaller answer, and the SRS and FFmpeg pieces of this design would be the only parts you would reuse.

The third is a low bandwidth or restrictive network environment. The design assumes WebRTC with a coturn TURN server as the fallback and FFmpeg transcoding in the middle, and it assumes a public internet topology with signed URLs and a CDN in front of the HLS and FLV output. A deployment that cannot reach a TURN server, or that must keep every stream inside one network, needs a different architecture, and this one is not parameterised for it.

On the state of the code, the repository is not archived and the last push was on 2026-04-26, so work continues, but there are no GitHub releases, the package version is still 0.0.1, and the licence is one GitHub cannot classify, with no licence file among the top level entries, so the terms are whatever the licence badge and the repository page say rather than a standard grant you can rely on without reading it.

## Conclusion

Adopt the open source Billd-Live as a reference implementation if you are building a live streaming product and want to see how one author wired WebRTC, SRS, FFmpeg transcoding, PK battles, gifts, orders and pull and push authentication together, since the code covers a lot of ground that a from scratch build would take months to assemble. Do not adopt it as your production streaming platform on the strength of the README, because the project states plainly that it has not published a stable version and does not recommend it for production use, and if you want that stability you would be looking at the paid Pro edition, whose source is not open. Verify first that the SRS and coturn deployment you need matches what the private deployment scripts expect, that the push and pull authentication scheme is what your CDN requires, and that the licence covering this repository is one you can use.

## FAQ

### What is the Billd-Live project built with?

The live streaming platform is built with Vue 3, WebRTC, Node, SRS and FFmpeg. The media server is SRS, the delivery formats are HTTP-FLV, HLS, WebRTC and RTMP, FFmpeg handles transcoding, and coturn, Redis, MySQL and Koa 2 appear in the infrastructure.

### Which repositories make up the Billd-Live ecosystem?

This repository is the web front end. The family also includes `billd-live-server` for the backend, `billd-live-admin` for the administration console, `billd-live-flutter`, `billd-live-react-native` and `billd-live-kotlin` for mobile clients, and `billd-live-electron` for the desktop client.

### Can I use Billd-Live in production?

The project itself advises against it, stating that BilldLive has not yet published a stable version and that developers should not use it in a production environment. The author points to the paid BilldLivePro edition, whose source is not open, as the more stable and more frequently updated option, while noting it stays free for ordinary users.

### What streaming formats does Billd-Live support?

Publishing can be native WebRTC, SRS over WebRTC, or MSR with FFmpeg transcoding, and observers can pull over `http-flv`, `hls`, `webrtc` or `rtmp`. OBS and FFmpeg are also supported as publishing tools, and both push authentication and pull authentication are implemented.

### Does Billd-Live support private deployment?

Yes, private deployment is listed among the completed features. The infrastructure the design assumes includes coturn for TURN, SRS as the media server, and Redis and MySQL for state and data, so a private installation means running that stack as well as the applications.

## Sources

- [galaxy-s10/billd-live on GitHub](https://github.com/galaxy-s10/billd-live)
- [Issues](https://github.com/galaxy-s10/billd-live/issues)
- [Project website](https://live.hsslive.cn)
- [README](https://github.com/galaxy-s10/billd-live/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/galaxy-s10-billd-live