← Blog

Comment créer un serveur Minecraft moddé stable et performant ?

Par Benjamin D. · PDG

· Mis à jour le 12 août 2026 · Lecture 10 min

Illustration de l'article : Comment créer un serveur Minecraft moddé stable et performant ?
Sommaire

Créer un serveur Minecraft moddé en 2026 demande un peu plus de rigueur qu'un simple serveur vanilla : il faut choisir un loader, aligner les versions entre client et serveur, dimensionner la RAM, et surveiller les mods qui plombent le TPS. Ce tutoriel décrit la démarche complète, du choix du modpack jusqu'à l'optimisation JVM et aux sauvegardes, avec les commandes réelles à utiliser.



Préparer son serveur Minecraft moddé : loader, version et dimensionnement

Avant de cliquer sur « installer », trois décisions conditionnent tout le reste : le mod loader, la version du jeu et les ressources matérielles. Se tromper ici, c'est repartir de zéro deux semaines plus tard.

Forge, NeoForge, Fabric ou Quilt ?

Les quatre loaders ne sont pas interchangeables : un mod Fabric ne se chargera jamais sur un serveur Forge. Le choix se fait donc en fonction des mods que tu veux, pas de préférences esthétiques.

Loader Usage typique Points d'attention
Forge Gros modpacks historiques, versions 1.12.2 à 1.20.1 Très riche en contenu, mais plus lourd en RAM et au démarrage
NeoForge Successeur de Forge sur les versions récentes (1.20.2+) Écosystème en croissance, mods souvent portés depuis Forge
Fabric Modpacks performance, technique, mods légers Démarrage rapide, mais nécessite souvent Fabric API
Quilt Fork de Fabric, compatible avec la majorité des mods Fabric Communauté plus réduite, à réserver aux cas précis

Règle de terrain : pars du modpack ou de la liste de mods que ta communauté veut jouer, puis déduis le loader et la version. L'inverse mène à des impasses de compatibilité.

Quelle version choisir en 2026 ?

Les versions les plus stables pour un serveur Minecraft moddé sont celles où l'écosystème de mods est mature. En pratique, 1.20.1 (Forge) et 1.21.1 (NeoForge / Fabric) restent des socles solides, alors que les dernières versions publiées manquent souvent de mods portés pendant plusieurs mois. Vérifie systématiquement sur la page de chaque mod la présence d'un build serveur pour la version visée, et consulte les notes officielles sur minecraft.net avant de migrer.

Dimensionner RAM, CPU et disque

Le moteur de Minecraft reste très dépendant des performances mono-cœur : un CPU à haute fréquence comme un Ryzen 9 fait plus de différence que le nombre de cœurs. Les mods, eux, consomment surtout de la RAM et des I/O disque (génération de chunks, structures, dimensions supplémentaires).

  • Modpack léger (20 à 40 mods) : 4 Go de RAM, 5 à 10 joueurs.
  • Modpack moyen (80 à 150 mods) : 6 à 8 Go de RAM, 10 à 20 joueurs.
  • Gros modpack (200 mods et plus, type expert) : 10 à 16 Go de RAM, 15 à 30 joueurs.
  • Modpack très lourd avec dimensions custom et quêtes : 16 Go et plus, stockage NVMe indispensable.

Attention à un piège classique : allouer toute la RAM disponible à la JVM. Le système et le garbage collector ont besoin de marge. Sur une offre 8 Go, alloue plutôt 7 Go à Java. Un stockage NVMe et de la DDR5 ECC évitent aussi les micro-freezes lors des sauvegardes de monde, très fréquentes sur les packs qui écrivent en continu.



Installer un serveur Minecraft moddé étape par étape

Deux approches existent : passer par un hébergement managé avec panel, ou tout gérer soi-même sur un VPS. Les deux sont détaillées ci-dessous.

Méthode 1 : installation via le panel (la plus rapide)

Sur un hébergement Serveur Minecraft, l'installation est instantanée et le loader est proposé directement dans le NexusPanel. Le déroulé habituel :

  1. Choisis l'offre en fonction de la RAM calculée plus haut.
  2. Dans le panel, sélectionne le type de serveur : Forge, NeoForge, Fabric, ou un modpack CurseForge / Modrinth par ID.
  3. Sélectionne la version du jeu et la build exacte du loader.
  4. Lance l'installation, puis accepte l'EULA depuis le gestionnaire de fichiers ou la variable dédiée.
  5. Démarre le serveur une première fois : les dossiers mods, config et world se créent.
  6. Arrête le serveur, envoie tes fichiers .jar dans /mods, puis redémarre.

Le gestionnaire de fichiers accepte l'upload d'archives : téléverse un .zip contenant tes mods, décompresse-le côté serveur, c'est bien plus rapide que 150 fichiers un par un. La console live permet de suivre le chargement mod par mod et de repérer immédiatement celui qui plante.

Méthode 2 : installation manuelle sur VPS

Si tu veux tout contrôler, un VPS Linux fait très bien le travail. Voici une installation propre sous Debian/Ubuntu, avec un utilisateur dédié et un service systemd.

