What is FivePanel?

Most server owners who want a web panel end up choosing between three imperfect options. The first is pointing a direct database GUI such as phpMyAdmin or MongoDB Compass at the production database: this gets data on screen quickly, but it grants whoever holds the credentials unrestricted read and write access to every table, with no audit trail of what was viewed, changed, or deleted, and it typically requires exposing the database port to the internet or tunneling around the problem. The second is a hand-rolled panel, usually a collection of Lua exports paired with a small PHP or Node backend: it can be tailored exactly to one server's needs, but it is also fragile — every framework update, column rename, or export signature change can silently break it, and the maintenance burden falls entirely on whoever wrote it.

The third option is a generic low-code builder such as Retool or Appsmith connected directly to the database. These tools are more capable than a one-off script, but they assume the operator already knows the schema and is comfortable writing SQL, they have no notion of FiveM- or RedM-specific conventions like JSON-stringified metadata columns or identifier arrays, and — like the first option — they still require the database to be reachable from wherever the builder runs.

FivePanel is built around a different set of constraints. Instead of exposing the database, a small agent runs on the same machine (or network) as the database and opens a single outbound, encrypted connection to the FivePanel gateway; no inbound port is ever opened on the database. The agent reports a sampled view of the schema, which FivePanel uses to infer tables, fields, and likely data types — including unpacking JSON columns that frameworks commonly use for character metadata — without requiring anyone to write a line of SQL. From there, panels are assembled by dragging and dropping pre-built widgets onto a grid and binding them to the inferred fields, rather than by writing queries or frontend code.

FivePanel natively supports both MySQL/MariaDB and MongoDB as connection targets for the agent. In both cases, the connection is configured once, as a single connection string supplied to the agent (a MySQL DSN or a MongoDB URI), and the agent handles the rest of the communication with FivePanel's gateway.

Critically, the agent has no framework-specific code path. It does not hardcode table names, column names, or collection shapes for any particular FiveM or RedM framework. Instead, it samples live data from whatever database it is pointed at and infers structure — tables, fields, likely types, and nested JSON shapes — directly from that data. In practice, this means the agent works with QBCore, ESX, vRP, OxCore, or a fully custom schema equally well, because from the agent's point of view they are all just data. The examples in the table below are common real-world setups you will see documented throughout these docs, not a fixed list of "supported frameworks" — if your schema doesn't match any of them, the same inference process still applies.