MiNET is a Bedrock Edition server written in C# with a generated protocol

A Bedrock server, and a stated ambition beyond it

MiNET describes itself as a Minecraft Bedrock Edition server written in C#, and the description in the repository metadata is more pointed: a not so basic Minecraft Pocket Edition server written in C#.

The What is this section gives the current goal plainly, which is to create a server that has enterprise performance for large Minecraft multi-user gaming providers. The README states that current servers handle 10 to 100 users per instance, that the aim with MiNET is to deal with thousands, and that priority is also to create interfaces and to some extent ready-made implementations of the most basic enterprise game-management features such as users and worlds. It then says that with all likelihood MiNET will emerge into a Microsoft Cloud ready product.

Those numbers are the ones the project states about its own current servers, and they are the right scale to judge it by. Ten to a hundred users per instance is a bedroom server, and the ambition is a hosted platform. That distance is the honest shape of the project, and an adopter who reads the README as a promise of a production-ready server for a game service will misread it.

The What is this section also names the two audiences the project is built for, which are not the same. There is the developer who wants to extend a Bedrock server, and there is the game-management layer of users, worlds and interfaces that a provider would need.

For a reader, the practical consequence is that MiNET is more interesting as a readable implementation of the protocol than as a deployable service today.

The protocol documentation is generated, not written

The most distinctive technical claim in the README is about how the protocol layer is produced. The project delivers an up-to-date automatically generated Bedrock protocol specification, and the README explains that this is possible because large parts of the communication code are generated from XML using T4 templates.

That is a real engineering decision rather than a documentation flourish. A Bedrock server has to speak a large binary protocol whose contents shift as the client updates. Hand-writing that layer means the code and the specification drift apart, and the specification ends up describing an older protocol than the server actually implements. Generating both from the same XML source removes that class of drift by construction.

T4 is the mechanism, and it is a text template engine rather than a compiler, so the templates live alongside the XML and are expanded at build time. The generated specification is checked into the repository, at a path under src/MiNET/MiNET/Net/ with a name referring to the MCPE protocol documentation, which means a reader can diff the protocol between versions without running anything.

The same reasoning explains the scale of the src directory and the presence of a CLAUDE.md file at the repository root. A codebase where much of the network layer is templated rather than handwritten has different maintenance characteristics from a hand-written one, and the tooling around the templates is part of the project.

For an adopter, the practical point is that the protocol layer is a build artefact, not a place to make changes. If you want to understand what the server sends, read the generated specification; if you want to change what it sends, change the XML and the templates.

Plugins are the supported way to extend it

The README answers the extension question directly. Can I do my own plugins? Yes you can, with a link to the Plugin API documentation in the wiki.

The caveat that follows is the important part. The plugin system is always going to be work in progress and the example might be a bit outdated at times. That is a candid statement from a maintainer about the stability of his own API, and it is the sort of thing an adopter should read twice before designing anything on top of it.

What the plugin model is for is spelled out in the Why do this section. One of the sub-projects of MiNET is the creation of new kid-friendly game modes, so that a child can play the kind of game rather than the kill-style game modes the project deliberately avoids. That intent runs through the whole design, and it explains why the priority list mixes protocol work with game-management features like users and worlds.

The wider project is described as a pet project and a true father-son project done together with the author's son Oliver over six years, with Oliver driving the requirements and doing much of the prioritisation of the order of implementation. The README is candid that the child is a fan of online Bedrock gaming but too young to play the real deal, and that he lacks the patience for laggy under-performant servers. The requirements the project prioritises, performance and accessible game modes, are visibly derived from that.

For a developer evaluating the plugin API, the practical position is that it exists, it is documented, and it is explicitly not frozen. Build against it, but keep the surface you depend on small.

Distribution is a NuGet package built on every push

The delivery mechanism is simple and worth knowing before you look for a download. The package is published on NuGet under the name MiNET, with the version and download count badges in the README header, and the project states that CI runs on GitHub Actions with every push to master building and packing the core MiNET package to NuGet.

That means the published package tracks the master branch continuously rather than being cut as a set of releases, and the repository has no GitHub releases at all. For a consumer, the practical consequence is that the version on NuGet is the state of master at the time of the build, so pinning a version is the only way to get a stable one, and the absence of release notes means the commit history is the changelog.

The installation question is answered by pointer rather than by command. The Getting Started section links to the Getting Started page in the project wiki, and the README opens by saying that if you cannot find the information you are looking for in the README, you should try the wiki. There is no command sequence in the README itself, which for a project that packages a server is a little surprising, and it means the wiki is a required part of evaluating it rather than an optional extra.

The project also has a NuGet-hosted identity of its own and a Discord for chat, and there are no forums. For questions there is a Stack Overflow tag, MiNET, which is a reasonable arrangement for a project of this size and a useful signal about where the real usage discussion happens.

The source tree is a conventional .NET layout with src, docs, assets and a CLAUDE.md, a LICENSE file and a PACKAGE.md, plus a .gitmodules file, which suggests that some dependencies are consumed as submodules rather than as package references.

Contribution terms, and what they say about the project

The Can I contribute section sets out three conditions, and they are worth quoting because they describe how the project is run.

You will use the same coding style as the rest of the code. You do not copy code from anyone or anywhere, unless you have their permissions. And we can always decide not to include your code, and we might make changes to it, so better ask before you do a pull request to the project.

That third condition is unusual, and it is the most informative one. It means the maintainer reserves the right to modify incoming code, and it means the project prefers a conversation before a pull request over a pull request as the first contact. Combined with the plugin caveat, it paints a picture of a project where the author wants to keep control of the shape of the code and is asking outsiders to work within that.

The first condition, on coding style, is the one that matters most for anyone who wants their patch accepted. The project is large and the communication layer is generated, so a patch that does not match the surrounding style is a patch that the author has to rewrite.

The second condition, on not copying code without permission, is worth noting in the context of a Minecraft server. Protocol implementations are a common source of copied code, and the rule is there deliberately.

The project also asks contributors to join the Discord for communication, and the Code of Conduct is the one referenced for the community. The licence situation is the loose end: the repository carries a LICENSE file and the metadata records a custom classification that GitHub cannot map, so anyone embedding MiNET in a product should read that file rather than infer the terms from a badge.

Editorial conclusion

MiNET suits a developer who wants to read a Bedrock server implementation in C#, extend it through the plugin API, or study how the protocol is generated rather than hand written, and who is comfortable with a project that says plainly that parts of it are work in progress. It is the wrong tool for running a public server for players today, because the project's own stated goal is enterprise scale for large multi-user gaming providers and the current state is a subset of that, and it is the wrong tool for anyone who needs a supported product with a service level agreement. Before you build on it, read the Getting Started page in the wiki, check the plugin API documentation, and note that the plugin system is described as always going to be work in progress with an example that can be outdated.

Frequently asked questions

Official sources

1. Issues
2. NiclasOlofsson/MiNET on GitHub
3. README