ssh root@ton-ip
apt update && apt upgrade -y
apt install -y openjdk-21-jre-headless screen wget unzip

adduser --disabled-password --gecos "" minecraft
su - minecraft
mkdir -p ~/serveur-modde && cd ~/serveur-modde

# Exemple NeoForge (adapter la version à ton pack)
wget https://maven.neoforged.net/releases/net/neoforged/neoforge/21.1.209/neoforge-21.1.209-installer.jar
java -jar neoforge-21.1.209-installer.jar --installServer

echo "eula=true" > eula.txt

Ensuite, un service systemd pour un démarrage automatique et des logs centralisés :

# /etc/systemd/system/minecraft.service
[Unit]
Description=Serveur Minecraft modde
After=network.target

[Service]
User=minecraft
WorkingDirectory=/home/minecraft/serveur-modde
ExecStart=/usr/bin/java @user_jvm_args.txt -jar run.jar nogui
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now minecraft
journalctl -u minecraft -f

Pour héberger plusieurs instances moddées avec isolation et quotas, un VPS Pterodactyl est plus confortable : chaque serveur tourne dans son conteneur, avec ses propres limites CPU/RAM et son propre port.

Arguments JVM et allocation mémoire

Les flags dits « Aikar » restent la référence pour un serveur moddé, car ils réduisent nettement les pauses du garbage collector. À placer dans user_jvm_args.txt ou dans le champ de démarrage du panel :

-Xms8G
-Xmx8G
-XX:+UseG1GC
-XX:+ParallelRefProcEnabled
-XX:MaxGCPauseMillis=200
-XX:+UnlockExperimentalVMOptions
-XX:+DisableExplicitGC
-XX:+AlwaysPreTouch
-XX:G1NewSizePercent=30
-XX:G1MaxNewSizePercent=40
-XX:G1HeapRegionSize=8M
-XX:G1ReservePercent=20
-XX:G1HeapWastePercent=5
-XX:G1MixedGCCountTarget=4
-XX:InitiateHeapOccupancyPercent=15
-XX:G1MixedGCLiveThresholdPercent=90
-XX:G1RSetUpdatingPauseTimePercent=5
-XX:SurvivorRatio=32
-XX:+PerfDisableSharedMem
-XX:MaxTenuringThreshold=1

Xms et Xmx doivent être identiques. Un heap qui grandit et rétrécit en permanence provoque des lags visibles en jeu. Et n'alloue jamais 24 Go « parce que c'est disponible » : au-delà de 16 Go, les cycles GC deviennent plus longs sur la plupart des packs.



Configurer, sécuriser et optimiser son serveur moddé

server.properties : les lignes qui comptent

server-port=25565
max-players=20
view-distance=8
simulation-distance=6
online-mode=true
white-list=true
enforce-whitelist=true
enable-rcon=true
rcon.port=25575
rcon.password=UnMotDePasseLongEtAleatoire
spawn-protection=16
max-tick-time=-1

Deux réglages font la différence sur un serveur Minecraft moddé : view-distance et simulation-distance. Passer de 10 à 8 en view-distance et de 10 à 6 en simulation-distance réduit fortement la charge CPU sans que les joueurs ne le remarquent vraiment. max-tick-time=-1 évite les crashs du watchdog quand un pack met du temps à générer une structure lourde.

Optimiser les performances et le TPS

Un modpack mal optimisé descend sous les 20 TPS dès que trois joueurs explorent en même temps. Quelques leviers concrets :

  • Mods d'optimisation côté serveur : FerriteCore, Lithium (Fabric), ModernFix, Ferrite / Canary selon le loader. Ils réduisent l'empreinte mémoire et le coût CPU par tick.
  • Pré-génération du monde avec Chunky : évite les pics de lag lors de l'exploration. En console : chunky radius 3000 puis chunky start.
  • Profiling : installe Spark et lance /spark profiler --timeout 60 pour identifier le mod ou l'entité qui consomme le plus de temps par tick.
  • Limiter les entités : dans la config du pack, réduis les mob caps et surveille les fermes de mobs abusives.
  • Nettoyer les items au sol : un mod de clear automatique toutes les 10 minutes soulage énormément les serveurs tech.

Sécurité : la base non négociable

Un serveur moddé attire les griefers, et certains mods ajoutent des mécaniques exploitables (téléportation, dupli, chunk loaders). Applique ces règles dès le départ :

  • Whitelist active tant que la communauté n'est pas prête : whitelist add Pseudo puis whitelist reload.
  • Mot de passe RCON long et unique, jamais réutilisé ailleurs, et port RCON non exposé publiquement si possible.
  • Sous-utilisateurs du panel plutôt qu'un mot de passe partagé entre modérateurs : chacun a ses droits, tu gardes la traçabilité.
  • Sauvegardes automatiques quotidiennes, plus un snapshot manuel avant chaque ajout ou mise à jour de mod.
  • Mods de protection : un système de claims (FTB Chunks, GriefPrevention selon le setup) limite énormément les dégâts.
  • Anti-DDoS : il est déjà géré côté infrastructure chez Nexus Games, tu n'as rien à configurer pour la protection volumétrique.

