Cardboard runs Bukkit plugins on Fabric, with a licence inherited from Paper

A compatibility layer, not a Paper server in a jar

Cardboard is an implementation of the popular Bukkit, Spigot and Paper modding API for FabricMC. The description is precise about what that means: it is a mod that lets you use plugins made for Bukkit and its derivatives, Spigot and Paper, on a Fabric modded server.

The distinction from running a Paper server matters. A Paper server is a complete server implementation with its own chunk handling, world generation, tick loop and configuration. Cardboard is a mod that lives inside a Fabric server and supplies the API surface those plugins compile against, so the plugin code finds the classes and methods it expects while the underlying server remains Fabric. Plugins written for Bukkit therefore load and their logic runs, but anything that depends on Paper-specific internals or on server behaviour that Cardboard does not reproduce is a different question.

The project credits the API's origin explicitly: BukkitTeam, Spigot and Paper for their work on the API, Glowstone for the library loader, and md_5's SpecialSource, SrgLib by Techcable and Orion, and MinecraftMapping by Phase for the tooling that makes the mapping work possible.

Support is tracked per Minecraft version, and only one branch is Active

The README keeps a version chart, and it is the first thing to read before anything else. The columns are support status, Minecraft version, git branch and dev status. The current entries are Fabric 26.1.2 on the ver/26.1 branch with status Active, Fabric 1.21.11 on ver/1.21.11 with status Low, and Fabric 1.21.1 on ver/1.21 with status Low. Fabric 26.3 has no branch yet and a dev status of to be determined, and anything at or below 1.20 is marked as not supported.

The default branch in the repository is ver/26.1, which matches the one branch marked Active. That is a deliberate structure: a compatibility layer for a moving target has to be pinned to specific game versions, so each supported combination gets its own branch rather than one branch trying to track several.

The Low status on the older entries is worth understanding as a maintenance signal rather than a feature list. Those branches exist and are marked supported, but they are not where the work is going. A server operator should read the Active row as the line that gets fixes and the Low rows as frozen points they can still use. The README also points to the Supported Versions wiki page for more detail and to a downloads page for builds.

Building from the Gradle project in the repository

The repository is a Gradle project. The top level holds build.gradle, settings.gradle, gradle.properties, a gradle directory, the gradlew and gradlew.bat wrapper scripts, a libs directory and the src directory. There is no separate installation script in the README, so the build path is the wrapper included with the project rather than a documented command sequence.

On a machine with a JDK and the wrapper in place, the Gradle wrapper is the entry point, and the src and libs directories are where the implementation and its dependencies live. The project also ships a .github directory, a .gitignore and a desktop.ini file, and the LICENSE file at the root is the licence inherited from Paper.

Since the README does not spell out the exact Gradle invocation or the required Java version for any branch, the concrete steps for a given branch belong to the repository itself and the wiki. What the repository layout shows is the shape of the project: this is a source project you compile, and the resulting mod is what you drop into a Fabric server.

The licence is inherited, and SrgLib adds an MIT layer

The licence section is two sentences and both matter. We inherit the license from Paper, with the full details in Paper's LICENSE file. And SrgLib is also licensed under MIT.

Inheriting a licence rather than choosing one is a deliberate choice with a practical consequence. Paper is GPL-3.0, and the project's own licence field gives GPL-3.0 as well, so a build that links against Paper's API inherits GPL obligations. For a server operator running the mod on their own server this is usually not the deciding factor, but for anyone redistributing a modified build, the obligation travels with the code, and the project does not offer a permissive alternative licence for the API portion.

SrgLib being MIT separately is worth noting because that is the component doing the mapping work, and the project credits SrgLib by Techcable and Orion alongside SpecialSource and MinecraftMapping. The tooling and the API are covered by different terms, and the README is explicit about which is which.

NMS support exists but the project calls the system imperfect

There is a commented-out section in the README that reveals something about the current state of the work, and it is the most candid part of the document. The NMS support section says that using Spigot's net.minecraft.server classes is supported, that classes and fields will automatically remap to their intermediary counterparts, and then that the current system is far from perfect.

The section is inside an HTML comment in the README, which means it is not presented as a current feature announcement, and there is no version or status attached to it. That is exactly why it is worth quoting rather than paraphrasing. A plugin that pokes at NMS classes, as some long-lived Bukkit plugins do, is the case where a remapping layer can silently produce wrong behaviour rather than a clean error, and the project's own wording is the strongest evidence available about the reliability of that path.

The section also documents where progress is tracked, which is useful if you are following the project: there is a progress indicator in the Discord, and otherwise progress can be determined by the completeness of the to-do lists on two pinned issues. The Discord is linked from the README badge.

Where Cardboard is the wrong choice

The case against is straightforward enough to state plainly. If you need the full Paper server, Cardboard is the wrong tool, because it implements the plugin API rather than reproducing the server. Plugins that lean on Paper-only features, or on server internals beyond what the API exposes, are where the gap shows.

The version support is the other hard boundary. Anything at or below Minecraft 1.20 is marked unsupported, and the newest line, Fabric 26.3, has no branch assigned and its dev status is to be determined. A server operator on a current Fabric version may find themselves waiting, and one on an old version may find themselves on a Low status branch with limited ongoing fixes.

There is also an operational point about what the project is. The README asks readers to join the Discord, points to a partner hosting test server at cardboardmod.apexmc.co:25666, and links a downloads page. A compatibility layer whose support matrix moves with the game means the build you deploy is tied to a specific Minecraft and Fabric pair, and you should expect to revisit that choice each time you update the server.

The project is a community effort with no releases published on GitHub, so builds are distributed through the project's own site rather than through a tagged release stream, and the last push was on 2026-10-03.

Editorial conclusion

Cardboard suits a server operator who has a Bukkit or Spigot plugin they need and a Fabric server they want to keep, and it does not suit a deployment that needs the complete Paper server implementation or that requires an officially supported platform. Before adopting it, check the version chart in the README against the Minecraft and Fabric version your server runs, because support is tracked per branch and only one entry is marked Active, and read the inherited Paper licence before distributing a build.

Frequently asked questions

Official sources

1. CardboardPowered/cardboard on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README