Offre Durée limitée : -10% sur tout le site* avec le code ELYPSEWELCOME10

Installer Carbon ou Oxide sur un serveur Rust : Linux, Windows, Pterodactyl et LinuxGSM

Mis à jour le 12 novembre 2026 15 min de lecture 13 sections

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èreOxide (uMod)Carbon
Version au 12 novembre 20262.0.7900 (7 novembre 2026)v2.0.264, build de production (5 novembre 2026)
Archive LinuxOxide.Rust-linux.zipCarbon.Linux.Release.tar.gz (ou Carbon.Linux.Minimal.tar.gz)
Archive WindowsOxide.Rust.zipCarbon.Windows.Release.zip (ou Carbon.Windows.Minimal.zip)
Où l'extraireRacine du serveur : le dossier RustDedicated_Data de l'archive se fusionne avec celui du serveurRacine du serveur, à côté de l'exécutable RustDedicated
Fichiers de Rust modifiésOui, des DLL de Managed sont remplacéesNon, Managed doit rester d'origine
Après une mise à jour SteamCMDRéinstaller OxideRien à refaire, Carbon se met à jour au démarrage
Script de lancement LinuxInchangéCharger carbon/tools/environment.sh avant RustDedicated
Dossier de travailoxide/ (plugins, config, data, lang, logs)carbon/ (plugins, configs, data, lang, logs, extensions)
Préfixe des commandes consoleoxide. ou o.c.
Stockage des permissionsFichiers de données OxideBase SQLite
Outils en plusAucun, le framework seulPanneau 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) ou RustDedicated.exe (Windows) et le dossier RustDedicated_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 dossier oxide/ ou carbon/.

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 :

ActionOxideCarbon
Afficher la versionoxide.version (alias o.version)c.version (alias carbon)
Lister les pluginsoxide.pluginsc.plugins
Recharger un pluginoxide.reload NomDuPluginc.reload NomDuPlugin
Charger, déchargeroxide.load, oxide.unloadc.load, c.unload
Donner une permissionoxide.grant group admin <permission>c.grant (tapez-la seule pour la syntaxe)
Extensions chargéesVoir les DLL Oxide.Ext.* de Managedc.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 :

  1. 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 dossier steamapps et recommencez.
  2. Installer Carbon à la racine du serveur, comme plus haut, de sorte que le dossier carbon soit au même niveau que RustDedicated.
  3. 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 Managed vers carbon/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 OxideAvec Carbon
