Serveur Project Zomboid dédié : 12 étapes, 30 min [2026]

Le 29 juillet 2026, The Indie Stone a fait basculer Project Zomboid vers la Build 42.20.0 sur la branche stable – la plus grosse mise à jour de l’histoire du jeu, avec Knox Country entièrement retravaillé, un système d’artisanat approfondi et l’élevage d’animaux. Le jour même, le compteur de joueurs simultanés sur Steam a grimpé à 67 662, un nouveau record absolu selon SteamCharts. Si vous voulez héberger votre propre monde persistant pour jouer avec des amis, ce guide vous montre comment installer, configurer et sécuriser un serveur dédié Project Zomboid en 12 étapes – en tenant compte de ce que la Build 42 change concrètement pour les hébergeurs.

Project Zomboid en quelques chiffres

Sorti en accès anticipé depuis 2013 sur Steam, Project Zomboid reste l’un des rares survivants de cette génération de jeux « early access » encore activement développé plus de dix ans après. Selon une estimation de GameDiscoverCo, le jeu aurait dépassé les 15 millions d’exemplaires vendus sur Steam ; d’autres traqueurs tiers avancent des fourchettes très variables (entre 7,9 et 24,5 millions de propriétaires), un écart qui illustre surtout la difficulté à mesurer précisément les ventes d’un titre en développement continu depuis plus d’une décennie – nous retenons donc le chiffre le plus prudent et le mieux sourcé. Le pic historique de joueurs simultanés avant cette semaine datait de janvier 2022, avec un peu plus de 65 000 joueurs connectés au même instant ; le lancement de la Build 42 vient officiellement de le dépasser. Cette popularité durable explique aussi pourquoi la communauté de hosting autour du jeu est aussi mature : des dizaines de guides, d’outils de configuration et d’hébergeurs spécialisés existent déjà, comme en témoignent les ressources citées tout au long de ce guide.

Prérequis : ce qu’il faut avant de commencer

Contrairement à d’autres jeux de survie, le serveur dédié Project Zomboid est un outil Steam totalement gratuit et distinct du jeu : vous n’avez pas besoin de posséder le jeu sur le compte qui héberge le serveur. Voici ce qu’il vous faut avant de commencer :

Système d’exploitation : Linux (Ubuntu 22.04+/Debian 12+ recommandés) ou Windows 10/11. Les exemples de ce guide couvrent les deux.
SteamCMD : l’outil en ligne de commande de Valve pour télécharger des serveurs dédiés, dernière version.
RAM : minimum 6 Go dédiés au serveur pour un petit groupe en Build 42 (voir l’étape 8 pour le détail par taille de groupe).
CPU : 2 cœurs minimum, 4 cœurs recommandés – Project Zomboid reste très dépendant de la fréquence mono-cœur pour la simulation de zombies.
Stockage : au moins 10 Go SSD libres (le jeu, les sauvegardes et les mods s’accumulent vite).
Accès à votre routeur/pare-feu pour la redirection de ports (étape 3), sauf si vous utilisez un serveur loué chez un hébergeur.
Un accès administrateur (root/sudo sous Linux, droits admin sous Windows) sur la machine qui hébergera le serveur.

Build 41 ou Build 42 : quelle branche choisir pour votre serveur

C’est la question la plus importante à trancher avant même d’installer quoi que ce soit, et elle a changé de réponse cette semaine. Jusqu’au 29 juillet 2026, la branche stable par défaut de Project Zomboid était la Build 41. Depuis, c’est la Build 42 (version 42.20.0) qui est devenue la branche stable par défaut, comme l’a confirmé l’annonce officielle de The Indie Stone. Concrètement, toute nouvelle installation via SteamCMD télécharge désormais la Build 42 par défaut, aussi bien pour le client que pour l’outil serveur dédié.

