Paper vs Fabric vs Forge: which Minecraft server type to run

What actually differs

Every Minecraft server runs the same game logic. The server types differ in how they let you change it.

• Vanilla is Mojang's server jar. No extension point beyond datapacks and commands. Any client on the same version joins.
• Paper (and Purpur, a fork of Paper with more configuration) is a performance-focused fork of Spigot. It runs plugins: server-side code written against the Bukkit API. Plugins live in plugins/, and because they only run on the server, unmodified vanilla clients join. Players never install anything.
• Fabric is a lightweight mod loader. It runs mods that patch the game itself, which means mods that add blocks, items, or dimensions must also be installed on every player's client. A subset of Fabric mods are server-side only, mostly performance and admin tools.
• Forge and NeoForge are the loaders behind large modpacks. Same rule: content mods must match between server and client. NeoForge forked from Forge in 2023; for 1.20.1 and older you want Forge, and for 1.21 and newer most of the modding ecosystem has moved to NeoForge.

Performance in practice

Paper's reason to exist is per-tick efficiency: async chunk loading, entity activation ranges, configurable tick rates for hoppers and mob spawning, and dozens of smaller fixes. On the same hardware and the same world, Paper typically holds 20 TPS at player counts where vanilla starts dropping ticks, and it exposes a tps command so you can watch it. The trade is that a handful of optimizations change technical behavior (some redstone and farm mechanics), which purists notice and most groups do not.

Fabric on its own performs like vanilla, because it is vanilla with a hook system. Add Lithium (game logic), FerriteCore (memory), and Krypton (networking) on the server and you get much of Paper's headroom while keeping vanilla mechanics exact. Technical players favor this combination for that reason.

Forge and NeoForge carry more loader overhead, and the mods people run on them are heavy: a 150-mod pack loads far more entities, block entities, and event handlers per tick than any plugin server. The loader is not the bottleneck; the pack is. Budget memory accordingly (see troubleshooting) and expect longer startup times.

Version availability lag

Server software trails Mojang releases, and the lag differs by loader. This matters more than it looks: if your group updates their clients on release day and the server cannot follow, nobody can join.

The practical consequence: pin VERSION in your compose file and move only when the plugins or mods you depend on have moved.

What a friends group usually wants

Most groups do not need mods. They need a survival world that stays up, a whitelist, and a few conveniences. That points to Paper. Plugins for land claims, sleep voting, teleport homes, and scheduled backups cover the requests that actually come up, and nobody installs anything on their client.

The exceptions are specific:

If you are unsure, start on Paper. The world carries over if you change your mind.

How each runs in the itzg image

The itzg/minecraft-server image installs any of these from one environment variable. VERSION sets the Minecraft version in every case; the second variable pins the loader build when you need to.

A Paper server for a friends group looks like this:

services:
  mc:
    image: itzg/minecraft-server:latest
    container_name: minecraft-server
    environment:
      EULA: "TRUE"
      TYPE: "PAPER"
      VERSION: "1.21.1"
      MEMORY: "4G"
      RCON_PASSWORD: "change-this-to-something-long"
    ports:
      - "25565:25565"
      - "127.0.0.1:25575:25575"
    volumes:
      - ./data:/data
    restart: unless-stopped
    stop_grace_period: 2m

Swap TYPE and the same file runs Fabric or Forge. Content goes into ./data/plugins or ./data/mods on the host, followed by a restart. The image can also fetch it for you: MODRINTH_PROJECTS takes a list of Modrinth project slugs (on Fabric, include fabric-api, which most mods require), and SPIGET_RESOURCES takes SpigotMC resource IDs for plugins. The full walkthrough of the rest of that file, including Podman, is in Run a Minecraft server in Docker on Linux.

Migrating between them

The world is the part that carries. Plugins and mods never do, because they are different APIs entirely.

1. Stop the server and take a full copy of data/.
2. Note what carries: world/ (and on Paper, world_nether/ and world_the_end/), server.properties, whitelist.json, ops.json, banned-*.json, and player data inside the world.
3. Note what does not: everything in plugins/ or mods/, and any config those wrote. You will source equivalents for the new type.
4. Vanilla to Paper: change TYPE and start. Paper splits the Nether and End into separate world folders automatically on first boot.
5. Paper back to vanilla: move the region files from world_nether/DIM-1 and world_the_end/DIM1 back under world/ first, or the Nether and End come up empty.
6. Any modded loader to Paper or vanilla: blocks and items from mods no longer exist and are dropped as air or missing entries when chunks load. Only do this if the world was effectively vanilla.
7. Fabric to Forge or the reverse: the world loads, but each mod's blocks vanish unless the same mod exists for the new loader under the same IDs.

Run the migrated server once, check the log for chunk errors, and join before deleting the copy from step 1.

Where MineUI and the companion mod fit

MineUI is a desktop app that attaches to a Minecraft server container. It does not care which TYPE the container runs; it reads /data the same way. The Mods page lists both /data/mods and /data/plugins and lets you upload a jar or fetch one from a URL, the config editor opens server.properties and files under config/, and the RCON console runs allowlisted commands against any of them. The tps command in that console returns real data on Paper and Purpur, which report tick rate over RCON; vanilla, Fabric, and Forge do not have that command.

MineUI's Simple mode, which creates and supervises a server for you without containers, is vanilla only. It downloads the official server jar and verifies its SHA-1; it does not install Paper, Fabric, or Forge. To run any of those, use the container route above and attach.

The optional companion, mineui_server_utils, runs inside the server JVM and feeds MineUI real tick-based TPS and MSPT, per-dimension chunk and entity counts, and the actual loaded mod or plugin list. Its current state, at version 0.2.0:

• a Forge mod built against Forge 47.x for Minecraft 1.20.1; it will not load on other Forge versions or on NeoForge;
• a Paper/Bukkit plugin compiled against the 1.20.1 API (api-version: 1.20), which also loads on Spigot, Purpur, Folia, and Bukkit-compatible hybrids;
• no Fabric or NeoForge adapter yet; the core is loader-agnostic and adding one means writing a new adapter module;
• no packaged release yet; you build the jars with the repo's Gradle wrapper and JDK 17.

Without it, MineUI still shows status, players, logs, and container metrics for every server type. Installation and the attach flow are on the Getting Started page.

Troubleshooting

Clients are rejected with "Incompatible mods" or a mod rejection list. Forge and NeoForge require the client to have the same content mods as the server, on the same loader and Minecraft version. Compare the two mods/ folders; the rejection screen names the missing or mismatched mods. On Fabric the same happens only for mods that require both sides; server-only mods do not trigger it.

A plugin fails to load with "Unsupported API version", or errors on startup after an update. Check the plugin's page for the Minecraft versions it supports and the Paper version it was built against. Plugins built for older APIs usually load on newer Paper; the reverse does not hold. Remove the jar, restart, then find a build for your version.

A Forge server crashes with OutOfMemoryError or takes minutes to start. Modpacks need more heap than the image default. Set MEMORY to 6G for a medium pack and 8G to 10G for large ones, keep it under about 75 percent of host RAM, and enable USE_AIKAR_FLAGS: "true". If startup is slow but succeeds, that is normal for large packs; look for the Done line in the log rather than the healthcheck, and raise start_period if the container is restarted before it finishes.