How to start a RedM server in 2026: a complete checklist

Most guides on how to start a RedM server stop the moment the console prints "Server started". That is the easy 10 percent. The other 90 percent is what decides whether you still have a community in three months: a database that survives a crash, staff who cannot wreck the economy by accident, events that cannot be abused, and a backup you have actually restored once. This is the RedM server setup we would follow ourselves in 2026, in the order you need it.

It assumes a roleplay server with a framework. Nothing here requires buying anything from us, and our own product gets one section you can skip.

#How to start a RedM server: what you need first

• A copy of Red Dead Redemption 2 and a Cfx.re account. Players need the game to join. You need the account to link txAdmin and to request a licence key.

• A server licence key. Every FXServer needs one, requested for free from the Cfx.re portal (many guides still call it Keymaster). The key is tied to your account and goes into server.cfg.

• A machine to run it on. A home PC is fine for building and testing. For players, rent a VPS or a dedicated server with a fixed public IP.

• Server artifacts. The FXServer binaries, available for both Windows and Linux from the official server download page. Cfx.re describes the Linux build as a courtesy port, and says issues are more likely to get fixed on Windows. If you know Linux well, it is still a fine choice. If you do not, Windows will cost you less time.

On specs, there is no official table for a roleplay RedM server, so treat this as a rule of thumb from running them, not a guarantee. FXServer does most of its work on a few threads, so single-core speed matters more than core count. Plan on fast storage (NVMe) and at least 8 GB of RAM for a small server. Your framework and script count move the needle more than the raw player number.

#Create a RedM server: install FXServer with txAdmin

txAdmin ships inside the FXServer artifacts and is the standard way to run a server: a web panel to start, stop and restart, read the console, manage players and schedule restarts. The official txAdmin setup guide covers the first run. In short:

1. 1

   Download the recommended build for your system and extract it into its own folder, away from your server data.

2. 2

   Run FXServer.exe (Windows) or run.sh (Linux). A txAdmin page opens with a PIN.

3. 3

   Link your Cfx.re account and set the admin password.

4. 4

   Name the server and pick a deployment template (a recipe), or point txAdmin at a data folder you already have.

5. 5

   Enter your licence key when the recipe asks for it, run the recipe, then save and start.

Some RedM frameworks publish a txAdmin recipe that downloads the framework, its dependencies and a base set of resources in one go. That is the fastest way to a working RedM server 2026 style stack, and you can read the recipe before you run it. A recipe installs software on your machine.

#Pick a framework and its database

The framework decides what every script on your server expects: characters, inventory, jobs, money. Changing it later means redoing most of your resources, so choose once.

• VORP Core is one of the two big roleplay frameworks, with a large catalogue of scripts and public documentation.

• RSG Core is the other, inspired by QBCore on FiveM. If you know that ecosystem, its structure will feel familiar.

• Other frameworks exist, and standalone is a legitimate choice if you are building a small, scripted experience without full roleplay systems.

Pick by the scripts you want to run and the community you can ask for help, not by a feature table.

Both big frameworks need a database, MySQL or MariaDB, accessed through the oxmysql resource on current setups. Create a dedicated database and user for the server, keep the database on the same machine (or a private network), and do not expose port 3306 to the internet. Some install guides open it to every address for convenience. Do not copy that part. Put the connection string in server.cfg above your ensure lines, with charset=utf8mb4 so accented player names are stored correctly.

#RedM server setup: the server.cfg essentials

Your server.cfg is the file that makes the difference between a lab and a real server. Here is a short, working shape for RedM. Every directive below comes from the Cfx.re server manual.

# Run RedM, not FiveM
set gamename rdr3

# Network: change the port only if you must
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

# OneSync is required above 32 slots
set onesync on
sv_maxclients 48

# Your licence key from the Cfx.re portal. Never publish it.
sv_licenseKey "YOUR_LICENSE_KEY"

# Listing
sv_hostname "My RedM Server"
sets sv_projectName "My RedM Server"
sets sv_projectDesc "Serious roleplay in the Old West."
sets locale "en-US"

# Block Script Hook clients (the default, kept explicit)
sv_scriptHookAllowed 0

# Database connection, above every ensure line
set mysql_connection_string "mysql://user:password@localhost/dbname?charset=utf8mb4"

# Optional: pin a game build. Cfx.re lists build 1491 for RedM; leave
# this commented out unless a script you rely on asks for it.
# sv_enforceGameBuild 1491

A few notes on that file. Above 32 slots FXServer requires OneSync, and above 64 it requires onesync on, so setting it from the start saves you a migration. sv_enforceGameBuild is a startup-only setting and the official table lists a single RedM build, so we leave it as an option rather than a recommendation: only touch it if a resource documents it. sv_scriptHookAllowed is off by default, and Cfx.re warns that enabling it makes the server vulnerable to security issues. Finally, run the server with +exec server.cfg from your data folder, or txAdmin does it for you.

