How to Set Up a FiveM Development Environment (2026)

Why You Need a Local Dev Environment

Developing FiveM scripts directly on a production server is a common mistake. Every restart kicks players, every error crashes the server, and there is no debugger. A local development environment gives you:

• Instant restarts — No players affected
• Full error output — Uncensored stack traces in the console
• Debugger support — Breakpoints and variable inspection
• Version control — Git integration for every resource
• Database isolation — Test schema changes without risk

This guide walks through setting up a complete local development environment in 2026.

Step 1: Install the FiveM Server Artifacts

Download the latest recommended server artifacts from the FiveM artifacts page. Choose the recommended build, not latest — the latest can have regressions.

Directory Structure

C:/
└── fivem-dev/
    ├── server/           # Server artifacts
    │   ├── FXServer.exe
    │   └── ...
    ├── txData/           # txAdmin data(auto-created)
    └── resources/        # Your resources
        ├── [framework]/
        ├── [standalone]/
        └── [dev]/        # Your scripts in development

First Boot

Run FXServer.exe to start txAdmin. On first run, it opens a web panel at http://localhost:40120.

1. Create a master password
2. Select Local Server deployment
3. Choose your framework recipe (QBCore or ESX)
4. Let txAdmin download and configure the framework
5. Set your server name to something like [DEV] My Server

Step 2: Local Database with MariaDB

Most FiveM scripts require MySQL. Install MariaDB locally:

Install MariaDB

Download MariaDB from mariadb.org/download. During installation:

• Set the root password to something simple like root (this is local only)
• Enable TCP/IP on port 3306
• Add the bin directory to PATH

Create the Development Database

CREATE DATABASE fivem_dev CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'fivem'@'localhost' IDENTIFIED BY 'fivem';
GRANT ALL PRIVILEGES ON fivem_dev.* TO 'fivem'@'localhost';
FLUSH PRIVILEGES;

Configure oxmysql

In your server.cfg:

set mysql_connection_string "mysql://fivem:fivem@localhost:3306/fivem_dev?charset=utf8mb4"
ensure oxmysql

HeidiSQL or DBeaver

Install a database GUI. HeidiSQL (Windows) or DBeaver (cross-platform) let you browse tables, run queries, and import/export data. This is essential for debugging inventory issues, job data, or player records.

Step 3: VS Code Setup

Extensions

Install these VS Code extensions for FiveM development:

Lua Language Server Configuration

Create .luarc.json in your resource root:

{
  "runtime": {
    "version": "Lua 5.4"
  },
  "diagnostics": {
    "globals": [
      "CreateThread",
      "Wait",
      "RegisterNetEvent",
      "RegisterServerEvent",
      "AddEventHandler",
      "TriggerEvent",
      "TriggerServerEvent",
      "TriggerClientEvent",
      "RegisterCommand",
      "RegisterNUICallback",
      "SendNUIMessage",
      "SetNuiFocus",
      "GetCurrentResourceName",
      "exports",
      "ESX",
      "QBCore",
      "lib",
      "MySQL"
    ]
  },
  "workspace": {
    "checkThirdParty": false
  }
}

This tells the Lua language server about FiveM globals so it does not flag them as undefined.

Step 4: Live Reload Without Restarts

File Watcher with ensure

The fastest workflow: edit your Lua file, save, then type in the txAdmin console:

ensure my-resource

This hot-reloads the resource without restarting the server. All other resources stay running.

Automatic Reload

txAdmin has a built-in resource monitor. In the txAdmin panel, go to Settings and enable resource file change detection. When you save a Lua file, txAdmin automatically restarts that resource.

For NUI resources with Vite, run the dev server in parallel:

cd my-resource/web
npm run dev

Changes in Vue files reflect instantly in-game without any restart.

Step 5: Debugging Lua Scripts

Print Debugging (Quick)

The simplest debugging method:

-- Client-side: prints to F8 console
print(('[%s] Player ped: %d, coords: %s'):format(
    GetCurrentResourceName(),
    PlayerPedId(),
    tostring(GetEntityCoords(PlayerPedId()))
))

-- Server-side: prints to server console
print(('[%s] Player %s triggered event with data: %s'):format(
    GetCurrentResourceName(),
    source,
    json.encode(data)
))

Structured Logging

For complex resources, create a logging helper:

-- shared/utils.lua
local resourceName = GetCurrentResourceName()

function Log(level, msg, ...)
    local prefix = ('[%s][%s]'):format(resourceName, level)
    if ... then
        print(prefix, msg:format(...))
    else
        print(prefix, msg)
    end
end

-- Usage:
Log('DEBUG', 'Player %d entered zone %s', playerId, zoneName)
Log('ERROR', 'Failed to load config: %s', err)

Using the FiveM Profiler

For performance debugging, use the built-in profiler as covered in our QBCore FPS optimization guide:

profiler record 10

This records 10 seconds of execution data and generates a flame graph you can analyze in your browser.

Step 6: Git Workflow for Resources

Repository Structure

Two common approaches:

Approach A: Monorepo — One git repo for the entire server:

my-server/
├── .git/
├── server.cfg
├── resources/
│   ├── [qb]/
│   ├── [standalone]/
│   └── [custom]/
│       ├── my-jobs/
│       └── my-hud/
└── .gitignore

Approach B: Per-Resource Repos — Each custom resource is its own repo:

resources/
├── [qb]/              # Framework(submodule or ignored)
└── [custom]/
    ├── my-jobs/.git   # Separate repo
    └── my-hud/.git    # Separate repo

.gitignore for FiveM

# Node modules(for NUI resources)
node_modules/
dist/

# Framework files(managed separately)
[qb]/
[standalone]/

# txAdmin data
txData/

# Cache
cache/

# Environment files
.env

Branching Strategy

For a FiveM dev team:

• main — What runs on the live server
• dev — What runs on the local dev server
• feature/job-system — Individual features in development
• Merge feature into dev, test, then merge dev into main and deploy

Step 7: Testing Checklist

Before moving any resource from dev to production:

1. resmon check — Run resmon 1 and verify client ms is under 0.5ms idle
2. Error check — Open F8 console and check for any red errors
3. Database check — Verify all tables were created and migrations ran
4. Multi-player test — Use a second FiveM client or ask a team member to join
5. Framework events — Test that QBCore/ESX events fire correctly (job changes, inventory, etc.)
6. Resource restart — Restart the resource 5 times in a row and check for memory leaks or orphaned entities
7. Edge cases — Test what happens when the player disconnects mid-action

How Alone Scripts Fits Into Your Dev Workflow

Every resource from Alone Scripts includes a config.lua and bridge files that are open and editable. You can set up your local dev server, ensure our resource, and start customizing the config immediately.

Our Jobs Creator ships with a clean config structure that you can version-control separately from the encrypted core. The Dynamic Fishing system includes a debug mode with zone visualization and catch logging for local testing.

→ Browse our scripts and start building