Skip to main content
A provider is the family the bridge selects for a given role — for example the esx framework provider or the ox inventory provider. Each provider is backed by an adapter: the implementation that translates that family’s API into the bridge’s normalized contract. You pick a provider with a convar; the bridge loads the matching adapter. Most owners can leave every provider on auto. The bridge detects what you run at startup and loads the right adapter.

​
Auto-detection order

When a convar is auto, the bridge checks for started resources in a fixed priority order and selects the first match. If nothing matches, it falls back to the standalone provider.
Resolved once at boot from the atlas:framework convar.
Framework and inventory are detected once at boot. Auto-detection only sees resources that are already started, so your framework and inventory must start before atlasBridge. If you cannot control start order, force the provider with a convar.

​
Supported providers

For the exact convar names, values, and defaults, see the Configuration reference.

​
UI defaults to the bridge’s own NUI

The default UI provider is the bridge’s own zero-dependency NUI. ox_lib is opt-in — set atlas:ui "ox" (and start ox_lib) to use it. UI is resolved one subsystem at a time, with a safety net: anything a provider does not implement falls back to the bridge’s own NUI. That means you can mix providers — for example ox_lib progress bars with bridge-owned notifications — and never end up with a missing UI. The radial menu and interaction prompts are always the bridge’s own.

​
When to force a provider

Set a provider explicitly instead of auto when:
  • Start order is wrong. A framework or inventory that starts after the bridge will be missed by detection.
  • You run more than one candidate. During a migration you may have two frameworks or inventories installed; force the one you actually use.
  • You want ox_lib UI. The bridge defaults to its own NUI; set atlas:ui "ox" (with ox_lib started) to use ox_lib instead.
  • Your stack is unsupported. Use custom and fill the editable adapter — see Custom Framework and Custom Inventory.
Example — a QB-Core server using ox_inventory and forcing bridge-owned UI:

​
Custom providers

When a provider is set to custom, the bridge loads your editable adapter instead of a shipped one:
  • atlas:framework "custom" → editable/framework/{server,client}.lua
  • atlas:inventory "custom" → editable/inventory/{server,client}.lua
If your custom adapter fails to load, the bridge falls back to the _default adapter so the server still starts. Each editable file lists every method with its expected parameters and return shape.

Custom framework adapter

The full framework contract and a complete worked example.

Custom inventory adapter

Item shapes and the inventory method set.