Modrinth-Modpacks mit Docker Compose betreiben

Das Pack gibt die Versionen vor

Ein Modpack legt die Minecraft-Version, den Loader, die Mods, die Konfiguration und häufig die Java-Version fest. Folge den Serverhinweisen des Pack-Autors.

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. Deaktiviere die Option nach der Fehlersuche wieder. Sie gleicht installierte Dateien mit dem ausgewählten Pack ab und kann dabei Dateien entfernen.

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

• Vor dem Spielerbetrieb automatische Backups ergänzen.