Understand QBCore framework concepts

This guide starts after a test server passes the first-boot checks. Its goal is to explain the boundaries you need before changing a resource—not to repeat installation.

A resource is the deployment unit

A FiveM resource declares client, server, shared, and UI files in fxmanifest.lua. Read the manifest first: it is the most reliable map of what code runs where and which dependencies load.

Client and server have different authority

• Client code handles input, presentation, local entities, and requests.
• Server code owns permission checks, economy/inventory mutations, and persistent state.
• Shared code defines data or helpers loaded on both sides; it is not automatically trusted.

Network events cross that boundary. Validate types, current permission, state, ownership, and proximity on the server before applying a requested action.

Request only the core surface you need

local QBCore = exports['qb-core']:GetCoreObject({ 'Functions', 'Shared' })

The filtered export reduces accidental coupling. See core concepts, shared data, and the API map before relying on a function or event.

Player data is runtime state

Use the framework player APIs and events instead of caching a character record indefinitely. A player can unload, change job or gang, lose an item, move, or disconnect between a client request and the server decision.

A safe first exercise

1. Create a separate resource with an fxmanifest.lua, client file, and server file.
2. Add a client command that requests a harmless server response.
3. On the server, validate source, rate-limit the request, and return a notification.
4. Restart only that resource and check both consoles for errors.
5. Commit the working baseline before adding game-state changes.

Continue with safe server events and the server-authority checklist.