SourceMod vs AMX Mod X vs Oxide: Compared

Almost every custom server you have ever joined ran on a modding framework you never had to install. You clicked connect, the map loaded, and suddenly there were shop menus, ranks, custom rounds and admin commands that the base game shipped without. None of that came down as a mod you installed. It was all running on the server, and your client simply obeyed.

That single idea — the server changes the rules, the client stays vanilla — is what separates a server-side modding framework from the mods you download and install yourself. It is also why a community server list is worth browsing at all. If every custom server needed a client download, nobody would ever try more than one.

This article compares the frameworks that make that possible: MetaMod:Source and SourceMod on the Source engine, Metamod and AMX Mod X on GoldSrc, Oxide/uMod and Carbon on Rust, and the rather different approach Minecraft took with Paper, Spigot and Fabric. They solve the same problem. They do not solve it the same way, and their plugins are not interchangeable in any direction.

What a server-side modding framework actually is

A game server is a program that owns the authoritative state of the match. It decides where players are, who shot whom, what the score is, which map loads next. The client is largely a renderer with input attached, plus a lot of prediction to hide latency.

A modding framework wedges itself between the game's own code and the operating system, or between the game's code and its own internal events, and gives you a place to stand. Once it is loaded, it can watch things happening — a player connecting, a round ending, a weapon firing — and it can change what happens next. That is the whole trick.

Because the server holds authority, a great deal can be changed without asking the client to do anything unusual. Damage values, weapon loadouts, respawn behaviour, team balance, round timers, chat, scoring, entity spawns, admin punishments. The client is told the results through the game's normal network protocol and renders them, blissfully unaware that a plugin decided them rather than the shipped game logic.

There is a limit, and it is worth understanding before you plan a server. Anything the client must have a file for — a new model, a new sound, a new map, a custom HUD texture — has to reach the client somehow. On Source that usually means a fast download server delivering assets over HTTP. On Minecraft it might mean a resource pack the client is prompted to accept. A framework can command the client to fetch something; it cannot conjure content into a client that has never seen it. This is why zombie mods on CS 1.6 historically leaned on models and sounds pushed to the client, and why a zombie server can feel like a different game while still technically being the game you own.

The shared architecture

Strip away the naming and the four ecosystems share a shape.

A loader attaches to the game. Something has to get code running inside, or alongside, the game server process before plugins can do anything. This is the least glamorous layer and the one most likely to break.

An abstraction layer exposes an API. Raw engine internals are hostile to work against and change constantly. The framework wraps them in named events, typed functions and stable concepts so that plugin authors write against "a player took damage" rather than against a memory offset.

Plugins load on top. Scripts or compiled modules that register for events and call the API. They are usually hot-loadable, often reloadable without restarting the server, and generally isolated enough that one broken plugin does not take the whole box down.

The differences are in how far down the stack each framework reaches, and how much stability the game's developer offers it.

MetaMod:Source and SourceMod

On Source-engine games — Counter-Strike: Source, Team Fortress 2, Left 4 Dead 2, Day of Defeat: Source, Garry's Mod, Counter-Strike 2 — the standard pairing is MetaMod:Source underneath and SourceMod on top.

MetaMod:Source is the loader. It hooks into the Source engine's plugin interface and provides a place for other plugins to attach to engine and game interfaces without each of them writing its own hooking code. On its own it does almost nothing you would notice as a player. It exists so that things above it can exist.

SourceMod is the framework everyone actually writes plugins for. It loads as a MetaMod:Source plugin and gives you an event system, an admin system with flags and immunity levels, a database layer, a translation system, timers, menus, and a compiled scripting language called SourcePawn. Plugins are written as .sp source files and compiled to .smx binaries that the server loads.

The reason SourceMod became the standard is partly technical and mostly social. A very large body of plugins exists, most of it published openly, and a great deal of it can be dropped into a server with minimal configuration. If you have played surf on CSS or CS2, a trade server on TF2, or a co-op campaign variant on Left 4 Dead 2, you have very likely been playing on SourcePawn plugins.

SourceMod also demonstrates the framework maintenance problem more clearly than anything else, because Source-engine games are not one game. Each title exposes slightly different game code, different entity names, different net messages. A plugin written for CS:S may need real work to run on CS2, and the transition between the two was not a quiet one for server operators. Extensions and gamedata files carry the per-game specifics, and when a game updates, those gamedata signatures are frequently the first thing to break.

Metamod and AMX Mod X

GoldSrc — the engine behind Half-Life, Counter-Strike 1.6 and Day of Defeat — has its own lineage, and it is genuinely separate. The loader is Metamod (not MetaMod:Source, which is a later reimplementation for a different engine), and the framework on top is AMX Mod X, itself descended from earlier work.

AMX Mod X plugins are written in Pawn, compiled to .amxx files, and loaded from a plugins list. The concepts rhyme with SourceMod — admin levels, menus, event hooks, modules that extend the core — but the API is not the same and the plugins are not portable. You cannot take an .smx and run it on AMX Mod X, or the reverse. The compiled format differs, the standard library differs, and the games underneath differ.

