Configuration

Overview

Every product comes with its own complete documentation and preview. You can also find detailed information, features, and important details about each product directly in its product description or the documentation of that specific product.

Configuration file structure

Most resources use config.lua; some companion tools use config.json. Keep the file valid, preserve required keys, and use the resource name exactly as installed. Lua supports comments beginning with --; JSON does not support comments or trailing commas.

Basic settings

• Set Config.Locale to an installed language code such as en.
• Set Config.Debug to false on a live server.
• Enter job, role, item, and location identifiers exactly as they exist in your framework.
• Use the displayed resource name in server.cfg and dependency declarations.

Advanced settings

Advanced options control permissions, feature toggles, webhooks, cooldowns, and integration behavior. Change one setting at a time and restart the resource between tests. If an option is absent from the distributed file, do not invent it; update to the documented release or ask support before adding it.

Framework-specific settings

• ESX: Verify es_extended starts before the resource that you purchased if it is made for ESX.
• QBCore: Verify qb-core starts before the resource that you purchased if it is made for QB.
• QBox: Verify qbx_core starts before the resource that you purchased if it is made for QBOX.
• Standalone: If a resource is marked as "standalone", this means that the script is usable on every framework, including custom ones. It does not require any other resources or anything extra.

Performance settings

Use conservative refresh intervals, limit drawing or proximity checks to nearby players, and disable unused integrations. Avoid running debug logging, frequent database polling, or large loops in production. Test changes with your normal player load rather than relying only on an empty development server.

Security recommendations

Never publish API tokens, database passwords, or Discord webhooks. Restrict this information using the instructions we give for every script, validate permissions server-side, and follow every other required security step.

Database configuration

Import the resource SQL file before starting the resource, then set the database connection through your server's database adapter. Use the adapter supported by the resource, commonly oxmysql. Confirm the selected database is the same one your framework uses and back it up before applying schema changes.

Example config.lua

Config = {}
Config.Locale = 'en'
Config.Debug = false
Config.Framework = 'auto' -- auto, esx, qbcore, qbox, standalone
Config.Database = 'oxmysql'
Config.RefreshInterval = 1500
Config.AllowedJobs = { 'police', 'ambulance' }
Config.Webhook = '' -- keep secrets out of version control

Example config.json

{
  "locale": "en",
  "debug": false,
  "framework": "auto",
  "database": "oxmysql",
  "refreshInterval": 1500,
  "allowedJobs": ["police", "ambulance"]
}

Common mistakes

• Using smart quotes, missing commas, or trailing commas in JSON.
• Renaming required keys or changing an expected value type.
• Leaving debug mode enabled on a production server.
• Adding ensure with a folder name that differs from the actual resource name.
• Updating the resource and overwriting a known-good configuration without comparing changes.

Best practices

• Keep a clean copy of the release configuration beside your customized version.
• Document why non-default values were changed and who changed them.
• Store secrets in server-side environment configuration where the resource supports it.
• Test configuration changes on a staging server before a busy restart.
• Review release notes for newly required settings and deprecated options.

Configuration FAQ