How to Install Mods on a Rust Server

What “mods” means on a Rust server

For Rust, a “modded server” usually means a standard Rust server running server-side plugins through a modding framework. Players do not install anything to join. All plugin code runs inside the server process, so the work lands on your server’s CPU, memory, disk and network rather than on the client.

There are four parts to keep straight:

• Framework: Oxide or Carbon. This is the loader and hook system that lets plugins talk to Rust.
• Plugin: a .cs C# source file, such as Kits, Gather Manager, Vanish or Admin Radar.
• Config: the plugin’s settings, usually JSON, created after the plugin loads.
• Data: the plugin’s saved state, such as player records or stored values between restarts and wipes.

Under the hood, the framework exposes hooks into Rust events. A plugin can listen for things like players gathering resources, joining, chatting or opening containers. Every hook call costs some CPU time, usually on the main server thread, so the busiest plugins are not the ones with the longest feature list but the ones attached to frequent events. Plugins with large data files also use heap memory and can add disk activity when they save often.

That is why the cleanest first setup is simple: pick one framework, load one plugin, confirm it compiles, set its permissions, then move to the next. A messy install with ten new files at once gives you no clear fault line when the Rust server starts throwing compile errors or tick-rate drops.

Decide first: Community or Modded tab

Make this decision before you install anything. Facepunch’s rule is straightforward: when using plugins with your Rust server, you should normally be listed under Modded. You can stay in Community only if every plugin follows the Community guidelines.

Use this matrix to separate safe admin tools from plugins that change gameplay or UI.

What usually forces you into Modded is anything that changes how the game plays or looks. That includes gather rates, item spawns, player spawns, smelting changes, selling kits or resources through custom UI or an external store, and plugins that display or modify in-game UI such as logos or loading messages. Examples given by Facepunch include Furnace Splitter, Gather Manager, Kits, InfoPanel, Loading Messages and Skinbox.

What can stay in Community is much narrower: admin tools that do not alter gameplay, anti-cheat tools that only affect the cheater, skip-queue and chat plugins, custom maps and any mods needed for those maps, plus vanilla convars such as team size, decay scale and population controls. Examples on the allowed side include Vanish, Admin Radar, Stash Traps, Logger, Group Limits, Bypass Queue, Colored Nicknames and Better Chat.

How the frameworks set the tab flag

Oxide marks the server as Modded by default. If you genuinely meet the Community rules, set Modded to false in oxide/oxide.config.json and restart the server.

{
  "Options": {
    "Modded": false
  }
}

Carbon uses IsModded and defaults to Modded as well. Its cleaner approach is to use the built-in commands that apply the right changes and tell you why the server is being flagged.

c.gocommunity
c.whymodded

If your plan includes kits, gather rates or any custom UI at all, stop trying to preserve a Community listing. Set expectations early, run Modded, and manage the server around that choice.

Choose a framework: Oxide or Carbon

Both frameworks load Rust plugins, but they do it differently. Oxide ships patched Rust server DLLs, so a file verify or SteamCMD validate restores the game to vanilla and removes those patches. Carbon patches at runtime using Harmony, so the base Rust files stay intact and a validate does not strip the framework out.

Neutral rule of thumb: if you want the most familiar Oxide-based workflow, use Oxide. If you want a framework that survives SteamCMD validate because it does not replace the game’s managed files, Carbon is the tidier long-term fit. Just do not install both in the same Rust server folder.

Step 1: install Oxide cleanly

This is the standard route if you are starting with Oxide plugins. The important detail is where the files go: extract at the server root so the archive’s RustDedicated_Data folder merges into your server’s existing RustDedicated_Data folder.

1. Stop the Rust server fully. Oxide’s own documentation warns that uploading files while the server is running can corrupt server data.
2. Download the latest stable Oxide build for your operating system, not a pre-release: Oxide.Rust.zip for Windows or Oxide.Rust-linux.zip for Linux.
3. Extract the archive into the server root, where RustDedicated.exe and RustDedicated_Data already exist.
4. Allow overwrite when prompted.
5. Start the server and check the console for the framework loading.
6. Verify with the version command.

oxide.version
oxide.plugins

Your normal Rust server config still lives in server/<identity>/cfg/server.cfg. Oxide is additional framework logic on top of that base install, not a replacement for Rust’s own config location.

Why this works: Oxide supplies patched server DLLs. When Rust starts, those patched files expose the hook points that plugins need. The trade-off is maintenance: anything that restores the vanilla game files, especially a SteamCMD validate or a host start script that runs SteamCMD after Oxide has been installed, removes the framework. If your plugins vanish after an update and the server suddenly looks vanilla, that is usually what happened.

