PixelStreamingInfrastructure: the servers and frontend behind Epic's Pixel Streaming

What moved out of the engine sample

The PixelStreamingInfrastructure repository is described as the official Pixel Streaming servers and frontend, and the change it represents is the point.

The frontend and web server elements for Unreal Pixel Streaming, previously located in `Samples/PixelStreaming/WebServers`, are now in this repository, for all to contribute to. They are referred to as the Pixel Streaming Infrastructure.

That move is what makes the components usable outside a stock engine installation. A signalling server and a web frontend buried in an engine sample directory are awkward to run in production, awkward to patch, and effectively closed to outside contribution because the engine source is not something third parties modify. In their own repository, with an MIT licence and a public issue tracker, they are ordinary software.

The goals section states four reasons for the move, and they are worth quoting in spirit because they explain the shape of everything else in the repository. The first is to increase the release cadence for the Pixel Streaming servers, with the stated reason of mitigating browser breaking changes sooner. The second is to encourage easier contribution of these components by Unreal Engine licensees. The third is to facilitate a more standard web release mechanism. The fourth is to grant a permissive licence to distribute and modify this code wherever you see fit, MIT licensed.

That fourth point is the substantive one for anyone outside Epic. The server side of a streaming product is often where the licence terms of the platform vendor stop and yours begin, and here Epic has placed the signalling, the forwarding and the frontend under MIT.

The primary language of the repository is TypeScript, the default branch is master, the last push was on 2026-10-22, and the repository is not archived.

Running it, and the monorepo layout

The Getting Started section is short because the goal is to be able to build and run everything needed to connect to the Pixel Streaming plugin with a single command.

On Windows:

.\SignallingWebServer\platform_scripts\cmd\start.bat

On Linux or Mac:

./SignallingWebServer/platform_scripts/bash/start.sh

So the entry point is a platform script inside the signalling web server directory, and there is a Windows batch variant and a bash variant of the same thing. The scripts are committed rather than generated, which is worth noting for a repository that is otherwise a JavaScript monorepo.

If you want to work on a specific library within this monorepo, you `cd` into that directory and run:

`npm install` `npm run build`

And if you want to install all the dependencies and flush any existing `node_modules`, you go to the root of the repo and run:

`npm install`

The reason a single root install is enough is NPM workspaces, and the README lists four consequences of using them. Each sub-workspace within the monorepo does not have its own `package-lock.json`, there is only a single one in the root. Common dependencies are hoisted into the root `node_modules` directory. Some sub-workspaces will not have a `node_modules` directory because all their dependencies exist in the root. And when working locally, dependencies on sub-workspaces will first try to use a local `symlink` to those dependencies instead of downloading the published packages from NPM, with the example that `pixelstreaming-frontend` depends on `pixelstreaming-common` and that dependency will first be attempted to be resolved using the local `./Common` directory.

That last point is the one that matters day to day. It means you can change the Common package and see the effect in the frontend without publishing anything, and the same mechanism is what lets a licensee fork one component and keep their changes while pulling the rest from upstream.

The root package.json lists the workspaces, and the list is a map of the whole system: Common, Frontend/library, Frontend/ui-library, Frontend/implementations/typescript, Frontend/implementations/react, Signalling, SignallingWebServer, SFU, and then the Extras, which are JSStreamer, FrontendTests, MinimalStreamTester, SS_Test and mediasoup-sdp-bridge.

The parts, and what each one is for

The directory listing is the clearest description of the system, since each top-level entry is a deployable piece.

`Signalling/` is the signalling protocol implementation, and it is the component that carries the WebRTC negotiation between the game, the browser and the forwarding unit. `SignallingWebServer/` is the web server that fronts it, and it is the directory whose platform scripts the quick start commands invoke. `SFU/` is the selective forwarding unit, the media path component that receives the video stream from the game and forwards it to the connected browsers.

`Common/` holds the shared code, and it is the package the frontend depends on. `Frontend/` holds the web client, split into a `library/` workspace, a `ui-library/` workspace and two implementations, one `typescript` and one `react`, so the same frontend logic can be delivered either as plain TypeScript or wrapped for React.

`Matchmaker/` is the component that pairs a browser user with an available instance, which is what lets a deployment run several concurrent sessions behind one address.

Then the Extras, and their names describe their purpose. `Extras/JSStreamer/` is a browser-side streamer, `Extras/FrontendTests/` is the frontend test harness, `Extras/MinimalStreamTester/` is a minimal client for checking a deployment works, `Extras/SS_Test/` is a signalling server test, and `Extras/mediasoup-sdp-bridge/` is a bridge for SDP handling, named after the mediasoup library that the SFU side uses.