#Resources and load order

Resources start in the order of the ensure lines. A script that needs the database or the framework must come after them, or it starts, finds nothing, and fails on first use. The order that works almost everywhere:

ensure oxmysql
ensure your_framework_core
ensure your_framework_modules   # inventory, characters, menus
ensure security_and_moderation  # anticheat, logging
ensure gameplay_scripts
ensure maps_and_cosmetics

• Add scripts one at a time. Restart, read the console, test in game, then add the next. Twenty scripts added at once and one error means twenty suspects.

• Read the script before you run it. Server code runs with full access to your database and files. A leaked or cracked script is a classic way to lose a server.

• Test changes on a copy. Do not experiment on the live server on a Saturday night.

#Staff roles and permissions

Give each staff member the minimum they need, and give it to a named person, not a shared account. txAdmin has its own admin accounts with granular permissions for the panel. In game, FXServer uses an ACE permission system configured in server.cfg:

# Moderators: can use the commands you grant them, nothing else
add_principal identifier.license:MODERATOR_LICENSE group.moderator

# Admins
add_ace group.admin command allow
add_ace group.admin command.quit deny
add_principal identifier.license:ADMIN_LICENSE group.admin

• Reserve the owner role for people who can also touch the host and the database. That is the real root of your server.

• Never give staff in game powers that let them create money or items unless their job requires it, and log every use. Most economy disasters start with a staff command.

• Remove access the day someone leaves the team, in txAdmin, in server.cfg, on the host and on your Discord.

#Backups before your first player

You need two kinds of backup: your server data folder (resources, configs) and your database. Players care about the second one far more than you do. Store copies off the machine, because a backup on the same disk dies with the disk.

mysqldump -u youruser -p yourdatabase | gzip > /backups/server-$(date +%F).sql.gz

Also take a dump before every resource update and every framework change. Then do the step most owners skip: restore the backup onto a test server and check that characters and inventories are intact. A backup you have never restored is a hope, not a backup.

#Security from day one

The cheapest time to fix a hole is before players depend on it. Three things matter at launch.

Server events

Every RegisterNetEvent handler is a door that any client can knock on, with any arguments. Scripts that trust the client to say how much money it earned, or which item it received, are how duplication and economy exploits happen. Check this before you add a script, and again before you write your own. The details are in our guide to securing RedM server events, and the damage side is in the money dupe article.

An anticheat from the start

Installing an anticheat after the first cheater has already shown up is the expensive way: by then, players have seen what the server tolerates. There are several ways to choose one, covered in our buyer guide to RedM anticheat. Whichever you choose, check that it works with your framework (see anticheat for VORP).

If you pick Baobab AC, the setup is short and documented step by step on the installation page. What matters for a new server:

• Your server needs outbound HTTPS to the Baobab API, so a restrictive egress firewall will block it.

• You create the server in the panel and copy its API key at creation, because it is shown only once.

• Put the key in server.cfg with set, never setr: a setr convar is replicated to every connected client, which would make your key readable by any player.

• Load it right after your framework core, and exempt your staff through the admin ACE groups so that testing does not trigger detections.

• It starts alert-only: nothing is punished until you decide to enforce, which gives you time to read what it sees on your own server first.

• The resource updates itself on disk and applies the new version at your next restart.

You can see what the panel looks like without an account in the live demo, and the features page lists every detection.

A ban policy that sticks

Write your rules down before the first ban, and decide who may ban and on what evidence. Cheaters come back with new accounts. How hardware and identifier bans work, and what they can and cannot do, is covered in our article on the RedM HWID ban.

#How to start a RedM server: the launch day checklist

Do not open the doors until every line is true.

1. 1

   Licence key set in server.cfg, the file kept private and out of any public repository.

2. 2

   gamename rdr3, OneSync and endpoints configured, the server visible and joinable from a machine outside your network.

3. 3

   Firewall: game port open, txAdmin restricted, database port closed to the internet.

4. 4

   Database on a dedicated user, utf8mb4, credentials not reused anywhere else.

5. 5

   Load order verified: database, framework, modules, security, gameplay.

6. 6

   Every script read, its source known, and no cracked or leaked files.

7. 7

   Server events reviewed for anything that lets a client decide money, items or XP.

8. 8

   Staff accounts named, minimal permissions, each tested once.

9. 9

   Anticheat running, staff exempted, and a test connection checked in the console and the panel.

10. 10

    Ban policy and rules written and posted where players can read them.

11. 11

    Backup taken, stored off the machine, and restored once on a test server.

12. 12

    Restart schedule set in txAdmin, with a warning message for players.

13. 13

    An announcement that tells players how to report a problem, and a staff member awake for the first evening.

The technical parts take an afternoon. The staff rules, the backups and the habit of reading before you install are what keep a server standing. For the anticheat side, start with how a RedM anticheat works. The pricing page is public when you are ready to compare.