CloudburstMC Nukkit: Running a Bedrock Edition Server with Java

Nukkit's Java Server Role and Intended Operators

CloudburstMC Nukkit targets operators of Minecraft Bedrock Edition servers rather than Java Edition servers. The project describes itself as server software for Bedrock Edition and distributes plugins through the CloudburstMC resources site. Its Java foundation also appeals to developers who want to write server-side code in Java or port plugins from other supported platforms. The README calls the plugin structure friendly and links to a separate Plugin API wiki, but it does not publish a full API guide on the repository page itself.

The project is aimed at several overlapping roles. A server operator needs a process that listens for Bedrock Edition clients, while a plugin developer needs a documented API and an established plugin distribution channel. A platform engineer may prefer Docker or Helm to repeated JAR deployment. Nukkit offers routes for each group, although those routes are not equally documented.

Its purpose should not be confused with a Bedrock client or a hosting control panel. The repository produces a server JAR and container image. Configuration, language selection, plugin management, and persistent server data are expected to exist around that server process. The exact directory layout and every supported configuration option are not included in the README, so they should be checked in `nukkit.yml.default`, the generated configuration, and the wiki before deployment.

Nukkit's JAR, Port, and Persistent Data Path

Nukkit is built as an executable Java archive. The `Dockerfile` uses `eclipse-temurin:8-jdk-jammy` for both build and runtime stages, runs `./gradlew shadowJar`, and copies `target/nukkit-1.0-SNAPSHOT.jar` into the final image as `/app/nukkit.jar`. The image starts Java through `ENTRYPOINT ["java"]`, with `CMD [ "-jar", "/app/nukkit.jar", "--language", "eng" ]`. This establishes the process flow clearly: the client connects to the server process, Java launches the shaded JAR, and command-line arguments select runtime options such as language.

The container exposes `19132/tcp` and `19132/udp`. Docker Compose publishes both mappings for the same port and mounts a persistent volume at `/data`, where the working directory is also set. The first interactive Docker run is documented as the way to generate the `nukkit-data` volume, default settings, and language selection. This matters because the Compose file declares the volume as external with the fixed name `nukkit-data`.

The volume is operational state, not merely build output. Configuration and server data written under `/data` can outlive container replacement, while the application JAR remains baked into the image. Operators therefore need to distinguish disposable configuration files from persistent world or player data, but the repository documentation does not enumerate those files. A backup plan must inspect the actual volume contents rather than assume that every file belongs in the same retention policy.

Building Nukkit from the Default master Branch

The README recommends a prebuilt download for operators who do not intend to modify the source. Developers can build the current default branch with the bundled Gradle wrapper. This produces the same artifact name used by the Dockerfile.

Use the repository's wrapper rather than an assumed system Gradle command:

git clone https://github.com/CloudburstMC/Nukkit
cd Nukkit
./gradlew shadowJar

The README says the compiled JAR appears in `target/`. Its documented filename is `nukkit-1.0-SNAPSHOT.jar`. The repository also contains `gradlew.bat`, so Windows source-build users have a corresponding wrapper script, although the README does not provide a Windows command sequence.

Building from `master` is not equivalent to selecting a stable release. The branch's build output remains named `SNAPSHOT`, and the release list exposes a snapshot dated 2018-07-15 as the latest release entry. Repository changes after that release can still alter the result. For production use, compare the source revision with the project wiki or download service and retain the exact JAR or container image identifier. The README does not document checksums, signatures, compatibility matrices, or a rollback procedure, so none should be assumed.

First Direct JAR Start for Nukkit

The shortest documented startup path assumes that a compatible Java runtime is already available and that the reader has obtained the JAR. The README gives the exact process command for its example artifact.

From the directory containing the downloaded JAR, run:

java -jar nukkit-1.0-SNAPSHOT.jar

A first launch should expose server output in the terminal and generate or request server settings according to the server's own behavior. The README does not identify the first-run acceptance test, the default world name, or the exact generated file list, so it does not support a more specific claim.

The direct JAR route is preferable when an operator wants the application process without a container layer. It also makes JVM memory and networking settings visible to the service manager. Its drawback is that runtime dependencies, process supervision, persistence, and upgrades are outside this short command. The README links to the download service for users who do not need source modifications. It does not specify supported Java versions for bare-metal execution, configuration syntax, default operator permissions, or how to stop and restore a server.

