Pour ajouter des plugins à un serveur Rust, il faut d'abord installer un framework de modding côté serveur : Oxide (distribué par uMod) ou Carbon. Les deux exécutent les mêmes plugins C#, mais ils ne s'installent pas de la même façon et ne réagissent pas de la même manière aux mises à jour mensuelles de Rust. Ce guide s'adresse à l'administrateur du serveur : quelle archive télécharger, où l'extraire, quoi changer dans le script de lancement sur un VPS Linux ou Windows, comment faire sur Pterodactyl ou LinuxGSM, comment vérifier l'installation et comment passer d'Oxide à Carbon sans perdre vos configurations. Versions vérifiées le 12 novembre 2026 : Oxide.Rust 2.0.7900 (publiée le 7 novembre) et Carbon v2.0.264 en build de production (publiée le 5 novembre, jour du wipe forcé).
Carbon ou Oxide : ce qui change à l'installation
Oxide est le framework historique : son archive écrase des fichiers du serveur dédié, en particulier des DLL du dossier RustDedicated_Data/Managed, et la bibliothèque de plugins de la plateforme uMod est écrite pour lui. Carbon se présente comme compatible avec les plugins Oxide, mais fonctionne autrement : il laisse les fichiers de Rust intacts, charge ses propres versions patchées au démarrage et se met à jour tout seul. Pour l'administrateur, la différence se voit surtout le jour d'une mise à jour de Rust.
| Critère | Oxide (uMod) | Carbon |
|---|---|---|
| Version au 12 novembre 2026 | 2.0.7900 (7 novembre 2026) | v2.0.264, build de production (5 novembre 2026) |
| Archive Linux | Oxide.Rust-linux.zip | Carbon.Linux.Release.tar.gz (ou Carbon.Linux.Minimal.tar.gz) |
| Archive Windows | Oxide.Rust.zip | Carbon.Windows.Release.zip (ou Carbon.Windows.Minimal.zip) |
| Où l'extraire | Racine du serveur : le dossier RustDedicated_Data de l'archive se fusionne avec celui du serveur | Racine du serveur, à côté de l'exécutable RustDedicated |
| Fichiers de Rust modifiés | Oui, des DLL de Managed sont remplacées | Non, Managed doit rester d'origine |
| Après une mise à jour SteamCMD | Réinstaller Oxide | Rien à refaire, Carbon se met à jour au démarrage |
| Script de lancement Linux | Inchangé | Charger carbon/tools/environment.sh avant RustDedicated |
| Dossier de travail | oxide/ (plugins, config, data, lang, logs) | carbon/ (plugins, configs, data, lang, logs, extensions) |
| Préfixe des commandes console | oxide. ou o. | c. |
| Stockage des permissions | Fichiers de données Oxide | Base SQLite |
| Outils en plus | Aucun, le framework seul | Panneau d'administration en jeu, modules, profiler (absents du build Minimal) |
Les deux frameworks prennent en charge Harmony 2.0, la bibliothèque utilisée par les « Harmony mods » qui modifient directement le code du jeu. Notre conseil : Oxide si vous suivez des tutoriels et des pages de plugins uMod qui supposent ses commandes et ses dossiers ; Carbon si vous voulez limiter le travail manuel après chaque mise à jour de Rust. Dans tous les cas, un seul framework par serveur : la documentation Carbon est explicite, Carbon et Oxide ne peuvent pas coexister et les faire tourner ensemble casse le serveur. Pour choisir vos plugins une fois le framework en place, voyez notre sélection des meilleurs mods Rust et leur administration.
Avant d'installer : prérequis et sauvegarde
- Un serveur Rust vanilla qui démarre : installez et testez d'abord le serveur dédié sans framework (application Steam 258550). Notre guide pour héberger un serveur Rust couvre cette étape.
- Un accès aux fichiers : gestionnaire de fichiers du panel, SFTP, SSH sur un VPS Linux ou bureau à distance sur un VPS Windows.
- Le dossier racine du serveur : celui qui contient l'exécutable
RustDedicated(Linux) ouRustDedicated.exe(Windows) et le dossierRustDedicated_Data. - Le serveur arrêté : la documentation Oxide prévient qu'envoyer des fichiers vers un serveur en marche peut corrompre ses données.
- Une sauvegarde du dossier
server/<identité>/(carte,cfg/server.cfg,cfg/users.cfg) et, si vous changez de framework, de tout le dossieroxide/oucarbon/.
Installer Oxide sur un serveur Rust Linux (Debian, Ubuntu)
Sur un VPS Linux, le serveur tourne sous un compte dédié (ici rust, jamais root) et ses fichiers sont dans /home/rust/server. Le lien releases/latest/download du dépôt GitHub d'Oxide renvoie toujours vers la dernière version publiée, c'est celui qu'utilise l'image Docker Rust de Pterodactyl :
sudo -iu rust
cd /home/rust/server
wget https://github.com/OxideMod/Oxide.Rust/releases/latest/download/Oxide.Rust-linux.zip
unzip -o Oxide.Rust-linux.zip
rm Oxide.Rust-linux.zip
L'option -o d'unzip écrase les fichiers existants sans poser de question : c'est voulu, l'archive remplace des DLL de RustDedicated_Data/Managed. Démarrez ensuite le serveur avec votre script habituel. Au premier lancement, Oxide crée le dossier oxide/ à la racine, avec ses sous-dossiers plugins, config, data, lang et logs.
Le piège de SteamCMD : réappliquer Oxide après chaque mise à jour
Le wiki officiel de Facepunch le rappelle : si votre script de démarrage met à jour le serveur avec SteamCMD, les fichiers reviennent à l'état vanilla et Oxide disparaît. La parade consiste à réinstaller Oxide dans le script, juste après la mise à jour et juste avant le lancement :
#!/bin/bash
# /home/rust/start.sh : met à jour Rust, réapplique Oxide, lance le serveur
SERVER=/home/rust/server
/usr/games/steamcmd +force_install_dir "$SERVER" +login anonymous +app_update 258550 validate +quit
wget -q -O /tmp/oxide.zip https://github.com/OxideMod/Oxide.Rust/releases/latest/download/Oxide.Rust-linux.zip
unzip -o -q /tmp/oxide.zip -d "$SERVER"
cd "$SERVER"
export LD_LIBRARY_PATH="$SERVER/RustDedicated_Data/Plugins/x86_64:$SERVER"
exec ./RustDedicated -batchmode +server.identity "monserveur" +server.port 28015 \
+rcon.port 28016 +rcon.password "UnMotDePasseLong" +rcon.web 1 -logfile "$SERVER/rust.log"
Le chemin complet /usr/games/steamcmd est celui du paquet Debian steamcmd : un service systemd ne cherche pas dans /usr/games, d'où le chemin absolu. La variable LD_LIBRARY_PATH pointe vers les bibliothèques du serveur, comme le font l'image Docker de Pterodactyl et le script d'exemple de Carbon. Rendez le script exécutable avec chmod +x /home/rust/start.sh.
Installer Carbon sur un serveur Rust Linux
Carbon publie ses builds de production sous un tag fixe, production_build, sur son dépôt GitHub. Serveur arrêté, extrayez l'archive à la racine :
sudo -iu rust
cd /home/rust/server
wget https://github.com/CarbonCommunity/Carbon/releases/download/production_build/Carbon.Linux.Release.tar.gz
tar -xzf Carbon.Linux.Release.tar.gz
rm Carbon.Linux.Release.tar.gz
Sous Linux, extraire l'archive ne suffit pas. La documentation d'installation de Carbon impose cet ordre dans le script de lancement : mettre à jour les fichiers du jeu (SteamCMD), charger carbon/tools/environment.sh avec source, puis lancer RustDedicated. Ce fichier prépare l'environnement de Doorstop, le chargeur qui injecte Carbon dans le processus avant le code du jeu :
#!/bin/bash
# /home/rust/start.sh : met à jour Rust, charge Carbon, lance le serveur
SERVER=/home/rust/server
/usr/games/steamcmd +force_install_dir "$SERVER" +login anonymous +app_update 258550 validate +quit
cd "$SERVER"
source "$SERVER/carbon/tools/environment.sh"
export TERM=xterm
export LD_LIBRARY_PATH="$SERVER/RustDedicated_Data/Plugins/x86_64:$SERVER:$LD_LIBRARY_PATH"
exec ./RustDedicated -batchmode +server.identity "monserveur" +server.port 28015 \
+rcon.port 28016 +rcon.password "UnMotDePasseLong" +rcon.web 1 -logfile "$SERVER/rust.log"
La ligne export TERM=xterm est recommandée par Carbon pour certaines distributions et surtout pour Docker. Ici, pas besoin de retélécharger Carbon à chaque démarrage : la mise à jour SteamCMD ne touche pas au dossier carbon/, et Carbon vérifie lui-même sa version au lancement. Le serveur doit simplement pouvoir joindre GitHub en HTTPS, car c'est là que Carbon télécharge ses correctifs.
Build Release ou Minimal ?
Le build Minimal se concentre sur l'exécution des plugins : il retire les fonctions propres à Carbon, comme CarbonAuto, le panneau d'administration en jeu et les modules. Il convient à un serveur qui n'utilise que des plugins Oxide classiques. Les branches Edge et Experimental fournissent des builds de développement (Debug) : réservez-les à un serveur de test.
Lancer le serveur moddé avec systemd
Pour que le serveur redémarre seul après un reboot ou un plantage, confiez le script à un service systemd. Le même fichier sert pour Oxide comme pour Carbon, seul le contenu de start.sh change :
# /etc/systemd/system/rust.service
[Unit]
Description=Serveur Rust (Oxide ou Carbon)
After=network-online.target
Wants=network-online.target
[Service]
User=rust
WorkingDirectory=/home/rust/server
ExecStart=/home/rust/start.sh
Restart=on-failure
[Install]
WantedBy=multi-user.target
Activez-le avec sudo systemctl daemon-reload puis sudo systemctl enable --now rust. Chaque redémarrage du service applique alors la mise à jour SteamCMD et le framework. Notre guide pour créer un service systemd pour un serveur de jeu détaille les options (journal, arrêt propre, redémarrage planifié), et celui pour ouvrir les ports d'un serveur de jeu avec UFW les règles de pare-feu à poser.
Installer Oxide ou Carbon sur un serveur Rust Windows
Sur Windows, la procédure manuelle est identique pour les deux frameworks : serveur arrêté, extraire l'archive dans le dossier qui contient RustDedicated.exe, en conservant l'arborescence de l'archive et en acceptant d'écraser les fichiers existants. Carbon n'a besoin d'aucune modification du script de lancement sur Windows : on démarre le serveur comme d'habitude.
Pour Oxide, le problème de SteamCMD est le même que sous Linux. Le wiki Facepunch propose un fichier RunServer.bat qui met à jour le serveur puis le relance en boucle ; ajoutez-y une ligne PowerShell qui réapplique Oxide après la mise à jour :
@echo off
:start
C:\Rust\SteamCMD\steamcmd.exe +force_install_dir C:\Rust\MyServer\ +login anonymous +app_update 258550 validate +quit
powershell -NoProfile -Command "[Net.ServicePointManager]::SecurityProtocol='Tls12'; Invoke-WebRequest https://github.com/OxideMod/Oxide.Rust/releases/latest/download/Oxide.Rust.zip -OutFile C:\Rust\oxide.zip; Expand-Archive C:\Rust\oxide.zip -DestinationPath C:\Rust\MyServer -Force"
cd /d C:\Rust\MyServer
RustDedicated.exe -batchmode +server.port 28015 +server.identity "server1" +rcon.port 28016 +rcon.password "UnMotDePasseLong" +rcon.web 1 -logfile
goto start
L'option -Force d'Expand-Archive écrase les fichiers existants. Sur un VPS Windows, limitez l'accès au bureau à distance et au port RCON à vos propres adresses : notre guide pour sécuriser Windows Server, RDP et le pare-feu montre comment.
Pterodactyl et LinuxGSM : choisir le framework sans script
Pterodactyl
L'egg Rust livré avec Pterodactyl contient une variable Modding Framework (FRAMEWORK) qui accepte trois valeurs : vanilla (par défaut), oxide et carbon. À chaque démarrage, l'image Docker ghcr.io/pterodactyl/games:rust met d'abord le serveur à jour avec SteamCMD (sauf si AUTO_UPDATE vaut autre chose que 1), puis télécharge la dernière version d'Oxide ou le build de production de Carbon selon la variable. Sur un panel de ce type, installer un framework revient donc à changer cette variable dans l'onglet Startup du serveur (si l'administrateur du panel l'a laissée modifiable) et à redémarrer. Pour passer d'Oxide à Carbon par ce biais, appliquez quand même la procédure de migration décrite plus bas. Si vous gérez votre propre panel, notre guide pour installer Pterodactyl explique comment importer les eggs.
LinuxGSM
LinuxGSM gère les deux frameworks comme des mods. Depuis le dossier du serveur, la commande ./rustserver mods-install affiche la liste des mods disponibles : tapez rustoxide pour Oxide ou rustcarbon pour Carbon. Ensuite, ./rustserver mods-update met à jour le framework installé et ./rustserver mods-remove le retire.
Vérifier que le framework est bien chargé
Une fois le serveur démarré, tapez la commande de version dans la console du serveur, en RCON, ou dans la console du jeu (F1) avec un compte administrateur :
| Action | Oxide | Carbon |
|---|---|---|
| Afficher la version | oxide.version (alias o.version) | c.version (alias carbon) |
| Lister les plugins | oxide.plugins | c.plugins |
| Recharger un plugin | oxide.reload NomDuPlugin | c.reload NomDuPlugin |
| Charger, décharger | oxide.load, oxide.unload | c.load, c.unload |
| Donner une permission | oxide.grant group admin <permission> | c.grant (tapez-la seule pour la syntaxe) |
| Extensions chargées | Voir les DLL Oxide.Ext.* de Managed | c.extensions |
oxide.version renvoie la version et la branche d'Oxide (par exemple Oxide.Rust Version: 2.0.7900) ; c.version donne la version du build Carbon et celle de Rust. Si la console répond que la commande est inconnue, le framework n'est pas chargé : passez à la section dépannage. Côté Carbon, l'option IsModded de carbon/config.json, active par défaut, classe le serveur dans l'onglet Modded du navigateur de serveurs.
Pour vous donner les droits d'administration du jeu, la méthode reste celle de Rust, quel que soit le framework : la commande ownerid suivie de votre SteamID64 dans la console du serveur, puis une reconnexion.
Installer un premier plugin
Un plugin est un fichier .cs. Avec Oxide, déposez-le dans oxide/plugins ; avec Carbon, dans carbon/plugins. Les deux frameworks surveillent ce dossier : le plugin est compilé et chargé sans redémarrage, puis rechargé quand vous remplacez le fichier. Sa configuration apparaît au premier chargement dans oxide/config ou carbon/configs (avec un « s » chez Carbon). Les erreurs de compilation s'affichent dans la console et dans le dossier logs du framework.
Ne téléchargez que depuis des sources reconnues : un plugin est du code exécuté par votre serveur, avec accès à tout ce qu'il peut faire. Pour transférer les fichiers depuis Windows vers un VPS Linux, un client SFTP comme WinSCP passe par la connexion SSH : suivez notre guide pour accéder à un VPS Linux avec PuTTY et WinSCP.
Mises à jour de Rust et jour de wipe : ce que fait chaque framework
Facepunch publie une mise à jour obligatoire le premier jeudi de chaque mois, qui force aussi un wipe de la carte. C'est le moment où un serveur moddé casse le plus souvent.
- Oxide : selon le wiki Facepunch, une nouvelle version d'Oxide sort en général peu après chaque mise à jour de Rust. Entre les deux, un serveur mis à jour avec l'ancienne version d'Oxide peut refuser de démarrer ou charger mal ses plugins. Le jour du wipe, vérifiez sur la page des versions d'Oxide qu'une version publiée après le patch existe avant de relancer le serveur avec le script ci-dessus.
- Carbon : sa documentation indique que le build de production du jour du wipe sort une heure avant la mise à jour de Rust, et que les builds stables arrivent environ deux fois par mois. Au démarrage, Carbon compare sa version à la liste publiée et télécharge le correctif correspondant. Sur la branche de production, cette mise à jour automatique d'un changement majeur n'a lieu que si vous mettez aussi Rust à jour : c'est pour cela que la mise à jour SteamCMD reste dans le script.
L'ordre des opérations ne change pas : sauvegarde, arrêt, mise à jour de Rust, framework à jour, redémarrage, puis contrôle de o.version ou c.version et des erreurs de plugins dans la console. Notre checklist d'administration du wipe Rust déroule la procédure complète, et notre guide pour mettre à jour un serveur de jeu Linux sans perdre sa configuration la méthode générale.
Passer d'Oxide à Carbon sans perdre ses configurations
La documentation Carbon décrit une migration en trois temps :
- Préparer : arrêtez le serveur, désactivez tout outil qui réinstalle Oxide automatiquement (la ligne Oxide de votre script, la variable du panel, le mod LinuxGSM), puis remettez les DLL de Rust à l'état d'origine avec
steamcmd +force_install_dir /home/rust/server +login anonymous +app_update 258550 validate +quit. Si la validation échoue, supprimez le dossiersteamappset recommencez. - Installer Carbon à la racine du serveur, comme plus haut, de sorte que le dossier
carbonsoit au même niveau queRustDedicated. - Démarrer : Carbon détecte les restes d'Oxide et copie automatiquement les configurations, les données, les fichiers de langue, les utilisateurs et les groupes, puis déplace les DLL d'extensions de
Managedverscarbon/extensions. Cette migration automatique ne s'exécute qu'au premier démarrage avec Carbon.
Si elle échoue, la migration manuelle suit cette correspondance :
| Avec Oxide | Avec Carbon |
|---|---|
oxide/plugins, oxide/data, oxide/lang | carbon/plugins, carbon/data, carbon/lang (tout le contenu d'oxide sauf config) |
oxide/config | carbon/configs |
RustDedicated_Data/Managed/Oxide.Ext.*.dll | carbon/extensions |
Commandes o. ou oxide. | Commandes c. (alias possibles) |
Après la migration, le dossier oxide n'est plus utilisé : vous pouvez le garder comme archive. Les commandes en o. ne fonctionnent plus sous Carbon ; si votre équipe y tient, Carbon permet de définir des alias (commandes c.aliases et c.assignalias).
Revenir de Carbon à Oxide
Carbon ne documente pas de procédure inverse. Le plus sûr est de repartir d'un dossier serveur propre installé par SteamCMD, d'y installer Oxide, puis de recopier carbon/configs vers oxide/config et carbon/data vers oxide/data. Les permissions, stockées en SQLite chez Carbon, sont à recréer avec oxide.group, oxide.usergroup et oxide.grant.
Dépannage : les erreurs les plus fréquentes
| Symptôme | Cause probable | Solution |
|---|---|---|
oxide.version inconnue après un redémarrage | Une mise à jour SteamCMD a remis les fichiers à l'état vanilla | Réinstaller Oxide après la mise à jour, dans le script de lancement |
c.version inconnue sous Linux | environment.sh n'est pas chargé, ou le panel a régénéré le script de lancement | Ajouter la ligne source avant RustDedicated, ou passer par la variable du panel |
| Le serveur plante au démarrage après le patch mensuel | Le framework n'est pas encore à jour pour la nouvelle version de Rust | Attendre la version compatible d'Oxide, ou vérifier que Carbon a pu se mettre à jour |
| Le serveur ne démarre plus après l'ajout de Carbon | Oxide encore présent : DLL de Managed modifiées ou script qui le réinstalle | Suivre la procédure de migration : valider les fichiers avec SteamCMD, ne garder qu'un framework |
| Un plugin ne se charge pas | Erreur de compilation ou dépendance manquante | Lire la console et le dossier logs, lister avec oxide.plugins ou c.plugins |
| Carbon ne se lance pas correctement dans un conteneur Docker | Variable TERM absente | Ajouter export TERM=xterm avant le lancement |
Surveillez aussi la charge du serveur à chaque plugin ajouté : chacun consomme du CPU et de la RAM, surtout ceux qui tournent en tâche de fond. Sur un VPS, htop ou btop suffisent pour repérer un plugin gourmand.
Offre Rust, VPS ou serveur dédié : où installer votre framework
| Option | Ce que vous gérez | Installation du framework | Point de départ chez ElypseCloud |
|---|---|---|---|
| Offre Rust clé en main | Plugins, configurations, permissions | Extraction de l'archive par le gestionnaire de fichiers du panel | 2 € par mois (1 vCore, 4 Go, 10 Go SSD) |
| VPS Linux | Système, pare-feu, SteamCMD, script, systemd, sauvegardes | Scripts de cette page | 5,99 € par mois (2 x E5-2697v4, 4 Go, 50 Go SSD) |
| Serveur dédié | Tout, sur une machine physique entière | Plusieurs serveurs Rust, un dossier et un service chacun | Voir la page serveurs dédiés |
Nos serveurs Rust vont du palier Starter à 2 € au palier Space à 18 € par mois (12 vCore, 32 Go de RAM), tous avec 10 Gbit/s de bande passante, protection anti-DDoS, hébergement en France et trois bases SQL pour les plugins qui stockent leurs données en MySQL. Le VPS Linux vous laisse le contrôle complet du script de lancement, et le serveur dédié se justifie pour plusieurs serveurs moddés en parallèle. Pour estimer les ressources nécessaires, lisez notre guide combien coûte un serveur Rust, et pour protéger vos dossiers oxide ou carbon, celui pour sauvegarder un VPS avec rsync.
FiveM
Minecraft
Rust
RedM
Hytale