FiveM artifacts: updating FXServer safely

FiveM server "artifacts" are the FXServer builds Cfx.re publishes at runtime.fivem.net/artifacts/fivem/, one list for Linux and one for Windows, each marking a recommended build and a newer optional one. Run the recommended build, update when it moves or when a framework or escrowed resource asks for something newer, and always update by putting the new build beside the old one rather than over it, so rolling back is renaming a folder. txAdmin ships inside the artifact, so it updates with it. Your server-data folder, your database and txAdmin's own data folder are what you back up before each update - the binary is disposable. This guide covers what the four separate version numbers on a FiveM server are, how to read the artifact list, the update procedure on both platforms, testing, and what to do when a build breaks something.

Four versions that move independently#

"Update the server" means different things depending on who says it. A FiveM server has four layers, each with its own version and its own schedule:

This post is about the first two. The game build pins which GTA Online update clients must be on and is covered in FiveM server.cfg explained. Framework updates are their own discipline, covered in FiveM frameworks compared. The reason to keep the four apart in your head is that most "the update broke my server" stories are two of them changed on the same evening, and nobody can tell which one did it.

The player's FiveM client updates itself and is not tied to your server build. When Rockstar patches GTA V, the client is sometimes broken for everyone until Cfx.re catches up; your server is not involved and nothing you update will fix it.

Reading the artifact list#

The artifact index has two paths:

Linux:   https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/Windows: https://runtime.fivem.net/artifacts/fivem/build_server_windows/master/

Each page lists builds by number, newest first, and highlights two of them:

• Latest recommended. A build Cfx.re considers stable for production. This is what you run.
• Latest optional. Newer, with fixes and features that have not had as much exposure. Run it on a test server if you need something in it.

Everything below those is older. Builds well behind the recommended one get warnings in the console, and Cfx.re has in the past stopped supporting builds old enough to be a security or compatibility problem, so "never update" is not a strategy either. The build number is printed when the server starts:

FXServer-master SERVER v1.0.0.12345 linux

Note it down before every update. "Which build were we on when it last worked" is the first question in every rollback, and nobody remembers.

Cfx.re publishes changelogs for server builds on its forum and documentation. Skim them for the range between your build and the target: changes to natives your resources use, OneSync behaviour, and txAdmin version bumps are the lines that matter.

When to update#

Updating for its own sake costs an evening and risks a broken weekend. The reasons that are worth it:

• The recommended build moved and you are several behind. Stay within a few weeks of recommended; falling far behind turns one small update into a large one.
• A resource requires it. Current libraries and frameworks state a minimum server build - Overextended's resources are strict about this - and escrowed resources need a reasonably current build to validate.
• A fix you need. A crash or sync bug listed in the changelog that matches what you see.
• A security fix. Read the announcement and update promptly.

And the reasons that are not: a forum post saying the latest optional build is faster, or a new feature you have no use for.

Updating the binary#

The procedure is the same everywhere in principle - new build beside the old, stop cleanly, swap, start, keep the old one until the new one has proved itself - and differs only in the commands.

On Linux

The conventional layout keeps the binary apart from your data, so the binary can be replaced wholesale:

/home/fivem/  server/          the artifact - replaced on update  server-data/     resources, server.cfg - backed up, never replaced  txData/          txAdmin's settings, admins, players, bans

The update, with the old build kept beside the new one:

$ cd /home/fivem$ wget -O fx.tar.xz "https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/<build>/fx.tar.xz"$ mkdir server-new && tar xf fx.tar.xz -C server-new# stop the server cleanly here, then:$ mv server server-old && mv server-new server$ cd server-data && bash ../server/run.sh +exec server.cfg

Take the exact download link from the artifact page; each build has its own folder name. If the new build misbehaves, stop it and swap the folder names back. Delete server-old only after the new build has run through a full evening of real players.

If you start the server through txAdmin, start run.sh without +exec as you did before; txAdmin finds its data folder and launches FXServer with your configuration.

On Windows

The Windows artifact is a server.7z archive containing FXServer.exe and its files. The procedure is the same in spirit: extract the new build into a new folder, stop the server, rename the old folder out of the way, rename the new one into place, and start it with the same shortcut or batch file. Never extract a new build over the top of a running one; files in use will not be replaced, and you end up with a mixture of two builds that fails in strange ways.

On a panel host

On a Pterodactyl-based panel the artifact lives in the server's own files and is fetched by the install script. FiveM eggs usually expose the build to run as a variable on the Startup tab - a version field that accepts a build number or a keyword such as recommended - and the install or update step downloads it. Look at the Startup tab on your server to see what it offers before assuming.

On RE:NODE, take a backup from the panel before changing the build; restoring is one button and backups are stored off the machine, so the safety net costs nothing. A backup can also be locked so scheduled rotation cannot delete the copy you took before the update. Your database lives in its own slot, so back that up separately - the full method is in FiveM databases and oxmysql.

txAdmin across updates#

txAdmin is part of the artifact, so a new build often brings a new txAdmin. It keeps its own data outside the artifact - settings, admin accounts, the player database, bans, warnings, whitelist approvals - in the txData folder (or the location set by the panel or start script). That folder is easy to forget and painful to lose: losing it means losing your ban list and your admin accounts.

