# Glowstone: a clean-room Minecraft server for Bukkit plugins, and where its gaps appear

> Glowstone is a from-scratch Java server for Minecraft: Java Edition that runs Bukkit, Spigot and Paper plugins without any decompiled Minecraft source code. The project declares itself unfinished, its most recent formal build dates from 2021, and the README build section names Maven as a prerequisite while the repository root holds only Gradle files.

**GlowstoneMC/Glowstone** — A fast, customizable and compatible open source server for Minecraft: Java Edition

- Repository: https://github.com/GlowstoneMC/Glowstone
- Website: https://glowstone.net
- Stars: 2,010 · Forks: 281
- Language: Java
- License: NOASSERTION
- Published: 2026-10-11 · Updated: 2026-10-11 · Language: en
- Canonical page: https://hysenlabs.com/projects/glowstonemc-glowstone

## A clean-room Java server for plugin operators who do not need vanilla Minecraft

Glowstone exists because the mainstream Minecraft server ecosystem carries a legal problem. CraftBukkit and the forks derived from it depend on decompiled Minecraft source code, which sits in uncertain legal territory. Glowstone rewrites the server from scratch, drawing on reverse-engineered protocol documentation and original Java code, so no Mojang-owned material appears in the source tree.

The target is an operator running minigame networks, utility servers, or testing infrastructure where vanilla survival mechanics play no part. Players connect and interact through plugins, and the underlying game engine exists only to provide the API surface those plugins call. In that context, completeness of vanilla behavior is not the measure of quality.

The project documentation names two main goals: a lightweight Bukkit API implementation for situations where exact vanilla functionality is not needed, and a server that delivers higher performance than the official software when a large number of players must be supported. Where vanilla gameplay matters, Glowstone is the wrong choice.

## Thread-per-world scheduling and when synchronization actually runs

Each Minecraft world in Glowstone runs on its own thread. Cross-thread synchronization only occurs when the Bukkit API itself requires it, not as a general rule. According to the project documentation, this thread model is the reason Glowstone delivers a performance improvement over CraftBukkit in situations where a large number of players must be supported simultaneously.

For plugin authors who stay within standard Bukkit API calls, the thread model is invisible. The synchronization is handled by Glowstone's engine rather than being exposed through the plugin API, so the standard call paths work as they would on any Bukkit-compatible server. The problem arises with plugins that bypass the Bukkit API and call directly into CraftBukkit internals, specifically classes from the org.bukkit.craftbukkit or net.minecraft.server packages. Those packages do not exist in Glowstone because no code was taken from CraftBukkit. A plugin that imports them will fail.

Contributing to Glowstone is also structurally easier than contributing to CraftBukkit for the same reason. With no decompiled source to work around, a contributor changes original Java code rather than maintaining a minimal diff against proprietary output. The contribution barrier is lower by design.

## The Bukkit compatibility promise: what it covers and where it stops

Glowstone's API compatibility covers Bukkit, Spigot and Paper plugins in principle. The qualifier is that some plugins call parts of the Bukkit API that Glowstone has not yet implemented. An unimplemented method can result in a silent return, an exception at runtime, or a plugin feature that simply does not work.

The harder limit is CraftBukkit-specific code. Plugins that import from org.bukkit.craftbukkit or net.minecraft.server are written for the CraftBukkit implementation layer, which is absent in Glowstone. On Glowstone, their startup or their first affected call will fail unless the plugin detected the missing packages and handled the gap itself. The README frames a completed Glowstone as one that would support all Bukkit plugins, placing the current state on a coverage map rather than a permanent exclusion list.

Before running any plugin on Glowstone, examine its source code or documentation for NMS imports. A plugin that documents a CraftBukkit dependency will not function on Glowstone as written.

## One build script, one output jar, and first-run configuration in config/glowstone.yml

Building Glowstone requires Oracle JDK or OpenJDK, and a clone of the repository from its dev branch. The scripts/ directory provides a build script that handles compilation:

```bash
git clone https://github.com/GlowstoneMC/Glowstone
cd Glowstone
./scripts/build.sh
```

The output is a single jar at build/libs/glowstone.jar. Dependencies are shaded into the jar at compile time, so the runtime requires only a JVM. The README gives a recommended startup command with heap limits and a garbage collector flag:

```bash
java -Xms1G -Xmx1G -XX:+UseG1GC -jar glowstone.jar
```

On first start, Glowstone generates a config/ subdirectory. The main configuration file is config/glowstone.yml, which replaces CraftBukkit's server.properties and bukkit.yml. During that initial run, Glowstone imports settings from those two files into config/glowstone.yml. Log output goes to logs/. Running java -jar glowstone.jar --help shows the full list of available command-line options. The JLine console that provides colored output can be disabled through config/glowstone.yml for headless or scripted environments.

