Update FXServer artifacts properly on FiveM

Introduction

FXServer is the FiveM server binary, distributed as versioned artifacts. Each version can introduce bugs or breaking changes. This procedure walks you through updating cleanly, choosing between LTS and latest, and rolling back if needed.

Prerequisites

• A FiveM server at VeryCloud
• Access to Files and Startup in Wisp
• A current backup (mandatory before any update)

Step 1: Identify current version

In txAdmin → Server → Diagnostics, FXServer version is at the top.

Or in FiveM console (live):

version

Version is a 4-digit build number (e.g. 7290).

Step 2: Understand channels

FiveM publishes on several channels:

For a public server, stay on recommended or sometimes latest if you need a recent feature.

Step 3: Pick a version

Go to https://runtime.fivem.net/artifacts/fivem/build_server_windows/master/ (Windows) or .../build_proot_linux/master/ (Linux).

Each entry is xxxx-hash format. xxxx is the build number.

Note the recommended version (usually marked) and full URL.

Step 4: Backup before update

Critical: full backup via Wisp Schedules → Create Backup.

Meaningful name: pre-fxserver-update-7290-to-7305.

Step 5: Update via Wisp

The standard Wisp FiveM image exposes a startup variable for FXServer version.

1. Open Startup
2. Identify the variable: often FIVEM_VERSION, FXS_VERSION or BUILD_VERSION
3. Change it to the target build (e.g. 7290)
4. Save

On next start, Wisp downloads the matching artifact.

💡 If the variable expects a full URL rather than a number, grab the exact URL from FiveM runtime.

Step 6: Restart and observe

Restart from console. Expected logs:

[txAdmin] Restart initiated
[Wisp]    Downloading FXServer artifact 7290...
[Wisp]    Extracting...
[FXServer] Starting v7290
[FXServer] Server ready

Server up >5 min = OK.

Step 7: Test on the server

Connect in-game. Test:

• Smooth spawn / connection
• Critical resources load (/restart <resource> if needed)
• No script errors in F8 console

Check txAdmin → System Logs for error spam since restart.

Step 8: Rollback if needed

If the new version breaks something:

1. STOP the server
2. Wisp → Startup → restore the old build number
3. Save + Start

Or for deeper config breakage:

1. Backups → restore the pre-update backup

2-5 minutes downtime for a rollback.

Step 9: Recommended workflow

For a serious server:

1. Staging: a second FiveM server (could be SboxDev or even a personal VPS) where you test artifacts first
2. Announce: warn your community 24h before the prod update
3. Quiet window: 3-5 AM ideally
4. Backup systematically
5. Prod update + 1h monitoring
6. Communicate result (Discord)

Step 10: Schedule version checks

To not miss a critical update:

• Subscribe to the official CFX Discord in #changelog or #announcements
• Or check weekly at https://forum.cfx.re/c/development/server/137

Troubleshooting

Server won't restart after version change — build doesn't exist or wrong URL. Verify on runtime.fivem.net. OS permissions on the binary: do a Reinstall from Wisp Settings. Crash at boot on a new version — resource incompatible with the new build (often oxmysql, very old ESX/QBCore). Rollback immediately then update resources before retrying. Performance degraded after update — memory climbing: profile with resmon (see dedicated tutorial). If not identifiable, rollback.

Useful commands

# View current version (FiveM console)
version

# Clean restart (txAdmin)
# Panel txAdmin / Server / Restart

# List resources that failed at boot
# txAdmin / Server / Resources / filter "Failed"

Conclusion

Updating FXServer = three clicks in Wisp + a backup. Classic trap: skipping the backup or pushing latest to prod without staging. Stay on recommended, keep a staging, and you'll never have bad surprises.

Going further: release notification automation via GitHub webhook, A/B testing between two servers.

Resources

• FiveM Artifacts — Linux
• FiveM Artifacts — Windows
• Cfx.re Forum — Server Development
• FiveM — Docs Server