FerrumC: a Minecraft 1.21.8 server written from scratch in Rust

What FerrumC replaces, and for whom

FerrumC is a Minecraft server implementation written from the ground up in Rust, targeting protocol version 1.21.8. The problem it addresses is the one every Java server operator knows: the vanilla server and its forks are JVM applications, and the project's stated goals are performance and memory efficiency rather than feature parity. The README is explicit that FerrumC is "not intended to be a perfect match for the vanilla server" and that the intended audience is "the average user who wants to run a server for their friends and family", not the operator of a Hypixel-scale network.

That framing matters when you evaluate it. This is not a project that promises you can drop your existing Paper world and plugins onto it and carry on. The README's own warning block describes the current state as "early, offline-mode alpha: a creative and minigame server, not survival, not vanilla-accurate, and not a drop-in replacement for Paper or Spigot". If your players expect survival progression, mobs, or redstone behaviour that matches vanilla, FerrumC is the wrong tool today, and the README says so before you install anything.

How the Rust implementation is put together

The Cargo workspace in the root Cargo.toml shows the architecture more clearly than the README does. It is split into roughly thirty member crates under src/lib, covering the network stack (net plus net/crates/codec and net/crates/encryption), world storage and generation (world, world_gen, storage), the Anvil and NBT adapters (adapters/anvil, adapters/nbt), commands and default_commands, entities, physics, inventories, registry, scheduler, messages, particles, dashboard, plugins, and a set of utilities including a threadpool and profiling crate. The binary lives in src/bin. That layout is a deliberate separation: the protocol codec, the world format handling, and the game logic are not one monolith.

The README describes two design choices behind that split. First, the server is "fully multithreaded; Utilizes all available CPU cores, instead of a single 'main' thread", and it uses Bevy ECS "for smart, lockless concurrency". Second, it says the project wrote "custom made network, NBT and Anvil encoding systems to allow for minimal I/O lag", and the Goals section admits those libraries use "experimental APIs and some raw assembly because the existing ones just weren't up to scratch". The workspace lints confirm the posture: unsafe_code is set to "allow" while unused_unsafe is denied. That is a conscious trade: the project accepts unsafe Rust to control performance, and the lint configuration only catches unsafe blocks that are no longer needed. The excluded tools/stress-bot entry is a dev-only azalea-based load-testing swarm, kept out of the main build so its dependency tree never compiles as part of CI or release.

Installing FerrumC and joining a flat creative world

The README lists the prerequisites plainly: a Rust compiler at the latest nightly version, and Cargo, which comes with Rust. There is no published binary path in the current README; the pre-compiled binary section is commented out in the source, so building from source is the documented route. Clone the repository and build the release binary with Cargo.

git clone https://github.com/ferrumc-rs/ferrumc.git
cd ferrumc
cargo build --release

The build produces the ferrumc binary under target/release. The Dockerfile shows the same build performed on rust:alpine3.20 with the nightly toolchain installed, cargo-chef for dependency caching, and a stripped binary in the final alpine:3.20 runtime image. It declares EXPOSE 25565 and a HEALTHCHECK that runs nc -z localhost 25565 every 30 seconds, which tells you the server listens on the standard Minecraft port. If you prefer containers, build and run the image directly.

docker build -t ferrumc .
docker run -p 25565:25565 ferrumc

Once the server is running, connect with a normal Minecraft 1.21.8 client. The README's warning block states you can join a flat creative world, that blocks such as logs, slabs, stairs, fences and doors place facing the right way, and that signs and chests work. It also lists area edit commands including /fill, /replace and /undo, a day and night cycle, and visible player rotation, held items and armor. Builds are saved when you leave, rejoin or restart the server, and an existing vanilla world can be imported. The README points to ferrumc.com for more information and notes that the official documentation at docs.ferrumc.com is "currently under construction", so the Discord server is the practical place to ask questions.

The v2 branch is where the working features live

The most important thing to understand before you build is that master and the rewrite are not the same code. The README's warning block says a fresh rewrite is being built from scratch on the rework/v2-skeleton branch, with a plan to merge it into master soon, and the feature list in that block (flat creative world, area edit commands, day and night cycle, world import, Rust plugins that can allow, block or change what players build, and a local-only web dashboard) describes what works on that branch. The v0.1.0-rc2 release is dated 2026-02-16, and the last push to the repository was on 2026-08-14, so the release tags are well behind the current branch state.

