SocketIOClient-Unreal: talking to a Socket.IO server from Unreal Engine

A port of the C++ client, not a reimplementation

Socket.IO is a real-time bi-directional communication library, and its usual shape is a server written in Node.js with a JavaScript client for the web. The readme is explicit that there are alternative client implementations and that this repository uses the C++11 client library, the socket.io-client-cpp project, ported into Unreal. That choice is the single most useful fact for anyone evaluating it, because the protocol handling, the reconnection logic and the encoding rules then come from an existing client rather than from a game engine plugin that reimplements them. The library underneath uses asio for the asynchronous IO, rapidjson for JSON and websocketpp for the WebSocket layer, and the JSON value type exposed to blueprints, SIOJson, was originally forked from ufna's VaRest project. The recommended server version is 3.0 or later, and if you need plain WebSockets rather than the Socket.IO protocol, the readme points to a plain WebSocket client section in the same repository.

The compatibility table decides which plugin you install

The readme states plainly that some features in later versions of the plugin are not supported by earlier versions of the Socket.IO server API, and then gives a two by two table. Plugin versions up to v1.5.5 work with a 1.x or 2.x server and do not work with a 3.x or 4.x server. Plugin versions from v1.6.0 onwards are the mirror image: they work with a 3.x or 4.x server and not with a 1.x or 2.x one. That is a hard split rather than a gradual deprecation, so you cannot simply take the newest release and hope. If your Node service is still on an older Socket.IO server, you need an old plugin, and if it is on 3.x or 4.x you need v1.6.0 or later. The current release line follows Unreal's own versions rather than the protocol's, with v2.12.4 published for UE 5.8 on 2026-09-24, v2.11.0 for UE 5.7 and v2.10.0 for UE 5.6, so the version you want is usually decided by two constraints at once, the engine you build with and the server you talk to.

Three ways to install it

The quickest route is a release download. You download the latest release, create or choose a project, browse to the project root, usually under Documents/Unreal Project, copy the Plugins folder into that root, and the plugin is ready to use. There is also a listing on the Unreal Engine Marketplace, and the readme explains why it is there: buying it helps support plugin development and maintenance, which is worth knowing if you were planning to depend on this long term. The third route is from source, and it has one requirement that catches people out, the repository uses submodules:

git clone https://github.com/getnamo/SocketIOClient-Unreal.git --recurse-submodules

You create a Plugins folder in your project root for it, then build your project, and the plugin builds with it. That last point matters for what kind of project you can use it in, because the project has to be a C++ or mixed project for the plugin to be compiled alongside it. There is also a separate example repository with both the server and the client parts needed to try Socket.IO based chat from Unreal to any other client and back, which is the fastest way to see the whole path working before you wire it to your own service.

The component connects on begin play, or when you say so

In blueprint you add the SocketIO Client Component to an actor of your choice, and by default it connects on begin play to a default address and port, http://localhost:3000. The default is configurable, and you can change the address to point at your own service and add any query or header or other URL parameters you need, which is how you pass a token or a tenant identifier without hardcoding it in the server. If you want to control when the connection happens, the component exposes a Should Auto Connect variable that you set to false, and then you call Connect with your address yourself. That option matters for a game, where a connection that starts before the loading screen is done can fire events into a level that is not ready. On the sending side, you emit events on the component, for instance pressing M on a key to emit a chat message string, and the component is the only object you need to talk to in blueprint.

Three ways to receive an event, and which one to pick

There are three ways to receive a Socket.IO event, and the readme ranks them. Receive To Function is the recommended one, where you bind an event directly to a function or to a custom event, and the example binds a chatMessage event that carries a String parameter. You can specify the exact receiving type when you know it, and the readme links the supported signatures, or you can set the type to SIOJsonValue and decode the payload with functions, which is the option for a struct or anything complex. Receive To Delegate is the second recommended way and has been available since v2.2.0, binding the event directly to a delegate. Receive To Generic Event is the fallback: you bind the Socket.IO event to a generic Unreal event, receive it, and then filter the results by checking the event name, which is fine for a debug view and unpleasant for production code. The choice between the first two is mostly a style question about how your project already binds events.

Printing a JSON value is where people lose an afternoon

The readme singles out one mistake as very common, and it is worth repeating because the symptom looks like a bug in the plugin. If you drag from an SIOJsonValue to the print string node for basic debugging, the engine picks the display name accessor, and that prints the container object's engine name and nothing about the actual value. The fix is to use either Encode Json or As String(SIOJson Value), both of which re-encode the value as a JSON string, and Encode Json is also available for SIOJsonObject types. The same type turns up when you build payloads in blueprint. Apart from the native basic types, which are supported directly through conversion and helpers such as Construct Json String Value, you can construct SIOJsonObject values and fill their fields: you start with Construct Json Object, set the fields you want with Set String Field, and the object is auto-converted into a message, which in the readme's example produces a JSON object with a myString field set to Hello. The design is that JSON is a first-class value in the blueprint graph rather than something you have to serialise by hand.

Platform support and how the project is funded

The current platform issues are listed at the top of the readme, and there is one that matters for anyone shipping on console: Xbox and PlayStation platforms are untested, tracked as issue 117. Everything else follows from the nature of the project. The plugin is a community maintained project rather than a first party engine feature, its upkeep is supported in part by the Marketplace listing, and the release history is tied to Unreal versions, so upgrading the engine means checking whether a matching plugin release exists. The last push was on 2026-10-11, and the repository carries the plugin descriptor SocketIOClient.uplugin alongside the Source, Config and Resources directories, with the submodules declared in .gitmodules for the client library and its dependencies. The licence is a file that GitHub does not classify, so if you are embedding the plugin in a commercial game, read it before you ship. For support there is an Unreal forum thread, a Discord server and a separate example project that you can run to see the whole flow first.

Editorial conclusion

SocketIOClient-Unreal is the right choice if your Unreal project has to talk to a Node.js service over Socket.IO and you want to stay in blueprints, since the component handles the protocol and the plugin is built on the C++11 client library rather than a reimplementation. It is the wrong choice if your server is on Socket.IO 1.x or 2.x and you want the newer plugin, because the two are mutually exclusive, and it is the wrong choice on console if you need verified behaviour. Before you start, check the compatibility table against your server version, clone with submodules, and use Encode Json rather than the default display name when you print a payload.

Frequently asked questions

Official sources

1. getnamo/SocketIOClient-Unreal on GitHub
2. Issues
3. README
4. Releases