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

Most outages on a FiveM city are self-inflicted. Someone SSHes into the live box at peak, hand-edits a config.lua, fat-fingers a comma, and the resource crashes 180 players out of the server with no way to undo it. fivem resource deployment is a release-engineering problem, not a text-editing problem, and the servers that stay up treat it that way: everything lives in version control, changes are proven on a staging box first, and the live server only ever receives reviewed, reload-tested artifacts. This guide lays out a workflow that takes hand-editing on prod off the table entirely.

Stop Editing the Live Box

The core failure mode is direct mutation of production. There is no review, no history, no rollback, and no test. If the edit breaks something, your only recovery is to edit again under pressure while the city is on fire. Treat the live server-data directory as immutable from a human's perspective: nobody types into it. Files arrive one way only — a git pull of a commit that already passed on staging.

Put Your Server in Git

Initialise a repository over your server-data directory (the folder that holds resources/, server.cfg, and your custom resources). This gives you history, blame, branches, and a clean rollback target.

What to commit:

Your custom and modified resources (Lua, manifests, SQL migrations)
server.cfg as a template with secrets stripped
resources.cfg/fxmanifest.lua files and stream metadata references

What to never commit:

License keys, sv_licenseKey, Steam web API keys, RCON passwords, DB credentials
The raw server.cfg if it contains live tokens
cache/, logs/, escrow-encrypted vendor assets you have no rights to redistribute

Pull secrets out of the tracked file and inject them at runtime through convars or environment variables:

# server.cfg (committed, 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

A gitignored secrets.cfg is exec'd at the top of server.cfg, or you read values from the process environment. Either way the repo stays clean and publishable internally without leaking a token.

Run a Staging Server That Mirrors Prod

You need a second box — or at minimum a second FXServer instance on a different port — that mirrors production: same artifact version, same resource list, same framework. Staging is where artifact bumps, new resources, and config changes get proven before they touch live.

Critical rule: staging never touches the production database. Point it at a separate DB, or restore a sanitised dump (scrub player identifiers and admin lists) on a schedule. Testing an economy migration against your live DB is how you corrupt 200 players' wallets.

# nightly sanitised refresh of staging DB
mysqldump --single-transaction prod_es > /tmp/prod.sql
mysql staging_es < /tmp/prod.sql
mysql staging_es < /opt/deploy/sanitise.sql   # scrub PII, reset bans/admins

A Deploy Workflow That Can't Surprise You

The flow is the same one any software team uses, adapted to FXServer:

Branch off main: git checkout -b bump/ox_inventory-2.40.
Make the change — bump an artifact reference, drop in the new resource, edit a config.
Push and deploy to staging; smoke-test with real clients (join, run the affected job, check txAdmin console for errors).
Open a PR, review the diff, merge to main.
On prod: git pull, then reload only the changed resource.

# on the production box, as the fivem service user
cd /opt/fivem/server-data
git fetch origin
git log --oneline HEAD..origin/main   # see exactly what's landing
git pull --ff-only origin main

You pulled three files. You restart one resource — not the whole server.

Reload Without a Full Restart

Most changes do not require a restart. Through the txAdmin live console or RCON:

# re-scan the resources folder so FXServer sees new/changed files
refresh
# apply the change to a single resource
ensure ox_inventory
# or, for an already-running resource
restart ox_inventory

refresh rebuilds FXServer's view of the resource manifests; ensure starts a resource (or restarts it if running); restart/stop+start cycle a single resource. Lua logic, config values, and most client/server script edits apply cleanly this way with zero impact on other resources.

What genuinely needs a full server restart:

New or changed stream/ assets (vehicles, MLOs, custom models) — the streaming manifest is read at startup
fxmanifest.lua changes to games, fx_version, or load order across many resources
OneSync/convar changes in server.cfg that are evaluated at boot
Artifact (FXServer binary) updates

Low-Downtime Tactics for the Restarts You Can't Avoid

When a restart is unavoidable, schedule it into a low-pop window and make it boring. txAdmin's scheduled-restart feature broadcasts warnings, and you should drain deliberately:

Announce at T-15, T-5, and T-1 minutes via in-game messaging
Use the scheduler so the restart is automatic and logged, not a manual kill
Keep the restart fast by warming caches and pre-pulling artifacts beforehand

Updating the FiveM Artifact Safely

Never bump the production artifact blind. Pin a known-good build rather than chasing latest:

Note your current working artifact number — that's your rollback.
Deploy the candidate (recommended channel, occasionally latest) to staging first.
Run the server under real load on staging; watch for resource incompatibilities and OneSync regressions.
Only then pin the same number on prod, keeping the previous artifact folder on disk.

# keep the last-good artifact so rollback is a symlink swap
ln -sfn /opt/fivem/artifacts/12345 /opt/fivem/current   # new
# rollback: ln -sfn /opt/fivem/artifacts/12180 /opt/fivem/current

Rollbacks Are Just Git

Because everything is committed, recovery is a git revert plus a redeploy — not a frantic re-edit:

git revert <bad-sha> --no-edit
git push origin main
# on prod:
git pull --ff-only && echo "refresh; restart ox_inventory" | rcon

The repo always holds your last-good state. You roll forward to undo, which keeps history honest.

Automate the Boring Parts

Wrap the pull-and-reload in a script (or a CI job triggered on merge to main) that backs up first, then deploys:

#!/usr/bin/env bash
set -euo pipefail
cd /opt/fivem/server-data
mysqldump --single-transaction prod_es | gzip > /backups/db-$(date +%F-%H%M).sql.gz
tar czf /backups/resources-$(date +%F-%H%M).tgz resources/
git pull --ff-only origin main
echo "refresh" | rcon
echo "restart ${1:?resource name required}" | rcon

A backup before every deploy, an explicit resource argument, and a single reload — that is the whole discipline. Build the pipeline once and your worst deploy becomes a non-event.

For more FiveM server-ops and resource guides across the fleet, see scripts-tebex.io, febex.io, and 0resmon-tebex.io.