## The build section names Maven, but the repository root contains only Gradle files

The build instructions in the README begin: "After installing Oracle JDK (recommended) or OpenJDK, and Maven." The repository root contradicts that instruction. It contains build.gradle.kts, gradle.properties, a gradle/ directory, gradlew and gradlew.bat. Maven reads from pom.xml, which is not present among the top-level entries.

The ./scripts/build.sh script is the only build entry point the README gives. No pom.xml appears in the repository root, so there is nothing for Maven to work with. The repository contains Gradle build files but not Maven build files.

This is a practical issue for contributors, not for someone who only wants to run the compiled jar. Anyone setting up the project in an IDE needs to import it as a Gradle project through build.gradle.kts, not as a Maven project. IntelliJ IDEA and Eclipse detect the Gradle project structure when pointed at the repository root, so the setup friction is low for anyone who looks at the files before reading the README. A contributor who follows the README step by step will install Maven and then have no use for it.

## A project that declares itself unfinished, with no formal build published since 2021

The README's drawbacks section contains this statement: "Glowstone is not finished. Nothing is guaranteed to work." That is the project authors' own description, not characterization from outside.

The most recent formal build is 2021.8.0, published on 2021-09-01. The glowstone.net downloads page offers LTS and monthly builds for operators who need something compiled more recently. GitHub shows no formal version since that 2021 build. An operator who wants a pinned, reproducible build with a version number to cite in a bug report has only the 2021 formal build or a self-compiled snapshot.

Testing is also less formal than the Bukkit project's own process, a gap the project documentation acknowledges directly. Support and bug reports go through the GitHub issue tracker, which the README names as the primary support channel.

## Paper as the production alternative, and when Glowstone's trade-off is worth it

For most plugin-compatible Minecraft server operators, Paper is the practical choice. Paper is a fork of Spigot, which is a fork of CraftBukkit. It ships builds alongside new Minecraft versions, carries the full vanilla implementation, and supports the CraftBukkit internals that NMS-dependent plugins expect. The trade-off is the one Glowstone was built to avoid: Paper's codebase includes decompiled Minecraft code.

Glowstone's clean-room architecture has value in narrow circumstances. An operator who contributes to server software and wants to avoid the legal ambiguity of decompiled code, or one running servers where no vanilla feature is ever called, has reason to evaluate it. For the majority of plugin operators, the current incompleteness makes Glowstone a test platform rather than a production one.

The repository was last pushed on 2026-05-18, and the LICENSE file holds custom terms that GitHub cannot classify with a standard identifier; read that file before distributing a modified build.

## Conclusion

Glowstone suits operators running plugin-heavy Minecraft: Java Edition servers where vanilla game mechanics are not needed and a clean-room codebase without decompiled Minecraft code is a real requirement. It does not suit anyone who depends on vanilla features, plugins that use CraftBukkit internals from org.bukkit.craftbukkit or net.minecraft.server, or a server that must work reliably across the full Bukkit API. Before deploying it, test every plugin you rely on against a current Glowstone build from glowstone.net and check each plugin's import list for NMS packages. The project documentation says nothing is guaranteed to work.

## FAQ

### How do I download and run Glowstone?

The glowstone.net downloads page offers LTS and monthly builds. To build from source, clone the repository and run ./scripts/build.sh, which outputs glowstone.jar in build/libs/. Use java -jar glowstone.jar --help to see all startup options, including the memory and GC flags the README recommends.

### Does Glowstone support Spigot and Paper plugins?

Glowstone supports plugins targeting the Bukkit, Spigot and Paper APIs. Plugins that import from org.bukkit.craftbukkit or net.minecraft.server will not work on Glowstone unless they were written to handle the absence of those packages without crashing.

### Is Glowstone finished and production-ready?

The README states that Glowstone is not finished and that nothing is guaranteed to work. It also notes that the project does not undergo the same rigorous testing as the Bukkit project.

### What configuration file does Glowstone use?

Glowstone stores its configuration in config/glowstone.yml, which replaces CraftBukkit's server.properties and bukkit.yml. Both files' settings are imported into config/glowstone.yml automatically on the first run.

### Why does the Glowstone README mention Maven when the project uses Gradle?

The README build section instructs users to install Maven, but the repository root contains only Gradle files: build.gradle.kts, gradlew and settings.gradle.kts. No pom.xml is present, and Maven has no build files to read in the repository.

## Sources

- [GlowstoneMC/Glowstone on GitHub](https://github.com/GlowstoneMC/Glowstone)
- [Issues](https://github.com/GlowstoneMC/Glowstone/issues)
- [Project website](https://glowstone.net)
- [README](https://github.com/GlowstoneMC/Glowstone/blob/dev/README.md)
- [Releases](https://github.com/GlowstoneMC/Glowstone/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/glowstonemc-glowstone