Rust server plugins with Oxide or Carbon

1. Oxide or Carbon#

Oxide (long distributed through uMod) is the older framework; its documentation now lives at docs.oxidemod.com and its builds on GitHub. Carbon calls itself "A drop-in replacement for Oxide", and its owner docs say it was built "with the sole purpose of allowing most Oxide-dedicated plugins to work". The plugin files are the same C# .cs files; Carbon's own tutorial tells plugin authors to use Oxide's namespace if they want "your plugin to be usable on both Carbon and Oxide servers".

Pick one. Carbon's docs put it in bold: "Oxide and Carbon can NOT coexist", and running both "will break your server!" Section 6 covers moving between them.

2. Install a plugin#

Put the plugin's .cs file in the plugins folder with the server running. Oxide's docs say it "will detect changes" and compile the plugin itself, "meaning your server does not need to be shut down to install or update plugins." Carbon does the same through what it calls watchers. Two rules from the Oxide docs:

• "Do not rename the plugin or change the file extension." The file name has to match the plugin's class, and Oxide refuses a file whose name does not.
• To update a plugin, "Simply upload the new .cs file to replace the old one".

A plugin that loaded prints two lines. From our test server on Oxide 2.0.7830:

FwgHello was compiled successfully in 1334ms
Loaded plugin FwgHello v1.0.0 by ForgeWorld Gaming

A plugin that did not compile says so, with the line and position. Our test plugin with one semicolon deleted gave:

Error while compiling FwgHello: ; expected | Line: 12, Pos: 36

Note what happened next: oxide.plugins went on listing the previous version as loaded, with no error beside it. Carbon's default is the same, according to its c.unloadonfailure command: unloading a working plugin on a failed recompile is "Disabled by default". So after updating a plugin, look for the compile line in the console, and compare the version oxide.plugins or c.plugins shows with the one you uploaded.

Configs, data and translations

• Config: a configurable plugin MyPlugin.cs creates MyPlugin.json in the config folder on its first load. Oxide warns that "Some plugins save their current configuration to disk when they are unloaded", so a reload can overwrite your edit. Its fix: oxide.unload MyPlugin, edit the file, then oxide.load MyPlugin.
• Data: plugin state, which "should generally not be manually edited". Back it up; Oxide keeps its own group and permission data there too.
• Lang: one folder per language, for the messages a plugin shows players.

The oxide and carbon folders sit next to the server program, outside the save folder, so clearing the save folder for a wipe does not touch them. The wipe-day checklist covers plugin data that should reset with a wipe.

3. Permissions#

Many plugins do nothing for a player until a permission is granted. Permissions usually look like pluginname.permission; the plugin's page lists them, and oxide.show perms lists every one registered by the loaded plugins.

Every player is in default. Oxide puts a player in admin only at Rust's owner level, set with ownerid; moderatorid players do not get it. Carbon has a moderator group for them, and its docs say it also removes groups again when a player's level drops. We found no such step in Oxide's code, so when you remove an owner on Oxide, also run oxide.usergroup remove <player> admin. Name a player with spaces in quotes.

4. After every Rust update#

Both frameworks have to match the Rust build. Oxide's docs: "For every server update by Facepunch, there is an Oxide update. Don't mismatch version of Oxide and version of servers." Rust hotfixes often need one too: in October 2026 Oxide shipped a release for the 1 October update and five more named for Rust hotfixes by the 13th.

• Oxide replaces some of Rust's own files, so a SteamCMD update that installs a new Rust build, or any validate, puts the server back to vanilla. Facepunch's wiki: "If you run SteamCMD in your startup script, your files will be reverted back to vanilla." The order that works is the game update first, then Oxide.
• Carbon leaves Rust's files alone and updates itself when the server boots, but "Carbon only self updates if you update to the latest Rust version". Carbon says it publishes its wipe-day build "1 hour before the actual Rust server update drops".

Facepunch's troubleshooting page, for NullReferenceException errors at start-up, adds: "If you are running a modded server, always make sure that all of your plugins are up to date." Plugin authors also ship fixes after big updates, so check each plugin's page on update day.

5. Modded or Community#

Facepunch's rule: "When using plugins with your Rust server you should be listed under the Modded section." A short list may stay under Community: admin tools that do "not alter gameplay for the player", queue skipping and coloured names, custom maps, and vanilla settings. Anything that changes gather rates, kits, spawns, smelting or the in-game interface belongs under Modded. Facepunch's general server guidelines add that breaking them "may result in delisting from the server browser".

