How to Install Oxide and Plugins on a Rust Server (2026)

A fresh Rust server is vanilla: it runs the game exactly as Facepunch ships it, and nothing you download will change that until a modding framework is installed underneath. Oxide is the oldest and most widely used one. Installing it takes a few minutes; keeping it working takes a habit, because every Rust update, including the small hotfixes, undoes it.

Download Oxide from its official GitHub releases, copy it over your server files with the server stopped, and drop plugins into oxide/plugins. Then remember the part people forget: every time Rust updates through SteamCMD, Oxide’s files are replaced and you must install the matching Oxide build again.

This guide is for server owners installing Oxide for the first time in 2026, or tidying up an install they inherited. It covers where to get the right build, the folders Oxide creates and what goes in each, installing and reloading plugins, the permission commands every owner needs, and the routine for update day. My two free plugins, Bad Console Filter and Better NPC Plus, serve as the examples.

What Oxide is and what it changes

Oxide is an open-source modding framework, published under the MIT licence on GitHub. It replaces some of the Rust server’s own program files with patched copies that call out to plugins at hundreds of moments in the game: a player connecting, an entity taking damage, a crate being looted. Those moments are called hooks.

Plugins are plain C# source files ending in .cs. Oxide compiles them on the server itself, so you never handle compiled code for a plugin. The first time a plugin is compiled, Oxide downloads its compiler, Oxide.Compiler.exe, into the server folder, so the server needs outgoing internet access on that first start.

Get the right build

The official source is the Oxide.Rust releases page. Take the newest release that is not marked Pre-release, and pick the file for your operating system under Assets:

• Oxide.Rust.zip for a Windows server.
• Oxide.Rust-linux.zip for a Linux server.

Each release names the Rust build it was made for. The release of 7 November 2026, version 2.0.7900, is a patch for that day’s Rust hotfix and targets Rust build 2636.290.1. The two before it came out on 5 and 6 November, for the monthly update and the first hotfix. Three Oxide releases in three days is normal in the week of an update, and it is the clearest picture of what keeping Oxide current means.

Many hosting panels have an “install Oxide” button. It does the same thing; what matters is that it installs the build matching the Rust version your server is running.

Install it step by step

1. Stop the server. Installing while it runs can leave files half replaced.
2. Extract the zip into a temporary folder on your own computer, not straight into the server.
3. Look inside: the zip holds a single folder, RustDedicated_Data, with Managed inside it. Copy that RustDedicated_Data folder into your server’s main folder, the one that contains RustDedicated.exe (or RustDedicated on Linux), and let it overwrite the existing files.
4. Start the server with your usual startup line.
5. When it has finished loading, type oxide.version in the server console, or in the F1 console in game as an admin. A version number means Oxide is running.

On the first start Oxide creates an oxide folder next to RustDedicated_Data. Some hosts rename it umod; it is the same thing.

The oxide folder, one by one

Everything you manage day to day lives in that folder:

• oxide/plugins – the .cs files. Put a plugin here to install it, remove it to uninstall it.
• oxide/config – one JSON settings file per plugin, created the first time the plugin loads. This is where you change how a plugin behaves.
• oxide/data – what plugins remember: player records, stored positions, generated files. Oxide’s own groups and permissions are saved here too, as oxide.groups.data and oxide.users.data. Back this folder up.
• oxide/lang – the messages plugins show players, one folder per language, so you can reword or translate them without touching code.
• oxide/logs – Oxide’s daily log files. When a plugin fails to compile, the reason is in here.
• oxide/oxide.config.json – Oxide’s own settings, including the names of the default groups and whether plugin files are watched for changes.

One thing is not in this folder: extensions. These are compiled .dll add-ons, such as the RustEdit extension many custom maps need. Oxide’s documentation puts them in RustDedicated_Data/Managed, and most of them only load on a restart, so stop the server before adding or updating one.

Installing a plugin: a worked example

Bad Console Filter is a good first plugin because it needs nothing else and shows the whole cycle. It hides console messages you choose, such as the endless navigation warnings, and removes NPCs that are stuck producing them.