Si vous préférez rester sur l’ancienne Build 41 – par exemple parce que vos mods ne sont pas encore compatibles avec la 42 – The Indie Stone a créé une branche bêta dédiée baptisée « legacy41 », explicitement pensée aussi pour les propriétaires de serveurs qui veulent continuer à héberger leurs joueurs sur l’ancienne version. Les sauvegardes Build 41 ne sont pas compatibles avec la Build 42 : il n’existe aucun outil de migration, et The Indie Stone déconseille formellement d’essayer.

# Installer/mettre à jour vers la Build 42 stable (comportement par défaut)
./steamcmd.sh +force_install_dir ./pzserver +login anonymous +app_update 380870 validate +quit

# Rester sur la Build 41 (branche "legacy41")
./steamcmd.sh +force_install_dir ./pzserver +login anonymous +app_update 380870 -beta legacy41 validate +quit

Gardez à l’esprit que la Build 42 est nettement plus gourmande en RAM (voir l’étape 8) et que ses réglages serveur ont légèrement évolué : le fichier servertest.ini passe d’un en-tête de version 4 (Build 41) à 5 (Build 42), et l’échelle de rareté du butin gagne un sixième palier (« Extrêmement rare »). Le reste de ce guide couvre les deux branches, avec les différences signalées explicitement.

Pourquoi un serveur dédié plutôt que le mode « héberger » du client

Project Zomboid permet de lancer un monde multijoueur directement depuis le client du jeu, sans rien installer de plus – pratique pour une soirée entre amis. Mais ce mode a trois limites structurelles qu’un vrai serveur dédié élimine. D’abord, la persistance : le monde s’arrête dès que l’hôte quitte le jeu, alors qu’un serveur dédié tourne 24 heures sur 24 indépendamment de qui est connecté. Ensuite, la performance : héberger et jouer sur la même machine partage le CPU et la RAM entre le rendu du jeu et la simulation serveur, ce qui provoque des ralentissements dès que le nombre de zombies augmente. Enfin, l’administration : un serveur dédié expose RCON (voir l’étape 3) pour gérer les joueurs, les bannissements et les sauvegardes à distance, sans avoir à rester devant l’écran de jeu.

Pour un groupe de deux ou trois amis qui jouent occasionnellement, le mode hébergé du client reste suffisant. Pour une communauté qui veut un monde persistant, modéré et accessible à toute heure, un serveur dédié devient rapidement indispensable – et c’est ce que ce guide installe pas à pas. Autre différence pratique souvent négligée : un serveur dédié tourne indépendamment de la version graphique du jeu, ce qui permet de l’héberger sur une machine sans carte graphique dédiée, y compris un petit NAS ou un VPS Linux sans interface, tant que le CPU et la RAM suivent.

Étape 1 : installer SteamCMD

SteamCMD est l’outil officiel de Valve pour télécharger des serveurs dédiés en ligne de commande, sans passer par le client Steam graphique – c’est la méthode recommandée pour n’importe quelle machine Linux distante (VPS, mini-PC headless) où l’interface graphique de Steam n’a pas sa place. Sous Linux, il nécessite au préalable la bibliothèque 32 bits lib32gcc-s1, car SteamCMD lui-même reste un binaire 32 bits malgré des serveurs de jeu 64 bits.

# Debian/Ubuntu
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install lib32gcc-s1 steamcmd -y

# Créer un dossier de travail et lancer SteamCMD une première fois
mkdir -p ~/pzserver && cd ~/pzserver
steamcmd

Sous Windows, téléchargez steamcmd.zip depuis le wiki officiel de Valve, extrayez-le dans un dossier dédié (par exemple C:\pzserver\steamcmd) et lancez steamcmd.exe une première fois pour qu’il se mette à jour automatiquement. Aucun compte Steam payant n’est nécessaire : la connexion se fait en mode anonyme, réservé aux outils serveur gratuits comme celui de Project Zomboid.

Étape 2 : télécharger le serveur dédié Project Zomboid

