Dragonfly: a Go server for Minecraft Bedrock Edition, meant to be embedded

What Dragonfly is and what makes it different

Dragonfly is a heavily asynchronous server software for Minecraft: Bedrock Edition written in Go. It was written with scalability and simplicity in mind and aims to make the process of setting up a server and modifying it easy.

The distinguishing sentence comes next: unlike other Minecraft server software, Dragonfly is generally used as a library to extend.

That single design choice accounts for most of what is different about the project. A conventional server is an application you run, configure through files and interact with through commands. Dragonfly is a Go package you import, and the world model, the player handling, the item registry and the protocol handling are all part of its public API. The README points at the developer info section and calls it a well-documented codebase with an easy-to-use API, with documentation on pkg.go.dev and in the subpackages you reach by clicking Directories.

The asynchronous emphasis is the other half. A Bedrock server is a networked, tick-based simulation, and a heavily asynchronous implementation means the parts that wait on the network, on the database or on chunk generation do not block the ones that do not. For a server meant to scale, that is the difference between adding players and adding latency.

The project is MIT licensed, the default branch is master, and the last push was on 2026-09-20. The repository has no GitHub releases, which for a library used as a dependency is less of a problem than it would be for an application, since Go dependencies are pinned by module version rather than by a release page.

Getting it as a library and running it from source

Running Dragonfly requires at least Go 1.26, and after starting the server through one of the available methods, ctrl+c may be used to shut it down.

There are two documented installation routes and they map onto the two ways you would use the project.

As a library, you create your own Go module and add Dragonfly to it:

go mod init github.com/user/module
go get github.com/df-mc/dragonfly

That is the route the project is designed around. Your module imports the server package, you construct a server with the configuration you want, and you own the main function. The wiki link in the README points to the setup documentation for this path.

To run the latest commit directly, you clone and run it:

git clone https://github.com/df-mc/dragonfly
cd dragonfly
go run main.go

That is the route for trying it out or for working on Dragonfly itself, and it is also the route that shows the shape of the project: there is a main.go at the root, a cmd/ directory, a server/ directory holding the package that everything else imports, a config.toml for configuration, and a doc.go at the root for the package documentation.

The dependency list in go.mod describes what a Bedrock server actually needs, and it is worth reading as a specification of the protocol rather than of the server. The network stack is go-raknet from the sandertv organisation for the Bedrock transport, plus pion/ice for NAT traversal and the pion family for WebRTC, which covers the voice and video chat features of Bedrock Edition. Data persistence is df-mc/goleveldb, an embedded key-value store, with worldupgrader handling the migration of world data between versions.

There is also df-mc/go-nethernet for the NetherNet networking protocol, the PlayFab and XSAPI client libraries for the Bedrock services, and intintmap and fasthash as the fast integer-keyed maps the tick loop needs. Configuration is pelletier/go-toml, and the version is go 1.26.0.

What the project wants from its contributors and its users

The README's Developer info and Contributing sections are short, and together they describe a project with a specific culture.

For users, the project asks you to consider adding the #df-mc topic to your repository and opening a pull request at df-wiki adding your project as a Community Project to improve its visibility. That is a directory of projects built on Dragonfly, which tells you the ecosystem is organised around the library rather than around a server distribution.

For contributors, the message is that contributions are very welcome, issues, pull requests and feature requests are highly appreciated, and if you are opening a pull request you should consider joining the Discord server to discuss your changes first. There is a CONTRIBUTING.md in the repository for the details, and a wiki for the more substantive documentation.

The hacktoberfest topic on the repository and the presence of a .golangci.yml with a lint target in the Makefile point to a project with a steady intake of outside patches and a defined style gate. The Makefile is minimal, with a single lint target that runs golangci-lint v2.11.4 through go run, so the linting version is pinned in the build rather than assumed to be on the developer's machine.

The README's own description of the wiki as the place to check for more detailed info is worth taking literally. The document covers installation, licensing, contribution and a short developer section. Everything about how the server is actually configured, how the world model behaves and which protocol features are supported lives in the wiki and in the godoc comments. That is a common shape for a library project whose main artefacts are the API and the wiki rather than a manual, and it is a reason to budget reading time before writing code.

Limits: no releases, a fast protocol and a library that is not a server

Several limits are worth stating, and some of them follow from the design rather than from gaps in the implementation.

The first is the release situation. The repository has no GitHub releases, so there is no version marker to pin and no release notes to read. For a Go library that is workable, because a dependency is pinned to a module version in your go.mod and the pseudo-version encodes the commit. For anyone who wants a known-good release, or wants to see what changed between versions, there is nothing to read.

The second is the protocol. Bedrock Edition's network protocol is not stable across game versions in the way that, say, an HTTP API is. It changes with each release, and a server implementation has to track it. The dependency on go-raknet and the family of df-mc libraries suggests that much of the protocol work happens in those separate modules, which is a good structure, and it also means the version you pull determines which protocol versions you support.

The third is the world upgrade problem, and it is the one that bites operators. Bedrock worlds have a format that changes between game versions, which is why worldupgrader is a dependency. A server that upgrades to a new game version has to migrate its stored world data, and that migration is not always lossless. If you are running a server with a world players care about, that is an operational concern the library handles rather than one it removes.

The fourth is that Dragonfly is not a server in the sense most people mean. There is no configuration file with a list of plugins, no permission plugin ecosystem and no admin console. You build the binary. The cmd/ directory and main.go are the starting point, and the README asks you to check the wiki for the details of how to assemble one.

The fifth is scale. Scalability is stated as a design goal, and the asynchronous architecture and the embedded key-value store are consistent with that, but the README gives no figures and no claim about how many players it handles. Anyone evaluating it for a public server needs to find that out independently.

Dragonfly against PocketMine-MP and against a vanilla Bedrock server

Two comparisons make the choice clearer.

The first is against PocketMine-MP, the other widely used Bedrock server implementation. The difference in approach is the language and the architecture. PocketMine-MP is PHP, which is why it is so widely deployed and also why its performance characteristics differ. Dragonfly is Go, and the asynchronous design is the reason it exists in that language rather than in PHP. If you are extending the server with plugins written in Go, Dragonfly is the only one of the two that makes that straightforward.

The second comparison is against the vanilla Bedrock server that Mojang ships. The difference is not performance or features; it is that you cannot modify the official server. The official server is a closed binary that you can configure but not extend, and for most people that is entirely sufficient. Dragonfly only becomes interesting when you need behaviour the official server does not have, which is the situation the Community Project directory exists to serve.

The honest framing is that Dragonfly occupies a narrow band. It is for people who want to write a Bedrock server in Go, or who want to add behaviour that has to be implemented at the server level rather than in a plugin. It is not aimed at the person who wants a server running this afternoon, and the README's own framing, that it is generally used as a library to extend, says so.

Editorial conclusion

Adopt Dragonfly if you are writing a Bedrock server in Go and want the world, player and item model available as a library rather than reimplementing the protocol. Do not adopt it if you need a battle-tested server for a public community, since there are no GitHub releases to pin and the project is explicitly aimed at extension work. Verify first that your Go version is 1.26 or newer, that the Bedrock protocol version you need is supported by the commit you take, and that you read the wiki rather than relying on the README, which covers setup and little else.

Frequently asked questions

Official sources

1. df-mc/dragonfly on GitHub
2. Issues
3. License: MIT
4. Project website
5. README