You cannot set the Modded, Oxide or Carbon tags yourself; the frameworks do it. Oxide adds its tag always and the Modded tag unless "Modded" is switched off under "Options" in oxide/oxide.config.json; it is on by default. Carbon does the same with IsModded, and has c.whymodded to list the reasons and c.gocommunity to change its own settings for Community. Neither can judge whether your plugins are allowed there; that call is yours.

6. Switching between Oxide and Carbon#

Oxide to Carbon needs clean game files first. Carbon's docs: "Your Facepunch DLLs must therefore be reverted to vanilla versions. The easiest way to revert is to run a steamcmd update operation on your server with the validate option included." Then take out whatever reinstalls Oxide when the server starts. Carbon's docs say you "must", because a start script that unzips Oxide again puts the patched files straight back. On its first start Carbon copies the oxide folder's config, data, language files and plugins into its own folders, but only while its own folders are empty. Carbon publishes no guide for the way back.

We tried both directions on a test server with one plugin and one granted permission:

• Oxide to Carbon without a validate: the server never finished starting. It looped on TypeLoadException: Invalid type BasePlayer ... at 99% CPU for over ten minutes, until we killed it.
• The same switch after a validate: Carbon 2.0.262 started and loaded the plugin with its permission, from the copy it had made during the failed start. Because Carbon copies only once, anything you add on Oxide after a failed first try, or before a second move to Carbon, has to be copied across by hand.
• Carbon back to Oxide: on our server, which had no Oxide extensions, only the setting had to change, because the start-up stops loading Carbon and unzips Oxide over the game files. Oxide used the oxide folder as it had been before the switch, so anything changed under Carbon in the meantime stayed in carbon. Carbon moves Oxide extension files (Oxide.Ext.*.dll) from RustDedicated_Data/Managed into carbon/extensions at every start, so a server that uses one has to move it back. Elsewhere, take the Carbon step out of your start script (the line that sources carbon/tools/environment.sh, or whatever sets LD_PRELOAD to libdoorstop.so) before you install Oxide.

7. Where plugins come from#

umod.org is the long-standing free plugin site, and Codefling sells and lists plugins too; Carbon's admin panel can install from both. OxideMod.com announces that "uMod.org & Lone.Design are becoming OxideMod.com" and still says "Coming Soon", so expect the address to change. A plugin is code that runs inside your server. Oxide's own checklist is to "Verify the plugin comes from a reputable source", check that it supports your framework version, and read the reviews. Facepunch makes keeping a server "free from viruses, malware and spyware" the owner's job. Oxide also refuses plugins written for the newer uMod framework, with a message saying "is a uMod plugin, not an Oxide plugin". Last checked 2026-10-21.

Where ForgeWorld Gaming fits#

On a ForgeWorld Gaming Rust server the framework is one setting: Modding Framework on the Startup tab, vanilla, oxide or carbon. Every start runs the Rust update first and then downloads the newest Oxide or the Carbon production build, so a restart after a Rust update also brings the framework up to date; restart again if the matching Oxide release came out after your restart. In our tests on 2026-10-21 that gave Oxide 2.0.7830 and Carbon 2.0.262, and on Oxide the server's query reply carried the Oxide and Modded tags. Setting it back to vanilla leaves Oxide's patched game files in place, so Oxide and its plugins keep loading; after leaving Oxide, use Reinstall Server on the Settings tab to put the game files back as Facepunch ships them.

Upload plugins on the Files tab into oxide/plugins or carbon/plugins, and type the commands above on the Console tab. Configs open in the panel's file editor. To move from Oxide to Carbon, stop the server, set the variable to carbon, and use Reinstall Server on the Settings tab before you start it: the reinstall validates the game files, and in our test it kept the world and the oxide folder. Back up the world (server/rust) and the oxide folder first all the same, on the Backups tab or over SFTP, as the panel asks before a reinstall. Going back to Oxide needs only the variable, plus moving any Oxide.Ext.*.dll extension files from carbon/extensions back into RustDedicated_Data/Managed on the Files tab before you start.

Prefer renting to keeping your own server machine online? ForgeWorld Gaming currently offers Rust Standard: 50 player slots at CA$31.49/month. Hosted in Iowa, United States. Prices are in Canadian dollars, with no setup fee and cancel any time. Your server is set up automatically after payment. Continue to secure billing, Rust · Oxide ready, CA$31.49 / month (Standard, 50 slots), or compare Rust plans.