Shipping: opening night checklist
A restaurant does not open for guests without prepped stations, a backup line, and a plan if a dish fails. Same here. You lock permissions, back up the database, turn on monitoring, and keep a known-good build to fall back to. In this lesson you build one small resource named qu_release. It prints a boot header on start so you always know which version is live. Then you rehearse a backup and a one-command rollback before you ever touch production.
Build it
Make the release resource
txAdmin is the browser admin panel that ships bundled inside FXServer, so you already have it at http://localhost:40120. You do not install it separately. (On a brand-new server the first visit shows txAdmin's one-time setup wizard and a master PIN. Once setup is done, that same URL is where you reach the Live Console used below.)
Inside your server's resources folder, create one folder for this lesson. A resource is one folder FXServer loads as a unit:
resources/qu_release/
fxmanifest.lua
server.lua
VERSION
Put your release tag in VERSION (no quotes, nothing but the tag):
v1.0.0
Write fxmanifest.lua
The fxmanifest.lua file is the manifest that tells FXServer what a resource contains and which files to load. Open it and paste this. Note there is no lua54 'yes' line. Lua 5.4 is the only runtime now, so that line is deprecated and ignored. Leave it out.
The fx_version 'cerulean' line sets the manifest format version. cerulean is just the current format name, like a year on a standard. Always use it on a new resource.
fx_version 'cerulean'
game 'gta5'
server_script 'server.lua'
files {
'VERSION'
}
Print a boot header
During an incident you should never have to ask "what version is running?". Open server.lua and paste this. It reads VERSION from the resource and prints a short header when the resource starts. GetConvar reads a convar, which is a server config variable set in server.cfg.
AddEventHandler('onResourceStart', function(resource)
if resource ~= GetCurrentResourceName() then return end
local version = LoadResourceFile(GetCurrentResourceName(), 'VERSION') or 'dev'
version = version:gsub('%s+', '')
print('[qu_release] release : ' .. version)
print('[qu_release] game build: ' .. GetConvar('sv_enforceGameBuild', 'unset'))
print('[qu_release] boot ok')
end)
Lock permissions and set the build
Open server.cfg. Set the GTA content build on purpose, then load and lock the resource.
The sv_enforceGameBuild value is the GTA V content build clients must load. It comes from Cfx.re's supported game-build list, not from the FXServer artifacts download page. Keep the value your official recipe wrote unless your assets require another supported build. A recipe is the one-click framework installer txAdmin runs on first setup.
The ensure line loads the resource. ACE (Access Control Entries) is FXServer's permission system. An identifier is one way a player proves who they are, such as their fivem: account number. Below, you allow admins to run commands but deny quit so a misclick cannot stop the server.
# license: free from the Cfx.re Portal (portal.cfx.re). The value is the cfxk_ string, pasted as-is.
sv_licenseKey "cfxk_yourkeyhere"
# GTA content build, not an FXServer artifact number; verify the live supported list
sv_enforceGameBuild 3751
# onesync is not on by default; set it (the modern standard every server should set). Required for 32+ slots, up to 2048
set onesync on
sv_maxclients 48
# lock commands: allow admins, but deny quit so a misclick cannot stop the server
add_ace group.admin command allow
add_ace group.admin command.quit deny
add_principal identifier.fivem:0000000 group.admin
# keep secrets out of git; rotate them after exposure and on your security schedule
exec server-secrets.cfg
ensure qu_release
Restart on staging and read the header
Open the txAdmin Live Console in your browser at http://localhost:40120. Restart only this resource. The restart command reloads one resource by name:
restart qu_release
Read the first lines. You should see the header, and crucially nothing red underneath it.
Back up the database before you deploy
A backup you have never made is hope. Take a snapshot before any production deploy. On a hosted panel this is the database backup button. On a machine with the mariadb-dump tool (it ships with MariaDB) you can run this in PowerShell or your VPS shell. A VPS is a rented remote server you connect to over the internet:
mariadb-dump -u BACKUP_USER -p --single-transaction --quick --routines fivem > backup-before-release-v1.sql
Swap BACKUP_USER and fivem for a MariaDB account with backup privileges and your database name. The -p flag prompts for the password so it never lands in shell history or the process list. --single-transaction gives a consistent snapshot for InnoDB tables. Check the command's exit status, then test a restore. Keep one copy off the game host.
Rehearse the rollback path
Before you ever need it, prove the rollback works on staging. Keep the previous version's folder on disk as qu_release_v0. To roll back, stop the new one and ensure the old one from the txAdmin Live Console. ensure starts a resource (or restarts it if it is already running):
stop qu_release
ensure qu_release_v0
The old boot header should print, telling you the previous version is live again. This is muscle memory you want before launch night, not during it.
Keep reading the full lesson
Sign in to start, then unlock every step of this lesson and the full FiveM School with a membership.
- If something went wrong
- What you can do now
- Try it yourself
The remainder of Shipping: launch checklist is available to FiveM School members.