Updating FiveM artifacts

Artifacts are the FXServer build itself, published by Cfx.re as a versioned archive. Updating them means swapping one folder for another. They contain no part of your server: not your resources, not your server.cfg, not your database, which is what makes an update reversible if you do it in the right order.

If you have not installed the server yet, start with Installing a FiveM server on Linux, which puts the build in /home/fivem/artifacts and your data in /home/fivem/server-data. This page assumes that split.

Recommended and latest

The artifacts page lists a build per commit, and marks two of them.

Recommended is the build Cfx.re considers ready for production servers. It has been out long enough for regressions to surface. This is what you run.

Latest is the newest build published. It carries fixes and features that have not reached recommended yet, and occasionally carries a regression that is the reason it has not. Run it only when you need something specific from it, most often support for a GTA V game build newer than the recommended artifact knows about.

Anything older than the recommended build is a build you have not updated to yet, not a third channel. There is no long-term-support line.

Checking the version you run

Four ways, in order of how quickly you can get to them:

• txAdmin shows the FXServer version on its dashboard, and flags it when the build you run is behind the recommended one.

• The startup console prints the version banner as the server comes up. In journalctl -u fivem -f it is in the first few lines after a restart.

• The info endpoint carries it in a server field, which is useful from a script:

  ShellCopy

  curl -s http://127.0.0.1:30120/info.json

• The download link you used has the build number in its path. This only tells you what you meant to install, so treat it as the weakest of the four.

The build number is the thing to write down before you change anything. It is what you compare against when something breaks a week later.

Updating

1. Note what you run now

   Read the current build number from txAdmin or the startup console and write it down. Without it, "roll back to what worked" is a guess.

2. Back up the server data and the database

   As root, stop the server, then take the copies as fivem:

   ShellCopy

   systemctl stop fivem
   su - fivem
   tar czf ~/server-data-$(date +%F).tar.gz -C /home/fivem server-data

   If a framework uses MySQL or MariaDB, dump it too:

   ShellCopy

   mysqldump -u root -p your_database > ~/your_database-$(date +%F).sql

   Copy both off the machine if you can. A backup that only exists on the server it protects covers a bad update, and nothing else.

3. Move the current build aside, do not overwrite it

   Still as fivem:

   ShellCopy

   mv /home/fivem/artifacts /home/fivem/artifacts-previous
   mkdir /home/fivem/artifacts

   Extracting a new build over an old one leaves files from both, and the result is neither version. Keeping the old folder intact is also the entire rollback plan.

4. Fetch the new build

   Copy the link for the build you want from https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/, then:

   ShellCopy

   cd /home/fivem/artifacts
   curl -sSL -o fx.tar.xz "PASTE_THE_LINK_HERE"
   tar xf fx.tar.xz
   rm fx.tar.xz
   chmod +x run.sh

   Do the extraction as fivem, not as root. Files unpacked as root inside /home/fivem leave the service unable to write where it expects to.

5. Start it and watch the console

   As root:

   ShellCopy

   systemctl start fivem
   journalctl -u fivem -f

   Watch until every resource has reported that it started. Then join the server yourself before you tell anyone it is back. Most update problems are visible in the first thirty seconds of console output, and the rest show up on the first join.

6. Roll back if it went wrong

   Nothing to think about, because the old build is still there:

   ShellCopy

   systemctl stop fivem
   rm -rf /home/fivem/artifacts
   mv /home/fivem/artifacts-previous /home/fivem/artifacts
   systemctl start fivem

   That deletes the build that failed and restores the one that worked. Your server data and database are untouched by all of this, provided you did not change them at the same time.

Was it the update?

Change one thing at a time and this question answers itself. Update the artifacts, or update your resources, or change the config, never two in one sitting. If the artifacts are the only thing that moved, a rollback is a clean test: if the symptom disappears on the old build, it came from the new one.

Signs that point at the build rather than at your server:

• The server fails to start at all, or exits before any resource loads.
• A resource that has not changed in months now errors on a native or an API, usually with a message naming something inside the server rather than your script.
• Players on a current client get a version or game build error while the server is plainly running.
• Something in txAdmin behaves differently, since it updates with the artifacts.

Signs that point somewhere else:

• Only one resource is broken, and it is one you updated or edited recently.
• The error names your own script file and a line number in it.
• The symptom survives a rollback. Then it was never the build, and the update only happened to be the last thing you touched.

Keep the console output from the failure. Reading it later beats reconstructing it, and it is the first thing anyone helping you will ask for. If you need us, see Opening a ticket.

Why staying too far behind eventually breaks

Falling behind is not a stable state. Three things move underneath a server that does not update.

The client updates itself. Players run whatever the FiveM launcher gave them this week. The server has to speak the protocol that client speaks, and very old builds eventually cannot.

Cfx.re raises the minimum supported build. Old builds stop being accepted for the server list, so the server disappears from it while continuing to run perfectly for anyone with a direct connect address. A server nobody can find is functionally down.

Game builds arrive. When Rockstar ships a new GTA V build, support for it appears in new artifacts first. A server pinned to an old artifact cannot enforce or accept a game build the artifact does not know about, and neither can the resources that expect it.

Security fixes ride along the same pipeline. The practical version of all this: update to the recommended build on a schedule you pick, in a quiet hour, with a backup and the previous folder still on disk. That is a fifteen minute job. Updating because the server list dropped you on a Saturday night is not.

Related