Le jeu Project Zomboid porte l’identifiant Steam 108600, mais l’outil serveur dédié est une application Steam totalement distincte, gratuite, sous l’identifiant 380870. C’est ce second identifiant qu’il faut cibler.

steamcmd +force_install_dir ~/pzserver +login anonymous +app_update 380870 validate +quit

Une installation réussie affiche ce type de sortie :

Redirecting stderr to '/home/user/Steam/logs/stderr.txt'
[  0%] Checking for available updates...
[----] Verifying installation...
Success! App '380870' fully installed.

Pour mettre à jour le serveur après un futur correctif, relancez exactement la même commande : SteamCMD ne retélécharge que les fichiers modifiés. C’est aussi la commande à reprogrammer si vous décidez plus tard de basculer entre Build 42 et la branche legacy41.

Étape 3 : ouvrir les ports nécessaires

Project Zomboid communique exclusivement en UDP pour le jeu, et en TCP pour l’administration à distance. C’est l’erreur la plus fréquente des nouveaux hébergeurs : ouvrir le port en TCP au lieu d’UDP ne fonctionnera jamais.

Port	Protocole	Usage
16261	UDP	Port de jeu principal (DefaultPort dans l’ini)
16262	UDP	Connexion directe, égal à DefaultPort + 1 (automatique, ne pas fixer à la main)
27015	TCP	RCON – administration à distance (à restreindre à votre IP)

Si le port 16262 reste fermé, le jeu bascule automatiquement sur le relais Steam – la connexion fonctionne toujours, mais avec une latence plus élevée. Si vous hébergez plusieurs instances sur la même machine, décalez chaque paire de ports (16263/16264 pour la deuxième instance, etc.) via l’option -servername.

Sous Linux (pare-feu ufw)

sudo ufw allow 16261/udp
sudo ufw allow 16262/udp
sudo ufw allow from VOTRE_IP_ADMIN to any port 27015 proto tcp
sudo ufw reload

Sous Windows (pare-feu Windows Defender)

netsh advfirewall firewall add rule name="PZ Game UDP" dir=in action=allow protocol=UDP localport=16261-16262
netsh advfirewall firewall add rule name="PZ RCON TCP" dir=in action=allow protocol=TCP localport=27015

N’oubliez pas la redirection de ports (« port forwarding ») sur votre routeur si la machine est derrière une box internet – le pare-feu logiciel ne suffit pas à lui seul. Si vous êtes derrière un CGNAT (IP partagée par votre fournisseur d’accès), la redirection ne fonctionnera pas et il faudra passer par un VPS ou un hébergeur géré (voir plus bas).

Étape 4 : premier lancement et création du compte administrateur

Le premier démarrage est interactif et génère tous les fichiers de configuration par défaut. Ne modifiez rien avant d’avoir lancé le serveur au moins une fois.

# Linux
cd ~/pzserver
chmod +x start-server.sh
./start-server.sh -servername myworld

# Windows (depuis le dossier d'installation)
StartServer64.bat -servername myworld

Au premier lancement, la console vous demande de créer le compte super-administrateur :

Enter new administrator password:
Confirm the password:
Server listening on port 16261

Ce mot de passe donne accès au compte admin in-game (droits complets) et sert aussi pour RCON. Le paramètre -servername myworld détermine le préfixe de tous les fichiers de configuration générés (myworld.ini, myworld_SandboxVars.lua, etc.) ; sans ce paramètre, le préfixe par défaut est servertest. Pour arrêter proprement le serveur, tapez quit dans la console ou faites un seul Ctrl+C – ne forcez jamais l’arrêt (kill -9) pendant une sauvegarde, cela corrompt le monde.

Étape 5 : comprendre les fichiers de configuration

Les fichiers de configuration ne vivent pas dans le dossier d’installation du serveur, mais dans le profil utilisateur : ~/Zomboid/Server/ sous Linux, %USERPROFILE%\Zomboid\Server\ sous Windows.

