Skip to main content
The Bridge global ships a complete UI library. Every component is a single line of Lua — Bridge.Notify(...), Bridge.Progress(...), Bridge.Menu.Open(...) — that renders on the bridge’s own NUI. No frontend to build, no extra resource to install, no markup to write.
The bridge’s own NUI is the default renderer. ox_lib is opt-in — set atlas:ui "ox" (and start ox_lib) to swap every call site over to it. You write the same Lua either way.

​
Themed by the accent

Every component reads the live server accent color (atlas:theme:color) automatically — toggles, progress fills, confirm badges, the radial wheel, and skill-check zones all tint to match. When an admin changes the accent, the UI follows without a restart. You never pass a color.

​
Provider selection

UI resolves to a provider per call, so a renderer that starts late is still picked up. The default is the bridge’s own NUI.
Anything a chosen provider does not implement falls back to the bridge’s own NUI automatically, so a call never silently does nothing. Radial and Interact are always the bridge’s own NUI regardless of provider.

​
Per-subsystem overrides

Pin a single component to a different renderer without changing the rest. Each is a provider id; blank inherits atlas:ui.
Bridge.Target reads its own convar, atlas:target (auto | ox | qb | own | custom) — not atlas:ui:target. See Target.

​
Components

Notifications

Toast feedback. The only UI callable from the server (targeted at a player).

Progress

Blocking progress bar with optional prop + animation. Returns completed/cancelled.

Text UI

A persistent help label ([E] Open shop). Show and hide.

Menus

Menu (toggles/steppers, stays open) and Context (a simple action list).

Input & Confirm

Blocking forms (Input) and yes/no dialogs (Confirm).

Skill Check

Blocking timing minigame — circle, bar, or key sequence.

Radial

A radial action wheel with optional submenus.

Target

Entity/zone targeting — ox_target → qb-target → own.

​
Server vs client availability

Almost all UI is client-only — it renders on a player’s screen, so it lives in your client VM. The one exception is Notify, which you can call from the server to push a toast to a specific player.
The blocking components — Progress, Input, Confirm, SkillCheck — yield until the player finishes. Always call them inside a CreateThread, command, or event callback, never at file top level.