Step 1 alternative: install Carbon

Carbon is installed at the server root too, but its update behaviour is different because it patches at runtime rather than replacing Rust’s managed DLLs.

Windows

1. Stop the server.
2. Download the Windows release archive.
3. Unpack it into the server root, on top of the folder containing RustDedicated.exe.
4. Launch the server as normal and verify Carbon loaded.

c.version
c.plugins

Linux

1. Stop the server.
2. Unpack the Linux release archive into the server root.
3. When starting the server, verify or update the game files first, then source Carbon’s environment script, then launch RustDedicated.

./steamcmd.sh +force_install_dir /path/to/rust +login anonymous +app_update 258550 -beta public validate +quit
cd /path/to/rust
source carbon/tools/environment.sh
./RustDedicated -batchmode ...

Some Linux distributions and Docker setups also need TERM=xterm exported before launch.

Why this works: Carbon does not modify RustDedicated_Data/Managed. It hooks at runtime through Harmony, so a file validate keeps Carbon intact instead of wiping it. That makes boot-time SteamCMD verification much less painful than on Oxide. Carbon also supports self-updating, but you should still treat framework updates carefully and watch the console after every Rust patch.

If you are migrating from Oxide, do it as a clean switch: shut the server down, disable any Oxide auto-install tooling, restore vanilla files with a SteamCMD validate, then unpack Carbon. The first Carbon start can migrate compatible config, data, language files and permissions. That one-way convenience is useful, but it is still safer if you keep a backup before the first Carbon boot.

Step 2: add your first plugin and check the file layout

Start with one small plugin, not a bundle. A sensible first pick is an admin tool like Vanish or Admin Radar first, then something gameplay-related like Kits or Gather Manager once the framework basics are confirmed.

• On Oxide, place the plugin’s .cs file in oxide/plugins.
• On Carbon, place it in carbon/plugins.
• Do not rename the plugin file or change the extension.
• Watch the console as soon as you upload it.

Plugins are compiled automatically on the server from C# source. A successful load usually appears as a “Loading plugin” style message; a failed load shows a compile error. No full restart is normally required. Oxide detects file changes automatically, and Carbon can hot reload too; with Carbon, ScriptWatchers handle this by default, or you can reload manually.

oxide.plugins
oxide.reload <PluginName>

c.plugins
c.reload <PluginName>

If you need plugin files, the usual places are uMod and Codefling. The important part is maintenance, not where you found the file: old plugins often compile badly after Rust API changes, especially after monthly updates.

Step 3: configure it properly, then set permissions

Most plugins create their config file only after the first successful load. So the order is: upload plugin, confirm it loads, then edit its JSON config. Keep the JSON valid: double quotes only, commas in the right places, and no trailing mistakes.

oxide.reload <PluginName>
oxide.unload <PluginName>
# edit the JSON
oxide.load <PluginName>

The unload-edit-load method matters because some plugins save their config on unload. If you edit while the plugin is still active, it can write its old in-memory values back over your changes. If a plugin seems to ignore edits, unload it first, make the change, then load it again.

Back up configs before every edit session, and avoid touching data files unless you know the plugin’s storage format. Configs define intended behaviour; data files often hold live state that plugins expect in a very specific shape.

Grant permissions to groups, not individuals

Permissions decide who can use plugin commands or features. Give those rights to groups wherever possible. That keeps administration predictable: when staff change, you move users in or out of groups instead of hunting through a pile of one-off grants.

oxide.group add vip
oxide.grant group vip myplugin.use
oxide.usergroup add 7656XXXXXXXXXXXXXX vip
oxide.grant user 7656XXXXXXXXXXXXXX myplugin.use
oxide.show groups
oxide.show perms

Oxide includes the default groups default and admin. Carbon uses the same idea with c. commands instead:

c.group add vip
c.grant group vip myplugin.use
c.usergroup add 7656XXXXXXXXXXXXXX vip

Type any Carbon permission command on its own (for example c.grant or c.show) and it prints its exact syntax, which is the quickest check if a command is rejected.

Why this works: most plugin commands first check a permission string before doing anything. If the player cannot use a command, the plugin is often fine and the permission is the missing piece. The trade-off is operational rather than technical: loose grants make moderation messy, while good group structure reduces mistakes and speeds up support when players say a command does nothing.

Keeping plugins working through Rust updates

