DEV Community: Meteo Studios

Why FiveM Server Setup Tutorials From 2023 Will Break Your Server in 2026

Meteo Studios — Mon, 11 May 2026 13:13:25 +0000

If you Google "how to set up a FiveM server" right now, most of the top results are tutorials from 2022 to 2023. They will technically work. They will also set you up with a stack that is two years behind what the framework developers actually recommend.

I do FiveM development for a living. The setup pipeline has been rebuilt twice in the last three years. Here is what shifted, and what an actually current 2026 install looks like.

The Quick Diff

Topic	2023 Tutorial Says	2026 Reality
Framework	QBCore or ESX	QBox
Database	MySQL or XAMPP	MariaDB + HeidiSQL
Artifacts	Pull latest from official page	Pull recommended from JG Scripts DB
Install method	Manual extract + edit server.cfg	txAdmin recipe deployment
Server config	Hand-edit server.cfg	Filled in via txAdmin wizard
Slot count	Set high, buy Element Club	Stay at 10 for free clothing tier
Hosting	Any cheap VPS or game host	Cfx.re approved partner, or proper VPS

If your tutorial is still telling you to do the left column, you are setting up an outdated server.

Framework: QBCore Is Not the Default Anymore

Most 2023 tutorials present the framework choice as ESX vs QBCore. ESX was already on the way out then. QBCore took over.

QBCore then ran into its own problems. Security issues stacked up. The update cadence slowed. The documentation got out of sync with what the codebase actually did.

QBox is the community-driven fork that filled the gap. It kept the QBCore script compatibility, so most existing scripts still work, but the core was rebuilt for performance and security. It uses ox_lib and ox_inventory by default. Server-side event validation is part of the core. The team ships actual updates and the Qbox docs are noticeably clearer than what QBCore offers.

The framework decision in 2026 is straightforward. Start on QBox. The only reason to touch QBCore is if you need a specific script that has not been ported yet, and that bucket keeps shrinking.

Database: MariaDB + HeidiSQL, Two Separate Downloads

The Qbox docs call this one out directly: XAMPP is not supported. Do not use it. Yet you can still find 2023 tutorials walking new users through XAMPP because it was the easy path at the time.

The current stack is MariaDB for the database server, HeidiSQL for the GUI. They are separate downloads. Some guides imply HeidiSQL is bundled with MariaDB. It is not.

MariaDB: mariadb.org/download
HeidiSQL: heidisql.com/download.php

Install both. You can leave the defaults if you are not sure what to set during MariaDB install. txAdmin will handle the rest later.

Artifacts: Use the Recommended Build, Not the Latest

The standard 2023 advice was "go to the official artifacts page and download the latest build." This still works technically, but the newest build is not always stable. Some have bugs. Some break specific resources.

The community has been pointing at artifacts.jgscripts.com for a while now. It is a database that tests artifact builds and flags broken ones. Each build gets marked as recommended, optional, or broken. You want the latest recommended.

You browse the site, find the recommended build for your OS, download the zip, extract with 7-Zip into a folder. Same process as the official page, just with the broken builds filtered out for you. The official Qbox install guide points to the same source.

Roughly once a month is a reasonable cadence to check for a newer recommended build.

Install: txAdmin Recipes Killed the Manual Method

This is the biggest shift, and the one most outdated tutorials get most wrong.

The 2023 install flow looked like this. Download QBCore. Extract it into the resources folder. Open server.cfg in a text editor. Manually paste in ensure lines for each resource in the right order. Add your license key. Set your hostname. Configure the database connection string. Hope the order was right. Run FXServer.exe.

The 2026 flow is:

Run FXServer.exe from your artifacts folder.
txAdmin opens in your browser.
Choose Popular Recipes, then QBox Framework.
txAdmin downloads QBox and its dependencies, configures resources.
On the database screen, just continue. Defaults work for a standard MariaDB install.
Fill in server name, description, slots, and license key in the wizard.
txAdmin generates server.cfg for you.
Start the server from the dashboard.

That is it. No manual resource ordering. No hand-edited config. The Qbox team officially recommends this method, and the Qbox install docs walk through the same flow with screenshots.

If a tutorial in 2026 is telling you to manually edit server.cfg to add framework resources, the tutorial is out of date.

server.cfg: You Do Not Need to Touch It

