From localhost to VPS with Git

Add a .gitignore before the first commit

Open your resource folder in VS Code and create a file named .gitignore at its root. List anything that holds a secret or is machine-specific:

# secrets and machine-specific files, never committed
*.env
license-key.txt
db-creds.txt
config.secret.lua
node_modules/

Keep real config out of code. Instead of writing a key into a committed file, set it as a convar in server.cfg (which lives on the server and is never in the repo) and read it at runtime. The convars lesson goes deep on this, but here is the shape so the secrets claim is not hand-waved:

-- server.cfg (on the VPS, NOT in the repo):
--   set my_license_key "your-real-key-here"

-- server.lua (in the repo, no secret in sight):
local key = GetConvar('my_license_key', 'unset')
print('license key loaded:', key ~= 'unset')

The code ships the variable name, not the value. Each machine supplies its own value through its own server.cfg.

Publish a PRIVATE repository

In GitHub Desktop, commit your work, then choose Publish repository. Crucial: untick Keep this code private only if you truly want the world to read it. For a server, leave it private.

Install Git on the VPS and clone into resources

Open an SSH session to your VPS (on Windows, type ssh user@your-vps-ip in PowerShell or Windows Terminal; or use the browser-based console in your VPS provider's control panel). Install Git if it is missing (sudo apt update && sudo apt install -y git on Ubuntu/Debian). Because the repo is private, GitHub will not accept your account password on clone. You need a credential the VPS can use. The fastest one to create is a fine-grained personal access token:

1. On github.com, go to Settings -> Developer settings -> Personal access tokens -> Fine-grained tokens -> Generate new token.
2. Scope it to Only select repositories and pick this one repo. Under Repository permissions, set Contents to Read-only. That token can pull this repo and nothing else.
3. Set a short expiry (30 to 90 days) and copy the token once. GitHub shows it a single time.

Now clone into the server's resources folder. When Git asks for a username, enter your GitHub username; when it asks for a password, paste the token (not your real password):

cd /home/fivem/server-data/resources
git clone https://github.com/your-username/your-resource.git qu_deploy_demo

The last word, qu_deploy_demo, is the folder name Git creates on the VPS (it overrides the repo's own name). Every command later in this lesson uses that exact name, so if you pick a different folder name, swap it in everywhere qu_deploy_demo appears.

A read-only token is the safer choice for a deploy box: even if the VPS is compromised, the attacker can only read one repo, never push or touch your account. An SSH deploy key (a keypair added to the repo's Deploy keys) achieves the same scoping and avoids token expiry if you prefer keys. Then ensure qu_deploy_demo in server.cfg and restart the server once so it loads.

Run the update loop

This is the loop you repeat forever. On your PC: make the change, test locally, then commit and push in GitHub Desktop. On the VPS: pull and restart.

On the VPS, inside the resource folder:

cd /home/fivem/server-data/resources/qu_deploy_demo
git pull

Then in the txAdmin Live Console:

restart qu_deploy_demo

Roll back a bad deploy

A deploy breaks the server. Stay calm: Git remembers every version. On the VPS, see recent commits and reset to the last good one:

git log --oneline -n 5
git reset --hard <good_commit_hash>

git log --oneline -n 5 lists your last five commits, newest first; each line starts with a short hash like a1b2c3d followed by its message. Replace <good_commit_hash> with the short hash from the line of the last commit you know worked (read the messages to find it). Do not type the angle brackets.

Then restart qu_deploy_demo. The resource is back to that exact known-good state. This is why you push working code in small commits: every commit is a save point you can return to.