SteelMC: A Minecraft Server in Rust That Keeps Gameplay on the Main Tick

The parallelisation boundary is the whole design

SteelMC is an independent implementation of the Minecraft Java Edition server, written in Rust, with the stated goal of matching vanilla behavior while making better use of modern multicore hardware. The interesting sentence is about which work moves where. Gameplay updates remain synchronous, while chunk generation, lighting, packet processing and chunk sending can run outside the main tick. That split is a deliberate architectural choice rather than an accident of implementation, and it explains both the design and the current limitations. Keeping gameplay on the main tick means a player pressing a button sees the same ordering as on a vanilla server, which is the property that makes a server implementation credible, while the expensive background work is exactly what multicore hardware can absorb. The project tracks the latest Java Edition release and currently targets Minecraft 26.2.

World generation is the most finished part, and the evidence is a parity suite

The claim about world generation is specific enough to check. A parity suite compares 7,500 randomly selected chunks with a reproducible vanilla reference, 2,500 in each dimension, and all tested chunks match block for block. Entity spawning is excluded from the comparison because most entity behavior has not been implemented yet. That is the shape of a good parity argument: a fixed number of randomly chosen chunks, a reference implementation to compare against, and a stated exclusion with a reason. The benchmark that goes with it is narrower. On a Ryzen 9 9950X, SteelMC generated a fresh 10,201-chunk Overworld area with a median of 3.98 seconds, and the documentation is careful to say that results vary with hardware and that the benchmark does not represent every server workload. The announcement post and the benchmark page carry the full results and reproduction instructions.

What works today, and what does not

The current status list is what a client can actually do: Java Edition networking, authentication, encryption and compression, persistent chunk generation, loading, saving and lighting, player movement, collision, block interaction and inventories, commands, permissions, chat and server configuration, and early entity, block entity and gameplay behavior implementations. Clients can join a persistent multiplayer world, move and interact, use inventories and commands, and return later to saved chunks. The list of what is missing is longer and more important. Survival gameplay is incomplete, only a small number of entities have meaningful behavior, full vanilla and protocol parity have not been reached, plugins are not available yet, and Paper, Bukkit, Fabric, Forge and NeoForge extensions are not compatible. That last point closes off the plugin ecosystem that most existing servers depend on, which is the single largest gap for anyone thinking of migrating. The alternative approach is to keep running an established Java server and its plugin ecosystem, which buys you the full vanilla behaviour and the extension ecosystem today, and costs you the architecture SteelMC is built around. SteelMC's case is that the split between synchronous gameplay and parallel world work is the shape a server should have had on modern hardware, and the tracker is the argument for that case one subsystem at a time.

A Rust workspace with a pinned nightly toolchain

The Cargo manifest lists ten workspace members, and the crate names describe the architecture: steel, steel-login, steel-macros, steel-protocol, steel-registry, steel-worldgen, steel-utils, steel-core, steel-crypto and steel-math. The dependency choices tell you the shape of the work. Tokio with the multi-threaded runtime for concurrency, rayon and crossbeam for parallelism, wincode and serde for serialization, simdnbt for the NBT format Minecraft uses, and glam with rustc-hash and phf for the data structures a registry-driven server leans on. The workspace is on edition 2024 with the resolver set to version 2, and the project uses a pinned nightly Rust toolchain, which is a sign of a codebase that depends on unstable language features and therefore needs the toolchain fixed.

Running it, and the checks a contributor has to pass

Pre-built releases, Docker images and source build instructions are in the installation guide, and the common validation commands are short.

cargo test
cargo fmt --all --check
cargo clippy -r --all-targets --all-features
typos

Nix and NixOS users can get the pinned toolchain, lld, prek and typos in one step with `nix develop`, or with `direnv allow` using the checked-in .envrc. The compose file gives you a nightly image with stdin and a tty left open, port 25565 exposed, and volumes for config, saves and logs. The Dockerfile builds from rustlang/rust:nightly-alpine3.23 with the stand-alone feature and then copies just the binary and the certificate bundle into a scratch image, which is why the runtime image is as small as it is. There is also a generated formatting path, enabled by turning on the fmt feature on steel-registry, steel-utils and steel-worldgen so their generated files are formatted with prettyplease during compilation.

Contributing means reading the vanilla source first

The contribution guide describes a specific way of working. Most changes begin by reading the vanilla source, understanding the behavior it implements and deciding how to express that behavior cleanly in Rust. Before you start, the steps are to check existing issues and pull requests and discuss substantial changes, read the contributor guide and the code standards, generate the targeted vanilla source with `./update-minecraft-src.sh` and verify behavior against it, and run the relevant tests and checks. New contributors are asked to limit themselves to three open pull requests at a time so that feedback arrives before more are opened, and to start with a small contribution of around a thousand lines changed or less. Issues tagged good first issue and the tracker of unimplemented content are offered as entry points. The project is explicit that AI may be used as a tool but that contributors must understand and be able to explain every line they submit, and that fully autonomous pull requests are not accepted.

Licence, community and what to expect from an early server

SteelMC is free software under the GNU Affero General Public License v3.0 or later, which is the licence that matters for a server implementation people may run as a service. The project website, documentation, implementation tracker and Discord are the main channels, and longer updates are published on the website, with sponsorship on GitHub as the funding route. The readme leads with the warning that it is still pre-alpha: you can connect and explore generated worlds, but survival gameplay is incomplete and many vanilla systems are still missing, and you should not replace your production server with it yet. The release tags encode the Minecraft version, v0.16.0+mc26.3 and v0.15.5+mc26.2, both on 2026-10-13, with a third on 2026-10-03, and the last push was on 2026-10-20. The generated Rust documentation is published in a rustdoc reference for the steel_core crate.

Editorial conclusion

SteelMC fits an engineer studying how a modern game server is built, or a server operator who wants to test a Rust implementation on a side world. It is the wrong choice for any production server today, since the project says so plainly: survival gameplay is incomplete, plugins do not exist, and Paper, Bukkit, Fabric, Forge and NeoForge extensions are not compatible. Before you spend time on it, read the implementation tracker and the benchmark page, because the parity claims and the world generation numbers are specific and worth checking against your own hardware.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Steel-Foundation/SteelMC on GitHub