GTA 6 Server Config
Config files are where most server owners make their mess. Secrets sprinkled in with settings, no versioning, no environments. Here's the setup your future self will thank you for.
The three types of configuration
- Runtime config: server name, player limit and game type. Checked into git.
- Feature flags: toggle which scripts and jobs are active. Checked into git, often environment-specific.
- Secrets: database credentials, API keys and tokens. Kept out of git entirely.
Directory structure that works
server/
server.cfg # runtime config, in git
resources.cfg # which resources to load, in git
.env # secrets, in .gitignore
.env.example # template for secrets, in git
resources/
[script-name]/
fxmanifest.lua
config.lua # public script config, in git
Secrets handling
Do not store tokens, passwords, or API keys in files that git can track. Instead, use environment variables that are loaded from a .env file which is included in your .gitignore.
The .env.example file lists what variables are available but has no actual values. New team members can copy this to .env locally and add the values.
Feature flags for environments
Development, staging, and production environments require different configurations. Feature flags can be used to enable/disable:
- Debug mode (verbose logging should be enabled on dev, disabled on production).
- Test commands (admin quick-spawn should be available on staging, never on production).
- Rate limits (should be strict on production, lenient on staging).
- External integrations (should talk to test Discord on staging, real Discord on production).
Version control for configs
- Commit your config changes with meaningful messages. "Adjusted max_players to 96 for the Friday tournament" is better than "fixed config".
- Review configuration changes in pull requests. A production config typo means a Saturday night outage.
- Tag production releases. That way, you'll be able to answer "what was running last Wednesday?"
Common config mistakes
- Secret leakage. Rotate immediately.
- Production values on staging (actually hitting the real database from dev).
- Unversioned manual edits. Configuration drifts from git over time.
- Monolithic config files that are 2000 lines long. Split them by concern.
Related reading
Version control details are in our version control guide. See our staging environment guide for the staging workflow, and our RP startup guide for other parts of the setup stack that interact with config.
Frequently Asked Questions
What goes in server.cfg vs resources.cfg?
Runtime settings (server name, max players, game type) are set in server.cfg. The scripts you want loaded are defined in resources.cfg. Secrets (database passwords, etc.) should be stored in .env and never in either of the other two files.
Should I put my server config in git?
Yes, with the exception of secrets. Commit server.cfg, resources.cfg, and any config files for your scripts. Have a .env.example template stored in git, and keep the actual .env local and ignored by git.
How do I manage different configs for dev and production?
Environment variables should be used for anything that differs between environments, and feature flags for toggles. Dev mode can have higher verbosity, different test commands and rate limits. One well-structured config file is better than two configs that diverge.