myworld.ini – le fichier maître : ports, mot de passe, nombre de joueurs max, PVP, visibilité publique, liste de mods.
myworld_SandboxVars.lua – les règles du monde : population de zombies, rareté du butin, durée du jour, multiplicateurs d’XP.
myworld_spawnregions.lua – les villes de spawn disponibles pour les nouveaux joueurs.
Saves/ (dans ~/Zomboid/Saves/) – les mondes sauvegardés ; c’est ce dossier qu’il faut sauvegarder régulièrement (voir l’étape 12).

Règle importante : le serveur réécrit ces fichiers .ini à chaque arrêt. Modifiez-les uniquement pendant que le serveur est arrêté, sous peine de voir vos changements écrasés au prochain redémarrage.

Étape 6 : configurer myworld.ini

Ouvrez le fichier avec un éditeur de texte pendant que le serveur est arrêté. Voici les réglages les plus consultés pour un serveur multijoueur en Build 42 :

PublicName=Mon Serveur Zomboid
PublicDescription=Serveur communautaire FR - RP survie
Public=true
Open=true
MaxPlayers=16
DefaultPort=16261
Password=
PVP=false
PauseEmpty=true
SleepAllowed=false
SleepNeeded=false
VoiceEnable=true
RCONPort=27015
RCONPassword=changez-ce-mot-de-passe

SleepAllowed=false et SleepNeeded=false ne sont pas des options facultatives en multijoueur : si un joueur pouvait dormir, le temps s’accélérerait pour tout le monde en même temps, ce qui casse l’expérience des autres. C’est pour cette raison que le sommeil reste désactivé par défaut dès qu’il y a plus d’un joueur connecté. PauseEmpty=true met la simulation en pause quand personne n’est connecté, ce qui économise des ressources CPU sans affecter le monde.

Étape 7 : ajuster les règles du monde dans SandboxVars.lua

Ce fichier contrôle la difficulté et l’équilibrage du monde. La Build 42 y ajoute quelques options supplémentaires par rapport à la Build 41, notamment un sixième palier de rareté de butin.

SandboxVars = {
    Zombies = 3, -- 1=Insane, 2=High, 3=Normal, 4=Low
    Distribution = 1,
    DayLength = 3, -- en heures reelles par jour in-game
    StartYear = 1,
    StartMonth = 7,
    XpMultiplier = 1.0,
    ZombieLore = {
        Speed = 2, -- 1=Sprinters, 2=Fast Shamblers, 3=Shamblers
        Strength = 2,
        Toughness = 2,
        Transmission = 1, -- infection activee
    },
    LootRarity = 3, -- 1=Extremement rare a 6 en Build 42
}

Comme pour le fichier .ini, éditez ce fichier serveur arrêté puis relancez-le pour appliquer les changements. Les serveurs communautaires orientés survie difficile augmentent en général la force et la vitesse des zombies ; les serveurs orientés construction/coopération douce baissent la population et augmentent la rareté du butin pour ralentir la progression.

Étape 8 : allouer la RAM au serveur

C’est le point technique qui a le plus changé avec la Build 42. Le moteur Java expose deux paramètres, -Xmx (mémoire maximale) et -Xms (mémoire initiale) – à définir dans le script de lancement ou dans ProjectZomboid64.json. Fixez toujours -Xms égal à -Xmx pour éviter les à-coups de redimensionnement, et ne dépassez jamais la RAM physique disponible moins environ 2 Go réservés au système.

# Exemple pour 8 Go alloues (8192 Mo)
JAVA_ARGS="-Xms8192m -Xmx8192m"

Selon les données croisées de DoomHosting et WinterNode, les besoins en RAM ont nettement augmenté entre les deux branches :

