Slimefun 4: a Spigot plugin that adds a modpack's worth of items without a single mod

The modpack feel, delivered through the plugin API

Slimefun is described as a plugin which aims to turn your Spigot Server into a modpack without ever installing a single mod. The scope it claims is everything you could possibly imagine, from backpacks to jetpacks, and it says it lets every player decide on their own how much they want to dive into Magic or Tech.

The two in game progressions it names are a good description of the design. There is a magical side with wands and a magical altar, and a tech side with an electric power grid, nuclear reactors and item transport systems. The player picks a lane rather than being given one.

The scale is stated plainly. The project started back in 2013 and has grown ever since, from one single person working on this plugin back then to a community of thousands of players and hundreds of contributors. It currently adds over 500 new items and recipes to Minecraft.

What makes this technically different from a mod is the delivery mechanism. A mod changes the client, so every player has to install it and the server has to run a mod loader such as Forge or Fabric. A plugin changes only the server, and the client sees ordinary Minecraft items and recipes. That is why the project insists on never installing a single mod, and it is the trade you are making: server side only means no client install and no version matching for the client, but also that anything the plugin cannot express as a server side item and recipe simply cannot exist.

That constraint is invisible in the marketing and real in practice. It is the reason the project has an addons ecosystem and an item transport system implemented in plugin logic, and it is the reason an item that needs client side rendering cannot be in the list of over 500.

Two release channels, and a recommendation to take the rougher one

The distribution model is unusual enough to need explaining, and the README spends a long time on it.

Slimefun 4 can be downloaded for free on the builds page, and the project provides two distinct versions, development builds and stable builds. The comparison table shows where they differ. Both cover Minecraft 1.16.* to 1.20.* and both need Java 16 or higher. Both get automatic updates. Only the development line gets frequent updates, the latest content, Discord support and bug reports. Only the stable line gets testing before release and change logs. The download links point to separate paths, one for the latest development build and one for the stable build.

The recommendation is blunt. The project wholeheartedly recommends using development builds, since they are the most recent version and receive the most frequent updates, and states that stable builds are so outdated that they will not accept bug reports from them at all.

The explanation follows. Stable builds do not receive frequent updates or fast patches, bugs are fixed over time but it takes a while until those fixes reach a stable build, and they are just old development builds that seemed to run fine without any major issues. Because they are not actually bug free, calling them stable would be hypocritical, which is why the word appears in quotes in the document.

The reasoning about the stable channel existing at all is worth noting too. These builds can only really stay stable if enough people use the development builds and report the bugs they hit, otherwise potential issues may go unnoticed and slip into a stable build. The stable line is funded by the testers of the development line.

The practical consequence for an operator is that you are choosing between a line that gets fixes in days and one that does not, and the project asks you to pick the first and accept that you are the one reporting the bugs.

Installing it, which means a jar and a version decision

The installation route is deliberately not in the README, and the reason is that there is no single command. The project links to an install guide in the wiki, How to install Slimefun, and it points you at the builds page for the download.

The requirement is the platform. Slimefun requires your Minecraft Server to be running on Spigot, Paper, or on any fork of these. The forks matter in practice, because a plugin built against one server implementation can behave differently on another, and the project is explicit that it runs on Spigot, Paper or any fork.

The version decision comes next, and it is the one you will live with. The table states that both channels support Minecraft 1.16.* to 1.20.* and need Java 16 or higher. That range is worth checking against your own server before you download anything, because a server on a newer Minecraft version is not covered by the version range the project lists.

The download itself is a jar you drop into the plugins directory, and the wiki page linked from the README covers the rest. Because the build is a jar rather than a mod, there is no client side component to distribute, which is the property that makes it usable on a server whose players are on vanilla.

The one thing the README is emphatic about is that the choice between channels is not a formality, and the project asks you to read the reasoning before you pick. Both channels update automatically, so the one you install will change over time either way.

Addons, because the plugin ships less than the wiki suggests

The README mentions addons in a single sentence, and it is the sentence that matters most for anyone planning a server. It also comes with a lot of addons, the project links to its addons list, and you may find exactly what you were looking for.

That framing tells you the content is distributed. Slimefun itself provides the framework, the item registry, the recipe system, the research progression and the shared infrastructure, and the addons supply the specific content. The magical and tech progressions the README describes, the altar, the power grid, the reactors, the transport systems, are addon territory rather than core.

