Oxide or Carbon? Picking a Rust plugin framework

Every Rust admin eventually asks this, usually a week before a wipe when performance is on their mind. The short version: Carbon is faster and Oxide is safer, they run substantially the same plugin ecosystem, and switching between them is a restart rather than a migration.

What they actually are

Both are modding frameworks that hook into the Rust server and load C# plugins. Oxide (uMod) has been the standard for a decade. Carbon is a newer reimplementation, built for performance, that deliberately keeps API compatibility with Oxide so existing plugins mostly just work.

That last point is what makes the decision low-stakes. You are not choosing an ecosystem; you are choosing a runtime for the same plugins.

Where Carbon wins

• Startup time. Carbon compiles plugins in parallel and caches the results. On a server with fifty plugins this is the difference between a 90-second boot and a 20-second one — which matters a lot on wipe day when you are restarting repeatedly.
• Memory. Noticeably lower in most setups, largely because of how it handles compilation and hook allocation.
• Hook performance. Carbon only wires up hooks that plugins actually subscribe to. Oxide historically fired everything. On a heavily plugged server this is measurable.
• Hot reload that works. Editing a plugin and reloading it is reliable enough to actually iterate with.

Where Oxide wins

• Ten years of documentation. Every problem you will hit has been hit before and written up somewhere. That is worth more than people credit.
• Plugin authors target it first. Compatibility is good but not universal — a plugin doing something unusual with internals may need a Carbon-specific build.
• It is what support expects. If you post a problem in a Rust admin community, the answers assume Oxide.
• Stability under updates. Both break on a Rust update; Oxide historically gets fixed fastest, because more people are waiting on it.

The honest recommendation

Running your first server? Oxide. You will be searching for answers constantly and they will all assume Oxide. The performance difference will not be your limiting factor.

Running fifty-plus plugins, or restarting often? Carbon. The startup time alone justifies it, and the memory saving is real.

Running something unusual — heavy custom plugins, an economy with a database, a plugin you wrote yourself? Test on Carbon before committing. Most things work. Some do not.

Switching is cheap

On our Rust plans both are one-click installs and they keep separate configuration directories, so switching does not overwrite anything. Install Carbon, start the server, see what breaks; if something does, switch back and your Oxide config is exactly as you left it.

That is worth doing on a test server before wipe rather than on the night. We will spin one up for a few days alongside your main server if you ask — it is the kind of thing a 72-hour refund window is for.

What neither of them fixes

Framework choice will not save a server that is struggling for other reasons. Before you blame Oxide:

• Check CPU steal time. If it is above a few percent, you are on an oversold node and no framework will help. It should be zero.
• Profile your plugins. One badly written plugin doing synchronous work in a per-player hook will cost you more than the entire framework overhead.
• Look at entity count. Three weeks into a wipe with decay disabled, the server is simulating vastly more than it was on day one.

Our write-up on wipe-day performance goes through those in the order worth checking them.