> For the complete documentation index, see [llms.txt](https://brunx-mods.gitbook.io/brunx-mods-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://brunx-mods.gitbook.io/brunx-mods-docs/products/scripts/brunx-bridge/configuration.md).

# Configuration

All settings live in `shared/config.lua`. Cayo Perico has its own file, see [Cayo Perico](/brunx-mods-docs/products/scripts/brunx-bridge/cayo-perico-integration.md). The defaults work on most servers: leave detection on `auto` unless you want to force a system.

## General

{% code title="shared/config.lua" %}

```lua
Config.Debug = false

-- Language file from locales/*.json: en, nl, de, fr, es, pt, it
Config.Locale = 'en'

-- Print the update check in the server console on start.
Config.VersionCheck = true
```

{% endcode %}

| Option                | Default | Description                                                                 |
| --------------------- | ------- | --------------------------------------------------------------------------- |
| `Config.Debug`        | `false` | Prints job lookups, elevator access and framework detection to the console. |
| `Config.Locale`       | `'en'`  | Language for notifications and the UI. Missing keys fall back to English.   |
| `Config.VersionCheck` | `true`  | Compares your version with the latest release on start.                     |

## Framework, inventory and target

{% code title="shared/config.lua" %}

```lua
-- auto, qbox, qbcore, esx, ox, standalone
Config.Framework = 'auto'

-- auto, ox_inventory, qs-inventory, framework
Config.Inventory = 'auto'

-- auto, ox_target, qb-target, drawtext
Config.Target = 'auto'
```

{% endcode %}

{% tabs %}
{% tab title="Framework" %}
With `auto` the bridge picks the first started framework in this order:

1. `qbx_core` → `qbox`
2. `qb-core` → `qbcore`
3. `es_extended` → `esx`
4. `ox_core` → `ox`
5. none → `standalone`

Renamed your framework resource? Add the name to `Config.ResourceNames.Frameworks`.
{% endtab %}

{% tab title="Inventory" %}
With `auto` the bridge uses:

1. `ox_inventory` when it is started
2. `qs-inventory` when it is started
3. otherwise `framework`

`framework` calls the framework's own item functions. That covers qb-inventory, ps-inventory, lj-inventory, the ESX inventory and inventories that hook into those, such as codem-inventory, origen\_inventory and core\_inventory.
{% endtab %}

{% tab title="Target" %}
With `auto` the bridge uses `ox_target` or `qb-target`, whichever is started. Without either it uses `drawtext`: an `[E]` prompt for box and sphere zones. See [Target](/brunx-mods-docs/products/scripts/brunx-bridge/target-integration.md).
{% endtab %}
{% endtabs %}

## Notifications

{% code title="shared/config.lua" %}

```lua
-- ox_lib, framework (QBCore / ESX notify, ox_lib on Qbox), okokNotify, native
Config.NotifySystem = 'ox_lib'

-- Title for notifications that do not set one themselves. nil shows no title.
Config.NotifyTitle = nil

Config.DefaultNotify = {
    position = 'top-right',
    duration = 4500
}
```

{% endcode %}

| `Config.NotifySystem` | Uses                                                                                               |
| --------------------- | -------------------------------------------------------------------------------------------------- |
| `ox_lib`              | `lib.notify`                                                                                       |
| `framework`           | `QBCore.Functions.Notify` on QBCore, `ESX.ShowNotification` on ESX, ox\_lib on Qbox and standalone |
| `okokNotify`          | `exports.okokNotify:Alert`, falls back to ox\_lib when okokNotify is not started                   |
| `native`              | GTA feed notification                                                                              |

Notification types are `inform`, `success`, `error` and `warning`. The bridge maps them to the names each system expects.

## Custom jobs

Standalone servers, or servers with their own job system, can supply jobs to the bridge. The function runs server-side before the framework lookup. Return `nil` to fall back to the framework.

{% code title="shared/config.lua" %}

```lua
Config.CustomGetPlayerJob = function(source)
    local job = exports.my_jobs:GetJob(source)
    if not job then return nil end

    return {
        name = job.name,
        label = job.label,
        grade = job.grade,
        gradeLabel = job.gradeLabel,
        isBoss = job.isBoss,
        type = job.type,  -- e.g. 'leo' or 'ems', used by elevator jobTypes
        duty = job.onDuty
    }
end
```

{% endcode %}

## UI defaults

{% code title="shared/config.lua" %}

```lua
Config.DrawText = {
    distance = 2.0,
    interactKey = 38, -- E
    position = 'left-center',
    icon = 'hand-pointer'
}

Config.DefaultProgress = {
    canCancel = true,
    disable = { move = true, car = true, combat = true }
}
```

{% endcode %}

`Config.DrawText` styles the target fallback prompt. `Config.DefaultProgress` fills in any field you leave out when calling [`Bridge.Progress`](/brunx-mods-docs/products/scripts/brunx-bridge/client-api.md#ui).

## CompChecker

{% code title="shared/config.lua" %}

```lua
Config.CompChecker = {
    enabled = true,
    command = 'compchecker',
    startupScan = true, -- print a duplicate report in the server console on start
    prints = true       -- false hides all [CompChecker] output except errors
}
```

{% endcode %}

See [CompChecker](/brunx-mods-docs/products/scripts/brunx-bridge/compchecker.md).

## Elevators

The elevator options (`Config.Elevators`, `Config.GlobalElevators`, `Config.MapElevators` and the carry settings) are explained on the [Elevators](/brunx-mods-docs/products/scripts/brunx-bridge/elevators.md) page.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://brunx-mods.gitbook.io/brunx-mods-docs/products/scripts/brunx-bridge/configuration.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.