peerflix-server wraps torrent-stream in a web UI on port 9000

It is torrent-stream with a web interface

peerflix-server describes itself as a streaming torrent client for Node.js with a web UI, and the README credits its ancestry in one line: it is based on torrent-stream and inspired by peerflix.

That is the honest summary, and it tells you what the design is. There is no torrent implementation here. The peer-to-peer machinery, the piece that is hard and version-sensitive, is `torrent-stream`, and this project supplies the daemon, the HTTP layer and the browser interface around it.

The consequence is good and bad. Good, because the protocol layer is somebody else's problem and this project can concentrate on the interface. Bad, because there is no abstraction between them: the configuration options documented here are described as the options of torrent-stream passed to all torrent-stream instances, so anything you cannot express there is not expressible here.

The runtime dependencies confirm the shape. There are thirteen, and the interesting ones are `torrent-stream` itself and `read-torrent` for parsing metadata, with `socket.io` for the live connection to the browser, `express` and `serve-static` for the HTTP side, `morgan` for request logging, `range-parser` for byte-range requests, `archiver` for zipping, `multer` for uploads, `body-parser`, `pump` for stream piping, `mkdirp` and `lodash`.

`range-parser` is the one to notice. Range requests can support seeking when a browser or media player plays a streamed file over HTTP.

`fluent-ffmpeg` sits in optionalDependencies rather than dependencies; the Docker image also installs the ffmpeg system package.

Three commands and a browser

The usage section is four lines and one of them is a URL.

npm install -g peerflix-server
peerflix-server

Then open a browser at `http://localhost:9000/`.

That is the entire quick start. The package registers a single binary through the `bin` entry in package.json, pointing at `./server/bin.js`, and `npm start` runs the same file directly.

Port 9000 is where the web interface lives, and it is configurable. The README documents setting the `PORT` environment variable, with the Windows form given as `SET PORT=1234` on its own line, which is the detail that catches people out since the syntax differs from the POSIX form.

The configuration file is `config.json`, which does not exist by default, so you create it. Its contents are torrent-stream options, and the example overrides two of them:

{
  "connections": 50,
  "tmp": "/mnt/torrents"
}

The `tmp` option is the one that matters operationally. That is the directory torrent data is written to, and pointing it at a mounted volume is what lets you run this on a NAS or a small server without filling the system disk.

Application state, meaning the list of torrents, is kept separately in `torrents.json`. The split between configuration and state is deliberate, and both live under a directory you can move with the `PEERFLIX_CONFIG_PATH` environment variable, which defaults to `$HOME/.config/peerflix-server/`.

The container is Node 14 with ffmpeg added at runtime

The Dockerfile is more informative about the project's age than the release list is.

Both stages use `node:14-alpine`. The build stage installs git, then grunt and bower globally, copies `package*.json`, `app/`, `server/`, `bower.json`, `.bowerrc`, `Gruntfile.js` and `karma.conf.js`, runs `npm install`, then `bower --allow-root install`, then `grunt build`, then `npm prune --production`.

That build sequence is a 2019 front-end toolchain: bower for front-end dependencies and Grunt to build the assets, with autoprefixer, postcss, uglify, cssmin, htmlmin, svgmin, filerev and usemin all in the devDependencies. There is no bundler in the modern sense, and `grunt build` is what produces the `dist/` directory.

The release stage assembles a `release/` folder containing only `node_modules`, `dist`, `server` and `package.json`, then copies it into a fresh `node:14-alpine` image. So the final image has no build tooling in it at all.

The runtime image then does three things worth noting. It sets `PEERFLIX_CONFIG_PATH` to `/app/config` in the environment, which is why there is a volume for it. It installs ffmpeg with apk, which is what makes the optional `fluent-ffmpeg` dependency usable. And it runs as `USER node` rather than root.

Two volumes are declared, `/tmp/torrent-stream` and `/app/config`, and two ports are exposed, 6881 and 9000. 6881 is the BitTorrent port; 9000 is the web interface.

The entrypoint is `npm start` with the argument `--no-update-notifier`, so the container does not phone home on start.

Where the project is dated, and where that matters

Three facts combine to describe the state of this project, and each one has a practical consequence.

The release history is 0.0.17 in January 2015 with the release name Not dead yet, 0.5.1 in October 2019, and v0.6.0 in July 2021. So the last published release is about five years old, while the last push was on 2026-10-07. Commits continue without releases.

The container targets Node 14. That version reached end of life, so the base image receives no security updates, and if you run this on a network-facing host you are choosing to run an unpatched runtime.

The dependency tree shows its own maintenance work. Several packages are on current majors, with express at 4.21.2, socket.io at 4.8.1, multer at 2.0.0, archiver at 7.0.1 and lodash at 4.17.21. That is somebody keeping a package alive with dependabot-style updates while not cutting a release.

The security surface is the other consideration. The web interface is a local browser UI with no authentication by default, and the FAQ links to a wiki page titled How to put a password on peerflix-server. A password added through that route is a reverse proxy or a middleware arrangement, not a built-in feature.

For a torrent client, that is unsurprising, since the content is usually served over HTTP to whoever can reach the port. For anything else, a browser interface that can add and stream arbitrary torrents with no login should not be exposed beyond localhost without a proxy in front of it.

There is also the licensing question of the content itself, which the project cannot resolve for you.

Editorial conclusion

Adopt peerflix-server if you already run torrent-stream and want a browser interface over it, since the configuration model is a pass-through rather than a new abstraction. Skip it for a new deployment: the last release was v0.6.0 in 2021, the container is built on Node 14, and password protection is a wiki page rather than a default. Verify first whether you need ffmpeg, since `fluent-ffmpeg` is an optional dependency and the Docker image installs it separately.

Frequently asked questions

Official sources

1. asapach/peerflix-server on GitHub
2. Issues
3. License: MIT
4. README
5. Releases