Configuration	Joueurs	Build 41 (mini / recommandé)	Build 42 (mini / recommandé)
Vanilla, petit groupe	1-4	3 Go / 4 Go	4 Go / 6 Go
Vanilla, groupe moyen	4-8	4 Go / 6 Go	6 Go / 8 Go
Vanilla, grand groupe	8-16	6 Go / 8 Go	8 Go / 12 Go
Mods légers (<10)	4-8	6 Go / 8 Go	8 Go / 12 Go
Mods lourds (30+)	4-8	8 Go / 12 Go	12 Go / 16 Go
Mods lourds, grand groupe	16+	12 Go / 16 Go	16 Go / 20 Go+

Si vous migrez un serveur existant de la Build 41 vers la Build 42, ne réutilisez pas vos anciens réglages de RAM : selon WinterNode, un serveur qui démarre à 6 Go d’utilisation peut grimper au-delà de 10 Go après une semaine d’activité en Build 42, à cause du nouveau système d’artisanat et de la simulation du monde plus poussée. Prévoyez systématiquement une marge de 20 à 30 % au-dessus du minimum recommandé.

Étape 9 : installer des mods depuis le Steam Workshop

Les mods se déclarent sur deux lignes distinctes et complémentaires du fichier .ini : les identifiants numériques du Workshop (pour que SteamCMD les télécharge) et les identifiants texte des mods (pour que le jeu les active, dans l’ordre de chargement).

WorkshopItems=2874193621;2470650961
Mods=BrITA;VFExplosives

Ces deux identifiants ne sont pas interchangeables et un mod oublié sur une seule des deux lignes ne se chargera pas. Chaque page Workshop indique les deux valeurs à copier – certains mods packagent plusieurs identifiants de mods sous un seul identifiant Workshop, lisez toujours la description complète avant de composer votre liste. Après modification, relancez le serveur pour que SteamCMD télécharge automatiquement les fichiers manquants au démarrage suivant.

Étape 10 : lancer le serveur en continu avec un service systemd

Pour qu’un serveur Linux redémarre automatiquement après un crash ou un reboot de la machine, créez un service systemd plutôt que de laisser tourner une simple session terminal.

# /etc/systemd/system/pzserver.service
[Unit]
Description=Serveur dedie Project Zomboid
After=network.target

[Service]
Type=simple
User=pzadmin
WorkingDirectory=/home/pzadmin/pzserver
ExecStart=/home/pzadmin/pzserver/start-server.sh -servername myworld
Restart=on-failure
RestartSec=15

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now pzserver.service
sudo systemctl status pzserver.service

Faites tourner le serveur sous un utilisateur dédié sans droits root (pzadmin dans l’exemple) plutôt que sous root – c’est une bonne pratique de sécurité de base pour n’importe quel service exposé sur internet, pas seulement pour un jeu.

Étape 11 : se connecter à votre serveur

Depuis le client Project Zomboid, ouvrez Host puis l’onglet Internet, et saisissez l’adresse IP publique du serveur suivie du port (par exemple 203.0.113.10:16261). Si le serveur est déclaré public (Public=true), il apparaît aussi directement dans la liste des serveurs publics après quelques minutes. Le mot de passe administrateur créé à l’étape 4 permet de récupérer les droits admin in-game via la commande /setaccesslevel VotrePseudo admin depuis la console RCON ou en jeu.

Étape 12 : sauvegardes et mises à jour

Le dossier ~/Zomboid/Saves/ contient l’intégralité de votre monde. Une sauvegarde régulière hors du serveur lui-même est la seule protection réelle contre une corruption ou une erreur humaine.

# Sauvegarde quotidienne automatisee via cron (a ajouter avec crontab -e)
0 4 * * * tar -czf /backups/pz-$(date +\%Y\%m\%d).tar.gz -C /home/pzadmin/Zomboid Saves/
# Purge des sauvegardes de plus de 14 jours
0 5 * * * find /backups -name "pz-*.tar.gz" -mtime +14 -delete

