txAdmin recipes: what a build installs

Build it

Server data location:  C:\FXServer\txData\qbox-build
Recipe:                Qbox (downloads resources, imports SQL, writes server.cfg)

Host:      localhost
Port:      3306
Username:  root
Password:  (your database password)
Database:  qbox-build

Performing recipe tasks...
Task: download_github  ok     (qbx_core)
Task: download_github  ok     (ox_lib)
Task: download_github  ok     (oxmysql)
Task: unzip            ok
Task: move_path        ok
Task: connect_database ...

mysql -u root -p

How it works

You picked a recipe, it ran a list of tasks, one task failed, and a clean re-run finished. The thing that turned a scary red wall of text into a five-minute fix was not knowing FiveM internals. It was reading the log to find which task failed and why, then removing that cause and deploying clean. Take the recipe apart now so you know what each piece was doing on your disk.

A recipe is just a list of tasks in a yaml file

A txAdmin recipe is a recipe.yaml file the community publishes for a framework. It is not code that runs on your server; it is a build script for txAdmin that says, in order, what to download and how to wire it up. The tasks you saw scroll past in the log map one-to-one to entries in that yaml. The common ones:

• download_github pulls a resource straight from its GitHub repository. Each framework resource (the core, ox_lib, oxmysql) is one of these. This is the step that needs working internet and a reachable GitHub, which is why a flaky connection or a renamed repo shows up here.
• unzip and move_path arrange the downloaded files into the folder layout the framework expects: the Qbox core under a [qbx] group, the ox resources (ox_lib, oxmysql, ox_target, ox_inventory) under an [ox] group, and genuinely standalone scripts under [standalone].
• connect_database and query_database open your database and import the framework's .sql schema (the tables for players, vehicles, inventory). connect_database is the step that failed for us: the connection handshake is where wrong credentials are rejected, so the deploy never reached the query_database import.
• write_file and replace_string generate your server.cfg and substitute in your license key and database connection string so the server can actually boot.

Read top to bottom, a recipe is: fetch the code, lay it out, build the database, write the config. Every framework recipe is some version of those four moves.

Where the files actually land

Everything a recipe installs goes under the Server data location you named, which lives inside txData. The shape after a Qbox deploy looks like this:

txData/
  qbox-build/
    server.cfg          <- written by the recipe (write_file)
    resources/
      [qbx]/            <- qbx_core and friends (download_github + move_path)
      [ox]/             <- ox_lib, oxmysql, ox_target, ox_inventory
      [standalone]/     <- genuinely standalone scripts
    ...

txData is txAdmin's home for everything that is not FXServer itself: each server you deploy is one folder under it. This matters for recovery. When a deploy fails halfway, the damage is contained to that one qbox-build folder and the database you pointed it at. Nothing outside txData/qbox-build is touched, which is exactly why deploying clean into a fresh folder is safe and reliable: you are not surgically repairing a half-built tree, you are throwing it away and letting the recipe rebuild it correctly from scratch.

Why the database step is the usual first-day wall

Look back at where the deploy stopped. The downloads worked because they only need internet. The database step failed because it needs three things to all be true at once: the database server is running, it is reachable from this machine on the host and port you gave, and the username and password are correct. On a first-time setup, one of those is almost always off. MariaDB is not started, the password has a typo, or localhost is wrong because the database lives in a separate container.

The recipe cannot guess any of that, so it does the honest thing: it tries, fails loudly, names the task, and stops before it writes a broken config. That ER_ACCESS_DENIED_ERROR is not the recipe being fragile. It is the recipe refusing to build a server on top of a database it cannot reach. The fix lives entirely on your side of the wall, which is why you verify the credentials outside txAdmin (mysql -u root -p) before blaming the deploy.

The recovery reflex, generalized

The exact failure you hit was a password. The reflex you just built is bigger than passwords and works for any failed deploy:

1. Find the failed task. The log names it (task #8 (connect_database)). That tells you the category of problem: a download task points at internet/GitHub, a database task points at SQL/credentials, a write_file task points at disk permissions.
2. Read the reason on the same line or just below. Access denied, repository not found, EACCES permission denied: the error string names the cause far more often than beginners expect.
3. Fix the cause where it lives, outside txAdmin if you can, so you confirm the fix before re-running.
4. Deploy clean into a fresh or wiped folder so no half-built state survives.

That loop, read the failed task, fix the cause, deploy clean, is the entire first-day survival skill for txAdmin recipes. Master it once here and you will never panic at a red deploy log again.

If something went wrong

What you can do now

• Start a framework server from a txAdmin recipe by picking a recipe, naming a server data location, and entering database details.
• Read a recipe as a list of tasks: download_github, unzip, move_path, connect_database, query_database, write_file, replace_string.
• Locate where a deploy puts files (txData/<server>) and explain why that containment makes clean redeploys safe.
• Read a failed deploy log to find which task failed and why, instead of guessing.
• Recover from a halfway-failed deploy by fixing the named cause and deploying clean into a fresh folder, not hand-patching a broken one.

Try it yourself