Héberger un serveur 7 Days to Die V2.6 sur un VPS : installer la branche v2.6, la configurer et préparer la V3

7 Days to Die V2.6 n'est plus la version courante du jeu : depuis la mise à jour V3.0 « Dead Hot Summer » du 29 juin 2026, The Fun Pimps a enchaîné les versions 3.1 à 3.4, et la branche par défaut de Steam est aujourd'hui en V3.4.0. Pourtant, beaucoup de communautés veulent encore héberger un serveur 7 Days to Die en V2.6 : un gros mod de refonte qui n'existe qu'en version 2.x, une partie de longue durée que personne ne veut recommencer, ou simplement l'équilibrage d'avant la V3. Steam le permet, grâce à une branche v2.6 figée sur la dernière build de la version 2.6.

Ce guide s'adresse aux administrateurs qui veulent installer un serveur dédié 7 Days to Die V2.6 sur un VPS Linux sous Debian 13 ou Ubuntu : choix de la branche avec SteamCMD, configuration de serverconfig.xml, ports à ouvrir, service systemd avec arrêt propre, administration par la console telnet, mods et Easy Anti-Cheat, sauvegardes, et enfin la marche à suivre le jour où vous passerez en V3.

Sources : notes de version V2.6 Stable, notes de version V3.0 Dead Hot Summer, notes de la V2.5 et historique des versions du wiki officiel.

7 Days to Die V2.6 en novembre 2026 : une branche figée

La V2.6 est sortie en version stable le 1er avril 2026. Elle a été la dernière version de la lignée 2.x : la V3.0 l'a remplacée sur la branche publique le 29 juin 2026, sur PC comme sur PlayStation 5 et Xbox Series. Depuis, Steam conserve les anciennes versions sous forme de branches bêta nommées par version. Au 12 novembre 2026, voici celles que publie Steam pour l'application 294420, le serveur dédié 7 Days to Die, et pour le jeu lui-même (application 251570) :

La branche v2.6 n'a plus été modifiée depuis le 1er avril 2026 : vous installez la build finale de la V2.6, et elle ne bouge plus. C'est exactement ce qu'on cherche pour un serveur moddé ou une partie en cours, mais cela a trois conséquences à connaître avant de vous lancer :

• Le client et le serveur doivent avoir la même build. Un joueur resté sur la branche publique (V3.4) ne peut pas rejoindre un serveur V2.6 : chaque joueur doit sélectionner la branche v2.6 dans Steam (voir plus bas).
• Pas de joueurs console. Les consoles reçoivent la version courante et n'ont pas d'onglet Bêtas : un serveur 7 Days to Die V2.6 n'accueille que des joueurs PC.
• Plus de correctifs. Les corrections publiées depuis la V3.0 n'arriveront jamais sur la V2.6. C'est un choix assumé, pas une installation définitive : gardez en tête la migration décrite en fin de guide.

Ce que la V2.6 a changé pour un administrateur

Si votre serveur tournait en V2.5 ou avant, la V2.6 apporte quelques changements qui comptent pour un serveur multijoueur. D'après les notes de version officielles :

• Performances en ville : la cause de fortes saccades (« hitches ») dans les grandes villes a été identifiée et corrigée. C'est la principale raison de préférer la V2.6 à une V2.5 pour un serveur 2.x.
• Collecteurs de rosée et bocaux : le collecteur de rosée (Dew Collector) consomme désormais des bocaux vides comme carburant pour produire de l'eau, et la fabrication des bocaux ne demande plus de creuset. Le réglage JarRefund de serverconfig.xml, ajouté en V2.5 avec une valeur de 0, passe à 60 % par défaut : c'est le pourcentage de chances de récupérer le bocal vide après avoir consommé son contenu.
• Progression des biomes : les biomes neige (Snow) et Wasteland sont plus durs (modificateurs de gamestage relevés) et accueillent maintenant des zombies Radiated, Charged et Infernal. Le commentaire de la propriété BiomeProgression a été mis à jour dans serverconfig.xml.
• Expérience des zombies : l'XP gagnée par zombie a été rééquilibrée selon le type, les points de vie et les dégâts. Les valeurs sont regroupées en tête du fichier entityclasses.xml, utile si vous ajustez la progression de vos joueurs.
• Serveur dédié : les vautours n'attaquaient qu'une seule fois sur un serveur dédié, c'est corrigé.

Quel VPS pour héberger un serveur 7 Days to Die V2.6