Sur un VPS auto-géré, ajoute une couche système classique :

ssh-keygen -t ed25519 -C "admin-minecraft"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@ton-ip

apt install -y ufw fail2ban
ufw default deny incoming
ufw allow 22/tcp
ufw allow 25565/tcp
ufw allow 25565/udp
ufw enable

systemctl enable --now fail2ban
# Puis desactiver PasswordAuthentication dans /etc/ssh/sshd_config

Sauvegardes : la règle des trois copies

Un monde moddé de 200 mods représente vite 10 à 30 Go. Les sauvegardes automatiques du panel couvrent l'essentiel, mais garde toujours une copie locale de ton dossier world avant une mise à jour majeure. Sur VPS, un cron suffit :

0 4 * * * tar -czf /home/minecraft/backups/world-$(date +\%F).tar.gz -C /home/minecraft/serveur-modde world
0 5 * * 0 find /home/minecraft/backups -name "*.tar.gz" -mtime +14 -delete


Dépanner les problèmes les plus fréquents

Le serveur ne démarre pas

Dans 90 % des cas, la réponse est dans logs/latest.log ou dans le fichier crash-reports/. Cherche les mots-clés Missing or unsupported mandatory dependencies, Incompatible mod set ou java.lang.NoClassDefFoundError.

  • Dépendance manquante : ajoute le mod requis (souvent Fabric API, Architectury, Kotlin for Forge).
  • Mauvaise version de loader : un mod compilé pour 1.20.1 ne tourne pas sur 1.21.1.
  • Mod client-only : les mods de shaders, de HUD ou d'optimisation graphique (Sodium, Iris, OptiFine) n'ont rien à faire dans le dossier mods du serveur.
  • Java trop ancien : 1.20.5+ exige Java 21. Vérifie avec java -version.

Les joueurs ne peuvent pas se connecter

  • « Mod rejections » : la liste de mods du client doit correspondre à celle du serveur. Distribue le modpack exact, idéalement via un export CurseForge ou Modrinth.
  • Timeout : vérifie le port dans le panel et l'IP/port communiquée. Sur VPS, contrôle ufw status.
  • « Outdated client/server » : mismatch de version Minecraft.
  • Ping élevé : choisis une localisation de datacenter proche de ta communauté ; la latence réseau ne se rattrape pas côté logiciel.

Lags, TPS bas et freezes

Lance un profiling Spark avant de toucher à quoi que ce soit. Les coupables récurrents : chunk loaders en masse, fermes d'entités, mods de génération de terrain, et systèmes de pipes / logistique très denses. Réduis simulation-distance, pré-génère le monde, et si le pack sature malgré tout, monte en RAM plutôt qu'en slots.

Mettre à jour un modpack sans casser le monde

  1. Snapshot complet (monde + configs + mods) via le panel.
  2. Lis le changelog du pack : certains updates suppriment des blocs ou des dimensions.
  3. Remplace le dossier mods et applique les nouvelles configs, en conservant tes réglages personnalisés.
  4. Teste en local ou sur une instance secondaire avant de basculer la production.
  5. Annonce une fenêtre de maintenance et demande aux joueurs de se déconnecter proprement.

Pour d'autres tutoriels d'administration, mods et optimisation, le Blog Nexus Games et Tous nos serveurs de jeux couvrent les autres jeux moddables si tu gères plusieurs communautés.



Conclusion

Monter un serveur moddé stable tient à trois choses : un loader cohérent avec ta liste de mods, une allocation RAM réaliste avec des flags JVM propres, et une routine de sauvegardes avant chaque modification. Le reste est du réglage fin, guidé par les logs et le profiling. Prends le temps de tester chaque ajout, et ton monde tiendra plusieurs saisons sans reset forcé.



FAQ

Combien de RAM faut-il pour un serveur Minecraft moddé de 150 mods ?

Compte 8 Go alloués à la JVM pour environ 10 à 20 joueurs, sur une offre disposant d'un peu de marge système. Garde Xms et Xmx identiques, ajoute les flags G1GC, et abaisse simulation-distance à 6 si le TPS descend. Au-delà de 200 mods ou avec des dimensions custom, passe à 12 ou 16 Go.

Peut-on installer un modpack CurseForge directement depuis le panel ?

Oui : le NexusPanel permet de sélectionner un modpack par son identifiant CurseForge ou Modrinth, puis d'installer automatiquement le loader et la bonne version. Il reste ensuite à accepter l'EULA, ajuster server.properties et distribuer le même pack aux joueurs pour éviter les rejets de mods à la connexion.

Faut-il un hébergement dédié ou un VPS pour un serveur moddé ?

Un hébergement de serveur de jeu avec panel suffit dans la majorité des cas : installation instantanée, console, sauvegardes et anti-DDoS inclus. Le VPS devient intéressant si tu veux plusieurs instances, un proxy Velocity, une base de données ou un bot Discord sur la même machine, avec un contrôle total via SSH.