Lightyear: server-authoritative multiplayer for the Bevy engine

Why server authority and not lockstep by default

Lightyear is a library for writing server-authoritative multiplayer games with Bevy, and it is compatible with wasm via WebTransport. Server authority means the server holds the truth about the world and the client sends intent, which the server then simulates and replicates back.

That choice shapes what the library is good at. Because the server decides, the client can still feel responsive: client-side prediction with rollback is enabled, in the project's phrasing, with just a one-line change. Snapshot interpolation does the same job for other entities, so entities are smoothly interpolated even if they are replicated infrequently.

Deterministic replication is also supported, but with a condition the README states plainly: the simulation needs to be deterministic. Where it applies, it is compatible with both lockstep and prediction and rollback. In other words, Lightyear does not force one network model on you. It offers a deterministic path if your simulation can be made bit-for-bit reproducible, and a prediction and interpolation path if it cannot.

The audience is Rust developers using Bevy who want the transport, replication, input and prediction plumbing assembled rather than written by hand.

A workspace split by role, thirty crates deep

The repository is a Cargo workspace, and the layout is organised by what a piece does rather than by layer. Workspace crate sources live under `crates/`, grouped by role, and the directory names drop the `lightyear_` prefix while the Cargo package names keep it.

`crates/io` holds the low-level IO links and backends, with crates for `aeronet`, `link`, `udp`, `crossbeam`, `websocket` and `webtransport`. `crates/connection` holds the connection abstractions and adapters, including `connection`, `raw_connection`, `netcode` and `steam`, and the workspace members list also includes a `p2p` crate. `crates/core` is where the top-level `lightyear` crate lives, along with shared core, sync, utils and frame interpolation crates. Then there are `crates/inputs` for input handling, `crates/replication` for replication, prediction and interpolation, `crates/transport` for serialization, transport and messages, and `crates/integration` for Bevy ecosystem integrations such as Avian, split into `avian2d` and `avian3d`.

Four more directories round it out: `crates/platform`, `crates/deterministic`, `crates/tools` and `crates/tests`, described as platform support, deterministic replication, tooling and test support respectively.

The consequence for you is that enabling a feature often means enabling a crate, and the workspace members list is the map you need. The `default-members` setting is just `crates/core/lightyear`, so a bare `cargo` command at the workspace root builds the core crate and not the whole tree.

Adding Lightyear to a Bevy project and running the box example

For Bevy 0.19, the README gives the dependency block exactly:

[dependencies]
lightyear = "0.30"

That is the whole installation step. Lightyear is published on crates.io, and the API documentation is on docs.rs, both linked from the badges at the top of the README.

Before writing your own game, the project points you at the `examples/` directory, and the tutorial in the book re-creates the `simple_box` example, so the fastest route to a working understanding is to run that example first and then follow the tutorial as it rebuilds it. The `examples/` tree is extensive: `auth`, `avian_2d`, `avian_3d`, `bevy_enhanced_inputs`, `delta_compression`, `deterministic_replication`, `fps`, `launcher`, `lobby`, `network_visibility`, `priority`, `replication_groups`, `simple_box`, `simple_setup` and `timeline_switch`.

Each example is its own workspace member, and the `justfile` has a recipe for building them with role features, where client and server add the default netcode and WebTransport stack and client and P2P add the GUI. The recipe names are documented in the file itself, for example `just build_examples` and `just build_examples features=client,server`.

Input buffering that survives packet loss

Input handling gets dedicated treatment, because a laggy input is the most common complaint in a multiplayer game. Lightyear has special handling for player inputs such as mouse presses and keyboard events. They are buffered every tick on the `Client`, and the library makes sure that the client input for tick `N` is processed on tick `N` on the server.

The loss protection is the part worth noting. Each packet contains the client inputs for the last few frames, so a dropped packet does not lose the input. This is a redundancy approach rather than a retransmit-and-wait approach, which keeps input latency independent of packet loss.

Two input ecosystems are supported directly. With the `leafwing` feature there is an integration with the `leafwing-input-manager` crate, where your `leafwing` inputs are networked for you. There is also support for the `bevy-enhanced-input` crate, and the repository carries an `examples/bevy_enhanced_inputs` directory for it.

