Forem: Meteo Studios

Setting Up Discord Rich Presence for FiveM Servers: QBox, QBCore, and Custom servers

Meteo Studios — Tue, 05 May 2026 17:47:28 +0000

If you are building a FiveM roleplay server, Discord Rich Presence is one of those small details that makes a big difference. It replaces the generic "Playing FiveM" status with your server name, logo, and player count. Every player on your server passively advertises your brand to their entire Discord friends list.

The setup is straightforward but the implementation differs depending on your framework. Here is a quick breakdown of how it works across QBox, QBCore, and a custom config-based approach.

Creating the Discord Application

This part is framework-agnostic.

Head to the Discord Developer Portal
Create a new application. Name it your server name since this is what displays in the Discord status
Copy the Application ID from General Information
Go to Rich Presence > Art Assets and upload your server logo. Give it a key name like server_logo_large

Recommended image size is 1024x1024px. Discord takes a few minutes to process new assets.

That is the Discord side done. Now the server side.

QBox Implementation

QBox handles RPC through qbx_core/config/client.lua. The discord config block lives here:

-- qbx_core/config/client.lua
discord = {
    appId = 'YOUR_APPLICATION_ID',
    largeIcon = { icon = 'server_logo_large', text = 'My Server' },
    smallIcon = { icon = 'server_logo_small', text = 'FiveM' },
}

Update the appId with your Application ID and the icon key names to match what you uploaded in the Developer Portal.

One thing to watch out for: if you update qbx_core, your config changes might get overwritten. Consider tracking your config changes separately or using a version control system.

Full QBox docs on this: docs.qbox.re/resources/qbx_core/discord

QBCore Implementation

QBCore handles Discord RPC through qb-smallresources. The config lives in qb-smallresources/config.lua:

-- qb-smallresources/config.lua
Config.Discord = {
    appId = 'YOUR_APPLICATION_ID',
    largeIcon = { icon = 'server_logo_large', text = 'My Server' },
    smallIcon = { icon = 'server_logo_small', text = 'FiveM' },
}

Different file location from QBox but same structure. Update the Application ID and icon key names to match your Discord Developer Portal assets.

Config-Based Approach (Meteo Server)

At Meteo Studios we took a different approach with our server package. Instead of editing Lua files inside framework resources, Discord RPC is controlled through the same cfg file that handles all other server-wide settings:

# meteo.cfg
set meteo:discord_enabled true
set meteo:discord_player_count true
set meteo:discord_app_id "YOUR_APPLICATION_ID"
set meteo:discord_icon_large "server_logo_large"
set meteo:discord_icon_small "server_logo_small"

The advantage here is that server owners never touch framework code. No risk of losing changes on updates. No hunting through Lua files. The same meteo.cfg file also controls the server name, currency symbol, speed unit, and other global settings across 100+ scripts.

We documented the full setup at docs.meteofivem.net.

The design philosophy behind this is simple: if a setting affects the entire server, it should live in one place. Not scattered across individual resource configs.

Gotchas That Will Save You Debugging Time

Client-side kill switch. FiveM has a setting that lets players disable Discord Rich Presence entirely. If you are testing and nothing shows up, check your FiveM client settings before debugging your server config. Settings > Game > Discord Rich Presence.

Case sensitive key names. If your art asset is named Server_Logo but your config says server_logo, it will not work. Match them exactly.

Application name is the display name. The name you gave your Discord application is what shows in the player's status. This is set in the Developer Portal, not your server config. If it says "test123" because you were experimenting, rename it.

Icon processing delay. New art assets take a few minutes to become available. Do not restart your server 30 seconds after uploading and assume it is broken.

Buttons. Most implementations support up to two clickable buttons in the rich presence. Link to your Discord invite and your website. This turns every player's status into a mini landing page for your server.

Is It Worth the 10 Minutes?

Quick math. 30 concurrent players, each with 100 Discord friends. That is 3,000 potential impressions of your server brand, every day, for free. No ad spend, no content creation, no social media grinding.

For 10 minutes of setup, the return is hard to beat.

If you are interested in how we handle server-wide configuration at scale, check out the Meteo Server documentation. We built the entire server around the idea that server owners should configure, not code.

I build custom FiveM servers and scripts at Meteo Studios. More at meteofivem.net.

I Build Premade FiveM Servers. Here Is Why Most of Them Are Trash (And What We Do Differently)

Meteo Studios — Mon, 04 May 2026 12:07:49 +0000

I have been building FiveM servers and scripts since 2023. I run Meteo Studios where we sell a custom built premade server package and 100+ individual scripts for QBCore and QBox.

Full disclosure: I sell a premade server so obviously I am biased toward our approach. But everything I claim in this article is testable. Our showcase server is free to join, our changelog is public, and our documentation is open. Do not take my word for it. Verify it yourself.

I recently saw an article claiming premade FiveM server packs are all bad. The author made some fair points but clearly never built one. Most of the arguments were generic and missed what actually matters. So here is what actually goes wrong with premade servers and how we solved each problem when building our V2.0 from scratch.

The Real Problem With Most Premade Servers

The article I read claimed premade packs "introduce hidden problems under real-world conditions." That is true for 90% of them. But the reason is not that premade servers are fundamentally flawed. The reason is that most sellers are not building servers. They are assembling them.

Here is what a typical premade FiveM server looks like behind the scenes:

30 scripts from 15 different creators
No shared architecture between scripts
Half the scripts use different coding patterns
Config files scattered everywhere with no consistency
Documentation that says "drag and drop into resources"
No testing beyond "it starts without errors"

