# Oxide vs Carbon for a Rust Server: How to Choose

> A neutral comparison of Oxide and Carbon for Rust servers: how they work, plugin compatibility, performance claims, updates, switching and how to choose.

URL: https://badgyver.com/blog/oxide-vs-carbon-rust-server/

Anyone setting up a modded Rust server meets the same fork in the road on day one: install Oxide, or install Carbon. Both run the same kind of C# plugins, both are free, both are listed on Facepunch’s own wiki, and forum threads argue about them as if the choice were obvious. It is not obvious, but it is simpler than those threads make it look.

**Oxide and Carbon do the same job, running plugins on a Rust server, and Carbon is built to run Oxide plugins without changes.** The real differences are how each one attaches to the server, how it behaves on update day, and what comes on top of plugins. Neither project publishes benchmark numbers, so test on your own server rather than trusting anybody’s claims, mine included.

This guide is for owners choosing a framework for a new server, or wondering whether to switch. It sets out what each project is, how plugin compatibility really works, what the performance claims actually say and who makes them, how to move from one to the other, and how to decide. Everything here comes from the two projects’ own documentation, their releases and Facepunch’s wiki, checked in November 2026.

### Two frameworks, one job

A modding framework sits between the Rust server and your plugins. It gives plugins hooks, points in the game where they can react or change what happens, plus shared services such as permissions, config files, stored data and translated messages.