Do not confuse the Docker command's `--language eng` option with a documented bare-JAR option. The language flag appears in the Dockerfile entrypoint, while the README's direct command contains no such flag.

Docker and Compose Deployment of Nukkit

Docker is the best-documented deployment path because the repository includes both `Dockerfile` and `docker-compose.yml`. The image uses a multi-stage build, creates a `minecraft` user, stores the application under `/app`, and runs it from `/data`. Building requires Docker 17.05 or newer according to the README and Dockerfile.

Create the image from the repository directory:

docker build -t nukkit .

The next command starts an interactive container, publishes UDP port `19132`, and creates the named `nukkit-data` volume. The README presents this run as the way to generate default settings and choose language:

docker run -it -p 19132:19132/udp -v nukkit-data:/data nukkit

After that initialization, the Compose file can manage the same named external volume. Its service publishes both TCP and UDP mappings, sets `restart: unless-stopped`, and names the container `nukkit`:

docker-compose up -d

There is a concrete ordering constraint here. Because `docker-compose.yml` marks `data` as `external: true` with `name: nukkit-data`, the named volume must exist before Compose attempts to use it. The documented `docker run` command creates it. The README does not document `docker-compose down -v` or any automated volume removal procedure.

The Compose file also differs slightly from the README's one-off command: it publishes TCP as well as UDP and does not request an interactive terminal. Those are deployment details an operator should inspect before copying the file into production.

Helm Lifecycle Commands and Their Documentation Gaps

The `charts/nukkit` directory provides a Kubernetes packaging option, while the README documents linting, installation, upgrades, tests, and removal through Helm commands. Linting validates the chart's structure without contacting a cluster:

helm lint charts/nukkit

The README then gives an installation command:

helm install nukkit charts/nukkit

It also documents an upgrade and a post-deployment test:

helm upgrade nukkit charts/nukkit
helm test nukkit

Removal is represented by:

helm uninstall nukkit

These commands cover the chart lifecycle, but the documentation is inconsistent in two places. The README shows `helm install --dry-run --debug nukkit charts/nukkit`, while the Makefile contains a separate `helm-install` target that uses `--name`. Older Helm command forms and current Helm behavior may differ, and the repository page does not state a supported Helm version. It also gives a values-file example:

helm install nukkit \
  -f helm-values.local.yaml \
    charts/nukkit

That file is presented as operator-supplied configuration. Its contents are not included, so image overrides, persistence, ingress, resources, and service settings cannot be confirmed from the README. Kubernetes users should inspect `charts/nukkit/values.yaml` and the rendered chart rather than assume that the Compose volume mapping carries over.

Nukkit's Release Age, Licence, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-09-19. That indicates source activity after the listed snapshot, but it does not establish that a new distributable release was published. The only listed recent release is `snapshot` from 2018-07-15. The gap matters because Java server code, Gradle dependencies, container base images, and game protocol compatibility can change independently of repository activity.

The project is licensed under GPL-3.0, and `LICENSE` is present at the repository root. Source availability and licence obligations matter when modifying Nukkit or distributing a modified server, although this review does not provide legal advice. The README's invitation to contribute is not a substitute for checking the actual licence text and any plugin-specific licensing terms.

Upgrade cost includes more than replacing a JAR. The Dockerfile is tied to Java 8-era images, while `build.gradle.kts` controls dependency resolution and the shadow JAR output. Container users also need to preserve the `/data` volume across image replacement. Helm users have chart templates and values to inspect. The documentation does not state a release-to-release migration procedure, database compatibility policy, world conversion process, or rollback command. These omissions make compatibility verification more important than the repository's push date alone.

Editorial conclusion

Nukkit is suitable for operators who specifically need a Java-based Minecraft Bedrock Edition server and are prepared to verify game compatibility, configuration behavior, and image maintenance themselves. It is a poor choice if a recent tagged release is a requirement or if an operator needs deployment instructions that are internally consistent. Before adopting it, compare the downloaded JAR or image with the repository, confirm that current Bedrock clients can connect, and inspect the permissions and contents of the `nukkit-data` volume.

Frequently asked questions

Official sources

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