bevy_replicon: server-authoritative replication that leaves the transport to you

Replication rules, not a magic mirror of your world

Bevy Replicon is described as a server-authoritative replication crate for Bevy, and the feature list is the clearest description of the model.

Automatic world replication is the first item, but the mechanism underneath is what matters. State serialization is based on replication rules, which means you declare which components replicate and how they are serialized rather than having the whole world mirrored. Remote events and triggers are the second item, and authorization support is the third, followed by control over client visibility of entities and components.

The visibility item is what separates this from a naive approach. In a multiplayer game, two clients in the same session often should not know about each other's entities at all, and sometimes should not know about specific components on entities they can see. Having a per client visibility control in the replication layer, rather than bolting one on afterwards, is a design choice that pays for itself in games with hidden information.

ECS relationships come into it too, with the ability to specify which entities should be replicated in sync using ECS relationships, so a parent-child structure in your game maps onto what gets replicated.

Serialization is customizable even for types that do not implement serde traits, which the documentation calls out explicitly with Box<dyn Reflect> as the example. In a Bevy project that leans on reflection rather than serde for its component data, that removes a real constraint.

The crate also abstracts game logic to support singleplayer, client, dedicated server and listen server configurations simultaneously, which is how you get an offline mode out of the same code that runs the multiplayer mode rather than a separate build.

No built-in I/O means you choose the transport, and pick one carefully

The design decision that most affects how you adopt this crate is stated plainly in the feature list: no builtin I/O, can be used with any messaging library.

Replicon does the replication and the messaging is somebody else's job. The README points at the messaging backends section for already available integrations, and the list covers renet through bevy_replicon_renet, renet2 through bevy_replicon_renet2, quinnet through bevy_replicon_quinnet, aeronet through aeronet_replicon, and matchbox through bevy_replicon_matchbox. Matchbox in particular is the one aimed at browser clients through WebRTC.

There is a version compatibility rule attached to these, and it is a warning rather than advice. Ensure that your bevy_replicon version is compatible with the used crate according to semantic versioning. Because the crate version tracks the Bevy version, a Bevy upgrade tends to move the Replicon version too, and a backend crate has to move in step. That is the main operational cost of this design.

The examples live in the example_backend directory in this repository, because you need I/O in order to run them. The messaging backend repositories usually contain the exact same examples with the backend initialisation adapted to each backend API, which is the practical way to see what integration actually costs.

For orientation, the README points newcomers to a glossary and to a Bevy discussion on what kind of networking a given game should use, and it also links a talk at Bevy Meetup #9 and a third party article on adding networked multiplayer to a game with Bevy Replicon.

The version table is the compatibility contract

Bevy Replicon is versioned against Bevy, and the README publishes the mapping as a table, which is the single most useful thing on the page for anyone planning an upgrade.

The current pairing is bevy 0.20.0 with bevy_replicon 0.45. Earlier rows go back a long way: bevy 0.19.0 maps to 0.41-0.44, 0.18.0 to 0.38-0.40, 0.17.0 to 0.36-0.37, 0.16.0 to 0.33-0.35, 0.15.0 to 0.29-0.32, 0.14.0 to 0.27-0.28, 0.13.0 to 0.23-0.26, 0.12.1 to 0.18-0.22, 0.11.0 to 0.6-0.17, 0.10.1 to 0.2-0.6 and 0.10.0 to 0.1.

The recent release list shows how quickly that moves. Version 0.45.0 was published on 2026-10-11, 0.45.1 on 2026-10-13 and 0.45.2 on 2026-10-15, and the last push to the repository was on 2026-10-15. Three patch releases in four days is normal churn for a crate that follows a fast moving engine, and it means your Cargo.lock will need attention on every Bevy bump.

The manifest shows the crate is on edition 2024 and depends on bevy 0.20 with default-features off and the bevy_state feature enabled, along with petgraph, variadics_please, typeid, bytes, serde, bitflags, smallbitvec, smallvec, postcard and xxhash-rust with the xxh3 feature. The workspace includes the example_backend member, and the published package includes only /src and the licence files.

Two implementation details are worth noticing in the dependency list. postcard is the serialization format, which suits a game networking stack because it produces compact binary output. And there is a target specific dependency block for platforms without atomic CAS support, where bytes is pulled in with the extra-platforms feature, which is how the no_std claim is kept honest.

Unusual targets, a hackable API, and a broad ecosystem

Two claims in the feature list stand out from the ordinary.

The first is that the crate supports no_std and environments without atomic CAS, such as thumbv6m. thumbv6m is an ARM Cortex-M0 target with no atomic compare-and-swap, which rules out most of the concurrency primitives a network stack would normally rely on. The dependency block that adds bytes with extra-platforms for exactly those targets is what makes the claim real rather than aspirational, and it means the crate can run on microcontrollers and other constrained targets.

The second is that the crate is hackable, with a pointer to the ecosystem section. The project provides an API that allows external crates to integrate with Replicon or to be built on top of it, which is the mechanism behind the whole list of messaging backends, rollback libraries and visibility extensions.

The ecosystem is broad and the maintenance status is marked honestly. Under interpolation and rollback there is bevy_rewind, a server-authoritative rollback inspired by Rocket League. Under a heading for unmaintained crates there are bevy_replicon_repair, which preserves replicated client state across reconnects, bevy_replicon_attributes, an extension of the raw client visibility API that adds ergonomic visibility control through client attributes, bevy_replicon_snap for snapshot interpolation and client-side prediction, bevy_timewarp, a rollback library that buffers component state, and bevy_bundlication, which automates the creation of replication rules for bundles.

That unmaintained list is not a criticism, it is a map of the extension points. Each of those crates solves a problem that the core deliberately does not, and if one of them matches what you need you can use it or read it as a worked example of the extension API. The `hackable` claim in the feature list is really a pointer to this section.

The repository also has a benches/ directory, a codecov.yml and a codecov badge, a deny.toml for dependency auditing, a build.rs, and tests/ directories, so the performance and coverage claims have the tooling behind them.

Licensing and where to ask questions

Bevy Replicon is licensed under either the Apache License, Version 2.0 or the MIT License at your option, and both files, LICENSE-APACHE and LICENSE-MIT, are in the repository root. The Cargo.toml records the same choice as MIT OR Apache-2.0, and the crate categories are game-development and network-programming.

The dual licence is the standard Rust convention, and it matters here because the crate sits inside a commercial game with no lock-in. You pick MIT for the shortest notice obligations or Apache-2.0 for the explicit patent grant, and either way you can ship the game without publishing your own code.

The authors are listed in the manifest as Hennadii Chernyshchyk and koe. The home page for the crate is the crates.io listing for bevy_replicon, and the API documentation is on docs.rs, where the README points for the quick start guide. The docs.rs build is configured with all-features enabled and a docsrs cfg, so the published documentation reflects the full feature set.

For questions there is a dedicated bevy_replicon channel in the Bevy Discord server, and the CHANGELOG.md at the repository root carries the release history in more detail than the tag list does.

Editorial conclusion

Bevy Replicon suits a Bevy developer who has decided on a server-authoritative model and wants replication rules, remote events and per client visibility without writing the replication layer, especially one who already has a transport or wants to choose one later. It does not suit you if you want a turnkey networking stack, because there is no built-in I/O and you must pick and integrate a messaging backend, and it does not suit a project that cannot accept the Bevy version cadence, since the crate version tracks the Bevy release line closely. Before you adopt it, check the compatibility table for your Bevy version, pin the matching bevy_replicon version, and note that the example_backend directory in this repository is where you can read what a backend integration actually looks like.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. simgine/bevy_replicon on GitHub