The Complete FiveM Server Stack: Every Layer, in the Right Order (2026)

Why order is an engineering decision, not a checklist

Server owners tend to plan their stack as a shopping list: get a framework, then buy whatever looks good next. That works right up until two systems both assume they own the same fact — two scripts writing to the same money field, a garage script that doesn't know the banking script's impound-fee format, an MDT with no dispatch feeding it calls. None of those show up as a missing feature. They show up weeks later as a dispute nobody can resolve, or a duplication bug nobody can explain.

The fix is to treat integration order as part of the architecture, not an afterthought. Each layer below exposes primitives — a money API, an item-move hook, an interaction prompt — that the layer above assumes exist and behave a specific way. Install top-down and you're configuring against primitives that don't exist yet; install bottom-up and each new layer has something real underneath it to build on.

Layer zero: framework and database

Everything above this layer references it, which is why it has to be settled — not necessarily perfect, but settled — before anything else goes in. Qbox, QBCore, or ESX Legacy fixes your player-data shape, job model, and event conventions; changing it later means touching every layer you've already built (/guides/qbox-vs-qbcore-vs-esx-2026, /guides/fivem-framework-lock-in). Prefer bridge-built resources over anything wired to one framework's internals, because the bridge is what survives a framework change.

The database layer is easy to underweight because it's invisible until it isn't. oxmysql with async, parameterized queries is the 2026 baseline — synchronous or string-built queries anywhere in your stack turn a small per-frame cost into a frame cost plus a blocking database round trip, and they reopen the door to injection that parameterization closed (/guides/fivem-resmon-script-performance).

Layer one: the interaction primitives — inventory, target, voice

Inventory sits this low because almost everything above it moves items or money through it: jobs pay out through it, banking touches it at the margins, evidence logs items out of it, garages sometimes gate repairs through it. A weak inventory layer — one that trusts client-reported item state — doesn't just risk its own exploits; it hands every layer built on top of it the same vulnerability.

A target-style interaction system needs to exist before you configure jobs, garages, or businesses that rely on it for their core interactions, because re-pointing every prompt after the fact means touching every script that added one. Voice is more loosely coupled architecturally, but RP-heavy layers built above it — EMS triage, undercover police work, gang scenes — are designed assuming proximity voice exists, so it belongs early rather than bolted on once those scenes are already live.

The full build order, layer by layer

The dependency and the specific failure risk of building each layer out of order:

• 1 · Framework (Qbox / QBCore / ESX Legacy) — everything above references its player, job, and money model. Risk if skipped or changed late: every other layer needs rework.
• 2 · Database (oxmysql, async, parameterized) — every stateful layer above writes through it. Risk: blocking queries compound into frame cost at every layer; unparameterized queries are an injection surface.
• 3 · Inventory — jobs, banking, garages, and evidence all move items or money through it. Risk: a client-trusting inventory hands its exploit to everything built on top of it.
• 4 · Target / interaction — jobs, garages, and businesses configure their core interactions against it. Risk: swapping it later means re-pointing every prompt across every script that added one.
• 5 · Voice — EMS, dispatch, and undercover-style RP scenes assume proximity comms exist. Risk: bolted on after those scenes are live, it disrupts scenes already built around radio-only or silent comms.
• 6 · Jobs — establishes the money-in side of the economy, and banking has nothing to reconcile without it. Risk: a banking layer installed first has no real income to test against.
• 7 · Banking — needs jobs for income and a server-authoritative money API. Risk: the classic duplication exploit lives here if the money API trusts client-submitted amounts.
• 8 · Garage — needs banking for purchase and impound fees, and database persistence for ownership records. Risk: vehicles that don't survive a restart, or that were 'spawned' rather than owned.
• 9 · Housing — the same dependency shape as garage: ownership, banking, and persistence, plus target for interaction points. Risk: property that can't prove who owns it is a dispute generator, not a feature.
• 10 · Dispatch — needs jobs to know which roles receive which alerts. Risk: installed after MDT or EMS, those systems have calls with nowhere to originate from.
• 11 · MDT — needs dispatch for incoming calls and jobs for officer records. Risk: installed first, it's a records system with nothing feeding it.
• 12 · Evidence — needs a case system to attach to and server-authoritative net events for custody logging. Risk: a client-trusted collection event lets evidence be planted or forged (/guides/fivem-evidence-script-buyers-guide).
• 13 · EMS — runs parallel to MDT, needs dispatch for incoming calls. Risk: triage and hospital-handoff flows with no call source behind them.
• 14 · Gangs — needs jobs and turf logic, benefits from banking already existing. Risk: territory income with no banking layer to land in becomes untracked, inflationary cash.
• 15 · Businesses — needs banking for books that reconcile and jobs for staffing. Risk: installed before banking exists, 'revenue' has nowhere honest to go.
• 16 · Admin / audit — needs every layer above to already emit events worth auditing. Risk: the layer's real failure mode is procrastination — most servers add it only after an incident, which is also the only moment it's too late to help.
• 17 · Announcements — low structural risk, but only useful once economy and job layers exist to key alerts off. Risk: a standalone announcer with nothing to announce.
• 18 · Cinematic / events (optional) — purely additive; nothing above or below depends on it. Risk: almost entirely performance — a heavy show script tanking resmon during the one moment the whole server is watching (/guides/fivem-resmon-script-performance).

The layer everyone installs last and regrets

Admin and audit tooling is architecturally a cross-cutting concern — it wants to observe every layer above, which is exactly why it's tempting to treat as a launch-day nice-to-have instead of infrastructure. The servers that regret this are never the ones that never needed it; they're the ones that needed it the week before they installed it. By the time a dupe or a staff-abuse complaint happens, the audit trail that would have resolved it in five minutes doesn't exist yet.

Announcements carries the opposite risk profile: genuinely low-stakes, but frequently installed too early, before there's anything meaningful for it to announce. Sequence it against your economy and job layers, not against how easy it is to set up.

Where to stop: the optional layer

Cinematic and event tooling — server-wide shows, scripted spectacles — is the one layer on this list that nothing else depends on. That makes it the safest thing to add and the easiest thing to defer; a server can run indefinitely without it and lose nothing structural. Add it once the stack beneath it is stable enough that a performance regression here doesn't get blamed on the wrong layer.