Pour mettre à jour le serveur après un correctif, arrêtez-le proprement (quit), relancez la commande app_update 380870 de l’étape 2, puis redémarrez. Tous les joueurs doivent être sur exactement la même version que le serveur : une Build 42.20.0 ne peut pas se connecter à un serveur resté en 42.19, la connexion est purement et simplement refusée.

La restauration est tout aussi importante que la sauvegarde elle-même – une archive qu’on n’a jamais testé de restaurer n’est qu’une fausse sécurité. Arrêtez le serveur, déplacez le dossier Saves/ actuel de côté, puis extrayez l’archive à sa place avant de relancer :

sudo systemctl stop pzserver
mv ~/Zomboid/Saves ~/Zomboid/Saves.corrompu-$(date +%Y%m%d)
mkdir -p ~/Zomboid/Saves
tar -xzf /backups/pz-20260728.tar.gz -C ~/Zomboid/
sudo systemctl start pzserver

Testez cette procédure de restauration au moins une fois avant d’en avoir réellement besoin, idéalement sur une copie de test de votre serveur plutôt qu’en conditions réelles la première fois.

Combien coûte un serveur Project Zomboid : auto-hébergement ou hébergement géré

Trois options existent, du moins cher au plus simple à maintenir : votre propre PC ou mini-PC à la maison, un VPS que vous administrez vous-même, ou un serveur de jeu géré chez un hébergeur spécialisé.

Option	RAM	Coût mensuel estimé	Idéal pour
PC/mini-PC personnel	Variable (6-16 Go dédiés)	~2-5 € d’électricité	Petit groupe, budget minimal
VPS OVHcloud (auto-géré)	8 Go (VPS-2)	7,21 € HT	Utilisateurs à l’aise avec Linux
VPS OVHcloud (auto-géré)	24 Go (VPS-4)	19,96 € HT	Groupe moddé, 16+ joueurs
G-Portal (hébergement géré)	3 Go	8,60 € / 30 jours	Débutants, zéro maintenance
G-Portal (hébergement géré)	9 Go	22,75 € / 30 jours	Groupe moddé, clé en main

Sources : grille tarifaire OVHcloud VPS et G-Portal (prix relevés en juillet 2026, hors taxes pour OVHcloud). Pour l’auto-hébergement à domicile, l’estimation électrique se base sur un mini-PC ou NAS consommant généralement entre 15 et 30 W en fonctionnement continu (11 à 22 kWh/mois), au tarif réglementé EDF de 0,1940 €/kWh en vigueur en juillet 2026 – n’oubliez pas d’y ajouter le coût de votre connexion internet. Vu la hausse des besoins en RAM de la Build 42 (étape 8), le VPS-1 OVHcloud (4 Go) ne suffit plus pour un groupe vanilla dès 4 joueurs : visez au minimum le VPS-2 (8 Go).

Erreurs courantes à éviter

Confondre TCP et UDP sur les ports de jeu.
16261 et 16262 doivent être ouverts en UDP, pas en TCP. Une redirection TCP ne laissera jamais un joueur se connecter, même si RCON (lui, en TCP) fonctionne parfaitement.

Éditer les fichiers de configuration pendant que le serveur tourne.
Le serveur réécrit ses .ini à l’arrêt : toute modification faite pendant qu’il tourne est silencieusement écrasée au prochain quit.

Mélanger des sauvegardes Build 41 et Build 42.
Les formats de monde ne sont pas compatibles. Ouvrir une sauvegarde Build 41 avec un serveur Build 42 ne fonctionne pas et il n’existe aucun outil de conversion officiel.

Fixer -Xmx sans ajuster -Xms au même niveau.
Laisser -Xms nettement plus bas que -Xmx force le moteur Java à redimensionner le tas mémoire en cours de partie, provoquant des micro-freezes perceptibles par tous les joueurs.

