RedM roleplay frameworks: VORP vs RSG

For a new RedM roleplay server the choice is between VORP and RSG. VORP is the longer-established RedM framework, with its own architecture and the largest set of RedM-native resources built around vorp_core. RSG is derived from QBCore and feels immediately familiar to anyone who has run a QBCore or Qbox FiveM server, with heavy use of ox_lib and the QBCore way of structuring jobs, items and player data. Both need a MySQL-compatible database through oxmysql, both run on the same FXServer, and neither can run the other's resources. Pick VORP if you want the deepest pool of existing RedM resources; pick RSG if your developers already know QBCore. Then stay with it, because moving later means a character wipe. This guide compares them properly and covers installing either one.

What a framework does on RedM#

FXServer gives you a world with nothing in it: no characters, no money, no inventory, no jobs. A framework is the shared layer that provides those, and that every other resource talks to.

• Players and characters. Identifiers mapped to accounts, several characters per account, character creation, appearance.
• Inventory and items. What exists, who holds it, weights and limits, usable items.
• Money. Usually cash and gold on RedM, plus whatever banking resources add.
• Jobs and groups. Who is a sheriff, a doctor, a rancher, and what that permits.
• An API. Functions and events other resources call to read and change all of the above.

The API is the part that locks you in. A job resource written for VORP calls VORP functions to give items and pay wages; it cannot do that on RSG without being rewritten. That is why the framework choice is really a choice of ecosystem. The FiveM version of the same decision, with the same reasoning, is in FiveM frameworks compared.

VORP and RSG side by side#

Neither is objectively better. They are two styles with two communities, both actively maintained at the time of writing. Check each project's repository for recent commits and releases before you commit, because RedM is a small scene and the balance shifts.

Questions to answer before choosing

A framework decision made on reputation alone tends to be revisited six months later. Answer these first, and the choice usually makes itself:

1. Who will write code? If nobody on the team writes Lua, the size of the existing resource pool matters most, and you will be assembling rather than building. If your developers come from QBCore, RSG costs them least.
2. Which resources must you have? List the five or ten systems your server is built around - a specific inventory feel, a horse system, a law and bounty system, a particular economy - and check which framework the best available versions target.
3. Which paid resources are you planning to buy? Paid RedM scripts usually state framework support. Check that the version you need supports the framework version you will run, not just the framework name.
4. How much documentation do you need? Read both projects' documentation for an hour before deciding. The one your team finds easier to follow is the one you will maintain more easily.
5. How active is the project right now? Look at recent commits, open issues and release notes for the core and its main resources. A framework that has stalled is a framework you will fork.

Write the answers down. When someone proposes switching a year from now, you will want to know why you chose what you did.

VORP#

VORP is a collection of resources around vorp_core: vorp_inventory, vorp_character for creation and appearance, vorp_menu, admin tools and utilities, and a long list of community job and system resources written against them. It has existed for most of RedM's life, so most RedM-native scripts you will find - free or paid - either target VORP or offer a VORP version.

A resource gets the core object and works with the player's active character:

local Core = exports.vorp_core:GetCore()RegisterNetEvent("ranch:sellMilk", function()    local src = source    local user = Core.getUser(src)    if not user then return end    local character = user.getUsedCharacter    -- validate on the server, then pay    character.addCurrency(0, 5.0)   -- 0 = cashend)

Older VORP resources fetch the core with TriggerEvent("getCore", function(core) ... end); current ones use the export. If you mix old and new resources, both styles will appear in your codebase. Read the VORP documentation for the exact API of the version you install, because function names and currency types have changed between major versions.

What tends to suit VORP: servers that want to assemble a lot of existing RedM content quickly, owners who are not developers and will rely on what the community has already built, and teams who prefer an API designed around RDR2 concepts rather than adapted from GTA V roleplay.

RSG#

RSG takes QBCore's structure - a core with shared data for jobs, items and gangs, a PlayerData table per player, callbacks, and functions on the player object - and adapts it to RedM. If you have written for QBCore, RSG code reads naturally:

local RSGCore = exports['rsg-core']:GetCoreObject()RegisterNetEvent("ranch:sellMilk", function()    local src = source    local Player = RSGCore.Functions.GetPlayer(src)    if not Player then return end    if Player.Functions.RemoveItem("milk", 1) then        Player.Functions.AddMoney("cash", 5)    endend)

RSG leans on ox_lib for menus, notifications, zones, callbacks and progress bars, so much of the UI and interaction code is shared with the wider Overextended ecosystem. The rsg- resources cover inventory, characters, appearance, jobs and the rest of a roleplay base.

What tends to suit RSG: teams with QBCore experience, servers moving from FiveM to RedM with developers who want their habits to carry over, and owners who prefer ox_lib's components over bespoke ones.

What has to sit underneath both#

Whichever you choose, the foundation is the same:

1. FXServer with `set gamename rdr3` and a current RDR2 game build enforced. RedM server setup covers the config.
2. OneSync on. Both frameworks assume it.
3. oxmysql, started before anything that touches the database.
4. `ox_lib`, required by RSG and by many VORP-era resources too.
5. The framework core, then its own resources, then everything built on it.

