ezyfox-server: an open Java game server for TCP, UDP and WebSocket traffic

A free alternative to per-user game server engines

EzyFox Server exists because of a pricing problem. The introduction explains that developers building online games often reach for an engine such as SmartFoxServer or Photon, and that these engines carry a high price tag, particularly as more users engage with the product. The stated goal of the EzyFox ecosystem is to be free and open for anyone building multiplayer games and applications. The audience is therefore Java backend teams who need realtime networking but do not want their player count to become a licensing line item. The scope is broader than a game server in the narrow sense, because the ecosystem covers TCP, UDP, WebSocket with SSL encryption, an HTTP RESTful API, a Remote Procedure Call protocol, database interaction, memory caching, and a message queue. The pitch is that you stop choosing between technologies and start writing business logic. The repository is Java, licensed Apache-2.0, and was last pushed on 2026-10-11.

Zones, apps and plugins form the server hierarchy

The architecture section gives the containment model in four lines, and those lines are the heart of the design. An EzyFox server contains multiple zones. A zone contains its user manager, multiple apps and multiple plugins. An app contains its own user manager. A plugin only handles events and client requests. The split between app and plugin is the part worth understanding: an app is a deployable product unit with its own user population, while a plugin is a behaviour that reacts to what clients do. Because a zone holds several apps, one server process can serve several titles or several logical products while sharing the networking layer. The user manager appearing at both zone and app level is what allows a user to be tracked per app and per zone. The repository layout mirrors the same structure in code, with separate Maven modules for the boot process, the core, an embedded variant, the NIO layer, a runner for NIO, and a support module.

Building it with Maven and a JDK 1.8 toolchain

The development section states the environment plainly: JDK 1.8 and Maven. The test entry point is a single command run from the source folder, and the project ships shell and batch build scripts alongside an assembly descriptor for packaging, plus a checkstyle configuration. The root pom.xml is the aggregator for the six server modules, and the .github directory holds a Maven workflow, which is also what the CI badge in the README points at.

mvn test

Expect this to be the only command most contributors need for a first check. Packaging the server into a distributable artifact is a separate step driven by the assembly descriptor, and the README does not spell out the exact invocation for it, so consult the project documentation linked from the README for that step rather than guessing. The official documentation and a getting started page are hosted on youngmonkeys.org, and the README points there for a walkthrough that it claims takes five minutes.

The protocol list is the real feature matrix

Most of the design decision in this project is captured by its transport list. TCP, UDP, WebSocket and HTTP are all supported, and traffic between clients and servers can be encrypted with SSL. On top of that sit the higher level pieces: a Remote Procedure Call protocol so a client can invoke a server method, database interaction, memory caching, and a message queue. Choosing which combination to use is described as a decision the framework makes for you, which is convenient but also the thing to watch. A project that offers a socket layer, an RPC layer, a REST layer, a cache and a queue in one box has to make opinions about how they interact, and the README does not document how those opinions are configured or where the boundaries are. The one architectural layer that is described in detail, the app and plugin split, is also the one you will write most of your code against. The dependency injection container is also present, described as a core container with bean manipulation, auto-binding and auto-implementation.

Ten client SDKs, and which one you actually need

The client side is where an engine like this lives or dies, and EzyFox publishes a long list: Android, C and C++, C#, Flutter, Java, JavaScript for ECMAScript 6, a separate JavaScript SDK, Netty, Swift, and React Native. Ten repositories means the network protocol is not meant to be hand rolled by each studio. The range spans native mobile, cross platform mobile, browser, and engine side integration, with Unity examples appearing in the sample applications rather than in the SDK list itself. The samples cover the range of use cases: a free chat application, a Cocos2d-x space game, a Unity space shooter, a Phaser HTML5 lucky wheel, a simple one two three game server, and a Unity title called Easy Smashers. Two video tutorials are also linked, one building a realtime chat application and one building a lucky wheel game, which is a reasonable way to see the zone, app and plugin model in action before writing any code.

The published benchmark is one hour of broadcast traffic

The README includes a single benchmark, and it is worth reading closely for what it does and does not say. The setup was broadcasting messages to 1000 concurrent users over one hour, on a VPS with 512MB of RAM and one CPU core, and a video of the test is linked along with a result image. That is a meaningful shape of test for a socket server, since a fan-out broadcast is the workload that punishes a blocking design. What is missing is as important as what is there. The README does not publish latency percentiles, message rates, or the frame size used, and there is no configuration file, hardware description, or tuning note attached to the number, so you cannot reproduce it or scale it. A separate open source game library, Game Box, supplies entities, managers, handlers and maths classes for turn based, MMO and normal online games, and that library is the layer where much of the application logic would go.

Where the framework does not reach

There are real limits to what the ecosystem covers. The build targets JDK 1.8, which is a constraint for teams on a current long term support JDK and who want to build without a separate toolchain, since the code and dependencies are compiled against that baseline. The documentation for anything beyond the README lives on an external site, and the README itself is a summary with links rather than a specification, so the details of zone, app and plugin configuration, and of how the RPC, cache and queue components are wired, are not in the repository. A multi player production service also has needs this list does not mention: rate limiting, abuse and cheat detection, observability, health checks, and orchestration. And the operational story is yours to build, since what is published is a server library plus SDKs, not a hosted offering, and the community route to support is a set of chat channels and a donation page. The Apache-2.0 licence keeps the commercial use question simple, and the release history shows steady work, with v1.3.2.1 published on 2026-10-11, v1.3.2 on 2026-09-17, and v1.3.1.4 on 2026-07-09.

Editorial conclusion

Choose ezyfox-server if you are building a realtime game or chat backend in Java and want to avoid per user licensing from a commercial engine, and if your clients can use one of the listed SDKs. Do not choose it if your team cannot work with JDK 1.8, if you need published latency or throughput figures for capacity planning, or if you want a managed service rather than a self hosted server. Verify first that the plugin and app model matches how your game is structured, and read the zone and app documentation at youngmonkeys.org before committing, because the README itself is a summary rather than a specification.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. youngmonkeys/ezyfox-server on GitHub