# Cuberite: a C++ Minecraft server with a Lua plugin API

> Cuberite is a Minecraft-compatible multiplayer server written in C++ for memory and CPU efficiency, with plugins in Lua. It supports the Java Edition client on protocol versions 1.8 through 1.12.2, and its last release line is marked EOL.

**cuberite/cuberite** — A lightweight, fast and extensible game server for Minecraft

- Repository: https://github.com/cuberite/cuberite
- Website: https://cuberite.org
- Stars: 5,450 · Forks: 656
- Language: C++
- License: NOASSERTION
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/cuberite-cuberite

## What Cuberite is, and which Minecraft players it can actually serve

Cuberite is a multiplayer game server for Minecraft that is written in C++ and speaks the Java Edition protocol. The README describes it as "designed to be efficient with memory and CPU, as well as having a flexible Lua Plugin API". That combination is the whole pitch: a compiled server core, and game logic extended through a scripting layer rather than through Java mods.

The constraint that decides most adoption questions is protocol support. The README states that Cuberite currently supports Release 1.8 through 1.12.2 Minecraft protocol versions. A player on 1.13 or later cannot connect, because the protocol changed. This is not a configuration problem you can work around; it is a version ceiling written into the project description. If your community runs modern Java Edition, Cuberite is the wrong tool regardless of how well it performs.

The audience is narrow and specific. It suits operators of older-version Java Edition servers, people running on small hardware such as a Raspberry Pi, and developers who want to write server-side behaviour in Lua instead of Java. The README notes that support for small embedded devices is experimental, so treat the Raspberry Pi and Android targets as supported but not guaranteed.

## How the C++ core and Lua plugin API divide the work

The repository layout shows the split directly. The C++ server lives under src/, with build configuration in CMakeLists.txt, CMake/ and SetFlags.cmake. The Server/ directory holds the runtime layout, including the settings and the plugin folders that a running instance reads. A .gitmodules entry and a lib/ directory indicate vendored or submodule dependencies pulled in at build time.

The data flow is conventional for a game server: the C++ core owns the network layer, the world representation, chunk handling and the tick loop, and it exposes hooks that Lua plugins subscribe to. Plugins do not reimplement the protocol; they attach to events the core already dispatches. That is why the API is described as flexible rather than fast: scripted hooks are convenient, but the hot path stays in compiled code.

Cuberite is developed in C++ and Lua, per the README, and plugins are written in Lua. The project maintains a separate plugin repository and a plugin API reference, and the README points contributors at a plugin introduction guide. There is also a plugin folder under Server/ in the repository tree, which is where a running server expects plugin code to sit.

One design consequence worth stating plainly: because plugins are Lua and the protocol is handled by the core, the ecosystem is not interchangeable with Java server plugins. Existing Bukkit or Spigot plugin jars will not load here. Any plugin you want has to exist in Cuberite's own repository or be written by you.

## Installing Cuberite with EasyInstall or compile.sh

The README gives several routes. The fastest is the EasyInstall script, which downloads a prebuilt binary for Linux or macOS from the project site. It is a single shell command:

```bash
curl -sSfL https://download.cuberite.org | sh
```

Running it should leave you with a server binary and the accompanying Server/ directory structure. Windows users are pointed at the website download instead, since EasyInstall covers Linux and macOS.

The second route compiles from source. The README states that compiling may provide better performance, 1.5 to 3x as fast, and supports more operating systems. The compile.sh script downloads the source and builds it, and the README says it notifies you about missing dependencies and how to install them. It does not work on Windows.

```bash
sh -c "$(curl -sSfL -o - https://compile.cuberite.org)"
```

The README also gives a wget variant of the same one-liner. Manual compilation is documented separately in COMPILING.md for anyone who wants to control the toolchain, and GETTING-STARTED.md covers the first run in more detail than the README does. For a hosted option, the README names Gamocosm as a provider of hosted Cuberite.

What the README does not give is the actual first-run procedure: no command line to start the binary, no default port, no configuration keys for the settings file. Those live in the Users' Manual and the plugin API documentation, both linked from the README. Plan on reading those before your first launch rather than expecting the README to walk you through it.

## The release situation is the real adoption risk

The newest release listed for this repository is 1.7EOL, dated 2019-12-30, and the name itself says end of life. The two entries before it are 1.6EoS from 2014 and a ProtoProxy build for 1.7.2 from 2014. There is no recent tagged release.

That does not mean the code is frozen. The repository's last push was on 2026-04-25, so commits have continued well past the last release. The gap between the two facts is the thing to weigh: development activity exists, but the project does not publish versioned binaries on a schedule. Anyone who wants current code is expected to build it, either with compile.sh or manually via COMPILING.md.

The EOL naming also implies something about the 1.7 line specifically: that branch is closed. If you are pinning to a released binary, you are pinning to a build from 2019. If you build from master, you get whatever state master is in, with no release tag to anchor against. Both choices have costs, and the repository does not present a middle option.