- **Oxide** is the long-established one. It is open source under the MIT licence, developed on [GitHub](https://github.com/OxideMod/Oxide.Rust). Rust plugins are generally written as Oxide plugins, which is why Carbon set out to run them unchanged.

- **Carbon** is the newer one. It is open source under the GPL-3.0 licence, also on [GitHub](https://github.com/CarbonCommunity/Carbon), and describes itself as a drop-in replacement for Oxide.

Facepunch’s wiki has a page for each under its modding section and does not recommend one over the other.

### How each one attaches to the server

This is the difference everything else follows from.

**Oxide replaces files.** Its download contains a RustDedicated_Data/Managed folder with patched copies of Rust’s own program files, including the main game assembly. You copy it over the server, and the patched files call your plugins.

**Carbon patches in memory.** You unpack it into the server’s root folder, where it adds a carbon folder, and it requires Rust’s files to stay exactly as Facepunch ships them. At startup it applies its changes while the server loads, using the Harmony patching library, and only loads the hooks that your installed plugins actually use.

What that means in practice:

- **Updating Rust.** A SteamCMD update puts Facepunch’s original files back, which removes Oxide until you copy the matching Oxide build over again. Carbon’s own instructions are the opposite: verify the server files and keep Rust up to date on every boot.

- **Updating the framework.** Oxide is updated by hand, or by your host’s panel. Carbon checks for a newer build of itself when the server starts and downloads it, a behaviour you can switch off in carbon/config.json.

- **Wipe day.** Both teams had their build ready before the update. For the update of 5 November 2026, released at 19:00 UTC, Oxide published its release at 18:33 and Carbon its production build at 18:34.

### Plugin compatibility

Carbon’s stated goal is to run Oxide plugins with no changes, and it keeps the same folder layout so that moving is mostly copying. Some details are worth knowing before relying on it:

- **One folder is renamed.** Oxide keeps plugin settings in oxide/config; Carbon uses carbon/configs. Plugins, data and language files keep their names.

- **Extensions move.** Oxide extensions, the compiled Oxide.Ext.*.dll add-ons such as the RustEdit extension used by many custom maps, live in RustDedicated_Data/Managed under Oxide. Carbon’s migration guide moves them into carbon/extensions.

- **It only works one way.** A plugin written for Carbon that uses Carbon-only features will not run on Oxide.

- **Edge cases exist.** Carbon’s porting guide does not discuss plugins that reach into Oxide’s internals rather than its normal plugin interface. Most plugins do not, but large or unusual ones sometimes do.

The honest summary: the great majority of plugins run on both, and the only way to know about a specific plugin is to load it on a test copy of your server and watch the console.

![Server console of a Rust test server showing Oxide Core loading its extensions, then compiling and loading the BadConsoleFilter, Halloween and NpcBands plugins](https://media.badgyver.com/blog/f5b6717a54-oxide-vs-carbon-rust-server-2-1300x630.png)

*What to watch on a test copy: each plugin should compile and print a Loaded plugin line without errors.*

My own plugins, [Halloween](/plugins/halloween/) and [Npc Bands](/plugins/npc-bands/) among them, are built and tested on Oxide. Carbon is designed to run them, but if you run Carbon, try them, like any plugin, on a copy of your server before wipe day.

### Performance: what is actually claimed

This is where most of the noise is, so it is worth being precise about who says what.

- **Carbon** says, on its own site and on the Facepunch wiki page about it, that it was written with performance as its first priority, uses small Harmony optimisations to cut CPU work and memory allocations, and loads hooks only when a plugin needs them, so unused hooks cost nothing.

- **Oxide**‘s owner documentation that I read makes no performance claims.

- **Neither** publishes benchmark figures in the documentation I checked: no measured frame rates, no player counts, no before and after.

Every performance statement above is the project’s description of itself, not an independent measurement. In practice the plugins you install, how many there are and how well they are written, decide far more of your server’s load than the framework underneath them.

If performance is your reason for choosing, measure it. Run the same plugins on the same map with each framework on a test server and compare server frame rate and memory under the same conditions. Carbon’s own comparison table lists a built-in profiler, which it marks as missing from Oxide.

### What comes on top of plugins

Beyond running plugins, the two projects have made different choices.

#### Oxide

- A plugin loader and nothing else, with the long-standing oxide. or o. commands: o.reload, o.grant, o.show and so on.

- Groups and permissions saved as data files in oxide/data.

- Builds for Rust’s staging branch for testing ahead of an update.

#### Carbon

- Commands with the c. prefix, such as c.reload, c.grant, c.show and c.version; aliases can be set up so some o. commands keep working.

- An in-game admin panel to install, update and configure plugins, and the option of storing permissions in an SQLite database.

- Several build types: Release, and a Minimal build that leaves out the admin panel and other extras and only runs plugins. Edge, experimental and staging builds are published too.

- Automatic groups based on a player’s admin level, set with c.autogrant_admin_group and related settings.

Whether that extra layer is a benefit depends on you. Some owners want a panel; others want the smallest possible thing between the game and their plugins, which is why Carbon itself offers the Minimal build.

### Switching from Oxide to Carbon

Carbon’s porting guide sets out the move, and the order matters:

- **Back up the whole server folder,** including oxide and the identity folder. This is also your only clean way back.

- Stop the server and switch off anything that reinstalls Oxide automatically, such as a host panel option or a line in your startup script.

- Return Rust’s files to vanilla with a SteamCMD update using validate, which removes Oxide’s patched files.

- Unpack Carbon into the server’s root folder.

- Start the server. On the first start only, Carbon copies Oxide’s config, data, language files, users and groups into its own folders and moves Oxide extensions into carbon/extensions. Then copy your plugin files into carbon/plugins if they are not there yet.

- Check every plugin in the console, and test permissions with c.show.

Oxide and Carbon cannot run on the same installation. A half-switched server, with Oxide’s patched files still in place under Carbon, is not a valid setup. Do the vanilla validation step, every time.

Carbon’s guide does not describe going back to Oxide. If you need to, restore the backup from step 1 rather than trying to undo the migration by hand.

### How to choose

Neither choice is wrong. A few situations point one way or the other:

- **Your host installs one for you and you are happy with it.** Stay. Switching costs an evening and gains you little unless you have a specific reason.

- **You depend on one large plugin or extension.** Check what its author supports and tests against, and follow that.

- **You want an in-game panel and automatic framework updates.** That is Carbon’s design.

- **You want the smallest moving parts and the most widely used platform.** That is Oxide’s, and Carbon’s Minimal build is its answer to the same wish.

- **You care about performance.** Measure both on a test server with your real plugins, as described above.

Whichever you pick, the routine around it is the same: back up before changes, test plugins on a copy, and have a plan for the first Thursday of every month.

### The checklist

- You know Oxide replaces Rust’s files and Carbon patches them in memory, and what that means on update day.

- Your important plugins and extensions checked on the framework you chose, on a test copy.

- Performance judged by your own measurements, not by forum claims.

- If switching: full backup, Oxide auto-install off, files validated to vanilla, Carbon unpacked, first start watched.

- Never both frameworks on one installation.

### Where Badgyver comes in

I make custom Rust maps and [Oxide plugins](/plugins/), and the way I install and update Oxide is in [How to install Oxide and plugins](/blog/how-to-install-oxide-and-plugins-on-a-rust-server/). If you want to try either framework with something real, [Better NPC Plus](/plugins/better-npc-plus/) and [Bad Console Filter](/plugins/bad-console-filter/) are free. Questions about running them on your setup come straight to me on Discord.
