PacketEvents: one packet API across Minecraft server platforms

A protocol library, not a plugin with features

PacketEvents is a protocol library tailored to Minecraft Java Edition, designed to facilitate the processing and transmission of packets. That description is short and precise, and it is worth reading closely, because the scope is the network layer rather than the game layer.

A Minecraft server plugin normally talks to the server through a platform API. PacketEvents sits below that, where the raw protocol messages flow, and it gives a plugin the ability to listen for packets, inspect them, modify them and send them. The topics attached to the repository describe that vocabulary directly: packet, bytebuf, listener, injector, wrapper and packet-wrappers, alongside the api and minecraft tags.

The homepage is packetevents.com, the documentation is hosted separately at docs.packetevents.com with a getting started page, and the JavaDoc is published at javadocs.packetevents.com. The project also runs a Discord server and a build workflow on GitHub Actions, both linked with badges in the README.

The primary language is Java, the licence is GPL-3.0, and the default branch is named 2.0, which tells you that the project is on its second generation and that the branch layout is part of its release scheme.

The module layout is the product's real architecture

The top level of the repository is where the design becomes clear, because the modules are named after the platforms and mapping sets the library has to cover.

api/
bungeecord/
fabric/
spigot/
sponge/
velocity/

There is an api module for the shared surface, and then an implementation directory per server platform: spigot, bungeecord, velocity and sponge. The fabric side is split three ways, into fabric-common, fabric-intermediary and fabric-official, which correspond to the different mapping sets a Fabric server can run under.

Two more directories sit alongside them. netty-common holds the code that is not specific to any one server platform, which is the networking layer the library builds on, and patch holds patch files applied to other projects. There is a mappings directory as well, and a separate testlibs.versions.toml alongside libs.versions.toml, which is how a project keeps a test-only dependency set separate from the shipped one.

The build is Gradle, with build.gradle.kts, settings.gradle.kts, a buildSrc directory and the wrapper scripts. The practical consequence for a consumer is that the same API is compiled per platform, so a plugin written against PacketEvents behaves the same on a Spigot server and on a Velocity proxy, which is exactly the value of the arrangement.

Three distribution channels and a separate CI for development builds

The README separates releases from development builds, and that separation matters more for a library than it does for an application.

Releases are published in three places: Modrinth, GitHub, and SpigotMC. The presence of Modrinth and SpigotMC means the artifact reaches plugin developers through the ecosystems they already use, while GitHub holds the canonical releases. The tagged versions follow a 2.x scheme, with v2.14.0 from 2026-09-23, v2.13.0 from 2026-06-22 and v2.12.2 from 2026-06-01.

Development builds are a different channel entirely, hosted on a CodeMC job for the project rather than on GitHub releases. A plugin author who needs a fix before it appears in a tagged release can pull from there, and a plugin author who wants a stable dependency can pin a tag. Keeping the two apart is a deliberate piece of release engineering that many libraries of this size skip.

The last push was on 2026-10-15, the repository is not archived, and a CHANGELOG.md file at the root records what changed. The project also links a bStats statistics page for its plugin listing, so the library is distributed as a plugin as well as a dependency, and that plugin reports usage statistics the way plugins on that platform do.

The credit list shows what the protocol work rests on

The credits section is unusually informative for a project of this kind. It lists projects that the maintainers say they are heavily inspired by and from which small portions of code have been integrated into their work.

The first entry is protocol documentation for the Minecraft Java Edition, hosted on the Minecraft wiki. The others are ViaVersion, ProtocolSupport, adventure and MCProtocolLib. That list tells you the shape of the dependency graph in this ecosystem without the library having to describe it: version translation work, protocol support for older and newer clients, a text component library, and a protocol library that precedes it.

Two things follow. First, PacketEvents is not standing alone; the ecosystem around it already has established pieces for the same problem areas, and this project integrates small parts of them rather than reimplementing the world. Second, the protocol documentation is treated as a first-class input, which is the sensible thing for a library whose whole job is to speak a protocol that has no formal specification from the vendor.

For an adopter, that also means there is a body of prior art to read when the wrapper API does not expose what you need, and it means the credit list is the fastest map of the surrounding projects.

Where the GPL-3.0 licence bites for a plugin author

The licence is GPL-3.0, and for a library that plugin authors link into their own code, that is the fact to plan around rather than discover later.

The mechanism of copyleft reaches code you distribute. A plugin that bundles PacketEvents and is then handed to server operators is a distributed work, and the terms of the licence that covers PacketEvents follow that bundle. Teams with a permissive licence policy on their plugins, or with a policy about what they are allowed to ship, need to read the LICENSE file and, if the answer matters to them, ask their own legal function.

This is a description of the licence situation and not advice about it. What it does mean in practice is that a commercial plugin built on PacketEvents should be reviewed before it ships, and that a plugin wanting to avoid the question altogether needs a different dependency or a different distribution model.

The rest of the project's materials are unremarkable and helpful: a Discord server for questions, an editorconfig, a changelog, and a contributing workflow in the .github directory. The point of the licence is only that it is the one part of this project whose consequences reach beyond the codebase.

Editorial conclusion

Adopt PacketEvents when your plugin needs to read, write or intercept packets and you want the same code path on Spigot, BungeeCord, Velocity, Sponge and Fabric rather than a separate implementation per platform. Do not adopt it if your project cannot live with GPL-3.0, since linking it pulls your distribution into those terms, and think twice if you only need the plugin API, because a platform API is simpler when the platform is fixed. Before the first build, check the module layout in the repository against the platforms you ship on, especially which of the fabric-common, fabric-intermediary and fabric-official variants matches your mappings, and read the CHANGELOG.md file before upgrading, since the 2.x line is still moving and the default branch is named 2.0.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. retrooper/packetevents on GitHub