Install a plugin without breaking your server.

Before you start

The three FerNode plugins are standard Bukkit-style JARs. They run on Paper or Spigot; they do not require the FerNode desktop app. You need file access to the server folder, either locally or through FTP/SFTP, and permission to restart the server.

1. Stop the server cleanly

Run stop in the server console and wait for the server to finish saving and close. Do not kill the process or close the terminal while it is still shutting down. If you use the FerNode app, stop the server from its dashboard and wait for the status to show offline before you touch the files.

Copying a JAR into a running server can leave the plugin half-loaded, and replacing a JAR that the JVM has open can fail on Windows. A clean stop avoids both.

2. Back up the world and plugin data

Before a plugin change, copy these to a folder outside the server:

• world/, world_nether/ and world_the_end/ if they exist.
• The whole plugins/ folder, including configs.
• server.properties and the Paper configuration files.

A zip is fine. The point is to have a copy you can restore without relying on the same disk. If the server hosts a world you care about, keep a second copy on another drive or machine.

3. Remove older copies of the same plugin

Open plugins/ and look for the same plugin name with a different version. Two JARs for the same plugin cause duplicate commands, duplicate listeners and confusing errors. Keep the config folder; delete only the old JAR.

Do not rename the new file to match the old one and do not unpack it. The server expects a file ending in .jar directly inside plugins/.

4. Copy the new JAR files

Download the builds from the plugin library, then place each JAR directly into plugins/:

plugins/
├─ UltraTreeFeller-1.1.0.jar
├─ AutoRefill-1.1.0.jar
└─ FerKunGStacker-1.3.0.jar

One file per plugin. If you downloaded the bundle ZIP, extract it first and copy the three JARs, not the ZIP itself.

5. Start the server and confirm the load

Start the server and watch the console. You should see the plugin name followed by an enable message. Then run /plugins in game or from the console and check that the plugin is listed in green rather than red.

Test each plugin with a small, reversible action:

• UltraTreeFeller: hold an axe, press SHIFT five times, then break a tree. The action bar shows the charging progress and the cooldown.
• AutoRefill: use up a stack in your main hand with more of the same item in your inventory. The hand should refill.
• FerKunG Stacker: drop a few matching items near each other and check that they merge and show an amount.

On first start, each plugin creates its own folder under plugins/ with a config.yml. If the folder is missing, the plugin did not enable.

6. Configure, then reload the right way

Edit the plugin's config.yml while the server is stopped, or reload only that plugin after saving. AutoRefill and FerKunG Stacker register a reload subcommand:

/autorefill reload
/fkstacker reload

UltraTreeFeller 1.1.0 does not register a command in its plugin.yml, so apply its config changes with a full server restart. Avoid the global /reload command: it reloads every plugin at once and can leave listeners and scheduled tasks in an inconsistent state.

7. Check permissions on a public server

All three plugins ship with player-facing permissions enabled by default. That is fine for a small private server; on a public server, review them with your permissions plugin.

8. Roll back if the server will not start

If the server crashes during startup after a plugin change, stop and remove the newest JAR, then start again. If it still fails, restore the plugins/ folder and the world folders from the backup you made in step 2.

Read logs/latest.log before deleting anything else. The last exception usually names the plugin or the missing class, which tells you whether the problem is a version mismatch, a duplicate JAR or an unsupported server build.

For specific error messages, see the troubleshooting guide.

The short version

1. Match the plugin to your Minecraft version and Java 17+.
2. Stop the server and back up the world plus plugins/.
3. Delete old versions of the same plugin.
4. Copy one JAR per plugin into plugins/.
5. Start, check the console and /plugins, then test in game.

Get the JAR from a source you can verify

A plugin is executable code inside the server process. It can read the world, the player data and, on a badly configured machine, the filesystem. Download from the official FerNode plugin library or the project repository, not from a mirror or a "plugin pack" site that reuploads other people's work.

• Check the filename and version. The file you expect is ultratreefeller-1.1.0.jar, not UltraTreeFeller-latest-final(2).jar.
• Check the hash if one is published. Download the SHA-256 from the same page and compare it locally.
• Do not run a JAR from an email attachment or a chat link. That is how most server compromises start.

On Windows, compare the checksum in PowerShell:

Get-FileHash .\ultratreefeller-1.1.0.jar -Algorithm SHA256

The hash must match exactly. If it does not, delete the file and download it again from the official page. A mismatch is not a warning to ignore; it means the bytes are not the bytes the publisher signed off on.

What "loaded" actually means

Every Bukkit-style plugin is a ZIP archive with a plugin.yml at its root. That file tells the server the plugin's name, version and entry class. When the server starts, it reads the file, loads the main class and calls its enable method. If any of those steps fail, the plugin never reaches the enabled state.

A plugin that appears in the console as "enabled" but has no commands usually has a command registration problem or a permission result. A plugin that is missing from /plugins did not get past the load step. Those are different failures and lead to different fixes.

Updating a plugin later

A plugin update is a small upgrade and deserves the same care as a server upgrade. The JAR can change config keys, data formats and behaviour.

1. Read the changelog. Look for removed keys, renamed commands and data migrations.
2. Back up the plugin's config folder before replacing the JAR.
3. Stop the server. Replacing a loaded JAR on Windows can fail or leave a half-updated file.
4. Replace the JAR, keep the config folder. The plugin migrates or adds keys on start.
5. Start and read the console. Compare the new config with the backup if a setting stopped working.

If the new build does not support your Minecraft version, stay on the old build. A plugin that works on an older version is more useful than a newer one that refuses to load.

Plugins that need other plugins

Some plugins are not standalone. They expect a library or an API provider to be present, such as an economy plugin, a permissions plugin or a packet library. If the dependency is missing, the plugin fails to enable or disables itself after a warning.

• Read the plugin's requirements before you copy the JAR. Most project pages list hard and soft dependencies.
• Install dependencies first and restart once so they register before the dependent plugin loads.
• Match versions. A plugin built for an older API provider can fail even when the provider is installed.

The three FerNode plugins are standalone. They do not require Vault, LuckPerms or a packet library, and they do not depend on each other. You can install one, two or all three in any order.

If the console mentions Unknown dependency or a missing class from another plugin's package, treat it as a dependency problem before you edit any config. Replacing the config will not install the missing class.