Input delay is treated as an explicit knob rather than a hidden default. You can add a custom amount of input delay as a trade-off between a more responsive game and more miss-predictions, which is the right way to think about it, since rollback prediction can only be as good as the delay you allow.

Transport, serialization, bandwidth and lag compensation

The transport layer is agnostic, which is the point. IO backends include UDP sockets directly, and `aeronet` is used for WebSocket, Steam and WebTransport support. That list covers a native UDP game, a browser build over WebTransport, a local WebSocket stack, and Steam's networking, without the library deciding for you.

Serialization uses `postcard` as the default serializer, and you can supply your own serialization function. Message passing is built around channels, so packets can be sent with different guarantees of ordering and reliability, and packet fragmentation is supported for messages larger than about 1200 bytes.

Bandwidth management is a first-class feature rather than an afterthought. You can cap the bandwidth for the connection, and messages are then sent in decreasing order of priority, with the priorities set by you and a priority-accumulation scheme deciding what actually goes out when the cap is hit. The `examples/priority` directory demonstrates it.

Lag compensation is available so that predicted entities can interact with interpolated entities, which the README notes is used most often for first-person shooters. That combination is the classic case where a client sees its own shot as a hit while the server disagrees, and lag compensation is what resolves it.

Version coupling with Bevy and the cost of upgrades

The supported Bevy version table in the README is the most important operational fact about this project. Lightyear 0.28 to 0.30 supports Bevy 0.19, 0.26 to 0.27 supports Bevy 0.18, 0.25 supports Bevy 0.17, 0.20 to 0.24 supports Bevy 0.16, and so on down to 0.1 to 0.9 for Bevy 0.12.

Read that as a one-way dependency: when Bevy moves a major version, Lightyear has to move with it, and your game has to move with Lightyear. The `Cargo.toml` confirms how tightly bound this is. The workspace uses `resolver = "3"`, edition 2024, and `rust-version = "1.95"`, so a toolchain older than that will not build the project.

The release history shows the same pattern of steady, frequent increments rather than stable releases: 0.28.0 on 2026-06-26, 0.29.0 on 2026-08-10, and 0.30.0 on 2026-09-14. The repository is not archived and the last push was on 2026-10-14, so the 0.x line is moving quickly. Treat that as a project you track, not one you pin once and forget.

Licensing is permissive. The workspace package metadata declares `license = "MIT OR Apache-2.0"`, and the repository carries both `LICENSE-MIT` and `LICENSE-APACHE` files, so you can take either terms for a dependency, though the repository description lists Apache-2.0.

What the project does not give you

Two limits are visible in the README and the repository layout. The first is the version coupling described above, and the second is the documentation state. The README calls the book a WIP book, so the tutorial is the primary teaching resource and it is explicitly a re-creation of one example rather than a systematic guide.

There is also a scope boundary. Lightyear is a networking layer, not a game. It does not give you matchmaking, lobbies with persistence, or a backend service, though the `examples/lobby` and `examples/auth` directories show that such things can be built on top. The `crates/tools` directory holds metrics and UI tooling, which tells you the project is aiming at enough in-engine tooling to debug a session, and the `crates/tests` crate exists so the workspace can test itself.

Topologies are flexible: you can run client-server, P2P, or a client acting as the server in host-client mode. That flexibility costs a common denominator, though, since features like the GUI and P2P are selected per example through Cargo features rather than being on by default, and the justfile comments explain that the Avian 2D and 3D examples are built separately to avoid unifying those feature graphs.

Editorial conclusion

Lightyear fits a team already building in Bevy that needs netcode rather than a networking layer from scratch, and that can accept tying its dependency version to a specific Bevy release. It does not fit a team that needs a stable 1.0 API, since the crate is still on 0.30 and the version table shows a Bevy bump forcing a Lightyear bump, or a team that wants deterministic lockstep without a deterministic simulation. Before starting, add `lightyear = "0.30"` to a Bevy 0.19 project, run the `simple_box` example from the `examples/` directory, and read the tutorial at cbournhonesque.github.io to confirm that the tick and input model matches your game design.

Frequently asked questions

Official sources

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