Use FxDK for a local FiveM project

FxDK is the FiveM local development environment, not a production host or a multiplayer test server. The documented environment is Windows/FiveM-based and single-user. Do not follow invented macOS application paths; macOS and Linux can edit source or run compatible build tools without providing the Windows FxDK client itself.

Choose the correct workflow

The official FxDK overview  and resource workflow  define current support. Check those and the selected FiveM track before choosing a toolchain; this guide does not assume the Legacy FxDK pipeline is an Enhanced certification path.

Start with an isolated project

Install the supported Windows FiveM client and the required purchased game. Launch FxDK through the currently documented FiveM development environment, create or open a project in a dedicated directory, and add only the resources needed for the task. Keep the project separate from your production server-data and database. Enable a resource deliberately rather than copying a full storefront server pack and debugging every dependency at once.

For a reproducible first resource, use the original runtime lab: compile its C# client/server output outside the game first, add the runtime-lab folder to the project, enable it and inspect the startup messages. The manifest includes a real fxdk_build_command pointing to its tested Node build script. The build guide walks through the produced files and deployment handoff.

Detect FxDK without creating a security bypass

A resource can identify this environment with the documented convar:

local runningInFxdk = GetConvarInt('sv_fxdkMode', 0) == 1
if runningInFxdk then
    print('[Development] FxDK environment: use isolated fixture data.')
end

Do not turn this into “skip every permission check when a flag is true.” The local FxDK player does not necessarily have the identifiers your production authentication flow expects. Substitute explicit development fixture data inside an isolated project, not an unguarded admin grant or a fallback that accidentally persists into production.

Validate what the environment can actually prove

Check manifest parsing, resource start/stop, client/server console messages, UI rendering and asset placement. Record those separately from a compiler pass. Then test the exported build on a standalone development server with real session identifiers and at least two clients before making claims about synchronization or account flows.

If the resource works in FxDK but fails after export, first compare enabled resources, compiled filenames, dependencies, .fxdkignore, private configuration and game track. If it only fails with another player, move to the multiplayer acceptance matrix rather than repeatedly rebuilding the same single-user project. No graphical FxDK launch or game-runtime execution was performed by the website CI; its evidence covers the explicit compiler and source/package checks.