The cheapest way to ruin a Friday night is to test a script on your live city. Someone drops a new inventory resource into resources/, types ensure, and 140 players eat a freeze followed by a rollback nobody planned. A FiveM dev server takes that whole class of accident off the table, and once you're running two instances, the natural third is an event box for race nights and seasonal builds. The workload doesn't triple — not if you get the topology right the first time.
When One City Needs More Than One Server
Most established cities end up with three instances: a dev server where changes get proven, the main city players connect to, and an event server spun up for one-off nights. Each one needs its own port, its own database, its own Cfx license key, and its own txAdmin data path. Nearly everything else can be shared.
| Instance | Uptime | Slots | Who joins | Data lifetime |
|---|---|---|---|---|
| Dev | On-demand or 24/7 | 4–8 | Devs, senior staff | Disposable, wiped freely |
| Main | 24/7 | 64–128 | Everyone | Permanent |
| Event | Hours to a weekend | 16–48 | Invited or whitelisted | Ends with the event |
The mistake is treating these as three copies of the same thing. They have different failure tolerances. Dev is allowed to crash — that's its job. Main is not. Event sits in between: nobody riots if a race night ends early, but it runs during peak hours.
Port Allocation: Pick a Scheme, Not a Number
Every guide tells you to change the port. None of them tell you to plan the numbering, and that's what bites you on instance four.
Give each instance a block of ten. Main takes 30120 for the game port and 40120 for txAdmin, dev takes 30130 and 40130, event takes 30140 and 40140. The gaps leave you room for a second endpoint or a voice server later without renumbering everything and re-editing firewall rules at midnight.
Two details that catch people out:
- FXServer needs both TCP and UDP on the game port. Open both. A server that shows in the list but times out on connect is almost always a missing UDP rule.
- Each instance needs its own txAdmin data path. Two instances sharing one
txDatafolder will overwrite each other's admin lists and server settings, and the symptom looks like random config corruption rather than a collision.
On Linux, the whole separation is convar-driven at launch:
# dev instance
./run.sh +set serverProfile dev \
+set txAdminPort 40130 \
+set txDataPath /opt/fivem/txData-devOne more thing the hosting knowledge bases get wrong: they tell you to open the txAdmin port in your firewall and move on. That port is a full admin panel with console access and file management. Bind it to localhost and reach it over an SSH tunnel, or put it behind a VPN or an IP allowlist — an exposed txAdmin is one weak password away from someone owning your city.
One Box or Three? The Actual Cost Math
Running everything on the box you already pay for is sometimes right and sometimes costs you your peak.
RAM doesn't scale with slots the way people assume. Your dev server loads the same resource list and the same streamed assets as production, so it costs nearly as much memory as the main city even with four people on it. A heavy RP resource set will sit at 3–5 GB on a dev instance that's basically empty — budget for the resources, not the player count. The main city with the same set and 64 players lands in the 8–16 GB range; an event server comes in lighter at 4–6 GB, but only because you strip it to the handful of resources the event needs.
CPU is where multi-instance really shows up. FiveM's server tick is effectively single-threaded per instance, so three instances want three fast cores — not one very fast core shared three ways. Core count is what lets you co-locate; clock speed is what makes each instance smooth. If you're on a 4-core VPS running a full city, adding a dev instance means your dev work and your main tick are competing for the same silicon.
That leads to a split recommendation:
- Dev on the main box is usually fine. It's idle most of the time, and you can cap it so it can't hurt anything. A stray
while true do endin a test script will otherwise peg a core and drag your live tick with it. A systemdCPUQuota=on the dev unit turns that from an outage into a slow dev server. - Event servers belong somewhere else. They run during peak, which is exactly when your main city needs every core it has. Rent a box for the weekend and hand it back. Three days a month of a mid-tier VPS is cheaper than upsizing your production host permanently to absorb spikes you use twelve times a year.
Databases: Your Dev Server Must Never Touch Prod Data
Every instance gets its own database. Not its own table prefix — its own schema, with its own credentials.
The trap is subtle enough that experienced owners still fall into it. Pointing dev at the production database feels harmless because "we're only reading." You aren't. ESX and QBCore both persist player state on disconnect and on a save interval, so a dev server connected to prod writes positions, inventories and cash back into live rows without anyone running a single destructive command. Idling on dev is enough to corrupt a real character.
The fix is a sanitized copy refreshed on a schedule — standard dump-and-restore, and your existing deploy pipeline probably already has the hooks. What matters more is what you scrub, because this is where most sanitize scripts are incomplete:
- Ban tables and ACE/admin grants — otherwise every dev is a superadmin on a dataset that will eventually get restored somewhere embarrassing.
- Player identifiers and Discord IDs, if the copy leaves your box at all.
- Donation, Tebex, and transaction tables. Dev has no business holding purchase records.
- Discord webhook URLs stored in config or DB rows. This one gets missed constantly. A sanitized copy that still holds live webhook URLs means your dev server floods the real staff logs channel with test bans and fake transactions, and your admins learn to ignore that channel — which is how a genuine alert gets missed.
Player Identity Is the One Thing Worth Sharing
Here's the leverage point. A player's identifiers — license:, steam:, discord:, fivem: — come from their account, not your server, so they're identical on every instance you run. That makes identity the one dataset both safe and genuinely useful to share.
Keep a small identity database holding your whitelist and staff roles, and let dev and event read from it. Character data, inventories, and economy stay strictly per-instance. Your event server then whitelists your entire existing playerbase on day one with no signup form, no re-verification, and no Discord bot rebuild.
Keep the flow one-directional. Event characters must never write back into the main economy — a weekend minigame with generous payouts becomes a money printer the moment those balances sync home. Fresh characters or a read-only copy, always.
Configs: One Base File, Per-Instance Overrides
Three hand-maintained copies of server.cfg will drift within a month. Split it instead: a shared base that every instance executes, plus a small per-instance file holding only what differs.
# instance-dev.cfg — the only file that differs per instance
endpoint_add_tcp "0.0.0.0:30130"
endpoint_add_udp "0.0.0.0:30130"
sv_hostname "CITY [DEV — not for players]"
sv_maxclients 8
set mysql_connection_string "${DB_DSN_DEV}"
sv_master1 "" # keep dev off the public server list
exec common.cfg # resource list + framework convars, sharedsv_master1 "" is the line people forget. Without it your half-broken dev instance advertises itself publicly, players join it, and you get bug reports about a server that was never meant to exist. Set it on both dev and event unless the event is genuinely open to the public.
Because the differences are convars, the same committed common.cfg works everywhere and your resource list can only drift on purpose.
License Keys: One Per Instance, and There's a Cap
Each running instance needs its own Cfx license key. Sharing one key across two servers confuses the backend, and the visible symptom is one server appearing in the list in place of the other while players fail to connect.
Two things have changed here that most tutorials haven't caught up with. Keys now live in the Cfx Portal, not Keymaster, which was deprecated through 2025. And the current key flow asks only for a display name — there's no server IP field anymore, so the old advice about rebinding your key's IP when you migrate hosts is obsolete.
The constraint worth planning around: a free account is capped at three keys. Dev, main, and event is exactly three. You are at the ceiling by design. Before you spin up a second event server or a rebuild instance, you'll need to delete a key you're no longer using or look at a Cfx subscription tier. Name your keys clearly in the Portal, because three keys called "server" is how you delete the wrong one.
A Promotion Cadence That Protects Your Peak
Multi-instance only pays off if changes actually flow through dev instead of around it. The topology is the easy part; the discipline is the product.
Promote with git, not rsync. If you've already got a deploy pipeline, point it at dev first and let main pull the same commit later. Where rsync specifically hurts on a multi-instance setup:
- Without
--delete, a resource you removed on dev keeps running on the target, and you're debugging a ghost. - With
--delete, it wipes the dev-only test resources you meant to keep — and if the path is off by one directory, it takescache/and.gitwith it. - Either way it moves files but not schema. Your SQL migration ran on dev and didn't run on main, and the two drift until something throws a column error at peak.
Reserve rsync for large binary stream assets that don't belong in git, and let everything else promote as a commit.
Then put it on a calendar:
- Monday–Wednesday: changes land on dev. New scripts from wherever you source them — febex.io, buy-tebex.io, cfxre-tebex.io — go here first, never straight to main.
- Wednesday evening: soak test. Not "does it boot" — join with three or more real clients, run the affected job loop end to end, and watch resmon and the txAdmin console for a full evening.
- Thursday: promote to main during a low-pop window, reloading only the changed resources.
- Friday and the weekend: frozen. Nothing ships. If it wasn't good enough for Thursday, it waits.
The freeze is the part people skip and the part that does the most work. Most catastrophic weekend outages trace back to a "quick fix" pushed at 7pm Friday, and a dev instance you bypass under pressure is just a second server you're paying for.
Get the ports blocked out, the databases split, the keys named and the calendar agreed with your staff, and the extra instances stop feeling like triple the admin work. They start being the reason your main city stopped falling over.
