FiveM Server Artifacts Explained: Recommended vs Latest and When to Update

The single most-quoted line in FiveM support tickets is “update your artifacts,” and it’s quoted that often because it’s usually right. Your fivem server artifacts are the FXServer build that everything else runs on top of, and the version number is invisible right up until the moment a brand-new script throws a native error and the city won’t load. Nobody thinks about the build until it breaks something, and by then you’re already debugging the wrong layer.

What a server artifact actually is

An artifact is a numbered build of the FXServer binary, published by Cfx.re from their runtime/artifacts page. On Linux you get a tarball containing the FXServer binary and the run.sh launcher; on Windows it’s a zip with FXServer.exe and FXServer.com. The number you care about is the build ID — something like 12345 — and it’s the version of the server-side runtime, the embedded CitizenFX client compatibility, and the set of game natives your scripts are allowed to call.

That last part is the kicker. Your resources don’t ship the runtime; they assume it. When a script’s docs say “requires build 7290 or higher,” they mean a native or a server API that simply did not exist in older binaries. The artifact is the floor everything stands on, and it’s the one thing in your whole stack that you don’t install from your server.cfg setup guide on scripts-tebex.io — you install it before server.cfg ever loads.

The channels: recommended vs latest vs critical

Cfx.re publishes two channels and tags individual builds, and the difference is exactly where most owners get it wrong:

• Recommended — the build Cfx.re has soaked and considers stable for production. This is your default. Run this on a live server unless you have a specific reason not to.
• Latest — the newest build off the pipeline. It has the freshest natives and fixes, and also the freshest regressions. Useful when a script you need requires a build newer than current recommended.
• Critical / optional tags — individual builds get flagged. A “critical” tag means a security or stability fix you should not skip; “optional” is a normal incremental.

There’s also a hard floor you can’t ignore: builds expire. Cfx.re sets an EOL date on older artifacts, and once a build passes it, clients are blocked from connecting and the server refuses to start. That deadline is deliberate — it’s the lever that forces the fleet off ancient binaries. If you’ve ever seen a server suddenly die with no config change, an expired artifact is the first thing to check.

The decision in plain terms: run recommended on production. Move to a specific latest build only when a script explicitly demands it, and when you do, pin that exact number rather than tracking “latest” forever. Tracking latest blindly means every server boot is a coin flip on whatever Cfx.re shipped that hour.

Why an outdated artifact silently breaks new scripts

Here’s why “update your artifacts” is the reflex first reply. A modern script calls newer server APIs, newer state-bag behavior, newer OneSync features, or natives added in the last few months. On an old build those calls don’t error politely — they return nil, or they no-op, or they throw deep in a dependency. The symptom shows up three layers away from the cause: a vehicle won’t spawn, a player slot silently fails, an event never fires. You’ll burn an evening blaming the script when the binary underneath it is two hundred builds stale.

This is especially brutal with framework cores. A current qb-core install from qb-tebex.io leans on recent server functionality, and running it on a year-old artifact produces exactly these ghost failures — players join, then half the resources never initialize. The framework isn’t broken; the floor under it is too low.

How to update safely

You have two clean paths.

• txAdmin — the supported route. txAdmin reads your current build, shows you what recommended and latest are, and runs the swap with one click plus a restart. It backs up enough to roll forward cleanly and it tells you the exact build number it moved you to. For most servers this is the right tool, full stop.
• Manual swap on Linux — download the artifact tarball, extract it into a new folder (never overwrite the running one), and point your run.sh at the new binary path. Keep the old folder. Your server-data and resources live separately, so swapping the binary folder is non-destructive if you keep them split.
• Manual swap on Windows — same idea: unzip the new artifact into its own directory, update your startup batch file to launch the new FXServer.exe, and leave the previous build folder untouched as your fallback.

Whichever path, the rule is the same: the binary and your data are separate things. Never extract an artifact on top of your live server folder, because the day you need to roll back you’ll want the old binary sitting right there.

Pinning and rolling back to a known-good build

“Pinning” just means committing to a specific build number and not moving off it without a reason. Write the build ID into your deployment notes. When you keep each artifact in its own folder, a rollback is a one-line change to run.sh or your batch file pointing back at the last folder that worked — no re-download, no panic. This is the entire reason the staged-folder approach beats drag-and-drop: rolling back is instant, not a scramble at 2 AM.

One real upside of staying current that owners underrate: newer builds ship genuine performance work — scheduler improvements, networking fixes, lower idle overhead. If you’ve ever chased frame-time and thread-time numbers in a resource monitor from 0resmon-tebex.io and wondered why your baseline drifts, part of that baseline is the artifact itself. An update can quietly hand you headroom you were about to pay for in optimization time.

Test on staging before you touch live

The whole discipline collapses without this step. Keep a staging server — same resources, same database snapshot, separate port — and apply the artifact bump there first. Boot it, watch the console for native errors, join, and exercise the scripts most likely to be build-sensitive: spawning, inventory, anything with state bags. Twenty minutes on staging catches the regression that would otherwise hit forty live players at once. Recommended on production, latest only when forced, every bump rehearsed on staging first, and the old build folder always one config line away — do that and artifacts stop being the thing that surprises you.