A related shift. The 2023 advice was "open server.cfg in VS Code and edit each of these lines."

In 2026, the txAdmin recipe wizard prompts you for all of them during deployment. Server name, description, slot count, license key, database connection. You fill them into the wizard, txAdmin builds the server.cfg for you.

If you need to tweak something later (tags, locale, custom convars), the txAdmin file editor handles it. You can do everything from the browser. The "open server.cfg in a text editor" step does not really exist in a normal 2026 setup.

The 10-Slot Loophole Nobody Mentions

This one almost no 2023 tutorial covers. FiveM allows free custom clothing streaming, vehicle textures, and other player asset streaming on any server with sv_maxclients at 10 or below. The moment you go to 11, you need an Element Club subscription (€15/mo for Argentum, which gets you up to 64 slots).

A 2023 tutorial usually says "set your slots to 32 or whatever, you can upgrade to Element Club later if you want custom clothing." That skips the part where you can have all the streaming features for free, indefinitely, as long as you cap at 10.

For early-stage and dev servers, this matters. Stay at 10 while you are testing and building your first players. Upgrade when you are actually filling 10 slots regularly.

Hosting: The Approved List vs Everything Else

A 2023 tutorial usually points you at whatever VPS the author has an affiliate code for. The picture is clearer in 2026.

Cfx.re publishes an official list of approved FiveM hosting partners at fivem.net/server-hosting. The current approved partners are GPORTAL, Shockbyte, Nitrado, Nodecraft, xREALM, and ZAP-Hosting. If a host is not on that list, they are not officially partnered, no matter what their marketing claims.

For VPS or dedicated, the FiveM development community on the Cfx.re forum has converged on a few recommendations that come up over and over:

OVH, 1of1: Best built-in DDoS protection at the infrastructure level
Hetzner, Contabo: Best price to performance
Vultr, Linode, DigitalOcean: Cleaner cloud setups

DDoS protection is worth paying attention to. Active FiveM servers do get attacked, and a host without proper protection will lose you players during downtime.

What a Current 2026 Install Actually Looks Like

Minimal version:

Download and install MariaDB and HeidiSQL.
Download the recommended FiveM artifacts from artifacts.jgscripts.com.
Extract to a server folder.
Run FXServer.exe.
In txAdmin, deploy the QBox Framework recipe.
Fill in the wizard (server name, description, slots, license key).
Continue past the database screen with defaults.
Start the server.

The whole thing is 30 to 60 minutes. If your install is taking significantly longer, you are probably following a tutorial that has you doing manual work the recipe was built to handle.

For local dev, the same flow runs on your own PC at zero cost. There is no point in this stack where you have to pay for anything before you have actual players.

Why This Matters

The old way is not broken. It will get you a running server. But it leaves you with a stack that is harder to maintain, less secure, and built on a framework other developers are moving away from. The cost compounds. Six months in, you are migrating or refactoring while everyone else is shipping features.

If you are setting up a new server in 2026, do it the 2026 way. The tutorials from two years ago meant well. They are also two years out of date in a space that moves fast.

Comments are open if you want to compare notes on what other old advice is still circulating.

Building a 100+ Script FiveM Server Package: Architecture Decisions That Mattered

Meteo Studios — Thu, 07 May 2026 13:38:10 +0000

When you have over 100 Lua scripts that need to share state, talk to each other, and run at under 0.5ms total CPU, architecture stops being optional. Here is how we structured the Meteo FiveM Server V2.0 and what we would do differently next time.

Context

I run Meteo Studios. We build premade FiveM server packages and individual scripts for QBCore and QBox. Our V2.0 is a complete rewrite. Not a patch on top of the old codebase. New architecture, new patterns, new everything.

The server ships with 100+ custom scripts covering crime systems, civilian jobs, economy, housing, vehicles, and more. Every script is exclusive to this package. The challenge was making all of them work together without turning the codebase into spaghetti.

The Core Problem With Premade FiveM Servers

Most premade servers are not engineered. They are assembled. A seller grabs 50 free scripts from different creators, drops them in a resources folder, and sells the zip. The scripts have no shared architecture. No consistent event patterns. No unified config system. When one breaks, three others break with it.

We built V1 this way ourselves and learned the hard way why it does not scale.

Single Config Source of Truth