• Back up `txData` before every update, alongside server-data.
• Expect one-way migrations. A newer txAdmin may update its stored data on first start. Going back to an older build afterwards can leave txAdmin unable to read it, so a rollback should restore the txData backup too.
• Read the txAdmin release notes when its major version changes. Settings move between pages and occasionally change meaning; the Discord whitelist settings are a recent example, covered in FiveM Discord whitelist and permissions.

Testing before production#

The safest update is the one somebody else tested on your exact resource list. That somebody is a second server.

1. Issue a second licence key from the same Cfx.re account. Escrowed resources owned by that account run on both keys, as FiveM escrow and asset licensing explains.
2. Copy `server-data` to the test server and point it at a copy of the database, never the live one.
3. Run the new build there. Start it, read the console from the top for errors, join, and walk through the parts players use: character creation, inventory, a job, a garage, a shop.
4. Profile it. A build change can change performance. Compare a profile against the live server under similar load, as described in FiveM server performance.
5. Only then update production, at a quiet hour, with the old folder kept.

For a small server, a test run can be the live server at 6am with txAdmin's whitelist set to admin-only for an hour. It is not as good as a second server, but it is far better than updating at peak and finding out with sixty people watching.

What to watch in the first evening

An update that starts cleanly can still fail under load. During the first busy evening on a new build, keep an eye on:

• Hitch warnings in the console. A build that changed sync or networking behaviour shows up here first, as server, sync or network thread hitches that were not there before.
• txAdmin's tick chart. Compare the shape with the previous evening. A new tail of slow ticks at the same player count is the build or a resource reacting to it.
• Memory over the session. A leak introduced by a build grows slowly; check the graph at the start and end of the evening.
• Player reports about specific actions. "My car vanished", "the shop did not take my money" - these point at OneSync or native changes that only show with real players doing real things.

If any of these move, you still have the old build beside the new one. Rolling back after one bad evening costs ten minutes; living with a bad build for a week while hoping it settles costs the community's patience.

The update checklist#

1. Note the current build number from the startup line.
2. Read the changelog between it and the target.
3. Announce a maintenance window; set txAdmin's whitelist to admin-only if you want the server closed while you test.
4. Stop the server cleanly so the framework saves player data.
5. Back up server-data, txData and the database. Lock the backup if your panel allows it.
6. Put the new build beside the old one and swap.
7. Start, and read the console from the first line to the last resource.
8. Join, and test the paths players use most.
9. Reopen the server; watch the console and txAdmin's tick chart through the first busy evening.
10. Remove the old build after a few days without problems.

Change one layer at a time. If the framework has an update too, do it on a different day. When something breaks, you then know which change broke it.

Rolling back#

When the new build breaks something you cannot fix in minutes:

1. Stop the server.
2. Swap the folders back: server becomes the new build's name, server-old becomes server.
3. If txAdmin migrated its data, restore txData from the pre-update backup.
4. If the new build had players on it for a while, decide about the database: restoring loses everything since, keeping it is usually fine because the database schema belongs to the framework, not to FXServer.
5. Start, confirm the startup line shows the old build number, and reopen.

Then find out why before trying again. Search the console output from the failed build for the first error, not the last; read the changelog for the natives the failing resource uses; ask the resource's author with the build number in hand. The general version of this, across games, is in what to do when a mod update breaks.

Troubleshooting after an update#

A resource fails to start with errors about a missing function or native. The resource relies on behaviour that changed, or requires a newer build than you installed. Check its stated minimum build.

Escrowed resources fail to load. The build is too old for escrow, or the update coincided with a key change. Run the recommended build and check the key.

txAdmin will not start or has lost its settings. It is pointed at a different data folder, or the data was migrated by a newer version and you rolled back without restoring txData.

The server starts, players connect, and sync is worse. A OneSync behaviour change. Compare against the old build on a test server, and report it with the build numbers.

Players cannot join after the update, but the server looks fine. Usually unrelated to the artifact: the game build enforced in server.cfg changed, or a resource is failing during the join flow. Read the console while someone connects.

FAQ#

What are FiveM server artifacts?

They are the FXServer builds published by Cfx.re, one list for Linux and one for Windows. Each build is a complete server binary with txAdmin bundled. Your resources and configuration live separately and are not part of the artifact.

Should I use the recommended or the latest FiveM build?

Recommended for any live server. The newer optional builds are for testing fixes and features before they are recommended. Use one only when you need something it contains, and test it first.

How often should I update FXServer?

Often enough to stay within a few weeks of the recommended build, and whenever a resource you rely on requires a newer one. There is no benefit in updating to every build as it appears.

Will updating the server delete my resources?

Not if you keep the artifact and server-data in separate folders, as is conventional. The artifact is replaced; your resources, server.cfg and database are not touched. Back them up anyway.

Does updating FXServer update txAdmin?

Yes. txAdmin ships inside the artifact. Its data folder survives the update, but a newer txAdmin may migrate that data in a way an older one cannot read, so back it up before updating.