Skip to content
Vice Drip
Free tool · client-side only

FiveM Stack Compatibility Checker

Select your framework, database layer, inventory, and target system, plus whether the resource uses ox_lib, NUI, or is escrowed. This tool reasons through named conflict patterns worth checking, a suggested install sequence, and a testing checklist — it never promises compatibility, only what's likely, what's worth inspecting, and what commonly needs a bridge.

This runs 100% client-side. It reasons only from the choices you make above and cannot see the actual resource you're installing — nothing you select is transmitted anywhere, logged, or stored.

The resource you're checking

Every result updates the moment you change a selection. There is no fetch, no upload, no server — this reasons only from the four selects and three checkboxes above, and it cannot see the actual resource you're installing. Open your browser's network tab if you want to confirm nothing leaves this page.

Result

Likely works

Nothing about this declared stack tripped a named check here. That's a reason to proceed carefully, not a guarantee — this tool cannot see the actual resource, only the choices you selected.

Findings — worth checking, not a verdict

  1. Info

    Declares ox_lib

    ox_lib is framework-agnostic and runs the same on Qbox, QBCore, ESX Legacy, and standalone. It only needs to be installed once and started before any resource that calls into it — see the Start Order Checker if you're unsure your server.cfg does that.

Suggested install sequence

  1. 01oxmysql (database connector)
  2. 02Qbox (framework core)
  3. 03ox_lib
  4. 04ox_inventory (inventory)
  5. 05ox_target (target system)
  6. 06This resource itself
  7. 07Anything that depends on this resource, started after it

Testing checklist for this stack

  • • Start the server with only oxmysql and Qbox running and confirm a clean console before adding this resource.
  • • Add this resource alone and read the first lines of console output on that boot, not just the end.
  • • Walk up to one of this resource's interactable points in-game and confirm exactly one prompt appears, not zero and not two.
  • • Measure this resource's resmon idle and active readings alone before judging it against anything else — the resmon calculator on this site turns that into a frame-budget share.
  • • Re-run the Start Order Checker once you've added the ensure line for this resource to your server.cfg.

This reasons from declared stack choices only, and cannot see the actual resource. For a full pre-flight walkthrough once you've decided to install, see the Install Pre-Flight Checklist.

Scope, stated plainly

What this reasons through, and what it does not.

What it does

  • Cross-checks the framework, database, inventory, and target you select for named patterns that commonly need a bridge or are worth a second look.
  • Flags specific conflicts — a target system that doesn't match your framework's common default, an inventory from a different framework's ecosystem, or an escrowed resource that cannot be patched later.
  • Suggests an install sequence and a testing checklist tailored to the exact stack you selected.

What it does NOT do

  • Does not read the actual resource you're installing — it only reasons from the stack choices you select here.
  • Never states a combination is "compatible": findings are phrased as likely, worth inspecting, or commonly needs a bridge, never a guarantee.
  • Does not know the resource's real dependency list, its actual code, or its author's tested-version matrix.
  • A "likely works" result is not a certification that nothing will break.
How to use it

Four steps.

  1. 01

    Pick the framework, database, inventory, and target you're running, or planning to run.

  2. 02

    Tick whichever of ox_lib, NUI, or escrowed actually describes the resource you're checking.

  3. 03

    Read the tier, the findings, and the testing checklist — every one updates live as you change a selection.

  4. 04

    Work through the suggested install sequence, then the testing checklist, before trusting the result.

Why this stays hedged

Most "it's just incompatible" reports were knowable in advance.

A support ticket that says a resource is incompatible is almost always a mismatch that was findable before install: a resource built for one framework's inventory running against another, a target system fighting a second one nobody remembered was still running, or an escrowed resource that quietly never supported the stack it was dropped onto. None of that requires reading the resource's code — it only requires writing down the stack you actually have and checking it against what the resource declares, before you install rather than after.

It's also why a single, open framework bridge exists at all rather than three separate framework-specific forks — see how frameworks compare on Qbox, QBCore, and ESX Legacy, or read what asset escrow actually locks down.

Questions, answered directly

Before you trust a result.

Does this tool tell me my resources will actually work together?

No — it cannot see your actual resources, only the framework, database, inventory, and target you select here. It reasons from a short, named set of common pairing patterns and flags what's worth checking; it never asserts a guarantee, and a "likely works" result is not a certification.

Why did it flag my combination when I know it works fine on my server?

The checks here compare your selections against common ecosystem pairings, not your actual, working setup. Plenty of servers run a resource from outside a framework's usual ecosystem successfully, often behind a bridge the author already ships. A finding means "worth a second look," not "broken."

What does "commonly needs a bridge or a fork" actually mean?

It means at least one selection — most often an inventory or target from a different framework's ecosystem, especially combined with an escrowed resource — is a pattern that, in practice, usually needs a bridge resource, a fork maintained for your framework, or explicit author support to function. It's a prompt to go check, not a verdict.

It marked an escrowed resource as risky — does that mean escrow is bad?

No. Escrow (Cfx asset encryption) is how most commercial FiveM resources protect their code, including some of Vice Drip's own paid products once they ship. The finding exists because escrowed code cannot be opened and patched by you if it turns out not to support your stack — so the diligence has to happen before you buy, not after, by checking the listing for explicit support rather than assuming it.

Is anything I select here sent anywhere?

No. Every calculation happens in plain JavaScript in your browser the moment you change a selection. There is no fetch call, no upload, and nothing is logged or stored — open your browser's network tab if you want to confirm that yourself.

More

Planning a whole server rather than one resource? Try the Server Stack Planner. Ready to install? Work through the Install Pre-Flight Checklist and re-check ordering with the Start Order Checker. Measuring performance after install? See the resmon calculator. Pasting a config or log for help? Scan it for secrets first. For a doc-grounded read of an actual error message, try Install Concierge. Back to the tools hub.

This tool cross-checks declared stack choices against a short, named list of patterns. It never states a combination is compatible, does not read your actual resource, and is a utility, not a Vice Drip product claim.

Last verified: 2026-09-02