EssentialsX: the fork of Essentials that every modern Spigot server actually runs

A fork with a blunt warning at the top of the README

The README opens by stating plainly that this is a fork of Essentials called EssentialsX, and then tells you not to ask the original Essentials project for support. The upstream repository is named. EssentialsX positions itself as the continuation of the suite, updated for modern Minecraft and Spigot versions, and claims to be a drop-in replacement for the original plugin.

That claim is the reason most servers are running it. The original Essentials stopped tracking new Minecraft releases, and server owners who needed a version that worked on a current Paper build had three choices: patch it themselves, run an unsupported version, or switch to EssentialsX. The repository topics reflect the lineage, listing bukkit, bukkit-plugin, spigot, paper, spigot-plugin and essentials-core alongside the essentialsx tag.

One consequence of being a fork worth naming: issue reports and configuration questions for EssentialsX belong in the EssentialsX tracker, not upstream. The README is unambiguous about this, and it also points support questions at the MOSS Discord community rather than at the issue tracker.

Ten modules, and you probably do not need all of them

The repository tree is the clearest description of what the suite actually does. `Essentials/` is the core module, and the rest are optional add-ons that each depend on it: `EssentialsChat/` for chat formatting, `EssentialsSpawn/` for spawn and warp handling, `EssentialsProtect/` for build protection, `EssentialsAntiBuild/` for the companion anti-build side, `EssentialsXMPP/` for XMPP chat integration, and `EssentialsGeoIP/` for geolocation lookups.

The two Discord modules are the interesting pair. `EssentialsDiscord/` implements a Discord bot that links in-game chat to a Discord channel, and `EssentialsDiscordLink/` is the separate linking mechanism that connects a player to their Discord account. Keeping them apart means a server that only wants the chat bridge does not have to take the account-linking code with it.

There is also a `providers/` directory and a `build-logic/` directory, which points at a Gradle setup with shared build conventions rather than eleven independent builds. `settings.gradle.kts` and `build.gradle` at the root, plus a `gradle.properties`, tie it together. Anyone reading the repository to understand the project is really reading a multi-module Gradle build, and the module names map almost directly onto the configuration file names administrators see on disk.

Building with the Gradle wrapper and running a local test server

Building needs JDK 8 or higher, which is a low bar. Clone the repository and run the wrapper, which is why `gradlew` and `gradlew.bat` are both checked in at the root:

./gradlew build

On Windows the README shows `gradlew build` without the leading path. The output lands in a `jars/` directory at the root, which is the same place the published downloads are organized, so what you build locally matches the layout of what you would download.

For working on the plugin itself there is a second command that spins up a throwaway server:

./gradlew build :runServer

The README flags the colon in `:runServer` with a warning, and the reason is worth repeating: without the leading colon Gradle will run several servers at once, which the project says will likely crash Gradle. That is a small piece of advice that would otherwise cost you an afternoon.

Configuration beyond the wrapper is not in the README. Checkstyle lives in `.checkstyle/`, there is a `.pre-commit` style setup implied by `CONTRIBUTING.md`, and the repository includes `.idea/` and `.github/` directories, so an IDE-specific config is checked in alongside the CI setup.

Depending on EssentialsX from your own plugin, and the group ID trap

If you are writing a plugin rather than running a server, EssentialsX publishes an API to a Maven repository. Releases live at a `releases` path under `repo.essentialsx.net` and snapshots, including dev builds, live under the sibling `snapshots` path.

The coordinates are the part that bites people. Three rows matter:

Latest release | net.essentialsx | EssentialsX | 2.22.0
Snapshots      | net.essentialsx | EssentialsX | 2.22.1-SNAPSHOT
Older releases | net.ess3        | EssentialsX | 2.18.2

Up to version 2.18.2 the group ID was `net.ess3`. From 2.19.0 onwards it became `net.essentialsx`. A build file that keeps the old group ID will fail to resolve against a current release, and a build file that uses the new one will fail against an old pin. There is no migration alias, so pick deliberately which line you depend on.

Dev builds are advertised through a badge on the README that links to the downloads page, so testing against a snapshot is a supported activity rather than something you have to ask permission for. Snapshots are exactly that though, and 2.22.1-SNAPSHOT is not the same thing as 2.22.0.

Version support is broad, and one release fixed exploits

The supported Minecraft list is long and specific: 1.8.8, 1.9.4, 1.10.2, 1.11.2, 1.12.2, 1.13.2, 1.14.4, 1.15.2, 1.16.5, 1.17.1, 1.18.2, 1.19.4, 1.20.6, 1.21.11, 26.1.2, 26.2 and 26.3. Holding that range on one branch is the practical value of the fork. It means a server owner is not choosing between a plugin that works and a plugin that is current.

The runtime requirements are less demanding than people expect. Java 8 or higher, with the README recommending the latest Java your server software supports. Server software must be CraftBukkit, Spigot or Paper, and the README is explicit that other software may work but is not tested by the team and they may not be able to help when it breaks.

The releases tell the more serious story. 2.22.0, published on 2026-05-31, adds support for content drops in Minecraft 1.21.11 and 26.1.2, and the release notes state that it fixes several item duplication and server crash exploits with a recommendation that all users upgrade. That is a server owner being told about an economy-breaking bug in their own stack. Earlier releases follow a slower pattern: 2.21.2 on 2025-08-03 and 2.21.1 on 2025-05-25, roughly every three to eight months rather than monthly.

Vault and permissions are a dependency, not a preference

The requirements list is where server owners most often get surprised. EssentialsX requires Vault to enable chat prefixes and suffixes and group support from a permissions plugin. The README recommends LuckPerms, and it explains the fallback: if you run a permissions plugin the project does not support but still want wildcards to work, you can enable `use-bukkit-permissions` in the configuration, and otherwise EssentialsX falls back to config-based permissions.

That fallback is worth understanding as a real degradation rather than a silent no-op. Config-based permissions means the plugin's own configuration becomes the authority for who can do what, which diverges from whatever your permissions plugin thinks. On a server with a carefully audited permission setup, that divergence is the kind of thing that produces a support thread nobody enjoys.

Licensing is GPL 3.0, which is the second real constraint. Running EssentialsX on a public or private server is unproblematic. Redistributing a modified jar, or bundling EssentialsX inside something you ship to others, pulls in GPL obligations. The README does not offer a commercial licence tier, so if your use case involves redistribution rather than running a server, that is a question to ask on Discord before you build on it.

Editorial conclusion

EssentialsX earns its place on a server that wants economy, kits, warps, chat formatting and moderation commands without writing plugins, and the module split means you can install only the parts you need rather than the whole suite. Two constraints deserve a look before you commit: the project is GPL 3.0, which matters if you plan to redistribute a modified build, and Vault plus a permissions plugin such as LuckPerms is a hard requirement for prefixes and groups rather than an optional extra. The README's supported version list runs from 1.8.8 through 26.3, and the last push was on 2026-09-26 with 2.22.0 published on 2026-05-31, so the 2.x branch on the default branch is the one to build. If you are writing a plugin against it, check your group ID first: `net.ess3` below 2.18.2 and `net.essentialsx` from 2.19.0 onwards.

Frequently asked questions

Official sources

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