Modrinth-Modpacks mit Docker Compose betreiben

Das Pack gibt die Versionen vor

Ein Modpack ist mehr als eine Mod-Liste. Es koppelt Minecraft-Version, Loader, Mods, Konfiguration und häufig eine bestimmte Java-Version. Ausgangspunkt sind deshalb die Serverhinweise des Pack-Autors – nicht unabhängig ausgewählte Einzelkomponenten.

itzg/minecraft-server kann ein Modrinth-Pack auflösen, den Loader auswählen, Dateien installieren und bei einem späteren Pack-Wechsel entfernte Dateien bereinigen. Stelle die Pack-Version fest ein, bevor wertvolle Weltdaten entstehen.

Voraussetzungen

• ein Modrinth-Pack mit ausdrücklicher Server-Unterstützung
• Projekt-Slug oder ID und eine getestete Versions-ID
• dokumentierte Speicher- und Java-Anforderungen des Packs
• genug Speicher für Downloads, Weltdaten und Backups
• das passende Client-Pack für den Beitrittstest

Ein reines Client-Optimierungspack ist kein Server-Pack. Prüfe auf Projekt- und Versionsseite die unterstützte Umgebung.

Compose-Grundlage

Das folgende kleine, reine Server-Beispiel wurde mit Minecraft 26.1.2 verifiziert. Es ist ein funktionierendes Betriebsmuster, keine allgemeine Pack-Empfehlung:

services:
  mc:
    image: itzg/minecraft-server:java25
    restart: unless-stopped
    ports:
      - "25565:25565"
    environment:
      EULA: "TRUE"
      TYPE: MODRINTH
      MODRINTH_MODPACK: essentially-optimized-server
      MODRINTH_VERSION: DR4Y3FOc
      MEMORY: 2G
    volumes:
      - ./data:/data

Die feste ID wählt Essentially Optimized Server 1.0.0 für Minecraft 26.1.2. Bei einem anderen Pack müssen Projekt, Version, Java-Image und Speicher gemeinsam nach dessen Vorgaben ersetzt werden. MODRINTH_MODPACK kann außerdem eine Projekt-/Versionsseite, .mrpack-URL oder eingebundene lokale .mrpack referenzieren.

Verwende das vom Pack benötigte Java-Image. Bei Class-Version-Fehlern hilft der Guide zur richtigen Java-Version statt Ausprobieren.

Pack getrennt von Produktion testen

Nutze beim ersten Start ein leeres Datenverzeichnis. Ein ungeprüftes Pack gehört nicht an eine bestehende Produktionswelt.

mkdir -p data
docker compose config
docker compose up -d
docker compose logs -f mc

Der erste Start kann wegen der Auflösung und Downloads dauern. Warte auf die normale Bereitschaftsmeldung, nicht nur auf den Status „running“.

Aufgelösten Stack prüfen

docker compose exec mc rcon-cli version
docker compose exec mc sh -c 'find /data/mods -maxdepth 1 -type f -name "*.jar" | wc -l'
docker compose logs --since=15m mc

Tritt anschließend mit dem passenden Client-Pack bei und prüfe:

• identisches Pack-Release auf Client und Server
• eigene Blöcke, Gegenstände, Dimensionen und Rezepte
• keine benötigte Serverdatei fälschlich als „client-only“ markiert
• Speichern und erneuter Login funktionieren

Erstelle das erste Backup erst nach diesem Test.

Overrides und Ausschlüsse

Einige Packs kennzeichnen eine reine Client-Datei für den Server falsch. Mit MODRINTH_EXCLUDE_FILES kannst du sie gezielt ausschließen. Nutze das erst, nachdem der Startfehler die konkrete Datei benannt hat und klar ist, dass der Server sie nicht benötigt.

MODRINTH_FORCE_SYNCHRONIZE erzwingt beim Debugging eine frische Synchronisierung. Lasse die Option nicht gedankenlos aktiv: Der installierte Satz soll dem ausgewählten Pack entsprechen, einschließlich Bereinigung.

Pack aktualisieren

Erstelle zuerst ein Backup, stoppe den Service, ändere ausschließlich MODRINTH_VERSION und beobachte den nächsten Start. Bewahre die frühere Compose-Datei und den vollständigen /data-Stand gemeinsam auf.

Arbeite dafür das Docker-Update- und Rollback-Runbook ab. Ein alter Loader oder Pack-Stand darf nie auf Weltdaten starten, die bereits vom neuen Stand migriert wurden.

Fehlerbehebung

Nächste Schritte

• Im Vergleich der Serversoftware klären, wann ein Modloader statt Paper nötig ist.
• Eine vorhandene Welt erst nach dem Docker-Migrations-Runbook verschieben.
• Vor dem Spielerbetrieb automatische Backups ergänzen.