This has a practical consequence for planning. If you install the core plugin and expect over 500 items, you will be disappointed, because the count describes the full ecosystem. If you install the core plus a curated set of addons, you are assembling the modpack experience yourself, which is exactly the workflow the project points at.

For a server operator this is usually the right shape, because it lets you choose the progression your players get rather than accepting a fixed set. It also means the update surface is larger than one jar, since each addon has its own release cycle, and the project does not document in the README how addons are versioned against the core. That question belongs in the wiki and the Discord support server.

The support structure is worth noting for the same reason. The project points at a Discord with over 7000 users for suggestions and questions, but states clearly that bug reports are not accepted on Discord and must go to the issue tracker, and it also hosts community events.

Maven, Crowdin, and a test fixture fetched from another project

The repository layout shows a conventional Java plugin project with a few details that reveal how it is built and who touches it.

There is a pom.xml at the root, a Makefile, a CHANGELOG.md, a CONTRIBUTING.md, a LICENSE, a crowdin.yml for the translation workflow, a jitpack.yml, a docs/ directory, and a src/ directory. There is also an .adr-dir, which is a directory of architecture decision records, and the presence of a Makefile with a single real target is the interesting part.

That target generates biome test data. The gen-biomes target curls a biome.json from the MockBukkit repository at a given version tag, pipes it through jq to extract the keyed values, and writes the result into the test resources as a versioned file. So the test fixtures for world generation biomes are pulled from another project at build time rather than committed.

That is a sensible arrangement and it is also a supply chain detail. A build now depends on a file fetched from a third party repository over the network at a specified tag, and if that fetch fails the test data is missing. It also means the biome data is not visible in the repository, so a reviewer has to run the target to see what the tests actually assert against.

The other two directories worth knowing about are docs/ and the .adr-dir. The crowdin.yml is what makes the plugin available in many languages, and the wiki is where the install guide, the addons list, the FAQ and the contributing instructions all live. The project keeps a separate Slimefun-Wiki repository for the images used in the screenshots in the wiki repository, which is a small thing that tells you the documentation and the plugin are maintained as separate artefacts.

What Slimefun is not, and where the mod loader still wins

The comparison to make is not with other plugins, it is with a real modded server, and the difference in approach is large enough to be worth stating plainly.

A modded server with Forge or Fabric runs modified code on both sides. The client can render new blocks, new item models, custom textures, animations and screens, and the server can run arbitrary logic in the mod itself. The cost is that every player has to install a matching client, the loader has to agree on the Minecraft version, and the mod list has to be identical on both sides or the connection fails.

Slimefun inverts that. Nothing is installed on the client, so the friction that makes modded servers hard to run for a general audience disappears. What you give up is everything that needs the client: custom models, new textures, new rendering, a custom inventory screen, a custom GUI. The items exist as server side item definitions with recipes and behaviours, and the visual result is a Minecraft texture someone drew to look like the thing.

That is the right trade for a survival server where you want the content without the install prompt, and the wrong trade for a server that wants the item to look and feel like a modded item.

There is a third option for the same goal. A server can use a client mod with a resource pack, where the client installs only a texture pack and the server logic comes from a plugin or a mod. That gives better visuals than Slimefun without requiring a mod loader, at the cost of a download prompt for the player and a resource pack that has to be maintained. A team that has the time to make textures should look at that option first, and a team that does not should look at Slimefun.

Editorial conclusion

Slimefun 4 fits a server owner who wants the flavour of a modpack on a Spigot or Paper server, who can accept that the content is a plugin rather than a mod, and who wants a single jar instead of a mod loader and a hundred mod jars. It does not fit a server running a modded client, because the whole point is that no client mod is required. Check three things before you commit. Check the Minecraft version range, which the project states as 1.16.* to 1.20.* for both release channels, and note that the newest listed release is RC-37 from 2024-02-25 while the last push was on 2026-09-19. Check which channel you want, because the project states outright that stable builds are so outdated that bug reports on them are not accepted, and that they are literally outdated development builds with no change logs. And check the addons, because the plugin ships a small part of the content and the addons carry the rest, so an incomplete install is a common outcome. The last push was on 2026-09-19, the default branch is experimental, and the license is GPL-3.0.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Slimefun/Slimefun4 on GitHub