1. Copy its .cs file into oxide/plugins while the server is running. Oxide notices the new file, compiles it and prints a line saying the plugin was loaded.
2. Open the file it has just created, oxide/config/BadConsoleFilter.json. Messages to hide go in the IgnoredLogStrings list; part of a sentence is enough.
3. Save it, then type o.reload BadConsoleFilter. The plugin restarts and reads the new settings.

The worked example on a real test server: the config file you edit, and the log lines that confirm the plugin restarted with it.

That third step is the one people miss. Editing a config file does nothing to a plugin that is already running until it is reloaded. Replacing the .cs file with a new version, on the other hand, reloads it automatically.

Some plugins build on others. Better NPC Plus turns the NPC spawners of a custom map into spawn points for the BetterNpc plugin, so it needs BetterNpc and NpcSpawn installed as well, and the files it generates go into oxide/data/BetterNpc/Custom/. If a plugin lists requirements on its page, install them first; otherwise it will load but do nothing, or report that something is missing in the console.

The commands you will use every week

• oxide.plugins – lists every loaded plugin and its version.
• oxide.load Name and oxide.unload Name – start or stop a plugin without deleting its file.
• oxide.reload Name – stop and start it again, after a config change.
• oxide.version – which Oxide build is running.

Every command also works with the short prefix o., so o.reload and oxide.reload are the same. The name is the plugin’s file name without .cs.

Permissions: oxide.grant and groups

Most plugins do not let everybody use every feature. They register permissions, usually written pluginname.something, and you hand them out to players or groups. Oxide creates two groups by itself: default, which every player who connects joins, and admin. Anyone you have made an owner with Rust’s ownerid command (saved with server.writecfg) is placed in admin automatically.

oxide.grant group admin pluginname.use
oxide.grant user PlayerName pluginname.use
oxide.group add vip
oxide.usergroup add PlayerName vip
oxide.grant group vip pluginname.use
oxide.revoke user PlayerName pluginname.use

To see what exists, oxide.show perms lists every registered permission; oxide.show user PlayerName and oxide.show group vip show what someone has and why. Granting to groups rather than to individual players keeps things manageable: when a VIP’s time runs out, you remove them from one group instead of hunting down ten permissions.

Oxide accepts wildcards, such as oxide.grant group admin * for every permission. Use that on admin if you like, but never on default: it would give every player who joins every admin feature of every plugin you install from then on.

Keeping Oxide working after every Rust update

Oxide works by replacing Rust’s own files, and a Rust update through SteamCMD puts Facepunch’s originals back. After any update, the monthly one or a hotfix, the server starts vanilla: plugins do not load and nobody gets an error message saying so in game.

The routine on update day:

1. Wait for the matching Oxide release. On 5 November 2026 it was published at 18:33 UTC, before Rust’s own update at 19:00. Hotfixes are not announced in advance, so on those days the Oxide build follows the hotfix rather than waiting for it.
2. Stop the server and update it: steamcmd +force_install_dir <server folder> +login anonymous +app_update 258550 -beta public validate +quit. Oxide’s documentation recommends naming the public branch.
3. Copy the new Oxide over it, exactly as in the first install.
4. Start, run oxide.version and oxide.plugins, and read oxide/logs for plugins that failed to compile against the new game. A plugin that broke with an update needs a new version from its author.

If your startup script runs SteamCMD before launching the server, which many tutorials suggest, it quietly returns the server to vanilla on every restart once Rust has updated. Either install Oxide again right after that step, or update by hand on update days.

Oxide also publishes builds for Rust’s staging branch, the test version where next month’s changes appear first. Owners with many plugins can run a second, private staging server to see what will break before wipe day.

The checklist

• Oxide downloaded from the official GitHub releases, the right zip for your system, not a pre-release.
• Installed with the server stopped, oxide.version answers.
• You know where plugins, config, data, lang and logs are, and that extensions go in RustDedicated_Data/Managed.
• Config changes followed by o.reload.
• Permissions granted to groups, nothing wildcarded on default.
• oxide/data in your backups.
• A routine for every Rust update: SteamCMD, then Oxide, then check the logs.

Where Badgyver comes in

I write Oxide plugins for Rust as well as custom maps, and I check them on my own Oxide test servers when Rust updates. Bad Console Filter and Better NPC Plus are free, so they are an easy way to practise everything above on your own server. If you would rather read about the alternative framework first, I compared the two in Oxide vs Carbon.