Oxide is a server-side plugin framework, best known from Rust, that also runs on 7 Days to Die dedicated servers. It swaps the game's main code file for a patched copy, and small C# plugins then react to what happens on the server: players joining, chat, console commands, damage, deaths, air drops and saves. uMod is the name of the site where its plugins are listed, so to a server owner Oxide and uMod are the same thing. Players install nothing. This guide covers what Oxide changes on a V3.3 server, what it is used for, how it differs from the game's own mods, and a real V3.3 server it hung at startup in October 2026. File names, numbers and log lines here come from Oxide's source code, the V3.3 server files (build 25661908) and Oxide's own logs.
TL;DR
Oxide is open source (MIT) and runs only on the server. Players join with the normal game.
It replaces 7DaysToDieServer_Data/Managed/Assembly-CSharp.dll with a patched copy that has 23 hook points, and adds eight Oxide DLLs next to it.
A plugin is one C# file in oxide/plugins. Oxide compiles it on the server with Oxide.Compiler, a separate program of about 128 MB that it downloads on the first start.
A game update or a file validation restores the stock DLL, and Oxide stays off until the build made for that game version is installed again.
Oxide writes two things into the server's root folder: its oxide folder and the Oxide.Compiler file. If it cannot create the folder, the start can hang; if it cannot save the compiler, no plugin ever loads.
You do not need Oxide to mod the game. 7 Days to Die has its own mod loader, and the V3.3 server ships three mods of its own.
Oxide is an open-source modding framework for game servers. A shared core does the common work, loading plugins, permissions, configs and logs, and each game gets its own extension. The 7 Days to Die extension, Oxide.SevenDaysToDie, has been on GitHub since December 2017 under the MIT license. Rust is where Oxide is best known, and the patch files that list where Oxide hooks into each game show the gap: Rust's has 869 hook points, 7 Days to Die's has 23.
The naming is the confusing part. The framework still calls itself Oxide everywhere a server owner looks: the log says Loading Oxide Core v2.0.4143..., the files are named Oxide.*.dll and the console commands start with oxide. uMod is umod.org, the site where Oxide plugins are listed and where the 7 Days to Die extension has its project page. As of October 2026, oxidemod.com, the site of Oxide B.V., says that uMod.org is becoming OxideMod.com.
Oxide itself is not a separate program next to the game: it runs inside the server process, which is why installing it means changing the game's own files. It changes them in two places, then creates a folder of its own on the first start.
Most of the server's game code lives in one file, 7DaysToDieServer_Data/Managed/Assembly-CSharp.dll. Oxide ships its own build of that file: the same game code with calls into Oxide inserted at chosen places, the hooks. On V3.3 the stock file is 11,697,152 bytes and Oxide's patched copy 11,903,488 bytes. These are its 23 hook points, in 17 game methods:
| When | Hook points | What a plugin can do |
|---|---|---|
| A player asks to join | IOnUserApprove | Let them in or kick them |
| A player connects, spawns, has spawned, disconnects | OnPlayerConnected, OnPlayerSpawn, OnPlayerSpawned, OnPlayerDisconnected | React: greet, log, count playtime |
| A chat message is sent | IOnPlayerChat | Answer chat commands, block the message |
| A console command runs, from the server console or from a player | IOnServerCommand (2 points), OnPlayerCommand | Log it or block it |
| A player, zombie or animal takes damage | OnEntityTakeDamage (2 points) | Block the damage |
| A player, zombie or animal dies | OnEntityDeath | React: kill feeds, stats |
| An entity spawns in the world | OnEntitySpawned | React: log, count |
| A player gains XP | OnExperienceGained (2 points) | React: track progression |
| An air drop is sent | OnAirdrop | React: announce it |
| Someone tries to open something locked | CanUseLockable | Allow or deny it |
| The game saves | OnServerSave (2 points) | React: back up, flush data |
| The server starts and stops | Initialize, InitLogging, IOnServerInitialized, IOnServerShutdown | Oxide starts itself, then tells plugins |
The same Managed folder gets Oxide's own libraries: Oxide.Core (the framework), Oxide.CSharp (the C# plugin loader, which talks to the compiler), Oxide.SevenDaysToDie (the game extension), Oxide.Unity, Oxide.Common, Oxide.References, and Oxide.MySql and Oxide.SQLite, which let plugins keep data in a database. On a V3.3 server in October 2026 the log showed Oxide Core 2.0.4143 with the 7 Days to Die extension 2.0.4058, the CSharp extension 2.0.4149 and Unity 2022.3.62f2, the Unity version the game runs on.
On the first start Oxide creates a folder named oxide in the folder the server was started from, normally the server's root folder next to 7DaysToDieServer.x86_64 or 7DaysToDieServer.exe. Inside it:
plugins: the plugins, one .cs source file each.config: each plugin's settings, as a JSON file.data: what plugins store, plus Oxide's own users, groups and permissions (oxide.users.data, oxide.groups.data).lang: plugin messages, in a folder per language.logs: Oxide's log and the compiler's log.oxide.config.json: Oxide's settings, among them the chat command prefix (/), the two default groups (default for every player, admin for admins), plugin reloading, the compiler's idle shutdown, and Oxide's own remote console, which is off by default.A plugin is one C# source file, and Oxide compiles it on the server. The compiler is not among Oxide's files: on the first start Oxide fetches it from downloads.oxidemod.com (the Linux build, linux-x64.Compiler, was 127,842,362 bytes in October 2026), saves it as Oxide.Compiler in the server's root folder (Oxide.Compiler.exe on Windows) and makes it executable. On every later start Oxide compares the file's checksum with the download server's and replaces it only when there is a newer one.
Only the compiler runs as a separate process next to the game. It is started when plugins need compiling, writes its own log to oxide/logs, and shuts itself down after 60 seconds with nothing to do; the Plugin Compiler section of oxide.config.json changes that.
Oxide also watches the plugins folder. A new .cs file is compiled and loaded, an edited one is reloaded, and a deleted one is unloaded, with no server restart. That is the PluginWatchers option, on by default.
A plugin can be written for 7 Days to Die only, or against Covalence, Oxide's universal API, so that one plugin runs on every game Oxide supports. The log line Using Covalence provider for game '7 Days to Die' is that layer starting.
Oxide also brings its own permission system, separate from the game's serveradmin.xml: plugins register permissions, and you grant them to players or to groups. These built-in commands manage it, typed in the server console:
| Command | Other names | What it does |
|---|---|---|
oxide.plugins | o.plugins, plugins | Lists the loaded plugins |
oxide.load, oxide.reload, oxide.unload | o.load, plugin.load and so on | Loads, reloads or unloads a plugin by name |
oxide.grant, oxide.revoke | o.grant, perm.grant and so on | Gives a permission to a player or a group, or takes it away |
oxide.group, oxide.usergroup | o.group, perm.group and so on | Creates and removes groups, puts players in them |
oxide.show | o.show, perm.show | Shows who holds which permission |
oxide.lang, oxide.save, oxide.version | o.lang, o.save, o.version | Sets the language, saves Oxide's data, shows the versions |
Twenty-three hook points is a small surface, so on 7 Days to Die plugins work at the edges of the game rather than inside it: who gets in, what they say and type, what admins can see, and who may open what. The game's content, its items, zombies and world, stays the territory of mods.
Loaded plugin Tebex v2.0.13 by Tebex. The owner sells perks in a web shop, and the plugin carries out each purchase on the server by running server commands.What a plugin cannot do is give players new models, textures, sounds or icons. Those have to be in each player's game, so new content still needs a mod.
7 Days to Die loads mods by itself, and that covers most of what people mean by modding the game. Each mod is a folder in Mods with a ModInfo.xml. XML modlets patch the game's config files with XPath, and code mods are .NET DLLs that implement the game's IModApi interface, usually with Harmony to patch game methods. The Fun Pimps ship this setup with the game: the V3.3 server comes with three mods in its Mods folder, 0_TFP_Harmony (the Harmony wrapper), TFP_CommandExtensions ("Additional commands for server operation") and Xample_MarkersMod, an example mod for the web map.
| Oxide plugin | Game mod | |
|---|---|---|
| Where it lives | oxide/plugins, one .cs file | Mods/<name>/, with a ModInfo.xml |
| Changes the game's own files | Yes, Assembly-CSharp.dll | No |
| Compiled | On the server, by Oxide.Compiler | By the author before release; XML needs no compiling |
| Reloads without a restart | Yes, when the file changes | No, mods load when the server starts |
| After a game update | Off until the matching Oxide build is installed again | Still loads; may need a new version if the game changed what it touches |
| Players install it too | Never | When it adds models, textures, icons or other assets |
| Typical use | Admin tools, permissions, chat, join rules, shop delivery | Content, balance, UI, overhauls |
The two can run on one server. Oxide's patch inserts its hooks into 17 game methods and leaves the rest of the game code alone, the mod loader included, so the Mods folder keeps loading. The mod installation guide covers the game's own route.
The patched Assembly-CSharp.dll is a full copy of the game's code for one game version, and that has two consequences.
oxide folder stay where they are, with every plugin, config and permission, but nothing calls them any more. The server simply runs without Oxide, and the Oxide lines are missing from its log.Oxide keeps pace. Its GitHub history shows patches for V3.0.0 on 29 June 2026, V3.0.1 on 13 July, V3.1.0 on 27 July and V3.2.0 on 26 August, each on the day that version came out, and for V3.3.0 on 6 October, the day after V3.3 went stable. After each game update the current Oxide build has to go on again.
The compiler is not tied to the game version. It updates itself by checksum, and the copy one server downloaded in October 2026 had the same MD5 checksum as the one another server had downloaded in July 2025.
In October 2026 a server owner uploaded Oxide to a V3.3 dedicated server over FTP. The upload did what an Oxide install does: it replaced Assembly-CSharp.dll and added the Oxide DLLs. The next start never finished. The server process sat at 100% CPU, the game never came up, and restarting changed nothing.
The cause was Oxide's first step: creating its oxide folder in the server's root folder. On that server the server process could read the root folder but was not allowed to write to it. Oxide's start failed on the folder, and instead of exiting, the server hung. Restoring the stock game files removed Oxide; uploading it again brought the hang straight back.
With an oxide folder the server could write to, the next start got through: Oxide Core 2.0.4143 and its extensions loaded and the game came up. Then the second write failed, because Oxide tried to save its compiler into the same root folder:
[Info] [CSharp] Downloading Oxide.Compiler. . .
[Error] Unexpected error occurred while trying to download Oxide.Compiler, please manually download it from https://downloads.oxidemod.com/artifacts/Oxide.Compiler/master/linux-x64.Compiler and save it here ...A server in that state looks healthy, which makes it easy to miss: the game runs and Oxide is loaded, but no plugin can ever load, because nothing can compile it. The fix was of the same kind: an empty Oxide.Compiler file in the root folder that the server could write to. On the next start Oxide saw a file whose checksum is that of an empty file, downloaded the real compiler over it and made it executable:
[Info] [CSharp] Checking for updates for Oxide.Compiler | Local MD5: d41d8cd98f00b204e9800998ecf8427e ...
[Info] [CSharp] Downloaded newer version of Oxide.Compiler | Remote MD5: a143ee6da12e3c79696bd95d30a6330d
[Info] File permissions set for Oxide.Compiler
[Info] Using Covalence provider for game '7 Days to Die'
[Info] Loading plugins...With the compiler in place, plugins dropped into oxide/plugins can be compiled and loaded.
oxide folder on the first start, and the Oxide.Compiler file right after. When the server runs as a user that cannot write there, the first failure can hang the start and the second quietly stops every plugin.Oxide itself is open source, so what the core, the compiler service and the 7 Days to Die extension do can be read on GitHub. The part to think about is the plugins. A plugin is C# code compiled and run inside the server process, with the same rights as the server: it can read and write the files the server can, make web requests, and see what the game knows about players, IP addresses included. Oxide also goes online beyond the compiler download: when a plugin asks for the server's public address, Oxide looks it up from a public IP lookup service unless the address was given on the command line. Run plugins whose source you have read or whose author you trust, and read oxide/logs after adding one.
For a server owner, yes. The framework is Oxide: the server log says Oxide Core and the files are named Oxide. uMod is umod.org, the site where Oxide plugins are listed, and oxidemod.com now says uMod.org is becoming OxideMod.com.
No. Oxide and its plugins run only on the server, and players join with the normal game.
Yes. Oxide's patch for V3.3.0 is dated 6 October 2026, the day after V3.3 went stable, and a V3.3 server ran Oxide Core 2.0.4143 with the 7 Days to Die extension 2.0.4058 in October 2026.
On the server in this guide, Oxide could not create its oxide folder because the server process was not allowed to write to its root folder, and the start hung at 100% CPU. Make sure the user the server runs as can write there: the oxide folder and the Oxide.Compiler file both go into that folder.
No. An update or a SteamCMD validate restores the game's own Assembly-CSharp.dll and Oxide stops loading. Plugins, configs and data in the oxide folder are kept; installing the Oxide build for the new game version switches it back on.
No. The game loads mods from its own Mods folder, XML modlets and Harmony code mods alike. Oxide is for server plugins: permissions, chat, join rules, logging and shop delivery.
Yes. Oxide and its 7 Days to Die extension are open source under the MIT license.
SevenDaysToDie.opj with its 23 hook points, the hook handlers, the built-in commands, and the patch history for each game release.oxide.config.json, plugin reloading, the compiler download, checksum check and idle shutdown. Oxide.Rust's Rust.opj for the 869 Rust hook points.7DaysToDieServer_Data/Managed/Assembly-CSharp.dll (11,697,152 bytes) and the three mods in Mods.