Carbon vs Oxide: Which Rust Mod Loader Should You Run?
Rust has no built-in plugin system, so every modded server runs a third-party mod loader. For years that meant Oxide (now branded uMod). Carbon arrived later as a modern, self-updating loader built on the latest C# and the Harmony patching library, and it has become the default question for anyone setting up a server: do I stay on Oxide, or move to Carbon? This guide answers that the way an admin needs it, focused on plugin compatibility, performance, commands, and how to switch without breaking anything.
Key point: You cannot run Carbon and Oxide at the same time. They are two competing loaders that hook the same game assemblies, so you pick one. The good news is that Carbon is designed to be a drop-in replacement and runs the vast majority of existing Oxide plugins unchanged.
What Each Framework Actually Is
Oxide / uMod is the long-established modding framework. It is mature, has the largest plugin catalogue, and almost every plugin author tests against it first. It uses its own patching layer to expose hooks that plugins subscribe to.
Carbon is a newer, self-updating loader that uses the modern Harmony runtime-patching library and the current C# compiler. Its headline feature is that it is fully compatible with Oxide plugins, so you keep the same plugin ecosystem while gaining a more efficient hooking model. Carbon also ships an in-game admin panel (/cpanel) and a built-in profiler.
Plugin Compatibility
This is the question most owners ask first, and the answer is reassuring. Carbon implements the Oxide hook surface and uses Harmony, so it does not require plugins to be rewritten. In practice the large majority of Oxide plugins load on Carbon without changes, including big community plugins. The small number that fail are usually ones that depend on internal Oxide types or ship their own Harmony patches that conflict.
Note: "Compatible" does not mean "guaranteed". Before you migrate a production server, test your exact plugin list on a fresh wipe or a private test server. Plugins that hard-reference Oxide-specific assemblies, or extensions distributed as compiled DLLs, are the usual exceptions.
Performance and Stability
Carbon's advantage comes from how it hooks the game. Instead of patching every possible hook up front, it uses dynamic hooking, applying patches only for hooks that loaded plugins actually subscribe to. Fewer active patches means less per-frame overhead, which matters most on servers running large plugin counts. Carbon servers also tend to boot noticeably faster than an equivalent Oxide setup.
For a light setup of a handful of plugins, you will rarely feel a difference and Oxide is perfectly fine. For a heavily modded server with dozens of plugins, Carbon's hooking model and its profiler make it the easier framework to keep stable and to diagnose when a plugin misbehaves.
Commands: Oxide vs Carbon
The console commands look similar but use different namespaces. Oxide uses the oxide.* prefix; Carbon uses c.* (with carbon.* available, and you can map Oxide-style aliases such as o.reload to c.reload).
| Action | Oxide | Carbon |
|---|---|---|
| Show loader version | oxide.version | c.version |
| Load a plugin | oxide.load <plugin> | c.load <plugin> |
| Unload a plugin | oxide.unload <plugin> | c.unload <plugin> |
| Reload a plugin | oxide.reload <plugin> | c.reload <plugin> |
| List loaded plugins | oxide.plugins | c.plugins |
| Grant a permission | oxide.grant user <id> <perm> | c.grant user <id> <perm> |
| Add user to group | oxide.usergroup add <id> <group> | c.usergroup add <id> <group> |
The permission system, group concept, and per-plugin config files behave the same way on both, which is a big part of why migration is painless.
Folder Structure
Oxide stores everything under an oxide/ directory in your server identity, with subfolders for plugins, configs, language files, and data:
oxide/plugins/ // .cs plugin files
oxide/config/ // per-plugin JSON config
oxide/lang/ // localization files
oxide/data/ // saved plugin dataCarbon uses a parallel carbon/ directory with the same subfolder layout (plugins, config, lang, data), so you drop plugins into carbon/plugins/ exactly as you would with Oxide. Carbon also keeps loader settings in carbon/config.json and its profiler configuration in carbon/config.profiler.json. The matching layout is what makes moving between the two loaders straightforward.
Migrating From Oxide to Carbon
Carbon includes automatic migration. The first time a server boots with Carbon installed, it copies your existing Oxide plugins, plugin configs, data files, language files, permissions, and Harmony patches into the managed Carbon directory. You do not have to move files by hand for a standard setup.
- Back up first. Take a full backup of your server identity folder, including the entire
oxide/directory, before changing loaders. - Stop the server. Never swap loaders on a running server.
- Switch the framework. On a managed host this is a single "Modding API: Carbon / Oxide" setting; on a self-hosted box you replace the Oxide install with the Carbon install.
- Start and verify. Run
c.versionin the console to confirm Carbon is loaded, thenc.pluginsto check that your plugins compiled. - Test gameplay. Join the server and confirm permissions, shop, kits, and any custom features behave as before.
Warning: Because the two loaders cannot coexist, do not leave both installed. If you ever roll back to Oxide, your oxide/ folder is still intact from your backup, so keep that backup until you are confident the migration is clean.
Which Should You Choose?
| Your situation | Recommendation |
|---|---|
| Small server, few plugins, everything already works on Oxide | Stay on Oxide; there is no urgent reason to switch |
| Heavily modded server, dozens of plugins, performance matters | Carbon, for its dynamic hooking and lower overhead |
| You need to profile a lag spike or a heavy plugin | Carbon, for its built-in profiler |
| You depend on a plugin that only targets Oxide internals | Test on Carbon first; stay on Oxide if it breaks |
| Brand new server, no existing plugin set | Carbon is a strong default, but either is fine |
Common Pitfalls
- Running both loaders: installing Carbon over a live Oxide install without removing Oxide leads to conflicts. Choose one.
- Skipping the test wipe: assuming 100% compatibility and pushing straight to production. Test your plugin list first.
- Forgetting the namespace: typing
oxide.reloadon a Carbon server does nothing unless you have mapped the alias. Usec.reloador set upo.reloadas an alias. - No backup: migrating without backing up the identity folder. If a plugin fails, you want a clean rollback path.
- Outdated plugins after a forced wipe: after a Rust update or forced wipe, plugins may need updating regardless of which loader you run.
Related Guides
- Installing and managing Oxide/uMod plugins
- How to host a modded Rust server
- Essential console and RCON commands
- Rust server performance optimization
- Rust wipe schedule and forced wipes
Whether you run Carbon or Oxide, your mod loader is only as good as the server under it. Host your Rust server with Supercraft and get one-click modding, daily backups, and full console access so you can switch frameworks safely whenever you want.