Build and Run a Cobblemon Server

This guide documents the architecture behind Kame House as of June 7, 2026. It is not a list of whatever versions happen to be newest today. The entire server is built around Minecraft 1.21.1, Fabric, and Cobblemon 1.7.3, so compatibility matters more than chasing version numbers.

The same approach works on UnRAID, Linux, or any host that can run Docker. I use UnRAID, but the Compose example below is a clearer way to show the important settings.

What you are building

The finished setup has four parts:

1. A Fabric Minecraft server running in Docker.
2. A persistent data directory containing the world, configuration, mods, and datapacks.
3. A versioned server manifest that records every installed component.
4. A matching Modrinth or Prism profile that players can import instead of assembling the client themselves.

The fourth part matters more than it sounds. A modded server is only easy to join when every player has the same Minecraft version, loader, required mods, resource packs, and configuration.

Decide the rules before installing anything

Start with the experience you want, not a page full of popular mods.

For Kame House, Cobblemon is the center of the server. Trainer battles, gyms, mounts, trading, maps, storage, and world generation support that experience. A mod does not get installed just because it looks interesting.

Write down these decisions first:

• Minecraft and Cobblemon versions
• Fabric or another supported loader
• Public, private, or VPN-only access
• Maximum player count
• PvP rules
• World-generation datapacks
• Backup frequency
• Who can administer the server

World generation deserves an early decision. Terralith, Incendium, and Nullscape change how new terrain is created. Add them before players explore. Removing or changing them later can leave obvious borders or create inconsistent terrain.

Create the Docker server

The server uses the itzg/minecraft-server image with Java 21 pinned in the image tag. A minimal Compose file looks like this:

services:
  cobblemon:
    image: itzg/minecraft-server:java21
    container_name: cobblemon
    ports:
      - "${MINECRAFT_PORT:-25565}:25565"
    environment:
      EULA: "TRUE"
      TYPE: "FABRIC"
      VERSION: "1.21.1"
      MEMORY: "14G"
      ONLINE_MODE: "TRUE"
      DIFFICULTY: "normal"
      PVP: "FALSE"
    volumes:
      - ./data:/data
    restart: unless-stopped
    stdin_open: true
    tty: true

On UnRAID, create the same values through the Docker template:

• Repository: itzg/minecraft-server:java21
• Container path: /data
• Host path: a dedicated appdata directory
• Container port: 25565/TCP
• Environment variables: the values shown above

Do not use an unpinned latest image for a mature modded server. Kame House broke when the runtime moved ahead of what Minecraft 1.21.1 and the mod stack expected. Pinning Java 21 removed that uncertainty.

Fourteen gigabytes works for the current server, but it is not a universal requirement. Start with enough memory for the pack and expected players, then watch actual usage. Do not give Minecraft all of the host’s RAM.

Start the container once and let it create the data directory. Stop it before adding the mod stack.

Build a mod manifest

Treat the mod list as a release, not a folder of downloads.

For every mod, record:

• Project name and download source
• Exact filename and version
• Minecraft version
• Loader
• Client required, client optional, or server only
• Required dependencies
• Reason it exists

The Kame House stack falls into a few useful groups:

Copy server mods into /data/mods. Put world datapacks into /data/world/datapacks after the world exists, or place them in the world before the first real launch.

Check dependencies carefully. Many startup failures are not caused by the main mod. They are caused by a missing library such as Architectury, Balm, Cloth Config, Polymer, or a config API.

Do not assume similar names mean the same project. We nearly rejected Radical Cobblemon Trainers because an incompatible mod with a similar trainer-battle name appeared on a compatibility list. The correct fix was research, not guessing.

Prepare a matching player release

The server is not ready until a clean client can join it. Separate client-required mods from server-only tools, test one known-good profile, and export that profile as a release.

The companion guide, Get Players onto the Server, covers the Modrinth pack, first launch, private distribution, and the client problems we already encountered.

Choose remote access deliberately

Test locally before making the server reachable from the internet.

For a private friend server, the main choices are:

• A private mesh VPN such as Tailscale, which avoids a public Minecraft port but requires players to join the private network.
• A direct TCP port forward, which is simple but exposes the home’s public IP to anyone who receives or discovers the address.
• A Minecraft-capable TCP proxy or hosting provider, which can keep the home address behind another endpoint.

A DNS name does not hide the IP behind it. Standard web proxying also does not automatically proxy Minecraft traffic.

If you use a direct port forward, publish only the Minecraft gameplay port. Never expose RCON, the UnRAID interface, Docker management, SSH, or file shares. Keep ONLINE_MODE=TRUE, use a whitelist for a private server, and remove former players when access should end.

Kame House began without a whitelist because the address was shared only among friends. If I rebuilt it today, I would enable the whitelist from the start. Private intent should also be enforced by the server.

Test before inviting players

Use a short acceptance test before the real world opens:

• The server starts without mod dependency errors.
• A clean packaged client can connect.
• A new player can select a starter.
• Maps and resource packs load.
• Gyms and custom terrain generate.
• Waystones, mounts, storage, and furniture work.
• Death creates a recoverable grave.
• A normal player cannot use administrator commands.
• A backup can be restored to a test directory.

The restore test is important. A backup is only a theory until you have successfully opened the restored world.

Update without gambling the world

Do not update mods directly on the live server because a launcher says something is newer.

Use this sequence:

1. Confirm nobody is online.
2. Save the world.
3. Create a dated backup.
4. Record the current manifest.
5. Change one related group of files.
6. Start the server and inspect the logs.
7. Join with the matching test client.
8. Update and export the player pack.
9. Keep the previous server and client releases until the new one is proven.

Version locking can feel conservative, but it is what keeps a shared world usable. The goal is not to run the newest possible collection of files. The goal is to run a known-good collection.

Lessons Kame House taught me

Pin the runtime. A Java update can break an otherwise unchanged server.

Add world generation early. Terrain changes are much harder to reverse after exploration begins.

Read compatibility notes closely. Similar mod names can describe completely different projects.

Prefer stable building blocks. A dedicated jail mod caused crashes, so the feature was rebuilt with vanilla commands and a permissions layer.

Disable integrations you do not use. An optional showcase feature wanted to synchronize player information to an external service. Turning it off reduced unnecessary data sharing.

Backups need restore tests. A folder full of archives is not a recovery plan.

Fewer mods can be better. Every addition creates another dependency, update decision, and possible conflict. A mod should earn its place.

Official references

• Cobblemon installation guide
• Fabric mod installation guide
• Fabric servers with itzg/minecraft-server