When you buy one of these, you are not getting a server. You are getting a folder of scripts that happen to be in the same directory. The moment one script updates and breaks compatibility with another, you are debugging code you did not write with no documentation to guide you.

That is a real problem. But the solution is not "build everything yourself from scratch" like that article suggests. Most server owners do not have 6 months and deep Lua knowledge to build a server. The solution is premade servers that are actually engineered, not assembled.

What "Built From Scratch" Actually Means

When we say every script in our server is custom built from scratch, we mean it literally. Not "we downloaded a free script and modified it." Not "we bought scripts from 10 creators and bundled them." Every line of code was written by our team for this specific server.

Why does that matter for performance? Because every script shares the same architecture.

Shared Architecture Matters More Than Individual Optimization

The article talked about "technical debt of unknown code." That is a real issue when you bundle scripts from different creators. Each developer has their own patterns, their own event naming conventions, their own database structure. When 30 scripts all do things differently, the server wastes resources on redundant operations.

In our V2.0, every script follows the same rules:

Event-driven architecture. We use lib.points, lib.onCache and event patterns instead of polling loops. The server only does work when something actually changes. No Wait(0) loops running every frame across 100 scripts.

Proximity-based loading. lib.points loads interaction zones only when players are within range and unloads when they leave. Job-specific targets like armory or lockers only load for players with that job. This means a police officer and a taxi driver have completely different resource footprints.

Entity cleanup. Every spawned entity is properly removed when players leave areas, change jobs, or disconnect. No orphaned entities eating memory after hours of uptime.

Server-side authority. Every critical action is validated server-side. The client never decides how much money to add or what items to give. This is a security practice but it also prevents the server from processing invalid requests that waste CPU cycles.

These are not optimizations bolted on after the fact. They are architectural decisions made before writing the first line of code. When every script follows the same patterns, the whole server runs leaner than any collection of individually "optimized" scripts ever could.

The Memory Leak Problem Is Real (If You Do Not Own The Code)

The article mentioned memory leaks that "manifest after 48 hours of uptime." This is a real issue and it is one of the biggest arguments for custom code over bundled scripts.

When you use someone else's script and it has a memory leak, you cannot fix it. The code is escrowed. You cannot see the source. You open a ticket with the creator and maybe they fix it in two weeks. Maybe they do not.

When we find a memory leak in our code, we fix it the same day. We push the update and every customer gets it automatically. Our full changelog is public. Every fix, every update, every new feature is documented. You can see exactly what changed and when.

This is why owning the entire codebase matters. Not because custom code is automatically better. But because you can actually maintain it.

"Just Build It Yourself" Is Bad Advice For Most People

The article concluded with "start with a minimal framework like QBCore and adding resources individually." That is technically correct. It is also unrealistic for 95% of the people looking for a premade server.

Building a production-ready FiveM RP server from scratch takes months. You need a crime system, jobs with progression, economy, housing, vehicles, phone, banking, inventory. Then you need to make all of those systems talk to each other. Then you need to test edge cases.

Most server owners want to run a community, not become full-time Lua developers. That is exactly who premade servers are for.

The real question is not "premade vs custom built." It is "assembled from random scripts vs engineered as a single product." Those are very different things.

How We Test Performance (With Real Data)

The article claimed premade packs "present a cleaner resource monitor reading during light testing." Fair criticism. Showing resmon with one player on an empty server proves nothing.

Here is how we actually test:

Client-side resmon. We run resmon 1 in game and check CPU usage per resource. Target is under 0.05ms per script. Anything above 0.10ms gets investigated.

Server-side profiler. We use the FiveM built-in profiler (profiler record 500) to capture server performance data. This saves a JSON file you can load in Chrome DevTools Performance tab to see exactly which resource uses how much CPU time, down to the specific file and line number.

We run these tests at idle, under light load, and under normal player counts. The profiler data is verifiable. Anyone can run the same commands on their own server and compare.

We are working on publishing full profiler data in our documentation so customers can see real numbers, not marketing claims.

What Actually Makes a Premade Server Good

After building servers for 300+ owners, here is what I have learned matters most:

Connected systems, not isolated scripts. A crime tablet that connects to the economy that connects to perks that connects to jobs. One action should ripple through multiple systems. If your crime script does not know about your economy script, you have a folder of scripts, not a server.

One config, not fifty. Server owners should not hunt through 50 config files to change their server name. Our meteo.cfg controls server name, logo, currency symbol, speed unit, and global settings across every script. Change once, updates everywhere.

Full documentation before shipping. Not "coming soon." Every script documented with step by step guides, commands, teleport coords, and video tutorials. We recorded a tutorial for every feature on our showcase server so customers can test and learn everything before buying.

Rename support. Your server list should show your brand, not the seller's. We built full rename support so every script reports under your name. No other premade server offers this.

Multi-language support. FiveM communities are global. One config change translates our entire server to any language using ox_lib locales. 14+ languages included out of the box.

Try before you buy. If a seller will not let you test the server before purchasing, that tells you everything. We run a free showcase server where you can try every feature. No deposit, no card.

The Bottom Line

Are most premade FiveM servers trash? Yes. They are random scripts bundled together by sellers who disappear after payment. The criticisms in that article apply to them completely.

But "premade" does not automatically mean "bad." It depends entirely on whether the server was assembled or engineered. Whether the seller maintains the code or abandons it. Whether there is documentation or a README that says "good luck."

If you are evaluating a premade server, ask these questions:

Is every script custom built or is it a bundle of other people's work?
Can you test the server before buying?
Is the documentation complete right now, not "coming soon"?
Is there a public changelog showing active development?
Can you rename scripts to your own brand?
Is the code secured following official FiveM security guidelines?

If the answer to most of these is no, keep looking.