What is remarkable about AMX Mod X is longevity. GoldSrc servers are still running, still populated, and still being modded, decades after the engine's commercial peak. If you browse Counter-Strike 1.6 servers today you will find deathrun, jailbreak, gungame, surf and enormous zombie mods still under active development, and there is a good overview in the CS 1.6 servers guide and a more specific one for the zombie server ecosystem. Half-Life itself still has servers listed, as does Day of Defeat: Source on the newer engine.

The practical consequence for a new operator: a 1.6 server is cheap to run and there is a deep back catalogue of plugins, but much of that catalogue was written years ago by people who have moved on. You are inheriting code, not buying support.

Oxide/uMod and Carbon for Rust

Rust is a modern game with an active development studio shipping frequent updates, and its modding situation reflects that.

Oxide — which spent some years under the uMod name and is still commonly called Oxide by everyone actually running servers — is the long-standing modding framework. It patches the Rust server assembly to expose hooks, then loads plugins written in C#. Those plugins compile at runtime, which means a plugin is a readable .cs file you drop into a folder rather than a binary you build elsewhere.

Carbon is a newer alternative framework that aims for compatibility with the existing Oxide plugin ecosystem while taking a different approach internally. Both exist, both have server operators who prefer them, and the practical question for most people is which one the plugins you actually want are known to run on.

Rust's update cadence is the defining pressure here. The game ships a monthly forced update, and every one of those updates can invalidate the hooks the framework relies on. That produces a rhythm that Rust operators know intimately: the game updates, the framework does not work yet, servers wait, the framework ships a patched build, plugins that depended on changed behaviour get fixed over the following days. Watching that cycle play out is instructive — the Oxide 2.0.7676 patch notes are a reasonable example of what one of these releases actually contains and how quickly it has to follow the game.

If you are weighing whether to run modded at all, that maintenance rhythm is most of the answer, and the trade-offs are laid out in modded versus vanilla Rust servers. Modded Rust can be enormously popular — browse the Rust server list and the variety is obvious — but you are signing up for a monthly maintenance window you do not control.

Minecraft solved it by forking the server

Minecraft went a different way, and the difference is structural rather than cosmetic.

Instead of attaching a loader to the official server binary, the Minecraft community rebuilt the server. Bukkit defined a plugin API. CraftBukkit implemented it against the game. Spigot forked that for performance. Paper forked Spigot for more performance and more API surface. Purpur forks Paper again for configurability. Each is a server you run instead of the official one, not a mod you load into it.

Fabric and Forge take yet another route: they are mod loaders that modify the game more deeply and typically require the client to install the same mods. That is the important split. A Paper plugin is server-side and players join with a vanilla client. A Fabric mod may well require the player to install it too, which changes who can join and how you advertise.

That distinction has real consequences for how you list a server. A Paper server can accept anyone; a heavily modded Fabric server needs the player to do work before connecting, and any listing that hides that fact will collect frustrated players who bounce. The differences between the server softwares are covered properly in Paper, Purpur and Fabric compared, and if you are starting from nothing there is a walkthrough on running a Minecraft server for free. The Minecraft server list shows how varied the results get.

Minecraft's approach has one clear advantage: the API belongs to the community, not to a hook into someone else's binary, so it is documented and reasonably stable across a major version. It has one clear cost: you are running a fork, and forks inherit bugs and diverge in behaviour. A plugin tested on Paper may misbehave on a fork of a fork.

Why plugins do not travel

People new to server hosting ask this constantly, and the answer is worth spelling out.

A plugin is not a description of a feature. It is code compiled against a specific API, calling specific functions, hooking specific events, reading specific entity properties, in a specific language. A SourcePawn plugin calls SourceMod natives. A Rust plugin calls Oxide hooks in C#. A Paper plugin implements Java interfaces from the Bukkit API lineage. There is no shared layer beneath them, because the games beneath them are different programs written by different companies in different languages.

Even within a family, portability is limited. SourceMod runs on many Source games, but a plugin that manipulates weapons in CS:S has nothing sensible to do in Garry's Mod, where the gamemode itself is Lua and the entire concept of a weapon is defined by the gamemode rather than the engine. Garry's Mod is its own case: it ships a Lua scripting layer as a first-class feature, and its gamemodes — DarkRP, TTT, sandbox variants — are effectively separate games sharing a physics engine. If that is unfamiliar territory, Garry's Mod gamemodes explained covers the ground, and the roleplay category shows how much of the population sits in one gamemode. FiveM does something comparable for GTA V, with its own resource system and its own script ecosystem, which is again incompatible with everything above — the FiveM server list is entirely its own world.

So when you choose a framework, you are choosing an ecosystem you will stay in. Migrating a server between engines does not mean porting plugins. It means finding equivalents, or writing them.

The maintenance burden nobody mentions first

Here is the pattern that catches new operators.

The game updates. The framework breaks, because it depends on details the game's developers never promised to keep stable — memory signatures, method names, class layouts. Your server either fails to start or starts without plugins. Players arrive, find a vanilla server where a modded one used to be, and leave.

