How to Tune QBCore Settings for Your Server

Choose QBCore settings from your installed version and the experience you want players to have. There is no universal config.lua preset that fixes lag, economy balance and permissions together.

Locate the settings that actually own behavior

Record the qb-core revision and local changes. Read its config.lua and the code that consumes each setting. HUD, spawn, inventory, jobs and voice resources can have separate configuration.

Back up resources and the database, then use staging. Keep server.cfg slot limits, framework player limits and platform entitlements consistent; a number in the framework does not create hosting capacity.

Tune the first player session

Test the actual character-selection and spawn resources. Confirm the spawn is walkable, readable and near a useful first activity. Check ordinary players after reconnect, not only administrators teleporting into the area.

Adjust hunger and thirst only after checking the installed status update interval and HUD behavior. Observe a representative session and choose a pace that supports roleplay. Increasing an interval is not a guaranteed FPS fix.

Change economy settings deliberately

Inspect the supported money types, starting balances, negative-balance rules and paycheck mechanism. Starting-money settings may apply only to newly created characters. A debt limit is not a complete inflation control.

Test society payroll when your job resource supports it: funded and empty societies, authorized grades, repeated payments and server restarts. Changing duplicate-license checks will not repair a money-duplication exploit.

Audit permission boundaries

Framework groups, ACE permissions and txAdmin accounts are separate systems. Names such as god, admin and mod do not guarantee a fixed permission set across resources. Test each staff action with the intended role and verify that ordinary players are denied.

Apply server-side checks to rewards and privileged events. A hidden button is not authorization.

Accept one change at a time

1. Write the intended outcome and the setting/resource responsible.
2. Change one value on staging and test the normal and failure paths.
3. Measure client or server performance with the appropriate tool if that is the goal. Use the official profiler workflow rather than invented slash commands.
4. Reconnect, restart and compare saved data. Record the result and deploy only the accepted configuration with a rollback copy.

Reference documentation

Source: qbcore-fivem/qb-core · Cfx.re — server security