Ne renseigner qu’une des deux lignes de mods.
WorkshopItems= télécharge les fichiers, Mods= les active. Oublier l’une des deux lignes revient à installer un mod à moitié – il n’apparaîtra tout simplement pas en jeu.

Forcer l’arrêt du serveur pendant une sauvegarde.
Un kill -9 ou une coupure brutale pendant l’écriture disque est la cause numéro un des mondes corrompus (« base disappeared »). Utilisez toujours quit ou un seul Ctrl+C, et attendez la fin de l’arrêt.

Réutiliser les anciens seuils de RAM Build 41 après une migration vers la Build 42.
Comme détaillé à l’étape 8, les besoins ont augmenté de 30 à 50 % selon la configuration. Un serveur qui tournait très bien à 6 Go en Build 41 a besoin d’au moins 8 Go en Build 42 pour le même nombre de joueurs.

Dépannage : résoudre les problèmes fréquents

Le serveur n’apparaît pas dans la liste publique.
Vérifiez que Public=true et Open=true sont bien définis dans le .ini, puis patientez : l’indexation peut prendre plusieurs minutes après le démarrage.

« Connection timed out » côté joueur.
Le port 16261 UDP n’est probablement pas correctement redirigé sur votre routeur, ou le pare-feu de la machine le bloque encore. Testez avec un outil de scan de port externe pour confirmer que le port est bien accessible depuis internet.

Le serveur plante juste après une mise à jour.
Vérifiez que le client et le serveur tournent exactement sur la même version de build. Un décalage de version, même mineur (42.19 contre 42.20), empêche toute connexion et peut faire planter le chargement du monde.

RCON refuse la connexion.
Confirmez le port (27015 TCP, pas UDP), le mot de passe exact défini dans RCONPassword, et que votre pare-feu autorise bien votre IP en TCP sur ce port.

Un mod installé n’apparaît pas en jeu.
Vérifiez que son identifiant Workshop est bien dans WorkshopItems= ET que son (ou ses) identifiant(s) de mod texte sont bien dans Mods=, dans l’ordre de chargement recommandé par l’auteur.

La consommation de RAM augmente continuellement au fil des jours.
C’est un comportement documenté de la Build 42, pas nécessairement une fuite mémoire : la simulation du monde s’alourdit avec le temps de jeu cumulé. Prévoyez une marge et surveillez avec htop ou un outil équivalent ; un redémarrage hebdomadaire planifié reste la solution la plus simple.

Connexion impossible malgré des ports correctement ouverts.
Vous êtes peut-être derrière un CGNAT (IP partagée par votre fournisseur d’accès), fréquent sur certaines offres fibre ou 4G/5G box. Dans ce cas, la redirection de ports est inopérante côté box : passez par un VPS ou un hébergeur géré.

Le client se connecte puis est immédiatement déconnecté.
C’est presque toujours un décalage de liste de mods entre le client et le serveur – vérifiez que chaque joueur a exactement la même liste, dans le même ordre.

Les joueurs ne peuvent pas dormir dans leur lit.
C’est normal et volontaire : SleepAllowed=false est la valeur par défaut en multijoueur, précisément parce qu’un joueur qui dort ferait avancer le temps pour tout le monde.

Conseils avancés pour aller plus loin

Administrez via RCON plutôt qu’en jeu. Un client RCON comme mcrcon permet d’exécuter des commandes d’administration (kick, ban, sauvegarde forcée, annonces) depuis un script ou un terminal, sans avoir à ouvrir le jeu.

Planifiez un redémarrage hebdomadaire automatique. Avec la dérive mémoire documentée en Build 42, un redémarrage planifié un jour à faible affluence (via cron et systemctl restart pzserver) évite les ralentissements progressifs sans intervention manuelle.

Coordonnez les mises à jour avec votre communauté. Les correctifs continuent d’arriver régulièrement sur la branche stable. Fixez un jour de mise à jour convenu avec vos joueurs plutôt que de mettre à jour au fil de l’eau, pour éviter les décalages de version qui bloquent les connexions.