For a hobby or small-community server on an old Minecraft version, this is manageable. For anything where you need a reproducible, versioned artifact, the absence of a current release is a real operational problem, not a cosmetic one.

## Where Cuberite loses to Paper and other Java servers

The obvious alternative is Paper, or the broader family of Java-based Minecraft server implementations. The difference is architectural, not cosmetic. Java servers run on the JVM, load plugins packaged as jars, and track the current Minecraft protocol versions as Mojang ships them. Cuberite is a native C++ binary with Lua plugins, and its documented protocol range stops at 1.12.2.

That means the two are not competing for the same operator in most cases. If your players are on a current Java Edition client, a Java server is the only one of the two that will let them connect at all. If you are deliberately running an old version, or you care about running a server on hardware where the JVM overhead matters, Cuberite's compiled core and Lua scripting are the reason to pick it.

The plugin ecosystems do not overlap either. Java server plugins are distributed as jars and written against those servers' APIs. Cuberite plugins are Lua and live in a separate repository. Porting between them means rewriting, not reconfiguring.

There is also the question of what happens when something breaks. A widely used Java server has a large population of operators who have hit the same problem. Cuberite's community is smaller, and the README routes support to a forum and a newsletter rather than to a large question-and-answer base. That is a genuine cost of choosing a less common implementation, and it is worth pricing in before you migrate an existing world.

## Licence and the cost of keeping a Cuberite instance current

The README states that Cuberite is licensed under the Apache License V2, and that the project welcomes forks and pull requests. The repository's licence metadata is recorded as NOASSERTION rather than a recognized identifier, so if the exact terms matter to your organisation, read the LICENSE file in the repository root rather than trusting the metadata field. This is a description of what the files say, not legal advice.

Apache License V2 is a permissive licence, which in practice means the usual things for a server operator: you can run it, modify it and redistribute it, subject to the terms in the LICENSE file. The README explicitly invites forking and pull requests back, which suggests the maintainers expect downstream modification rather than discouraging it.

The upgrade cost is where the release situation bites. Because there is no current tagged release, keeping a Cuberite instance current means either rebuilding from master at intervals or staying on the 1.7EOL binary. Rebuilding means tracking a moving branch and accepting that a change between two builds may alter behaviour with no changelog entry to point at. Staying on 1.7EOL means accepting a binary from 2019.

Plugin maintenance adds to this. Lua plugins are separate from the core and are distributed through the project's plugin repository, so a core rebuild can leave a plugin behind. There is no dependency manager described in the README that would pin versions for you. Budget for manual checking after each rebuild.

## Conclusion

Adopt Cuberite if you run a Java Edition server for protocol versions 1.8 through 1.12.2, want a small C++ binary with Lua plugins, or want to host on a Raspberry Pi class device. Do not adopt it if your players are on 1.13 or later, since the README states support stops at 1.12.2, and do not expect a maintained binary release: the newest release is 1.7EOL from 2019-12-30. Before committing, verify that the EasyInstall script at https://download.cuberite.org resolves for your architecture and that the plugins you need exist in the plugin repository.

## FAQ

### How do I install Cuberite?

The README gives two main routes: the EasyInstall script for Linux and macOS, which downloads a prebuilt binary, or compile.sh, which downloads the source and builds it. Windows users are directed to the website download. Manual compilation is documented in COMPILING.md.

### Is Cuberite a Minecraft server written in C?

It is written in C++, not C, and the README describes it as developed in C++ and Lua. The C++ core handles the protocol and world, and plugins are written in Lua.

### Which Minecraft versions does Cuberite support?

The README states that Cuberite currently supports Release 1.8 through 1.12.2 Minecraft protocol versions, and it is compatible with the Java Edition Minecraft client. Later protocol versions are not listed as supported.

### What language are Cuberite plugins written in?

Plugins are written in Lua. The README points to a plugin repository, a forum section and a plugin introduction guide, and the repository includes a Server/ directory where a running server expects plugin files.

### Does Cuberite run on a Raspberry Pi or Android?

The README says Cuberite runs on Windows, *nix and Android, including Android phones and tablets as well as Raspberry Pis, and that support for small embedded devices is experimental. The repository also contains an android/ directory.

### What licence is Cuberite under?

The README states that Cuberite is licensed under the Apache License V2. The repository's licence metadata is recorded as NOASSERTION, so check the LICENSE file in the repository root if the exact terms matter to you.

## Sources

- [cuberite/cuberite on GitHub](https://github.com/cuberite/cuberite)
- [Issues](https://github.com/cuberite/cuberite/issues)
- [Project website](https://cuberite.org)
- [README](https://github.com/cuberite/cuberite/blob/master/README.md)
- [Releases](https://github.com/cuberite/cuberite/releases)

---

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