The Fun Pimps ne publie pas de configuration minimale pour le serveur dédié. Ce qui fait varier la consommation de mémoire et de processeur est connu : la taille de la carte (Navezgane ou carte aléatoire RWG de 6 ou 8 km), le nombre de joueurs connectés, le nombre de zombies actifs (MaxSpawnedZombies, 64 par défaut, que le wiki officiel décrit comme un réglage à fort impact sur les performances), la distance de vue autorisée (ServerMaxAllowedViewDistance) et, surtout, les mods : une refonte complète pèse bien plus lourd que le jeu de base. Les nuits de horde (Blood Moon), qui font apparaître des vagues de zombies autour de chaque joueur, sont en général le moment où le serveur est le plus sollicité : c'est sur elles qu'il faut dimensionner.

Voici notre point de départ parmi les offres VPS Linux ElypseCloud, à ajuster après mesure :

L'offre Starter (4 Go de RAM) suffit pour tester l'installation, mais nous ne la conseillons pas pour un serveur ouvert à une communauté. Une fois le serveur lancé, mesurez sa consommation réelle pendant une Blood Moon avec htop (notre guide pour surveiller les ressources d'un VPS Linux) et ajoutez un fichier d'échange en filet de sécurité contre l'OOM killer avec notre guide pour configurer le swap sur un VPS. Au-delà, ou pour regrouper plusieurs serveurs de jeu, un serveur dédié devient plus intéressant.

Préparer le VPS Linux et installer SteamCMD

Le serveur dédié 7 Days to Die existe en version Linux native (Steam publie un dépôt Linux pour l'application 294420, branche v2.6 comprise) : pas besoin de Wine. Connectez-vous en SSH, de préférence avec une clé (voir notre guide pour configurer une clé SSH sans perdre l'accès), puis mettez le système à jour :

sudo apt update && sudo apt upgrade -y

SteamCMD, l'outil en ligne de commande de Valve qui télécharge les serveurs de jeu, est empaqueté par les deux distributions, mais uniquement en architecture i386 et hors du dépôt principal : non-free sur Debian 13, multiverse sur Ubuntu.

Debian 13 « Trixie » : ouvrez /etc/apt/sources.list.d/debian.sources (ou /etc/apt/sources.list sur les images plus anciennes) et complétez la ligne des composants pour obtenir Components: main contrib non-free non-free-firmware, puis :

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd netcat-openbsd

Ubuntu 24.04 ou 26.04 LTS :

sudo add-apt-repository -y multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd netcat-openbsd

L'installation affiche l'accord de licence de Steam, qu'il faut accepter pour continuer. Le paquet netcat-openbsd servira plus loin à envoyer les commandes d'arrêt propre au serveur. Créez ensuite un compte système dédié, sans droits root : si le processus du serveur de jeu est compromis, l'attaquant reste enfermé dans ce compte.

sudo useradd -m -s /bin/bash sdtd
sudo -u sdtd mkdir -p /home/sdtd/server /home/sdtd/config /home/sdtd/data

Installer le serveur dédié sur la branche v2.6 avec SteamCMD

Le serveur dédié est téléchargeable avec un compte anonyme, sans posséder le jeu. L'option -beta v2.6 sélectionne la branche figée au lieu de la branche publique :

sudo -u sdtd /usr/games/steamcmd \
  +force_install_dir /home/sdtd/server \
  +login anonymous \
  +app_update 294420 -beta v2.6 validate \
  +quit

Au premier lancement, SteamCMD se met à jour lui-même avant de télécharger le serveur, c'est normal. Vérifiez ensuite que c'est bien la V2.6 qui est installée : le manifeste Steam du dossier d'installation indique la branche et le numéro de build. La build attendue pour le serveur dédié en V2.6 est la 22422094.

grep -iE '"buildid"|"betakey"' /home/sdtd/server/steamapps/appmanifest_294420.acf

Gardez la même option -beta v2.6 à chaque mise à jour ou validation. Une commande app_update 294420 validate sans branche, copiée d'un ancien tutoriel ou lancée par un script automatique, ramènerait le serveur sur la branche publique, donc en V3.4, avec une sauvegarde et des mods prévus pour la V2.6.

Configurer serverconfig.xml pour la V2.6

Le serveur lit sa configuration dans un fichier XML passé au lancement avec -configfile=. Ne modifiez pas le serverconfig.xml livré dans le dossier du serveur : une validation SteamCMD le remplace par la version d'origine. Copiez-le dans le dossier config créé plus haut et travaillez sur la copie :

sudo -u sdtd cp /home/sdtd/server/serverconfig.xml /home/sdtd/config/serverconfig.xml
sudo -u sdtd nano /home/sdtd/config/serverconfig.xml

En V2.6, chaque réglage de partie est encore une propriété séparée du fichier (la V3.0 en a regroupé une trentaine dans un code unique, SandboxCode). Les propriétés à revoir en priorité :

Exemple pour un serveur public de 8 joueurs sur une carte aléatoire :

<property name="ServerName"           value="Ma communauté 7DTD V2.6"/>
<property name="ServerPassword"       value=""/>
<property name="ServerVisibility"     value="2"/>
<property name="ServerPort"           value="26900"/>
<property name="ServerMaxPlayerCount" value="8"/>
<property name="GameWorld"            value="RWG"/>
<property name="WorldGenSeed"         value="elypse-v26"/>
<property name="WorldGenSize"         value="8192"/>
<property name="GameName"             value="Saison1"/>
<property name="UserDataFolder"       value="/home/sdtd/data"/>
<property name="TelnetEnabled"        value="true"/>
<property name="TelnetPort"           value="8081"/>
<property name="TelnetPassword"       value=""/>

Dans le fichier livré, UserDataFolder est commenté : sans lui, le serveur range ses données dans ~/.local/share/7DaysToDie de l'utilisateur qui le lance. Le fixer explicitement évite de chercher la sauvegarde le jour où vous en avez besoin. Avec GameWorld à RWG, le premier démarrage génère la carte, ce qui prend plusieurs minutes et sollicite fortement le processeur : laissez-le finir avant de conclure à un blocage.

Ouvrir les ports du serveur 7 Days to Die

Le serveur écoute sur le port défini par ServerPort (26900 par défaut) en TCP et en UDP, et utilise les trois ports UDP suivants pour le trafic de jeu. Avec UFW, sans oublier SSH avant d'activer le pare-feu :

sudo ufw allow OpenSSH
sudo ufw allow 26900/tcp comment '7DTD V2.6 jeu'
sudo ufw allow 26900:26903/udp comment '7DTD V2.6 jeu'
sudo ufw enable
sudo ufw status verbose

N'ouvrez pas les ports 8080 (tableau de bord web) et 8081 (telnet) sur Internet. Pour administrer à distance, passez par un tunnel SSH, par exemple ssh -L 8081:127.0.0.1:8081 vous@ip-du-vps, puis connectez-vous à 127.0.0.1:8081 depuis votre poste. Le détail des règles UFW pour les serveurs de jeu est dans notre guide pour ouvrir les ports d'un serveur de jeu Linux avec UFW.

Lancer le serveur avec systemd et l'arrêter proprement

Le serveur se lance avec le script startserver.sh fourni, qui démarre le binaire 7DaysToDieServer.x86_64 en mode dédié et accepte le chemin du fichier de configuration. Pour l'arrêt, le plus sûr est de demander au serveur d'enregistrer le monde (saveworld) puis de s'arrêter (shutdown) par sa console telnet, qui n'écoute que sur la boucle locale tant que TelnetPassword est vide. Créez le script d'arrêt :

sudo -u sdtd tee /home/sdtd/stop-7dtd.sh >/dev/null <<'EOF'
#!/bin/sh
printf 'saveworld\nshutdown\n' | nc -q 10 127.0.0.1 8081
EOF
sudo chmod 750 /home/sdtd/stop-7dtd.sh

Puis l'unité systemd /etc/systemd/system/7dtd.service :

[Unit]
Description=Serveur 7 Days to Die V2.6
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=sdtd
Group=sdtd
WorkingDirectory=/home/sdtd/server
ExecStart=/home/sdtd/server/startserver.sh -configfile=/home/sdtd/config/serverconfig.xml
ExecStop=/home/sdtd/stop-7dtd.sh
TimeoutStopSec=120
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Volontairement, l'unité ne lance pas SteamCMD au démarrage : sur une branche figée, il n'y a rien à mettre à jour, et une commande de mise à jour mal écrite suffirait à faire passer le serveur en V3. Activez et démarrez le service, puis suivez le journal :

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd
sudo journalctl -u 7dtd -f

Lors d'un sudo systemctl stop 7dtd, vérifiez dans le journal que l'enregistrement du monde a bien lieu avant l'arrêt. Pour aller plus loin sur les unités (limites de ressources, redémarrages planifiés), voir notre guide pour créer un service systemd pour un serveur de jeu.

Administrer le serveur : console telnet et serveradmin.xml

La console du serveur se rejoint en local avec nc 127.0.0.1 8081 (ou par le tunnel SSH vu plus haut). Les commandes les plus utiles au quotidien :

Les droits d'administration sont enregistrés dans serveradmin.xml, dans le dossier Saves de UserDataFolder (ici /home/sdtd/data/Saves/serveradmin.xml). Le niveau de permission fonctionne à l'envers de l'intuition : plus le nombre est petit, plus le joueur a de pouvoir. Passez de préférence par la commande admin plutôt que d'éditer le fichier à la main.

Mods V2.6 et Easy Anti-Cheat

Les mods se déposent dans le dossier Mods du serveur (/home/sdtd/server/Mods). On distingue deux familles :

• Les mods côté serveur uniquement (modlets XML qui modifient le butin, les recettes ou les spawns) : rien à installer chez les joueurs.
• Les mods client et serveur (refontes complètes, nouveaux objets, interface modifiée, code C# avec Harmony) : chaque joueur doit installer exactement la même version du mod que le serveur.

Pour la grande majorité des mods, EACEnabled doit passer à false sur le serveur, et les joueurs lancent alors le jeu sans Easy Anti-Cheat. Avant d'installer un mod, vérifiez sur sa page qu'il cible bien la V2.6 : un mod écrit pour la V3 ne fonctionnera pas sur la branche v2.6, et inversement. Un mod de refonte vient souvent avec son propre serverconfig.xml ou ses réglages recommandés : comparez-les à votre copie plutôt que d'écraser votre fichier.

Faire rejoindre les joueurs sur la branche v2.6

Chaque joueur doit passer son jeu sur la même branche que le serveur. Dans la bibliothèque Steam : clic droit sur 7 Days to Die, Propriétés, onglet Bêtas, puis choisir la branche v2.6 (Version 2.6 Stable). Steam télécharge alors la V2.6 à la place de la V3.4. Pour revenir à la version courante, il suffit de repasser sur la branche par défaut.

Les joueurs trouvent ensuite le serveur dans la liste des serveurs du jeu (si ServerVisibility vaut 2) ou s'y connectent directement avec l'adresse IP du VPS et le port 26900. En cas de refus de connexion pour version incompatible, faites-leur taper version dans la console du jeu (touche F1) et comparez avec la sortie de la même commande côté serveur.

Sauvegarder le monde du serveur

Tout ce qui fait la valeur de votre serveur se trouve dans deux dossiers : /home/sdtd/data (sauvegardes, carte générée, serveradmin.xml) et /home/sdtd/config (votre serverconfig.xml). Ajoutez le dossier Mods si vous en utilisez. Pour une copie cohérente, arrêtez le serveur, archivez, redémarrez :

sudo systemctl stop 7dtd
sudo tar -czf /root/7dtd-$(date +%F).tar.gz /home/sdtd/data /home/sdtd/config /home/sdtd/server/Mods
sudo systemctl start 7dtd

Une archive qui reste sur le même VPS ne protège pas contre la perte de la machine : envoyez-la ailleurs, et planifiez l'opération à une heure creuse. Notre guide pour sauvegarder un VPS avec rsync vers un serveur distant détaille la mise en place, et celui sur cron et les timers systemd montre comment automatiser l'arrêt, l'archive et le redémarrage.

Préparer le passage de la V2.6 à la V3.4

Rester en V2.6 est un choix temporaire pour la plupart des communautés. Le jour où vos mods existent en version 3, la migration se prépare ainsi :

1. Sauvegardez tout avec la procédure ci-dessus. La V3 convertit les données d'une ancienne sauvegarde au chargement, et ses notes de version mentionnent un avertissement à l'ouverture d'une partie issue d'une version majeure antérieure. Gardez l'archive V2.6 intacte : c'est votre seul retour arrière.
2. Notez vos réglages de partie. En V3, une trentaine de propriétés de la V2.6 (GameDifficulty, LootAbundance, DayNightLength, BloodMoonFrequency, JarRefund, ZombieMove, etc.) n'ont plus d'effet dans serverconfig.xml. The Fun Pimps demande aux administrateurs qui veulent poursuivre une partie V2.6 de recréer ces réglages dans le menu Sandbox Options du jeu, qui produit un SandboxCode à coller dans la propriété du même nom.
3. Repartez du serverconfig.xml de la V3 livré avec la nouvelle version, et reportez-y vos réglages réseau et administration (nom, mot de passe, ports, UserDataFolder, telnet).
4. Changez de branche : relancez SteamCMD avec -beta public à la place de -beta v2.6, et demandez aux joueurs de repasser sur la branche par défaut dans Steam.
5. Faites un premier démarrage de test sur une copie de la sauvegarde, idéalement sur un second VPS, avant d'ouvrir le serveur. Les procédures générales de mise à jour d'un serveur de jeu sont dans notre guide pour mettre à jour un serveur de jeu Linux sans perdre sa configuration.

Dépannage : les problèmes les plus fréquents

En résumé

Héberger un serveur 7 Days to Die V2.6 en novembre 2026 revient à installer la branche Steam v2.6 de l'application 294420 avec SteamCMD, à ne jamais lancer de mise à jour sans cette option, et à faire passer chaque joueur sur la même branche. Le reste est un serveur de jeu Linux classique : un compte dédié, une copie de serverconfig.xml hors du dossier du jeu, les ports 26900 à 26903 ouverts, un service systemd qui enregistre le monde avant de s'arrêter, et des sauvegardes envoyées hors de la machine. Pour héberger ce serveur sur une machine KVM en France, protégée contre les attaques DDoS, découvrez nos VPS Linux ; nous avons aussi un guide pour héberger un serveur Enshrouded sur un VPS Linux si votre communauté joue à plusieurs jeux de survie.