The database connection string goes in server.cfg with set, never sets:

set mysql_connection_string "mysql://user:password@host:3306/redm?charset=utf8mb4"set mysql_slow_query_warning 150ensure oxmysqlensure ox_lib# framework core and its resources follow, in the order its docs give

mysql_slow_query_warning makes oxmysql print every query slower than 150 ms, which is the cheapest performance tool you have on a roleplay server. The rest - schema, indexes, backups - is in FiveM databases and oxmysql, which applies to RedM unchanged.

Installing: recipe or by hand#

txAdmin recipes. txAdmin's deployer can build a server from a recipe: it downloads the resources, writes server.cfg, creates the database tables and fills in the connection string. Community recipes exist for both VORP and RSG. It is the fastest route to a working server, with one caveat: a recipe pins whatever versions it was written for. Check that the recipe is maintained and recent before running it.

By hand. Clone or download each resource from the framework's repositories, import each resource's .sql file into your database, and add the ensure lines in the documented order. Slower, but you know exactly what is installed and where it came from, which matters when you update.

The SQL import is the step people skip and then spend an evening on. Each framework resource that stores data ships a schema file, and the resource fails - often quietly, with nil errors later - if its tables do not exist. Import them all before the first start, with a utf8mb4 character set so names with accents and emoji do not break inserts. phpMyAdmin import and export walks through importing a .sql file and the errors you will see.

Load order

Order in server.cfg is load order, and load order is dependency order. A typical shape for either framework:

ensure oxmysqlensure ox_libensure <framework core>ensure <framework inventory>ensure <framework character and appearance>ensure [framework]ensure [jobs]ensure [maps]

A job resource that starts before the core asks for the core object, gets nil, and does nothing for the rest of the session, usually without an obvious error. If something works after you restart it by hand but not after a full server restart, it is starting too early. Bracketed folders such as [jobs] start every resource inside them, in an order you do not control, so keep anything with dependencies between its resources out of a shared bracket or ensure it explicitly.

Performance#

Neither framework is the usual cause of a slow server. On RedM as on FiveM, the server's scripts run on one main thread and the cost comes from the resources on top: loops that run every frame, database queries inside loops, events broadcast to every player far more often than needed. The diagnosis is the same - resmon 1 in the client's F8 console, profiler record on the server, the console's hitch warnings and txAdmin's tick chart - and is set out in FiveM server performance.

Two framework-specific notes. Inventory resources do the most database work of anything on a roleplay server, so check their save behaviour: saving every change immediately is safe and costly, saving on an interval is cheap and loses data on a crash. And character data saved for every player at once on a timer causes a regular hitch; staggered saves avoid it.

Updating and staying current#

Both frameworks move, and resources built on them follow at their own pace.

• Pin versions. Know which release of the core and of each major resource you run. Update deliberately, not by re-running a recipe.
• Update the core with its own resources. A core update often needs matching inventory and character updates; read the release notes for the set.
• Run a test server. A second licence key from the same Cfx.re account, a copy of server-data, a copy of the database. Update there first.
• Back up the database before every update, and know you can restore it. Backups that actually restore makes the case.

Paid RedM resources are often escrowed and tied to the Cfx.re account that owns your licence key, exactly as on FiveM. Check before buying that a resource supports your framework and its current version.

Securing framework events

Both frameworks expose server events and callbacks that change money and items, and the resources built on them add hundreds more. Any connected client can call any server event with any arguments, so every handler that pays out must check its input on the server: use source rather than a player ID sent by the client, compute amounts on the server, check the player is where the action happens and holds what they claim to sell, and rate-limit. The RSG example above removes the item before paying; the VORP one only marks where that check belongs, and many free resources skip it entirely. FiveM anticheat options covers the method in detail, and it applies to RedM unchanged, including sv_entityLockdown under OneSync.

Switching frameworks later#

There is no migration path. VORP and RSG store characters, items and money in different tables with different structures, and every resource on top of them is written for one API. Switching means a new database, a new resource list, and a character wipe for your players. Some servers turn that into an event - a new season, a new map region - but it is still a reset. This is the strongest argument for spending an evening on the choice before the first player joins.

FAQ#

Is VORP or RSG better for a new RedM server?

Neither is better outright. VORP has the larger pool of RedM-native resources and a longer history; RSG is familiar to QBCore developers and uses ox_lib throughout. Choose by your team's experience and the resources you need.

Can I run VORP and RSG resources on the same server?

No. Each resource is written against one framework's API and data. Running both cores at once gives you two sets of characters and inventories that know nothing about each other.

Do both frameworks need a database?

Yes. Both store characters, inventories and money in a MySQL-compatible database through oxmysql, and import their tables from .sql files shipped with each resource.

Can I use QBCore resources on RSG?

Not directly. RSG follows QBCore's structure, which makes porting much easier, but QBCore resources call GTA V natives and QBCore's own exports. They need adapting for RDR3 and for RSG.

Can I switch from VORP to RSG later?

Only by starting again. The data structures are different and there is no supported migration, so players lose their characters. Choose before launch.