oxide/plugins, oxide/data, oxide/langcarbon/plugins, carbon/data, carbon/lang (tout le contenu d'oxide sauf config)
oxide/configcarbon/configs
RustDedicated_Data/Managed/Oxide.Ext.*.dllcarbon/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ômeCause probableSolution
oxide.version inconnue après un redémarrageUne mise à jour SteamCMD a remis les fichiers à l'état vanillaRéinstaller Oxide après la mise à jour, dans le script de lancement
c.version inconnue sous Linuxenvironment.sh n'est pas chargé, ou le panel a régénéré le script de lancementAjouter la ligne source avant RustDedicated, ou passer par la variable du panel
Le serveur plante au démarrage après le patch mensuelLe framework n'est pas encore à jour pour la nouvelle version de RustAttendre 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 CarbonOxide encore présent : DLL de Managed modifiées ou script qui le réinstalleSuivre la procédure de migration : valider les fichiers avec SteamCMD, ne garder qu'un framework
Un plugin ne se charge pasErreur de compilation ou dépendance manquanteLire la console et le dossier logs, lister avec oxide.plugins ou c.plugins
Carbon ne se lance pas correctement dans un conteneur DockerVariable TERM absenteAjouter 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

OptionCe que vous gérezInstallation du frameworkPoint de départ chez ElypseCloud
Offre Rust clé en mainPlugins, configurations, permissionsExtraction de l'archive par le gestionnaire de fichiers du panel2 € par mois (1 vCore, 4 Go, 10 Go SSD)
VPS LinuxSystème, pare-feu, SteamCMD, script, systemd, sauvegardesScripts de cette page5,99 € par mois (2 x E5-2697v4, 4 Go, 50 Go SSD)
Serveur dédiéTout, sur une machine physique entièrePlusieurs serveurs Rust, un dossier et un service chacunVoir 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.

FAQ

Carbon ou Oxide : lequel installer sur un nouveau serveur Rust ?

Les deux exécutent les plugins C# écrits pour Oxide. Oxide (uMod) est le framework historique, celui que supposent la plupart des pages de plugins et des tutoriels. Carbon laisse les fichiers de Rust intacts, se met à jour seul au démarrage, stocke les permissions en SQLite et ajoute un panneau d'administration en jeu. Choisissez Oxide pour rester au plus près de la documentation uMod, Carbon pour réduire le travail manuel après chaque mise à jour mensuelle de Rust.

Peut-on installer Carbon et Oxide sur le même serveur ?

Non. La documentation Carbon indique que Carbon et Oxide ne peuvent pas coexister et que les faire tourner ensemble casse le serveur. Pour passer de l'un à l'autre, désactivez tout ce qui réinstalle Oxide, remettez les fichiers de Rust à l'état d'origine avec SteamCMD (app_update 258550 validate), puis installez Carbon.

Où extraire l'archive d'Oxide ou de Carbon ?

À la racine du serveur, dans le dossier qui contient l'exécutable RustDedicated (Linux) ou RustDedicated.exe (Windows). L'archive d'Oxide contient un dossier RustDedicated_Data qui se fusionne avec celui du serveur, en écrasant des DLL du dossier Managed. L'archive de Carbon ajoute un dossier carbon et quelques fichiers à la racine.

Pourquoi Oxide disparaît-il après une mise à jour du serveur Rust ?

Parce que la mise à jour SteamCMD remet les fichiers du serveur dédié à l'état vanilla, comme le rappelle le wiki Facepunch. Il faut réinstaller Oxide après chaque mise à jour : le plus simple est d'ajouter le téléchargement et l'extraction de la dernière version d'Oxide dans le script de lancement, juste après la commande SteamCMD.

Faut-il réinstaller Carbon après chaque mise à jour de Rust ?

Non. Au démarrage, Carbon compare sa version à la liste publiée et télécharge lui-même le correctif correspondant depuis GitHub. Le jour du wipe, le build de production sort une heure avant la mise à jour de Rust. Sur la branche de production, cette mise à jour automatique n'a lieu que si vous mettez aussi Rust à jour : gardez la commande SteamCMD dans le script de lancement.

Pourquoi la commande c.version ne répond pas sur mon serveur Rust Linux ?

Le plus souvent, le script de lancement ne charge pas carbon/tools/environment.sh. Sous Linux, la documentation Carbon impose cet ordre : mise à jour des fichiers du jeu, puis source carbon/tools/environment.sh, puis lancement de RustDedicated. Vérifiez aussi que votre panel n'a pas régénéré le script, et sous Docker ajoutez export TERM=xterm.

Comment vérifier qu'Oxide ou Carbon est bien installé ?

Dans la console du serveur, en RCON ou dans la console du jeu (F1) avec un compte administrateur : oxide.version (ou o.version) affiche la version et la branche d'Oxide, c.version affiche la version de Carbon et celle de Rust. oxide.plugins liste les plugins, y compris ceux qui n'ont pas pu se charger avec la raison de l'échec, et c.plugins liste les plugins chargés par Carbon.

Mes configurations et permissions sont-elles conservées en passant d'Oxide à Carbon ?

Oui, si vous suivez la procédure. Au premier démarrage avec Carbon, la migration automatique copie les configurations, les données, les fichiers de langue, les utilisateurs et les groupes, et déplace les extensions Oxide.Ext.*.dll vers carbon/extensions. Elle ne s'exécute qu'une fois. À défaut, copiez à la main le contenu d'oxide vers carbon, sauf oxide/config qui va dans carbon/configs.

Quelle différence entre Carbon Release et Carbon Minimal ?

Les deux sont des builds de production optimisés. Minimal se concentre sur l'exécution des plugins et retire la plupart des fonctions propres à Carbon : CarbonAuto, le panneau d'administration en jeu et les modules. Il convient à un serveur qui n'utilise que des plugins Oxide classiques. Les builds Edge et Experimental sont des builds de développement à réserver aux tests.

Comment installer Oxide ou Carbon avec Pterodactyl ou LinuxGSM ?

Sur Pterodactyl, l'egg Rust a une variable Modding Framework (FRAMEWORK) qui vaut vanilla, oxide ou carbon : l'image Docker met le serveur à jour puis télécharge le framework choisi à chaque démarrage. Avec LinuxGSM, lancez ./rustserver mods-install et choisissez rustoxide ou rustcarbon ; ./rustserver mods-update met le framework à jour et ./rustserver mods-remove le retire.