WorldGuard protects Minecraft regions, and it will not run without WorldEdit

The unit of protection is a region, not a player permission

WorldGuard sits between the server and the people playing on it, and its job is to put borders on the map. The README frames it plainly: it lets you and players guard areas of land against griefers and undesirables, and tweak and disable various gameplay features of Minecraft. The second half of that sentence is what separates it from a permissions plugin. A region is a spatial claim that carries its own rules, so an operator can hand a build team a plot inside a shared world without granting them rights anywhere else.

The audience is therefore the server owner or moderator, not the player. The player benefits, but the person writing the rules is the one who has to keep them consistent as the world grows. Regions created early and inherited by later staff are a common source of support questions, and nothing in the project description suggests the plugin resolves that for you. The design puts the maintenance burden on the human operator, and the project leans on that operator for every rule.

Every feature is off until an administrator turns it on

The list of what WorldGuard can do is long, and the list of what it does by default is empty. The README makes that explicit: "Enable only features you want! Everything is off by default." On the block side of the equation it can stop creeper and wither block damage, fall damage, fire spread, lava fire spread and ice formation, and it can stop Endermen from picking up blocks. Items and blocks can be blacklisted so they cannot be used, or merely flagged so moderators get warned when someone uses them.

Region rules cover the rest. Areas can be protected so only certain people can build in them, and separate areas can be set where PVP, TNT, mob damage and other features are disabled. There is also protection against server exploits such as magical obsidian creation machines, a way to disable or enable particular Minecraft features such as sponges from classic, and a command that stops all fire spread immediately.

That blacklist and warn pair is the interesting mechanism here, because it separates enforcement from notification. An item can be unusable in a region while staff still receive a signal that somebody tried to use it, which turns a silent block into an observable event. It also means an unconfigured server has none of these behaviours at all, so a fresh install changes nothing about the game until someone writes the rules.

The plugin refuses to work without WorldEdit and a Bukkit server

The dependency chain is stated at the top of the README and it is a hard requirement, not a suggestion. A Bukkit server implementation, such as Paper, and the WorldEdit plugin are both required to use WorldGuard. That means the target is Bukkit-family servers specifically, and that WorldEdit is a prerequisite you must install and keep in step with the WorldGuard version you choose. Running WorldGuard on a server that has no WorldEdit plugin is not a degraded mode, it is a nonfunctional one.

The distribution story is also not GitHub. The README says you can get a release copy of WorldGuard from the BukkitDev site, and the repository itself has no GitHub releases. The GitHub repository is the source, the issue tracker and the pull request target, not the download you install. The homepage sits at enginehub.org/worldguard, end-user documentation at worldguard.enginehub.org/en/latest/, and the continuous integration status is served from builds.enginehub.org. A server owner therefore touches two sites for one plugin, one to obtain it and one to learn it, plus a third for the issue tracker if something breaks.

Three modules separate core rules from the Bukkit binding

The repository layout shows how the code is split. The build uses Gradle with a wrapper, and the project carries the usual build files plus a build-logic/ directory for custom build logic and a gradle.properties file. The source itself lives in three modules:

worldguard-core/
worldguard-bukkit/
worldguard-libs/

The names carry the architecture. A core module holds the region and rule logic, a bukkit module binds it to the server platform, and a libs module holds shared or third-party code. This is a conventional separation and it has a practical consequence for contributors: logic changes that should apply to any server platform belong in core, while anything touching the server API belongs in the bukkit module, and getting that boundary wrong is what makes a change hard to backport. The root also contains a config/ directory and the wrapper files that build it:

gradlew
build.gradle.kts
settings.gradle.kts

The README does not reproduce the build steps. It points to COMPILING.md for that, so the compile path is documented in a separate file rather than in the front page, and contributing work is additionally steered through CONTRIBUTING.md.

A custom LGPL v3 that GitHub cannot classify

Two licence statements appear, and they need to be read together. The README says WorldGuard is open source and available under the GNU Lesser General Public License v3, and it adds that submissions must be licensed under the GNU Lesser General Public License v3. The repository licence field, however, is listed as a custom licence that GitHub cannot classify, with a pointer to the LICENSE file. At the root of the tree that file is LICENSE.txt, alongside HEADER.txt.

The practical implication is that the LGPL version stated in prose is not the whole answer. A fork, a redistribution or a plugin bundle needs the actual text of LICENSE.txt, and a contribution needs to satisfy whatever HEADER.txt requires of new files. LGPL v3 also carries conditions about linking and redistribution that matter if you redistribute the plugin itself, though that is a matter for your own review rather than something the README can settle for you. Note also that contributions are accepted through pull requests on GitHub and that the issue tracker is the place to report problems, so a change that only exists as a local patch is on your own maintenance schedule.

No GitHub releases, so the version 7.0.x branch is the update channel

The default branch is named version/7.0.x, which tells you how the project expects releases to be organised: by a version line rather than by a single trunk. The repository has no GitHub releases, so the tags that matter are not surfaced on the release page, and the artefact you install comes from the BukkitDev site. For an operator, that means version selection is a manual step that happens outside the repository, and it is the point where a plugin update goes wrong: the WorldGuard build you download has to match the WorldEdit build already on the server, and the README gives no compatibility matrix to consult.

On the state of the code, the repository is not archived and the last push was on 2026-10-17, so work is landing on that branch rather than being frozen. The change log lives in CHANGELOG.md at the root, and the README notes that end-user documentation is published separately at worldguard.enginehub.org/en/latest/. Neither of those is the same thing as a release announcement, so a careful operator checks the changelog and the plugin listing together instead of waiting for a GitHub notification that will not come.

Where in-game region rules stop and other layers begin

The honest limit of this plugin is scope. Every rule WorldGuard applies is a rule applied inside a running Minecraft server, to regions an operator has drawn, for mechanics the plugin knows about. The same enforcement problem can be approached at other layers, and the difference is where the rule is evaluated. A layer outside the game, such as a proxy in front of the server or a moderation system working on connection records, sees a player before they enter a world and can act on the account rather than on a coordinate in a region. A plugin sees only sessions that already reached the server.

That makes WorldGuard the right choice for the problems it names, such as stopping TNT inside a spawn area or keeping players out of someone else's build, and the wrong choice for problems phrased in terms of accounts, network behaviour or anything that must hold when the game server is not running. The plugin also does not replace the two things it depends on. It is a layer on top of Paper and WorldEdit, and a team that has not decided whether to run WorldEdit at all is not ready to evaluate WorldGuard.

Editorial conclusion

Adopt WorldGuard when you run a Paper or comparable Bukkit server, already run WorldEdit, and need per-region rules for building, PVP, TNT or fire spread, and accept that every flag starts off and lives in the server config directory. Do not adopt it as a standalone protection layer, since it is a plugin and not a server, a proxy or a mod. Verify first that your server platform is Bukkit compatible, that a WorldEdit plugin is present on the same server, and read LICENSE.txt and HEADER.txt yourself, because the repository licence is a custom LGPL v3 variant that GitHub cannot classify.

Frequently asked questions

Official sources

1. EngineHub/WorldGuard on GitHub
2. Issues
3. Project website
4. README