Choosing and updating FiveM server artifacts

#latest vs recommended

The download page offers two moving targets and a list of pinned builds. "Latest" is the newest build that compiled and passed CI. "Recommended" is a build that has been running in the wild long enough that the obvious problems have surfaced.

On a live server, run recommended. The only good reason to run latest is that you need a native or a fix that only exists there, and in that case you should know exactly which one.

#Where the artifact lives

Keep the artifact separate from your server data. The layout below survives updates, because updating means adding a new folder next to the old one and changing one line in the start script — not overwriting anything.

C:\FXServer\
├─ artifacts\
│  ├─ 12053\        <- the build you are running
│  │  └─ FXServer.exe
│  └─ 11996\        <- the previous one, kept for rollback
├─ server-data\
│  ├─ resources\
│  ├─ cache\
│  └─ server.cfg
└─ start.bat

#A start script you can roll back in ten seconds

The entire point of this layout is that BUILD is one variable. To roll back, change the number and restart.

@echo off
set BUILD=12053
set ROOT=C:\FXServer

cd /d "%ROOT%\server-data"
"%ROOT%\artifacts\%BUILD%\FXServer.exe" +exec server.cfg
pause

#!/usr/bin/env bash
BUILD=12053
ROOT=/opt/fxserver

cd "$ROOT/server-data" || exit 1
exec "$ROOT/artifacts/$BUILD/run.sh" +exec server.cfg

#Updating without breaking the night

1. 01 Read the changelog first

   Cfx.re publishes what changed. Breaking changes to natives and to the resource manifest schema are called out there, and that is usually the only warning you get.

2. 02 Copy, do not replace

   Download the new artifact into artifacts/<new build>/ next to the old one. Nothing about the live server changes yet.

3. 03 Point a test server at it

   Run the new build against a copy of server-data on a different port. Half an hour with three people on it finds more than any amount of reading.

4. 04 Clear the server cache

   Delete server-data/cache/ before the first start on a new build. Stale cached resource metadata produces errors that look like resource bugs.

5. 05 Switch and watch

   Change BUILD, restart, and read the first sixty seconds of console output properly. Most breakage announces itself immediately.

#Game build vs artifact build

These are different numbers and people mix them up constantly. The artifact build (five digits, e.g. 12053) is the server binary. The game build (four digits, e.g. 3258) is the GTA V DLC level the client runs at, and you set it with sv_enforceGameBuild.

A newer artifact lets you enforce a newer game build, but does not do it for you. If you stream content from a recent DLC and it does not appear, the game build is what you check.

#When a new build breaks a resource

It is almost always one of three things: a native that changed signature, an escrow-protected resource compiled against an older runtime, or a manifest field that is now rejected rather than ignored.

The console tells you which resource, and that is enough. Roll back, pin the old build, and update the resource before trying again — do not try to fix a live server forward.

• Read the first error, not the last. Later errors are usually consequences.
• Note the resource name and grep your resources folder for the native mentioned.
• Escrowed resources you cannot edit: the author has to ship a new build. Roll back and contact them.
• If everything breaks at once, it is not the resources — it is the cache. Delete server-data/cache/ and try again.