valence-rs/valence: building Minecraft servers in Rust on Bevy ECS

What Valence replaces, and who it is written for

Valence targets Minecraft: Java Edition servers written in Rust. The README frames it as an effort to build a Minecraft compatible server completely from scratch in Rust, and describes it as a game engine for Minecraft servers: it does not ship game rules, it ships the protocol plumbing and the ECS scaffolding you write rules against. The intended audience is developers building highly custom experiences such as minigame servers, where the vanilla loop is not the product. Opinionated features like dynamic scripting, dedicated executables and vanilla game mechanics are expected to arrive as optional plugins rather than core code, so the framework stays small and you compose the rest. If you want a server that boots into survival Minecraft, this is the wrong layer. If you want to own the tick loop, the entity model and the packet handling, it is the right one.

Bevy ECS underneath, protocol crates on top

The architecture is visible in two places. First, Valence is built on Bevy ECS, so entities, components and systems are the vocabulary; the README points at Bevy's plugin system as the extension mechanism, which means user code plugs in the same way Bevy plugins do. Second, the root Cargo.toml splits functionality into optional crates wired through feature flags: advancement, anvil, boss_bar, equipment, inventory, log, network, player_list, scoreboard, world_border, command, weather and testing are all on by default, and each maps to a dependency such as valence_advancement or valence_anvil. Turning a feature off removes the crate, so a server that never touches scoreboards does not compile scoreboard code. The repository also carries an extractor directory described in the README as a Fabric mod that extracts data from the game into JSON files, which a build script processes to generate Rust code; those JSON files are reusable in other projects. That pipeline is how the framework tracks a moving game format without hand-writing tables. On top of this sit concrete subsystems: NBT via valence_nbt, authentication, encryption and compression, block states, chunks, entities and metadata, a bounding volume hierarchy for spatial entity queries, dimensions, biomes and worlds, a JSON text API, inventories, items, particles, read-only Anvil loading and proxy support for Velocity, Bungeecord and Waterfall.

Running the examples, then depending on Valence

The README's first path is the example set, which is the fastest way to see a working server. Clone the repository and run the parkour example in release mode; the README also recommends game_of_life, terrain and cow_sphere.

cargo r -r --example parkour

With that process running, open a Minecraft client and connect to localhost. If the connection succeeds you are on the example server and can move around the generated world. The examples directory lists the rest of the surface area, from advancement.rs and anvil_loading.rs through command.rs, chest.rs and resource_pack.rs to server_list_ping.rs, so you can read a feature's usage before writing your own.

To depend on the published crate, add it with cargo. The README warns that the crates.io version is likely outdated, and the only release listed is v0.1.0 from 2022-09-03, which makes that warning concrete rather than cautious.

cargo add valence

For current code, the README shows a git dependency in Cargo.toml instead. Documentation from the main branch is hosted at valence.rs/rustdoc/valence/.

[dependencies]
valence = { git = "https://github.com/valence-rs/valence" }

Pinning a revision or tag on that git line is the difference between a reproducible build and one that shifts under you, since main is the development branch.

Where Valence will cost you time

The README carries its own warning: Valence is still early in development with many features unimplemented or incomplete, and you should expect bugs, limitations and breaking changes. Treat that as the operating constraint, not a disclaimer. A git dependency on main means an upstream commit can break your build between two of your own releases, and the feature-flag layout means a subsystem you rely on can be reshaped or moved. Version support is another boundary: the project targets the most recent stable Minecraft version and does not plan support for multiple versions at once. The README's answer for older clients is a proxy running ViaBackwards, which is an extra moving part you now operate. Anvil support is read only, so world saving in that format is not something the framework does for you. And the framing itself is a limitation: because Valence deliberately does not implement vanilla game mechanics, a team expecting a configurable server will spend its time rebuilding behavior that a conventional server jar already ships.

Valence against a plugin-driven server platform

The obvious comparison is Paper or Spigot, and the difference is where the extension point lives. On a plugin platform you run a finished Java server and register against its API; the server owns the tick loop, entity handling, world storage and vanilla behavior, and your plugin sits inside those rules. Valence inverts this. You own the binary, the ECS world and the systems, and the framework supplies protocol-level abstractions you call into. The README states that direct access to the Minecraft protocol is provided, which is the part a plugin API usually hides. The trade is stark. You get control over the tick loop and the data model, and in exchange you implement anything the framework does not, in Rust, against a project that warns about breaking changes. A plugin platform is the better choice when the game you want is close to vanilla. Valence is the better choice when the server behavior is the product and you would otherwise be fighting an API designed around someone else's game loop.

Maintenance, licence and what upgrading looks like

The repository is not archived, and the last push to main was on 2026-06-15, roughly three months before this writing. That is recent activity, but the release history is thin: v0.1.0 on 2022-09-03 is the only release listed, so there is no cadence of tagged versions to upgrade between. In practice, upgrading means moving a git revision and reading the diff, and the README's warning about breaking changes tells you to expect compile errors rather than a migration guide. Budget for that. On licensing, the README states the code is MIT while the Valence logo is under CC BY-NC-ND 4.0, so the permissive terms cover the code and a separate, more restrictive licence covers the artwork. If you plan to display or modify the logo, that distinction matters; the README does not spell out further terms, and this is not legal advice.

Editorial conclusion

Adopt Valence if you are writing custom Minecraft server logic in Rust and want direct protocol access with Bevy's plugin and ECS model underneath. Do not adopt it if you need a finished server: the README states features are unimplemented or incomplete, the only published release is v0.1.0 from 2022-09-03, and the last push to main was on 2026-06-15. Before committing, pin the exact commit you depend on, run cargo r -r --example parkour against your target client version, and check the module list in the default feature set to confirm the parts you need are present.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. valence-rs/valence on GitHub