Unity's community contributions repo: extra transports for Netcode for GameObjects

What the repository is, and who maintains it

The Multiplayer Community Contributions repository contains extensions provided by the community for Unity Multiplayer Networking products. The maintenance section is the part to read first, and it is unusually direct about the arrangement. The repository is a community repository and not an official Unity product, and that means three things. Unity will accept new content and bug fixes and try to keep the content in the repository up to date. Unity does not guarantee that any of the content will be supported by future Netcode for GameObjects versions. And Unity asks the community and the authors to maintain the content, being not responsible for fixing bugs in community content. The last push to the repository was on 2026-10-16, so the content is being kept current even though the support commitment is limited, and the licence is MIT with a separate file for third party notices, which matters because several of the transports wrap other people's libraries.

The transports, and the platform limits on each

The transports table is the reason most people come here, since Netcode for GameObjects ships with a default transport and the interesting cases are the others. Ruffles covers desktop and mobile. Enet covers desktop and mobile, with an asterisk on mobile that means it needs manual binary compilation. LiteNetLib covers desktop and mobile. SteamNetworkingSockets is for Steam, and Facepunch is for Steam as well. WebSocket covers desktop, mobile and WebGL. WebRTC covers desktop, mobile and WebGL, and is the newest of the set, marked only against the current Netcode version. Photon Realtime covers desktop, mobile and WebGL, with a note that other platforms such as console platforms are also supported but require communication with Exit Games. Multipeer Connectivity is for iOS. The two footnotes matter more than the table looks, because a transport marked for Steam or for iOS is not a general purpose choice, and one that needs manual binary compilation is a build step you inherit.

The runtime extensions, which are not transports

The second table covers extensions rather than transports, and the difference is what they sit on. LagCompensation, NetworkObjectPool, NetworkManagerHud, NetworkDiscovery and NetworkDictionary are the five listed, and each is marked against the Netcode versions it was built for. Lag compensation is the one most projects reach for, since it is the mechanism that makes a client-side action land where the server thinks it should, and a lag compensation implementation is exactly the kind of thing that is easier to take than to build correctly. NetworkObjectPool covers the cost of spawning networked objects repeatedly. NetworkManagerHud is a debug view. NetworkDiscovery is about finding peers. NetworkDictionary is about synchronising a dictionary over the wire. All five are marked for the current and the 0.1.0 lines, and NetworkDictionary is the only one not marked for the oldest v12 line, which tells you it came later.

Version support, expressed as a table

The compatibility table is what makes this repository usable, and its axes are the Netcode for GameObjects versions, with columns for 1.0.0, 0.1.0 and v12. Reading across the transport rows gives a clear picture of what is old and what is new. Ruffles, Enet, LiteNetLib and Facepunch are marked for all three versions, so they have been around the whole time. WebSocket, Photon Realtime and Multipeer Connectivity are marked for 1.0.0 and 0.1.0 but not for v12. WebRTC is marked only for 1.0.0, which is why it is the newest addition. That pattern is a reasonable proxy for how much risk you are taking on a given transport, since a transport that has been carried across three Netcode majors has been through more upgrade cycles than one that only appears in the newest column.

Release branches, and how to pick one

Content for a specific major version of Netcode for GameObjects can be found in the release branches, and two are listed. There is a v12 branch and a 0.1.0 branch, each linked from the table. This is the mechanism that resolves the support question, because a project on an older Netcode major should not be pulling the community content for the newest one, and the branch structure lets both exist at once. The two how-to guides at the top of the repository cover the two ways in: installing a community transport for Netcode for GameObjects, and installing the community extensions package, and they are separate documents because the two are distributed and consumed differently. The repository root also carries an artifact_paths.json, which is the kind of file a package build reads, and the directory layout is a Transports/ directory and a com.community.netcode.extensions/ directory alongside the documentation.

Where the questions should go, and the contribution route

For general questions, networking advice, or discussions about Unity Multiplayer Networking or Netcode for GameObjects, the project points you to a Discord community or the Unity Multiplayer Forum. New content goes through the contribution guidelines in CONTRIBUTING.md, and the repository also carries a code of conduct, which is the ordinary governance for a project that accepts outside code. The split of responsibilities runs through all of it. Unity keeps the repository current and takes bug fixes, the authors maintain their own contributions, and neither Unity nor the authors of a given transport are on the hook for a future Netcode upgrade breaking something. If you are evaluating a transport for a shipped game, the sensible question is not whether the code is good but who you would call when a Netcode upgrade changes an API underneath it, because the answer in this repository is that you would call the author, and there is no guarantee they still will.

Editorial conclusion

This repository fits a Unity team that needs a transport Netcode for GameObjects does not ship, such as WebRTC, WebSocket, LiteNetLib or the Photon Realtime integration, and it fits a team that wants lag compensation or a network object pool without writing them. It does not fit a team that wants a supported vendor dependency, because the maintenance section says in terms that the content may not be supported by future Netcode versions and that Unity is not responsible for fixing bugs in community content, and it does not fit a project still on an old Netcode major unless you pick the matching release branch. Before you take anything from here, check which Netcode major version you are on against the compatibility table, read the maintenance section as a contract rather than as boilerplate, and check whether the transport you need has a platform limitation, since several of them are marked for particular platforms only.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Unity-Technologies/multiplayer-community-contributions on GitHub