Configuration

Overview

Every resource ships with defaults intended to work on a clean supported server. Keep your custom values in the provided configuration file, then restart only the affected resource after saving. Read the resource README first: product-specific options always take precedence over this general guide.

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: use the configured ESX import or export for your ESX version and ensure the required job names exist.
• QBCore: verify qb-core starts before the resource and use shared item/job names from your QBCore data.
• QBox: keep qbx_core and supported bridge dependencies current; do not mix legacy QBCore-only integrations unless the product documents them.
• Standalone: enable standalone mode only when the product lists it, then configure any required identifiers and notifications explicitly.

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, Discord webhooks, or Tebex secrets in a public repository. Restrict webhooks to the least information needed, validate permissions server-side, and grant database accounts only the privileges the resource requires.

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