What a priority queue actually is
When your FiveM server hits its sv_maxClients limit, new players cannot join. They sit in a connection queue and wait for a slot to free up. By default that queue is first come, first served. A priority queue changes the order: it lets certain players, usually your paying supporters, jump ahead of the regular line so they wait less or not at all.
The critical thing to understand is what a priority queue is not. It does not give the player more money, better cars, faster vehicles, extra health, or any edge once they are in the game. It only affects how long they wait at the door. That distinction is the entire reason this perk is safe to sell, and we will come back to why Cfx cares about it.
A queue only matters on a server that actually fills up. If you have 64 slots and rarely see 30 players, nobody waits and a priority queue does nothing. The perk has real value precisely on busy servers, which is also where the temptation to oversell it is strongest.
It also helps to separate two things players often confuse: a queue and a slot reservation. A reservation holds a specific seat open so a named player always has somewhere to land. A priority queue does not reserve anything; it only reorders the waiting line. Most servers want the queue model for paid perks because it scales with demand, and they keep a small handful of true reservations for staff. Mixing the two without thinking is how operators accidentally lock out their own community.
The mechanism: connect deferrals
The technical foundation of every FiveM queue is the playerConnecting event combined with deferrals. When a player tries to connect, the server fires playerConnecting before they finish joining. Deferrals let your resource pause that connection, show the player a status message, and decide when, or whether, to let them through.
A queue resource works like this. It listens for playerConnecting, reads the connecting player's identifiers, and instead of letting them straight in it calls deferrals.defer() to take control. It then places the player in an ordered list. Each loop it updates the player with a message like "You are position 7 of 23 in queue" using deferrals.update(). When a real slot opens and the player reaches the front, it calls deferrals.done() to release them into the server.
Priority is just sorting. Every player in the list has a weight. A supporter with a higher weight gets inserted ahead of players with lower weight, so they climb the list faster. A regular player has weight zero. This is the whole trick: the queue is a sorted list, and priority is a number that decides where you land in it.
Two details make a queue feel good rather than broken. The first is a grace period. If a connected player crashes or has a brief network drop, a good queue holds their place for a short window so they reconnect straight back in rather than starting at the back. The second is honest messaging. Because the connection is paused by deferrals, the player sees only what you send them. Without a clear position and total, a paused connection looks identical to a dead server, and impatient players leave. A queue that tells you "position 4 of 19, estimated wait 2 minutes" keeps people calm and in line.
Queue resources you can use
You do not have to write the deferrals logic yourself, though understanding it helps you debug.
txAdmin ships with FiveM and includes a built-in player queue. It is the simplest starting point and handles the connection deferral and the join messages for you. Its priority handling is basic, so many servers outgrow it once they want fine-grained tiers.
Open source queue scripts such as the long-standing connectqueue resource give you a configurable, code-level queue. You define priority by identifier in a config table or through exports, set queue messages, and control grace periods for reconnects. Because it is open source you can read exactly how it sorts and adapt it.
Paid queue scripts on Tebex marketplaces and similar stores add convenience: web dashboards, database-backed priority, automatic expiry, and tier management without editing Lua. These are worth it if you sell several tiers and do not want to maintain the plumbing.
Whatever you pick, the contract is the same. The resource needs a way to look up a connecting player's priority weight, and you need a way to set that weight when someone buys.
Granting priority from a Tebex package
Tebex is the standard, Cfx-sanctioned way to take payments for FiveM servers. The flow for selling priority queue is:
- Create a package in Tebex, for example "VIP Priority" priced monthly.
- Attach a command or a webstore variable that captures the buyer's identifier. Tebex can require the buyer to enter their in-game ID or pull it from a linked account, and it can run a server command on purchase through the Tebex plugin.
- On purchase, write that player's priority weight and tier into your store: a database row, a JSON file, or the queue script's own table, keyed by a stable identifier.
The identifier matters. FiveM gives you several: license:, discord:, steam:, fivem:, and others. For priority queue, the FiveM license identifier (license: or the newer license2:) is the most reliable because it ties to the player's Rockstar/Cfx account and does not require Steam or Discord to be running. Store the supporter's license, and in your playerConnecting handler match the connecting player's license against your priority list.
A clean grant looks like: buyer pays on Tebex, Tebex runs setpriority license:xxxxx 25 30 through the server, the queue script saves weight 25 with a 30 day expiry against that license. Next time the player connects, the queue reads weight 25 and slots them near the front.
Two operational habits make this robust. First, make grants idempotent and renewable. If a member rebuys or renews, the command should refresh their expiry rather than stack a second entry, so you never end up with duplicate or conflicting weights for one license. Second, plan for revokes. Tebex can fire a command on chargeback, refund, or subscription cancellation just as it does on purchase. Wire that to remove or zero the player's priority. If you only ever grant and never revoke, refunded buyers keep a perk they no longer pay for, and over months your priority list fills with people who should not be on it.
Why Cfx is fine with selling priority
The Cfx.re platform agreement is strict about monetization. The core rule is that you may sell things that do not affect gameplay or grant an unfair advantage. You cannot sell in-game money, items, weapons, levels, or anything that changes a player's power or progression relative to others.
A priority queue passes this test cleanly. It does not touch gameplay at all. Two players, one paying and one not, who are both standing in the same spot in the game are completely equal. The only difference happened before either of them loaded in: one waited less to connect. Skipping a line is a convenience, like priority boarding on a flight. The seat you get is the same.
This is why priority queue, alongside cosmetic-only items, custom Discord roles, and supporter tags, is one of the few perks experienced FiveM operators recommend without hesitation. It generates recurring revenue, it is genuinely useful on a busy server, and it will not get your server in trouble for pay to win.
Balancing slots so you do not gate normal players
Here is the failure mode that turns a fair perk into a broken one. If you sell so many priority slots that the queue is always full of supporters, regular players never get in. At that point you have effectively made your server pay to play, and the experience for non-paying players, the people who make your server feel alive, collapses.
The fix is to cap priority as a fraction of capacity, not an open tap. Treat priority slots as a budget. On a 64 slot server you might decide priority members should never occupy more than, say, a quarter to a third of the live population during a rush, so that there is always meaningful throughput for the regular line.
In practice this means two levers. First, limit how many priority memberships you sell relative to your real peak concurrent players, not your max slots, because not everyone is online at once. Second, use tiered weights so a small number of top supporters jump highest while most priority members get a modest bump rather than a guaranteed instant join. The goal is that a supporter reliably waits less, while a regular player on a busy night still gets in within a reasonable time. If your non-paying players are quitting because they can never connect, you have oversold, full stop.