Professional FiveM Resource Deployment: Git Workflows, Staging Servers, and Zero-Downtime Updates

Stop Editing Files Directly on Production

Directly editing files on a live FiveM server is one of the most common causes of unexpected downtime. Connecting via SSH or FTP during peak hours to edit a script configuration file can easily lead to syntax errors. A single missing comma can crash a script, disconnect dozens or hundreds of players, and leave server administrators struggling to fix the error under intense pressure.

Maintaining high availability requires treating live server files as immutable. Server administrators should never edit live files directly. Instead, any changes to your production server-data directory should arrive solely through controlled updates pulled from version control after proper validation.

Setting Up Version Control with Git

The first step toward reliable resource management is placing your server-data directory into a Git repository. This directory contains your resources/ folder, server.cfg, and custom resource files. Version control provides an accurate audit history, clear blame tracking, and instant rollback capabilities when unexpected issues occur.

What to Track in Version Control

• Custom Lua scripts, framework modifications for QBCore or ESX, and standalone resources
• Database migration files and SQL patches
• Manifest files (fxmanifest.lua), resource configuration files, and stream metadata references
• Template files for server.cfg with sensitive credentials removed

What to Exclude from Version Control

• Production license keys (sv_licenseKey), Steam Web API keys, and RCON passwords
• Database connection strings containing production usernames and passwords
• Server log files, the cache/ directory, and temporary runtime files
• Encrypted vendor assets obtained via Keymaster and Asset Escrow that you do not have permission to redistribute publicly

To keep sensitive secrets out of your repository, store them in environment variables or a local configuration file that is listed in your .gitignore file. You can execute this ignored secrets file at the start of your main server.cfg file:

# server.cfg (tracked in Git, contains no secrets)
sv_licenseKey "${FIVEM_LICENSE_KEY}"
set mysql_connection_string "${DB_DSN}"
set rcon_password "${RCON_PASSWORD}"

# .gitignore
cache/
logs/
*.log
secrets.cfg
server-secrets.env

Building a Dedicated Staging Environment

A staging server is a secondary FXServer instance running on a separate machine or port. It must mirror your live environment by using the same server artifact build, identical framework releases, and the same script configuration settings. Staging serves as a testing ground where config updates, code rewrites, and new FiveM scripts can be verified before affecting active players.

It is critical that your staging server never connects to your live production database. Testing updates against live player data risks corrupting character inventories, vehicle garages, or economy statistics. Always configure staging to point to an isolated database. You can populate staging with sanitised exports from production by stripping away player identifiers, administrative privileges, and ban lists.

# Exporting and sanitising data for staging
mysqldump --single-transaction live_database > /tmp/live_dump.sql
mysql staging_database < /tmp/live_dump.sql
mysql staging_database < /opt/scripts/sanitise.sql

A Structured Release Workflow

Adopting a standard software development lifecycle prevents unexpected deployment errors. Follow these steps whenever updating your server:

1. Create a dedicated Git branch for the task (for example, git checkout -b update/inventory-system).
2. Apply your configuration changes, script edits, or file additions on this branch.
3. Deploy the branch to your staging server and test functionality with real clients.
4. Open a pull request, review the code differences, and merge the branch into main.
5. Log into your production server and pull the validated commit.

# Running deployment commands on the production server
cd /opt/fivem/server-data
git fetch origin
git log --oneline HEAD..origin/main
git pull --ff-only origin main

Applying Live Updates Without Full Restarts

Many script and configuration updates do not require rebooting the entire FXServer process. You can reload individual resources through the txAdmin live console or via RCON:

# Scan resource folders for modified files
refresh

# Start a resource or reload it if it is running
ensure ox_inventory

# Restart an active resource
restart ox_inventory

Executing refresh forces FXServer to re-read resource manifests across your server directories. Using ensure or restart allows you to apply updated Lua logic, modified configuration options, or updated client interface assets instantly without interrupting players who are using unrelated systems.

Changes That Require a Full Reboot

Some changes cannot be applied dynamically through resource restarts. A complete server restart is necessary when:

• Adding or modifying stream files inside stream/ folders, such as custom vehicles, MLOs, clothing, or 3D prop assets
• Modifying core manifest properties like fx_version, game, or global resource loading sequences
• Updating OneSync modes or boot-level convars inside server.cfg
• Upgrading the underlying FXServer server binary artifact

Handling Necessary Server Restarts

When a full server reboot is unavoidable, schedule it during off-peak hours and inform your community in advance. Using txAdmin's built-in scheduler allows you to automate restart sequences and issue player warnings across in-game chat at set intervals (such as 15 minutes, 5 minutes, and 1 minute before shutdown).

Safely Upgrading FXServer Artifacts

Avoid setting your production server to track the latest artifact release automatically. Unreleased regressions in server binaries can lead to unexpected crashes or resource failures. Always pin your production server to a specific, verified artifact build number.

When testing new artifact versions:

1. Identify your current, stable artifact number as a backup point.
2. Install the target artifact build on your staging environment first.
3. Run staging under load to test for OneSync anomalies or resource errors.
4. Once confirmed stable, update production and maintain the old artifact build on disk for quick recovery.

# Updating a symlink to switch active artifacts
ln -sfn /opt/fivem/artifacts/12345 /opt/fivem/current

# Reverting to the prior build if needed
# ln -sfn /opt/fivem/artifacts/12180 /opt/fivem/current

Executing Quick Rollbacks

Because all changes pass through version control, reverting a problematic update is straightforward. Instead of attempting manual edits during an incident, use Git to revert to the previous working state:

git revert <commit-hash> --no-edit
git push origin main

# On production:
git pull --ff-only && echo "refresh; restart ox_inventory" | rcon

This approach ensures that your repository history remains accurate while instantly returning your live environment to a known good state.

Automating the Deployment Process

To ensure consistency, bundle your deployment and backup commands into an automated script or continuous integration job. A basic bash deployment script can perform a database backup, fetch the latest code from Git, and trigger resource reloads through RCON:

#!/usr/bin/env bash
set -euo pipefail
cd /opt/fivem/server-data

# Create a database backup prior to deployment
mysqldump --single-transaction live_database | gzip > /backups/db-$(date +%F-%H%M).sql.gz

# Pull latest code and refresh resources
git pull --ff-only origin main
echo "refresh" | rcon
echo "restart ${1:?Please specify a resource name}" | rcon

Automating your backup and deployment steps reduces human error, protects player data, and ensures reliable resource updates across every release cycle.