Facepunch updates Rust regularly, and plugin servers have to plan around that. The key difference is framework behaviour: Oxide must be reinstalled after every Rust server update, while Carbon is not removed by a SteamCMD validate because it does not overwrite the managed game files.

If your host or startup script runs SteamCMD on boot, pay attention to the order. On Oxide, a validate after framework install reverts the server to vanilla and your plugins stop loading because the hooks are gone. On Carbon, validation is fine, but you should still keep Carbon itself updated and confirm it loads after boot.

1. Before the update, back up your framework folders: at minimum oxide/config and oxide/data for Oxide, or carbon/configs and carbon/data if you run Carbon.
2. Stop the server cleanly.
3. Update Rust itself through your panel or SteamCMD using the public branch.
4. If you use Oxide, reinstall the latest stable Oxide build into the server root after the Rust update.
5. If you use Carbon, update Carbon if needed, then keep the normal boot order: verify or update game files first, source the Carbon environment on Linux, then start RustDedicated.
6. Start the server and watch the console closely for framework version messages, plugin compile errors and missing dependency warnings.
7. Run a plugin list command and test one permissioned command before opening the server fully.
8. If a plugin broke after the update, disable only that plugin first rather than tearing the whole framework out.

Rollback is simplest when you keep dated backups. If a plugin update corrupts a config or writes bad data, restore that plugin’s config and data from the last known good copy, then reload the plugin. If console output is thin in your panel, using a launch parameter such as -logFile can make the failure clearer.

Keep a modded Rust server manageable

Most plugin trouble is self-inflicted through sprawl. Add one plugin at a time, note why you installed it, and keep a small changelog of file dates, config changes and granted permissions. That gives you a clean path back when a wipe, Rust patch or plugin revision changes behaviour.

• Prefer maintained plugins: after Rust API changes, abandoned plugins are more likely to fail compilation or produce stale hooks.
• Watch server.fps: it is a practical signal for plugin overhead, especially after adding gather, loot or heavy admin tools. For the wider resource picture, see our Rust server requirements guide.
• Remove unused plugins: a loaded plugin still runs its hook code every time those events fire, even if nobody uses its commands. Carbon’s documentation adds that Oxide fires its hooks whether or not a plugin needs them, while Carbon only runs the hooks loaded plugins actually use.
• Back up before each wipe and update: configs and data matter more than the plugin file itself because they hold your actual server rules and saved state.

What the server is doing underneath matters here. A plugin that listens to frequent events such as gathering, combat, spawning or inventory actions adds main-thread CPU work every time those hooks fire. Large data sets add heap pressure and can lengthen save or load operations. Logging-heavy plugins add disk writes. UI-heavy or chat-heavy plugins can add some bandwidth as they send extra messages to connected players. The best sign that a change helped is not a feeling but a cleaner console, stable plugin reloads and a better server.fps after unloading the suspect plugin and comparing behaviour.

Troubleshooting and deciding when to tune or upgrade

Common plugin problems

Tune it first or move to a better plan?

If you are not sure whether your problem is plugin hygiene or raw hardware, it helps to understand how game server hardware requirements work. Plugins mainly punish weak single-thread CPU performance and poor admin routines long before they justify random guesswork with bigger plans.

Rust server FAQ

Do players need to download anything to join a modded Rust server?

No. Rust server plugins are server-side, so players join with the normal game client. The framework and plugin code run on your server, not on the player’s PC.

Should I use Oxide or Carbon?

Use one, never both. Oxide is familiar and widely used, but it must be reinstalled after every Rust server update because SteamCMD validate restores vanilla files. Carbon is designed to run most Oxide plugins and survives file validation because it patches at runtime.

Will plugins put my Rust server in the Modded tab?

Usually, yes. Admin-only tools can still fit Community if they follow Facepunch’s guidelines, but gameplay changes like kits, gather rates, smelting changes and custom UI force a Modded listing. If your plan includes those features, treat Modded as the correct destination from day one.

Why did my plugins disappear after a Rust update?

On Oxide, the usual cause is that the Rust update or a SteamCMD validate removed Oxide’s patched files and returned the server to vanilla. Reinstall the matching Oxide version after the Rust update, then start the server again. On Carbon, the framework is not removed by validate, so look first for plugin-specific compile errors or a missed Carbon update.

Can I install Rust plugins without restarting the server?

Usually, yes. Uploading a .cs file to the correct plugin folder triggers automatic compilation, and you can reload plugins with framework commands if needed. Full restarts are still sensible for framework installs, major updates and cases where you need to rule out stale state.

More Rust server help

Compare hosts, or check what your modded server needs in RAM and CPU.