Rust Carbon vs Oxide: switching frameworks

Carbon is a Rust modding framework that runs Oxide plugins. Most .cs plugins written for Oxide load on Carbon unchanged, the permission commands work the same way, and the folder layout is nearly a mirror image. The difference is underneath: Oxide patches the game's own assemblies, while Carbon injects itself at startup and leaves the game files alone. In practice that means Carbon tends to be usable again sooner after the monthly update, ships extra built-in features, and gives up a little of Oxide's decade of edge-case compatibility. Switching takes about half an hour: put the vanilla files back with SteamCMD, install Carbon, and move four folders. The rest of this post is the detail - what changes, what breaks, and how to choose.

How the two frameworks differ#

Both frameworks do the same job: call your plugins at hook points inside the game, let them change outcomes, and give them a permission system, config files and data storage. They differ in how they get inside the game and what they bundle.

Oxide is the reference. Plugin authors write for it, test against it, and the uMod site is still the largest free catalogue. Carbon positions itself as a faster, more modern host for that same ecosystem. Neither is a different game mode or changes what players see; a player cannot tell which framework a server runs unless a plugin tells them.

If you are new to plugins altogether, start with Oxide (uMod) plugins on Rust for the concepts - hooks, configs, data, permissions. Everything there applies to Carbon with the folder names changed.

What carries over and what does not#

The honest summary: the plugins you are likely to run - teleports, kits, clans, remover tools, chat formatting, stack and gather controllers, admin tools - nearly always work. What fails is the code that reaches past the plugin API.

• Ordinary Oxide plugins using documented hooks and the permission, config, data and lang APIs: work.
• Plugins that inspect Oxide's internals through reflection, or assume Oxide's exact class layout: may fail. The console says so on load.
• Oxide extensions - compiled .dll files such as Oxide.Ext.Something.dll that sit in RustDedicated_Data/Managed: not loaded the Oxide way. Carbon has its own extension mechanism and reimplements some popular ones. Check each one specifically, especially anything a custom map depends on.
• Plugins that use their own Harmony patches: usually work, but two patches on the same method can conflict regardless of framework.
• Plugins whose authors target Carbon only: will not run on Oxide. This is increasingly common for paid plugins.

Before switching a live server, list every plugin and extension you run and check each one. Most authors state Carbon support on the plugin page or in their changelog. The rest you find out on a test server, not on wipe day.

Installing Carbon#

Carbon publishes builds for Windows and Linux, and separate builds for the Rust release and staging branches. Take the one that matches both your operating system and the branch your server runs. Some editions are trimmed down; the project's documentation describes which modules each one includes.

1. Stop the server cleanly with quit.
2. Remove Oxide if it is present. Run SteamCMD with app_update 258550 validate to restore the original game assemblies. Move the oxide folder somewhere safe rather than deleting it.
3. Extract the Carbon archive over the server root. It adds a carbon folder and the loader files beside the executable.
4. On Windows, the loader is picked up automatically when RustDedicated.exe starts from that folder.
5. On Linux, the environment must be set before the binary runs. Carbon ships a script for this:

#!/bin/bashcd /home/rust/serversource carbon/tools/environment.sh./RustDedicated -batchmode -nographics -logfile - \  +server.identity "main" +server.port 28015 \  +rcon.web 1 +rcon.port 28016 +rcon.password "change-me"

1. Start and check the console for Carbon's startup banner, then run c.plugins. An unknown-command error means the loader did not run - on Linux, almost always the missing source line.

On a Pterodactyl-style panel, the egg decides whether the environment script runs. Many current Rust eggs offer a framework choice on the Startup tab (vanilla, Oxide or Carbon) and handle this for you. If yours does not, installing Carbon by hand will look successful and do nothing, because the start command never loads it.

Folders, commands and permissions#

Note the one spelling trap: Oxide's folder is config, Carbon's is configs. Copying configs into a folder named config under Carbon does nothing, and every plugin quietly writes its defaults.

c.plugins                     list plugins and their statec.load Kits                   load a pluginc.unload Kits                 unload itc.reload Kits                 reload, rereading its configc.grant group default kits.usec.revoke group default kits.usec.group add vipc.usergroup add 76561198012345678 vipc.show user 76561198012345678

The permission model is Oxide's: permissions registered by plugins, groups with parents, default for everyone and admin for owners, grants to groups or users by SteamID64. If you know oxide.grant, you know c.grant. Carbon also understands many of the Oxide command names for compatibility, but write your own scripts with the c. forms so nobody has to guess which framework a command was meant for.

Built-in modules

Carbon ships optional modules that replace things Oxide servers install plugins for. They live under carbon/modules, each with its own config, and they are off until you enable them. The set changes between versions; the current list includes modules for gather rates, stack sizes, vanish and whitelisting, among others, and an in-game admin panel.

The case for modules is fewer moving parts: one maintained component instead of a third-party plugin that might be abandoned. The case against is that your configuration becomes Carbon-specific, which makes switching back to Oxide a rebuild rather than a folder move. If you think you might return to Oxide, use ordinary plugins for anything gameplay-defining such as rates and stacks.

Carbon also includes a profiler that records how long plugins and hooks take. On Oxide you rely on the hook times in oxide.plugins and on external tools; on Carbon you can capture a profile while the server is struggling and see which plugin and which hook are responsible. That is one of the more practical reasons people switch, and server performance and entity count explains what else to look at.

Testing a switch on a copy first#