Limitez raisonnablement le nombre de joueurs en Build 42. En l’absence de retours de performance à grande échelle sur une branche tout juste passée stable, restez autour de 20 joueurs maximum tant que vous n’avez pas testé la stabilité de votre propre configuration à cette taille.

Automatisez la rotation des sauvegardes vers un stockage distant. Un script cron qui envoie l’archive quotidienne vers un espace de stockage externe (rsync vers un second serveur, ou un espace cloud) protège contre une panne totale de la machine hôte, pas seulement contre une corruption locale.

Passez par un DNS dynamique si vous n’avez pas d’IP fixe. La plupart des offres fibre grand public en France attribuent une IP publique qui change périodiquement. Un service de DDNS (DuckDNS, No-IP ou équivalent) associe un nom de domaine stable à votre IP changeante, pour que vos joueurs n’aient pas à chercher une nouvelle adresse à chaque redémarrage de votre box.

Un projet fonctionnel complet

En suivant les douze étapes ci-dessus, vous obtenez un serveur Project Zomboid Build 42 qui tourne en continu via systemd, redémarre seul après un crash, expose RCON pour l’administration à distance, sauvegarde son monde chaque nuit et communique sur les bons ports UDP/TCP. C’est la même architecture – SteamCMD, service systemd, sauvegardes cron, pare-feu ciblé – que celle utilisée pour Satisfactory ou Enshrouded : une fois maîtrisée sur un jeu, elle se transpose presque telle quelle aux autres serveurs dédiés basés sur SteamCMD.

Questions fréquentes

Faut-il acheter Project Zomboid pour héberger un serveur dédié ?
Non. L’outil serveur dédié (App ID 380870) est gratuit et se télécharge en connexion anonyme via SteamCMD, sans compte Steam payant. Seuls les joueurs qui se connectent ont besoin de posséder le jeu.

Combien de RAM faut-il pour un serveur Project Zomboid en Build 42 ?
Comptez au minimum 4 à 6 Go pour un petit groupe vanilla de 1 à 4 joueurs, et jusqu’à 16-20 Go pour un grand groupe fortement moddé. Voir le tableau détaillé de l’étape 8.

Peut-on migrer une sauvegarde Build 41 vers la Build 42 ?
Non. The Indie Stone est explicite sur ce point : les formats de monde ne sont pas compatibles et il ne faut pas essayer de migrer, il faut démarrer un nouveau monde.

Quels ports faut-il ouvrir pour un serveur Project Zomboid ?
16261 et 16262 en UDP pour le jeu, et 27015 en TCP si vous utilisez RCON. Voir le tableau de l’étape 3.

Le sommeil (sleep) fonctionne-t-il en multijoueur ?
Non, il est désactivé par défaut (SleepAllowed=false) car un joueur qui dort ferait avancer le temps pour tous les autres joueurs connectés simultanément.

Combien de joueurs un serveur Project Zomboid peut-il accueillir ?
Techniquement, le champ MaxPlayers accepte des valeurs bien plus élevées, mais en Build 42 tout juste passée stable, les hébergeurs recommandent de rester autour de 20 joueurs maximum tant que la stabilité n’a pas été testée à plus grande échelle sur votre propre configuration.

Comment revenir à la Build 41 si la Build 42 pose problème ?
Relancez la commande SteamCMD de l’étape 2 en ajoutant -beta legacy41, la branche officiellement maintenue par The Indie Stone pour les joueurs et hébergeurs qui préfèrent rester sur l’ancienne version.

Faut-il un serveur dédié, ou le mode « héberger » du client suffit-il ?
Pour deux ou trois amis qui jouent occasionnellement, le mode client suffit. Pour un monde persistant, disponible 24h/24 et modéré à distance via RCON, un serveur dédié est nécessaire – voir la section dédiée plus haut dans cet article.