This is a real adoption hazard rather than a footnote. If you clone master and the rewrite has not landed, you may get a different feature set than the one the README advertises, and the project offers no compatibility guarantee between the two. The README does not document a migration path from master to the v2 skeleton, and it does not document rollback. Check out the branch explicitly if you want the features described in the warning block, and treat the rc tags as historical.

Where FerrumC is the wrong choice

The README rules out survival twice, once in the warning block and once in the Goals section, and the Upcoming features list still contains "PvE mechanics, and entities", web dashboard, optimizations and plugin support. So mobs, combat and entity behaviour are not there yet in the documented state. Offline mode means no authentication against Mojang accounts, which is fine for a private server among friends and unacceptable for anything public.

The plugin story is another boundary. The README describes plugins written in Rust, with the Goals section noting that Rust via FFI is the current mechanism and that other languages will be considered later. If your server depends on the Java plugin ecosystem, FerrumC cannot run it. The project also states it is not a drop-in replacement for Paper or Spigot, which means the usual migration path of copying a plugins folder and a world across does not exist. And because the server is a from-scratch protocol implementation, any behaviour you rely on that is not in the documented feature list should be treated as unverified rather than assumed to work.

FerrumC against Pumpkin, Steel and the other Rust servers

FerrumC is not the only attempt at a Rust Minecraft server. The searches people run around this project keep returning PumpkinMC, SteelMC, Stevenarella, Feather and RustCraft, which is a useful signal that the category is crowded but also that no single one has settled the question. The difference worth noting is in how FerrumC positions itself. Its README rejects the idea of being merely a faster vanilla: "Simply speeding up the server feels like a waste of the opportunity to do something new and exciting." That is a different bet from a project that aims for behavioural parity with vanilla and optimizes underneath. FerrumC is choosing to change setup, configurability and plugins along with performance, which means its correctness surface is deliberately smaller and its feature set deliberately different.

For an operator the practical consequence is that comparing feature checklists between these projects is more useful than comparing benchmarks. FerrumC's own Goals section says it wants to be the fastest implementation, but the README offers no reproducible benchmark methodology, and the performance images are screenshots rather than measurements. Treat the performance claims as directional until you can reproduce them on your own hardware, and decide between the Rust servers on which documented features you actually need.

Licence, maintenance and the cost of upgrading

FerrumC is MIT licensed, which is permissive: you can use, modify and redistribute it, including in closed products, provided the licence text and copyright notice are preserved. The repository ships a LICENSE file at the top level, and that file, not this article, is the authoritative text. Nothing in the README suggests any additional restriction on running the server commercially, but the MIT grant covers the code, not the Minecraft name or assets, and this article is not legal advice.

On maintenance, the last push was on 2026-08-14, which is recent relative to the 2026-09-28 date of this review, and the repository is not archived. The release cadence is thin, though: the two most recent tags are v0.1.0-rc1 and v0.1.0-rc2, both dated 2026-02-16, and both are release candidates rather than stable releases. The upgrade cost is dominated by the pending v2 merge. Because the rewrite is described as being built from scratch, moving from a master-based deployment to the merged v2 code is not a patch upgrade, and the README does not document a migration path or rollback. Budget for rebuilding, re-testing world import, and re-checking any Rust plugins against the new core. The nightly toolchain requirement adds a second ongoing cost: rust-toolchain.toml pins a toolchain, and a nightly pin can break when you update it.

Editorial conclusion

Adopt FerrumC if you want a small creative or minigame server for friends and are willing to build from source with a nightly Rust toolchain, accepting offline-mode alpha and no survival mechanics. Do not adopt it if you need a drop-in replacement for Paper or Spigot, vanilla-accurate survival gameplay, or a stable release. Before committing, check which branch you are building: the README states the rewrite on rework/v2-skeleton is planned to merge into master, and the v0.1.0-rc2 release dates from 2026-02-16.

Frequently asked questions

Official sources

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