The safest way to switch a live server is to not switch it at first. Build a copy, prove it works, then repeat the steps on the real one with a checklist you already trust.

1. Make a test server from a backup of the live one - same Rust version, same plugins, same configs, same data. On a VDS that is a second directory and a second set of ports; on a panel it is usually a second server restored from a backup.
2. Install Carbon on the copy following the steps above, and migrate the folders.
3. Start it and read every line of the startup log. Plugins that fail to compile, missing dependencies and permission warnings all appear here, once, and nowhere else so clearly.
4. Join it with two accounts - one admin, one normal player - and run through the commands players actually use. Kits, homes, teleports, clans, the remover tool, any shop. Note anything that behaves differently.
5. Leave it running for an evening with a few volunteers. Some problems only appear when hooks fire under real play: damage, looting, building, raiding.

If the copy is clean, schedule the real switch for the next wipe, when players expect downtime anyway and a fresh map hides any data you decide not to migrate. If the copy is not clean, you have learned that cheaply. Either way, keep the copy around until the live server has run a full week on Carbon; it is your fastest route back if something surfaces late.

Switching from Oxide to Carbon#

Plan it for a wipe day or a quiet evening, and take a backup of the whole server directory first, including the oxide folder.

1. Back up, stop the server, and run SteamCMD with validate.
2. Install Carbon as above and start once with no plugins, so it creates its folders. Stop again.
3. Copy oxide/plugins/*.cs to carbon/plugins/.
4. Copy oxide/config/*.json to carbon/configs/ - plural.
5. Copy oxide/data/ contents to carbon/data/, and oxide/lang/ to carbon/lang/.
6. Read Carbon's migration notes for permission data on your version, then start the server.
7. Check every plugin loaded with c.plugins, and check permissions with c.show group default, c.show group admin and a couple of real players.
8. Join as a normal player and test the commands people actually use - kits, homes, teleports, remover.

The step that bites is permissions. If your grants were built up by hand over a year, nobody knows exactly what default had. Before you switch, run oxide.show group default and the same for every group, and save the output. Better still, keep a plain text file of every grant and group parent command your server needs; it doubles as documentation and lets you rebuild permissions on any framework in a minute.

Switching back is the same in reverse: validate, install Oxide, move carbon/configs back to oxide/config and so on. Anything you built with Carbon modules has to be replaced with plugins.

The monthly update on Carbon#

The first-Thursday update still affects Carbon. Because it does not patch the game's assemblies, SteamCMD does not overwrite it, but hooks can still move and plugins can still break when Facepunch changes game code. The routine is close to Oxide's:

1. Stop, update Rust with validate.
2. Check that Carbon has published a build or hook update for the new game version, and update if so.
3. Start, read the console for plugins that fail to compile.
4. Fix or unload the failures before opening the server.

The step you might skip on Carbon is the reinstall, not the checking. A server that starts with Carbon loaded but half its plugins failing is in the same position as an Oxide server that lost its framework. The monthly force wipe schedule has the calendar, and Rust wipes without losing your players has the wipe-day runbook.

Which one should you run?#

There is no difference in what your players can do, and claims of large performance gains should be tested on your own plugin set rather than taken on trust: the expensive part of most modded servers is a few heavy plugins and the entity count, not the framework. Change frameworks when it solves a problem you have.

The cost of switching is mostly time and attention, and it is highest on a server with many plugins and a long history of hand-made permissions. A new server pays almost nothing to start on either framework, so that is the moment to choose deliberately. An established server with a working Oxide setup and a team that knows it gains little from moving unless a specific plugin, the profiler or the update routine is a real pain point.

Wherever you host, plugins and frameworks are uploaded by you. On RE:NODE's panel that means the file manager, which unpacks an archive in place, or SFTP with credentials scoped to one server; there is no framework installer or plugin allow-list, so the install steps above are the ones you follow. SFTP and the file manager covers both tools.

Troubleshooting#

`c.plugins` is an unknown command. Carbon's loader did not run. On Linux, the start command is missing source carbon/tools/environment.sh or runs from a different directory. On a panel, check the egg's framework setting.

Plugins load but every config is default. The configs were copied to carbon/config instead of carbon/configs.

Messages appear twice and the server is unstable. Oxide's patched assemblies are still present. Stop, validate, reinstall Carbon.

One plugin fails on Carbon and worked on Oxide. It uses Oxide internals or an Oxide extension. Look for an update or a Carbon-specific alternative.

Custom map features are missing. An extension the map relied on is not loaded. Check Carbon's support for it before blaming the map.

Permissions look empty after switching. The permission data did not migrate on your version. Rebuild from your saved grant list.

FAQ#

Is Carbon allowed by Facepunch?

Rust servers run third-party frameworks under the same terms whether they use Oxide or Carbon: the framework is not the issue, how you list the server is. A server whose plugins change gameplay belongs in the Modded tab either way.

Can I run Oxide and Carbon at the same time?

No. They hook the same game code and conflict. Pick one, and run SteamCMD with validate when you switch so the game files are clean.

Do players need Carbon installed to join?

No. Like Oxide, Carbon runs only on the server. Players join with the normal game client.

Is Carbon faster than Oxide?

It is designed to have less overhead and includes a profiler, but whether your server runs faster depends on your plugins and entity count. Measure on a test copy rather than expecting a framework change to fix lag.

Will my uMod plugins work on Carbon?

The large majority will. Plugins that rely on Oxide internals or on .dll extensions are the exceptions, and you find those by testing before you switch a live server.