The health check table in the README confirms that split, because the badges are per component. There are health checks for Libraries, Platform Scripts, the Signalling Protocol, the Signalling Server Image, the SFU Docker Image and Documentation Links. Four of them have per-engine-version columns for the UE5.8, UE5.7 and UE5.6 branches, showing that libraries are published to NPM per branch, container images are published per branch, and releases are created per branch. The Signalling Server Image and SFU Docker Image checks appear only in the master column, which suggests the container builds are not tracked per branch in the same way as the libraries.

Pixel Streaming 2 and the transition period

The first section of the README is about a migration, and it is the most important thing to understand before deploying anything from this repository.

From UE 5.5 onwards, Epic Games introduced a layer that makes it easier to maintain WebRTC internally. As the original Pixel Streaming plugin used WebRTC directly, this change meant that a new plugin had to be introduced to ensure a better transition phase for the developers who have developed custom solutions on top of the Pixel Streaming plugin. For now, both the original Pixel Streaming plugin and the Pixel Streaming 2 plugin will be shipped with Unreal Engine to give users time to migrate.

So the situation is a deprecation with a long runway. The original plugin spoke WebRTC directly and the signalling server in this repository talks to it. The new plugin inserts a layer that Epic maintains, and the signalling server has to speak the new protocol instead.

A migration guide has been created at `/Docs/pixel-streaming-2-migration-guide.md` to ensure a smooth transition for all licensees using the plugin and to highlight all major changes between the plugins.

The phrase to hold on to is all major changes between the plugins. This is not a rename. Anything a licensee built on top of the original plugin, a custom signalling server, a custom frontend, an integration with their own session management, is affected by the protocol change rather than by an API tidy-up.

That is also why the repository has a Signalling health check as a separate item from the Libraries check. The signalling protocol is the part with a compatibility contract against the engine plugin, and the health check for it is the one that tells you whether the server in this repository still matches the plugin in a given engine version.

Both plugins shipping with the engine for now is the detail that determines your timeline rather than the library's. The engine keeps the old plugin available, so a deployment can stay on the original protocol until the migration guide has been worked through, at the cost of running an older signalling protocol against a newer engine.

Releases, branches and the tooling around them

The release scheme carries the engine version in the package name, which makes the branches self-documenting.

The three most recent releases are lib-pixelstreamingfrontend-ue5.8-0.1.3, lib-pixelstreamingfrontend-ue5.7-0.3.2 and lib-pixelstreamingfrontend-ue5.8-0.1.2. Two of them are for UE5.8 and one for UE5.7, and the 5.7 line is at a higher minor version than the 5.8 line, which tells you that the 5.8 branch is the newer one and started from a lower version rather than continuing the 5.7 numbering.

The repository has `RELEASE_BRANCHING.md` and `RELEASING.md` as separate documents, so branching and release procedure are documented apart from each other. There is a `RELEASE_VERSION` file and a `NODE_VERSION` file at the root, which is how a repository pins the Node version for the build without duplicating it in a workflow file.

The versioning tool is Changesets. The root package.json has a `changeset` script running `npx @changesets/cli`, the dev dependencies pin `@changesets/cli` at 2.29.7, and there is a `.changeset/` directory at the root. The workflow names in the health check table confirm the pipeline: publish NPM libraries per branch, publish container images per branch, and create a GitHub release per branch.

The rest of the tooling is modern and conventional. ESLint with a flat config at `eslint.config.mjs`, Prettier with `.prettierrc.json`, lint-staged with `.lintstagedrc.mjs`, TypeScript 5.7 with the typescript-eslint plugin, and a `pre-commit` hook that runs the staged lint. The dev dependencies are pinned to exact versions rather than ranges, which for a repository that publishes to npm is the right discipline.

The `overrides` block in the package.json is worth a look because it is the kind of thing that only appears in a repository with a security policy. `cross-spawn` is forced to 6.0.6 or newer, `glob` to 7.2.3 or newer, `serialize-javascript` pinned to 7.0.5, and `tar` pinned as well. Those are transitive dependencies being held above known vulnerable versions, and the presence of a `SECURITY.md` alongside them is a good sign about how the project treats reports.

The remaining top-level files describe the project's working arrangements: `DEVELOPING.md`, `CONTRIBUTING.md`, `CHANGELOG.md`, `CLAUDE.md`, `LICENSE.md` and a `.backportrc.json`, which is the configuration for automatic backporting of fixes onto the release branches.

Editorial conclusion

Adopt this repository if you run a Pixel Streaming deployment and want to build or patch the signalling server, the SFU or the web frontend yourself, since that is exactly what it now holds. Do not treat it as a drop-in for the engine plugin, because the signalling protocol has moved behind the Pixel Streaming 2 layer introduced in Unreal Engine 5.5 and the migration guide is the first thing to read, and check first which engine branch you need, because the releases are cut per branch and the naming carries the engine version.

Frequently asked questions

Official sources

1. EpicGames/PixelStreamingInfrastructure on GitHub
2. Issues
3. License: MIT
4. README
5. Releases