FiveM server git: what to commit, .gitignore and git pull deploys

A server that lives only on one disk has no history: a bad edit on a Friday night cannot be undone, and moving machines means copying folders by hand. Putting it under git fixes both. This guide shows what to commit, the .gitignore to use, how to keep secrets out, and how to deploy with git pull.

#What goes in the repository

Commit the things you write or configure:

• Your resources (the resources/ folder, including config and SQL files).
• A server.cfg without secrets.
• Small helper files, such as a README with the start-up order.

Do not commit generated or private files:

• cache/, which FiveM rebuilds. See clear the FiveM cache.
• The txAdmin data folder (txData), with its settings, admin accounts and logs.
• Secrets: the license key, database password and API keys.
• Logs, crash dumps and node_modules.

#A starting .gitignore

At the root of the repository (the server data folder that contains resources/ and server.cfg):

cache/
txData/
*.log
*.dmp
node_modules/
secrets.cfg
.env

If you version the whole txAdmin folder on purpose, remove txData/ from the list, but keep it private and out of any shared repository. Large binary assets (streamed cars, MLOs) make a repository big; consider whether they should be in git at all, or kept in a separate store.

#Keep keys out of server.cfg

This is the part that goes wrong most often. These lines are secrets:

sv_licenseKey cfxk_xxxxxxxxxxxx
set mysql_connection_string "mysql://user:password@localhost/fivem"
set steam_webApiKey "xxxxxxxx"
rcon_password "xxxxxxxx"

Move them to a separate file, secrets.cfg, which is in .gitignore:

# secrets.cfg  (never committed)
sv_licenseKey cfxk_xxxxxxxxxxxx
set mysql_connection_string "mysql://user:password@localhost/fivem"
set steam_webApiKey "xxxxxxxx"

And load it at the top of the committed server.cfg:

exec secrets.cfg

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
sv_hostname "My Server"

ensure oxmysql
ensure ox_lib

Commit a secrets.cfg.example with empty values so the next person knows what to fill in. See server.cfg explained for the settings themselves.

Warning: if a key was ever committed, deleting it in a later commit is not enough. It is still in the history. Generate a new key or password and treat the old one as leaked.

#Create the repository

cd /path/to/server-data
git init
git add .
git status

Read the git status list before you commit and check that nothing from the "do not commit" list is staged. Then:

git commit -m "Initial server"
git branch -M main
git remote add origin [email protected]:youruser/your-server.git
git push -u origin main

Use a private repository. Paid resources are licensed to you, and putting them in a public repository is redistribution, even if the code is encrypted. See escrow lack entitlement for how encrypted assets are tied to your account.

#Deploy with git pull

On the machine that runs the server, clone once and pull afterwards:

git clone [email protected]:youruser/your-server.git server-data
cd server-data
# create secrets.cfg on this machine (not from git)

To update after a push from your development PC:

cd server-data
git pull

Then reload what changed. For a single resource, from the server console:

refresh
restart my_resource

If server.cfg or a start-up order changed, schedule a full restart (see scheduled restarts). Do not git pull in the middle of peak hours without a plan, since many resources restarting at once can spike the server.

For authentication on a private repository, use an SSH deploy key with read access only, or a personal access token. Never type your own password into scripts.

#A simple branch habit

Keep main as what is live. Make changes on a branch, test on a local or staging server, then merge:

git checkout -b new-police-job
# edit, test
git commit -am "Add police job"
git checkout main
git merge new-police-job
git push

When something breaks after a pull, git log shows what changed and git revert <commit> undoes it without losing history. Git is not a backup of the database, though: keep real backups too, as in backup your FiveM server.

#Checklist