Terra: a Minecraft world generation platform with an addon layer

Four layers between a config file and a generated chunk

Terra is described as a modern world generation modding platform, primarily for Minecraft, that allows complete customization of world generation with an advanced API tightly integrated with a configuration system. The design is the interesting part, because the project is organised as four pieces rather than one plugin.

At the bottom sits the voxel world generation API, with the emphasis on configuration and extensibility. Above it are the platform implementations, described as the layer between the API and the platform it runs on. Then an addon loader, which lets addons talk to the Terra API in a platform-agnostic way. Finally there are core addons implementing what the project calls the default configurations, which the README compares to the config standard library.

That layering is what makes Terra more than a terrain generator. The addon loader means a configuration written once can run on both supported platforms, and the core addons mean a server operator who wants a working terrain setup does not need a custom addon. The target user is a server operator or a plugin author who wants terrain as a configuration problem rather than as Java code.

Fabric and Bukkit are the two supported platforms

Terra officially supports the Fabric mod loader and the Bukkit API, which the README describes as Paper and friends, and it welcomes pull requests implementing additional platforms. For Bukkit that means Paper, Tuinity, Purpur and similar server software.

The distribution channels differ by platform. Fabric builds are published on Modrinth and CurseForge, listed under the names terra-world-generator on CurseForge. Server-side builds for Paper and the rest are on SpigotMC. So the same project reaches players through two ecosystems with two separate installers, and the artefact names differ to match.

The platform-agnostic layer is where the addon loader earns its keep. A server owner who moves between Paper and Fabric, or an addon author who wants their terrain pack to work on both, writes against Terra's API and the loader handles the rest. Without that layer the same world definition would have to be reimplemented per platform, which is the main alternative approach and the reason the middle layer exists at all.

Core addons as a configuration standard library

The core addons implement the default configurations of Terra, and the README describes them as something you can think of as the config standard library. The licensing note makes the intent explicit: they are MIT licensed so that people can freely use code from them to learn and make their own addons without worrying about GPL infection.

That framing sets a clear division of labour. If the default configurations already cover the landscape you want, you configure and you are done, and the addon layer is not something you have to touch. If they do not, you write an addon against the API, and the platform implementations underneath keep your code from having to know which server software is running.

The alternative to all of this is writing terrain generation directly against each platform's own API and maintaining two codebases, or hard-coding a world preset per server. Terra's approach moves that work into the platform implementations and the core addons, so the trade is between a shared configuration model and the flexibility of owning the whole code path yourself.

Building with Gradle and the shaded JAR names

Terra is a Gradle multi-project. The repository root holds build.gradle.kts, settings.gradle.kts, gradle.properties, a buildSrc/ directory and a gradlew wrapper, with common/ and platforms/ as the code directories. Building everything is a single command:

./gradlew build

On Windows the wrapper is gradlew.bat and the argument is the same, so the command is gradlew.bat build. The build produces JARs per platform under platforms/<platform>/build/libs, and the production artefacts have specific names, which matters if you script the download of a release.

For the Bukkit server build the file is Terra-<version>-shaded.jar. For Fabric it is Terra-<version>-shaded-mapped.jar, where the mapped variant is the one produced by remapping against the actual Minecraft jar rather than the intermediary names. The mapped distinction is worth understanding because an unmapped Fabric jar will not load in a live client or server, and the naming makes the two easy to confuse in a deployment script.

If you only need one platform, the build can be narrowed to it:

gradlew :platforms:<platform>:build

The JARs still land in platforms/<platform>/build/libs, so the single platform build is a shortcut rather than a different output layout.

Running a Paper server or Fabric client from the IDE

For testing without packaging, the Gradle tasks launch Minecraft with Terra already installed. For Bukkit there is a runServer task, described as running the Paper test server with Terra installed. For Fabric there are two: runClient, which runs a Minecraft Fabric client with Terra installed, and runServer, which runs a Minecraft Fabric server with Terra installed.

The two platforms behave differently for a reason. On a Bukkit server you are testing the server side, where the world is generated, and there is no client to launch. On Fabric you may be working on either side, so both tasks exist, and running the client is how you see the terrain you have just configured.

The practical workflow is therefore: change a configuration, run the relevant task, and look at the generated world in the client or on the server. The repository also carries a Jenkinsfile, so a continuous integration setup for the project itself was already anticipated by the maintainers.

Two licences in one repository

Terra does not use a single licence across the codebase, and the split is deliberate. Parts are under the MIT License and parts under the GNU General Public License, version 3.0.

The API is MIT, so that everyone is able to freely use it however they want. The core addons are MIT for the same reason as the API, so people can take code from them to learn and write their own addons without worrying about GPL infection. The platform-agnostic implementations and the platform implementations are GPL-3.0, to ensure they remain free software wherever they are used.

The practical advice is in the README itself. If you are unsure which licence a particular file is under, check the file header and the LICENSE file in the closest parent folder of the file in question. That is a slightly unusual arrangement for a Minecraft platform, and it means the answer to can I copy this file into my closed source plugin depends on which directory the file came from.

Beta status and a release line that stopped in 2022

Two limits are stated directly. The project says it is still in beta, that while it is stable it is not feature-complete, and that there is a lot to be added. Any expectation of a finished, settled feature set has to be adjusted accordingly.

The release history is the second thing to look at. The tagged releases are v6.2.0, labelled 6.2.0-BETA, dated 2022-07-08, v6.1.2 dated 2022-06-13 and v6.1.1, also a beta, dated 2022-06-08. The last push to the repository was on 2026-09-28, on the master branch. So the code is moving while the published artefacts are four years older than the latest commit, which is the same pattern that bites any project where distribution and development have drifted apart.

For an operator this matters concretely. A published JAR from 2022 may not match the Minecraft version your server runs, and the README does not document a compatibility matrix. Building from source, as the Gradle instructions above assume, is how you get a JAR that corresponds to current code.

Editorial conclusion

Adopt Terra if you run Minecraft servers on Paper or Fabric and want world generation driven by configuration and addons instead of custom code, and if you are prepared to work with a Java and Gradle build rather than a downloaded plugin. Do not adopt it for other platforms, since only Fabric and the Bukkit API are officially supported, and do not adopt it expecting a finished feature set, because the project states it is still in beta and the newest tagged release is v6.2.0 from 2022-07-08 even though the last push was on 2026-09-28. Verify three things first: which licence applies to the file you want to copy, since the API and core addons are MIT while the platform and platform-agnostic implementations are GPL-3.0; which Minecraft version your target platform accepts, since Terra bridges to the platform rather than replacing it; and whether the core addons already cover your terrain needs before you write an addon. The build is a Gradle multi-project with platform artefacts under platforms/<platform>/build/libs.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. PolyhedralDev/Terra on GitHub
4. README
5. Releases