The first architectural decision was centralizing server-wide configuration. In V2.0, a single meteo.cfg file controls the server name, logo, currency symbol, speed unit, group size, and other global settings.

Every script reads from this file using FiveM's GetConvar system. No script has its own copy of the server name. No script hardcodes a currency symbol. Change it once in meteo.cfg and every script picks it up on next restart.

-- Any script can read global config
local currency = GetConvar('meteo:currency', '$')
local serverName = GetConvar('meteo:servername', 'My Server')

This also enabled a feature our customers kept asking for: full script renaming. Because no script hardcodes the brand name, one rename operation updates everything. The rename system is documented and takes about 2 minutes.

Event-Driven Over Polling

FiveM scripts commonly use CreateThread with Wait loops to check state. This works for simple scripts but at 100+ resources, polling loops add up fast.

We replaced most polling with event-driven patterns using lib.points from ox_lib for proximity detection and lib.onCache for state changes. The server only does work when something actually changes.

-- Instead of polling player position every 500ms
-- Use lib.points for proximity-based loading
local point = lib.points.new({
    coords = vec3(x, y, z),
    distance = 15,
})

function point:onEnter()
    -- Load targets, spawn entities
end

function point:onExit()
    -- Cleanup
end

Job-specific targets (armory, lockers, garages) only load for players with that job. Spawned entities get cleaned up when players leave areas, change jobs, or disconnect. The result is 0.42ms total client CPU with all 100+ scripts running.

Connected Systems Through a Shared Tablet

The crime ecosystem was the most complex part. Instead of standalone crime scripts that do not know about each other, everything connects through a single crime tablet interface.

Organizations feed into territory control. Territory control affects drug turf zones. Boosting contracts affect crime rank. Crime rank unlocks higher tier heists. Crypto from heists flows into the blackmarket. Everything shares the same economy and progression.

The alternative was separate scripts with their own databases, their own UI, and their own progression. That is what most servers do. But then you get situations where a player maxes out one crime activity and has no reason to touch the others. Connected systems create natural gameplay loops.

Security as Architecture, Not Afterthought

Most FiveM servers bolt on an anti-cheat and call it secure. The problem is that if your server code has exploits, no external anti-cheat will save you.

We followed every official FiveM security guideline at the architecture level:

Server-side authority on all critical actions. The client never decides how much money to add or what items to give.
Validated net events. Every event checks source player exists and has permission.
NUI callback strict mode enabled. Other resources cannot trigger your NUI callbacks.
No exposed exports that external code can abuse.
Rate limiting on sensitive operations.

The full security breakdown is in our documentation.

Translations Without Code Changes

FiveM communities are global. We needed the entire server to be translatable without touching Lua files.

We used the ox_lib locale system. Every user-facing string is a locale key. One config change in ox.cfg switches the server language. 14+ languages ship out of the box. Adding a new language is one JSON file per script.

-- Every string is a locale key
lib.locale('crime_tablet_title')
lib.locale('job_level_up', { level = newLevel })

No UI edits. No codebase changes. No find-and-replace across 100 files. This was only possible because we enforced locale keys from day one. Retrofitting translations onto an existing codebase is painful. Designing for it from the start is easy.

What We Track Publicly

One decision we made with V2.0 was full transparency on development. Every update is logged in a public changelog. The development roadmap is visible on the development page.

We also run a free showcase server where anyone can test every feature before purchasing. Each feature has a video tutorial. The full script list is documented at docs.meteofivem.net.

What We Would Do Differently

If we started V2.0 again today:

Stricter typing from day one. We use ox_lib's type checking but should have been more aggressive with it early on. Catching type mismatches at dev time instead of runtime saves hours.

Better test tooling. FiveM does not have great unit testing support. We ended up doing most testing manually on the showcase server. Building a lightweight test harness early would have saved time.

Modular UI components. Our NUI layers are custom built per script. Extracting shared UI components into a reusable library earlier would have reduced duplication.

Performance Numbers

For those who care about benchmarks: the full server runs at 0.42ms total client CPU with all 100+ scripts loaded. We did a comparison against a default QBox server to show that our scripts do not bloat the base framework.

The optimization approach is documented in the security and optimization docs if you want the technical details.

Try It

If you want to see how all of this works in practice, the showcase server is free to join. Documentation for every script is at docs.meteofivem.net. The server itself is at meteofivem.net.

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

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.