How bad this gets depends almost entirely on the game's update policy. Rust's monthly forced update makes this a scheduled event. Source-engine games update less often but occasionally break things badly and without warning. Minecraft's version bumps are predictable in timing but require the server software and every plugin to catch up, which can take weeks for less popular plugins. GoldSrc barely changes at all, which is a real advantage of an old engine.

What you can control:

Keep a copy of the server that works. Before applying a game update, make sure you can go back. This is boring advice and it is the advice that saves servers.

Do not run a plugin you cannot read or replace. Every plugin is a dependency, and an unmaintained plugin doing something clever with internals is the one that will break first and be hardest to fix.

Have a plan for the downtime window. Players do not have infinite patience, and a server that is down for a week after every game update trains its regulars to go elsewhere. Communicating in advance costs nothing and holds a community together far better than silence. Some of the reasons a server empties out are more mundane than technical, and why nobody joins your server covers those.

Judging whether a framework is still alive

Before you build anything on a framework, check whether anyone is still maintaining it. Marketing pages will not tell you. These will.

Look at commit dates on the actual repository. Not the website, not the forum, the code. A framework that has not had a commit since the last major game update is a framework that will not survive the next one.

Check how quickly it responded to the most recent game update. This is the single best predictor. Find the game's last significant patch, then find the framework release that followed it. Hours, days, weeks — that gap is what you will be living with.

Count the maintainers, not the users. A project with one active maintainer is one life change away from being abandoned, regardless of how many servers run it. Several people merging changes is a much better sign than a large user count.

Read the issue tracker rather than the changelog. Open issues that nobody has replied to for months tell you more than a tidy release note. Look for whether maintainers answer, not whether they fix everything.

Check whether plugin authors are still publishing. A framework is only as useful as what runs on it. If the plugin forum's newest threads are years old, the ecosystem has moved even if the core is technically maintained.

Be sceptical of forks that promise everything. Alternative frameworks appear regularly, often with real merit. The question is not whether the fork is better designed. It is whether it will still be here in two years, and whether the plugins you need have been tested on it.

If a framework fails several of these checks, you can still run it. Plenty of people happily run old software on stable old engines. Just make the choice knowingly, rather than discovering it the first time something breaks.

Choosing, practically

Pick the game first. The framework follows from it, and there is rarely a meaningful choice within a game — SourceMod for Source, AMX Mod X for GoldSrc, Oxide or Carbon for Rust, the Paper family for server-side Minecraft. Rust is the main place where a genuine decision exists, and even there the deciding factor is usually which framework your intended plugins support.

Then be honest about your appetite for maintenance. A GoldSrc server can sit for months untouched. A modded Rust server will want your attention every month, without fail. A Minecraft network on a fork of a fork will want attention whenever any layer beneath you moves.

And whatever you build, remember why the server-side model matters commercially: players can try you instantly. No download, no launcher, no install. They see an entry in a list, they click, and thirty seconds later they are either enjoying themselves or gone. That is the entire funnel. Browsing the full server list makes the competition clear, and there is broader advice on finding good servers in 2026 that reads just as usefully from the operator's side.

FAQ

Do players need to install anything to join a modded server? For server-side frameworks, no. SourceMod, AMX Mod X, Oxide and Paper all run entirely on the server, and players connect with an unmodified game client. The exception is content the client needs a file for — custom models, sounds or maps — which is delivered by a download server or resource pack rather than a manual install. Client-side mod loaders such as Fabric and Forge are a different case, and often do require the player to install matching mods.

Can I run a SourceMod plugin on AMX Mod X, or the other way round? No. They target different engines, use different compiled plugin formats, and expose different APIs. The scripting languages are related historically but the standard libraries and natives are not compatible. You would need to rewrite the plugin.

Is Oxide the same thing as uMod? They are the same project lineage. The uMod name was used for a period, and much of the community continued calling it Oxide throughout. If a plugin says it is for uMod, it is for the Rust modding framework people generally call Oxide.

What is the difference between Carbon and Oxide for Rust? Both are modding frameworks for Rust servers, and Carbon aims to remain compatible with the existing Oxide plugin ecosystem while working differently internally. The practical question is whether the specific plugins you want to run are confirmed working on the one you choose. Check the plugins first, then pick.

Why does my modded server break every time the game updates? Because the framework depends on internal details of the game server that the developers never committed to keeping stable. When those details change, the hooks miss. This is normal and expected; the fix is to wait for the framework's patched release and then update plugins that relied on changed behaviour. Keeping a known-good backup before updating is the difference between an hour of inconvenience and a lost weekend.

Is an older framework like AMX Mod X a bad choice in 2026? Not automatically. GoldSrc barely changes, which means an old framework on a stable engine can be a low-maintenance setup with a huge back catalogue of plugins. The risk is support: many of those plugins are unmaintained, so you should be willing to read and fix code yourself. Judge it by the same checks as anything else — recent commits, active maintainers, and whether people are still publishing plugins for it.

Should I choose the framework or the game first? The game, always. Your framework is largely determined by the game you pick, and your players care about the game, not the technology underneath it. Decide what you want to run, then accept the maintenance profile that comes with it.