FiveM Server Settings Explained: The Best Config for Your Group

For a small private FiveM group, start with a deliberately simple configuration: bind both TCP and UDP on the host’s assigned port, enable OneSync, set sv_maxclients just above your real peak, start only the resources you use, leave Script Hook disabled, and keep txAdmin administration separate from in-game ACE permissions. This avoids the two common mistakes—advertising capacity your hardware and scripts cannot deliver, and giving staff more control than they need.

server.cfg controls FXServer startup, endpoints, resources, OneSync, player limits, permissions, and the license key. txAdmin controls its web panel, staff roles, moderation tools, recipes, and restart controls. Treating those as two related but distinct layers makes the server easier to troubleshoot and safer to operate.

What does server.cfg control?

server.cfg is the startup contract for your FXServer process. It is read when the server launches and can also include other configuration files. The file determines how clients reach the server, which resources start, how many clients are allowed, which synchronization mode is active, and which commands different principals may run.

Area	Typical settings	What it changes
Network	endpoint_add_tcp, endpoint_add_udp	The addresses and ports on which FXServer listens.
Capacity	sv_maxclients	The configured client ceiling, not a promise that your scripts or host can sustain that population.
Synchronization	set onesync on	Server-side entity state synchronization and the rules that apply to higher slot counts.
Startup	ensure, start, and included cfg files	Which maps, frameworks, chat systems, and scripts load, and in what dependency order.
Permissions	ACE and principal statements	Which in-game identities can execute protected commands.
Security	sv_scriptHookAllowed, sv_endpointPrivacy	Whether Script Hook is accepted and whether player IP addresses are hidden from public reports.

txAdmin is a separate administration layer. Its roles can control console access, resource actions, configuration editing, server start and stop operations, scheduled restarts, and moderation. A txAdmin role does not automatically define every in-game ACE permission, and an ACE rule does not grant access to the txAdmin panel. Document which system owns each setting so a recipe or hosting panel does not silently overwrite an edit.

What is a good baseline server.cfg for a private group?

The following is a compact starting point. It deliberately leaves out framework-specific resources and secrets; add those only after the vanilla server launches cleanly. Replace the endpoint port with the value assigned by your host when you are not self-hosting.

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

set onesync on
sv_maxclients 16
sv_scriptHookAllowed 0
sv_endpointPrivacy true

ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure basic-gamemode
ensure hardcap
ensure rconlog

The two endpoint lines are intentional: FiveM uses both transports, and declaring only one can produce inconsistent connection failures. Port 30120 is the typical example, but a managed host may allocate another port. Copy the provider’s assigned value into both lines and expose that same value through the host firewall or router.

Set sv_maxclients slightly above the group’s actual peak rather than choosing a large number because it is available. The cap creates an admission limit; it does not add CPU time, memory, bandwidth, script capacity, or database performance. Add your license key through the Portal or txAdmin-generated configuration and keep it out of public repositories, screenshots, and support posts.

How should I choose sv_maxclients?

Choose the smallest cap that covers your expected simultaneous players plus a modest cushion. The command reference permits values from 1 through 2048, but the practical rules change at 32, 48, and 64 slots.

Target group	Starting configuration	Checks before increasing the cap
Under 16 players	OneSync on; cap near the expected peak; vanilla resources first.	Confirm both endpoints, firewall exposure, and clean resource startup.
16–48 players	OneSync on; cap a little above the normal peak; review dependencies and txAdmin roles.	Observe script errors and server behavior with your real resource stack.
More than 48 players	Keep OneSync on and verify eligibility before changing the cap.	Cfx support requires the latest artifact, an eligible Portal subscription tier, and a restart for caps above 48.
More than 64 players	OneSync must be on.	Values above 64 are not supported by the legacy mode; confirm the artifact and Portal requirements first.
A resource that requires legacy	Use legacy only for the documented compatibility need.	Record the dependency and accept its performance and graphical trade-offs.

Values starting at 32 require OneSync set to on or legacy; values above 64 require on. Separately, Cfx support states that raising the cap above 48 requires the latest artifact, an eligible Portal subscription tier, and a restart. These are policy and compatibility gates, not a benchmark for a particular CPU or host. The sources do not define one universal RAM, processor, bandwidth, or geographic specification because frameworks, scripts, database load, and player locations vary.

Do I need OneSync?

For a new group server, use set onesync on unless a specific resource requires a different mode. OneSync adds server-side entity state synchronization and supports higher player counts. It also establishes the synchronization behavior expected by many current resources.

What does legacy mode mean?

Legacy is a compatibility mode, not the preferred performance setting for a new build. The command documentation describes performance and graphical drawbacks, so isolate the resource that requires it and document why the server cannot use on. Do not switch modes casually while diagnosing an unrelated script; first confirm that the resource actually declares the dependency.

Which OneSync options should I change?

Population spawning, entity migration, distance culling, and entity lockdown are advanced controls. Leave them at their defaults until a resource’s documentation or measured server behavior gives you a specific reason to change one. An advanced setting can hide a symptom while creating new entity or visibility problems for every player.

How do I configure the network endpoints?

Use matching TCP and UDP declarations and make the same port reachable from outside the machine. A self-hosted server normally needs a router forward and host-firewall rules; a managed server normally requires the provider’s allocated port in the cfg and panel.

1. Find the assigned port. If the provider gives you a port other than 30120, use that value everywhere. Do not retain the example port just because it is common.
2. Bind both transports. Add endpoint_add_tcp "0.0.0.0:PORT" and endpoint_add_udp "0.0.0.0:PORT", using the same assigned port.
3. Expose the port. On a home connection, forward the port from the router to the server’s fixed local address and allow it through the operating-system firewall. On hosted infrastructure, apply the provider’s network rule instead.
4. Restart and inspect the console. Look for endpoint bind errors or a message showing that another process already owns the port.
5. Test externally. Have a friend on a different connection join. A test from the same local network can succeed even when router forwarding is wrong.

The endpoint syntax is stable, but the network topology is not. Carrier-grade NAT, changing home IP addresses, provider security groups, and a panel that rewrites cfg files can each affect reachability. If the running console shows a different port from the one you opened, fix the configuration owner rather than repeatedly changing the router.

Which resources should start, and in what order?

Begin with the resources in the vanilla example: mapmanager, chat, spawnmanager, sessionmanager, basic-gamemode, hardcap, and rconlog. They provide a known-good baseline for map selection, chat, spawning, sessions, a basic game mode, a slot cap, and console logging.

How should I add a framework or script?

1. Keep a known-good copy of server.cfg and the resource folder.
2. Read the resource’s stated dependencies and required startup order before adding its ensure line.
3. Add one resource or dependency change at a time.
4. Restart and inspect the console for missing exports, database failures, dependency errors, and endpoint messages.
5. Only then add the next resource.

txAdmin recipes can add ensure entries automatically. Review those entries in the recipe and use txAdmin’s CFG editor and validator before saving. If a recipe regenerates the file at launch, make the durable change in the recipe or its managed variables; otherwise your manual edit may disappear on the next restart.

How do txAdmin and in-game permissions differ?

Use txAdmin for panel and operational duties, and ACE principals for commands executed inside the game server. This separation lets a moderator kick a player without granting permission to edit cfg files or stop the server.

txAdmin role design

Give staff only the panel capabilities they need: viewing settings, reading the console, controlling resources, editing cfg files, restarting the server, or performing moderation actions. Reserve broad control and all_permissions for trusted owners. A role that can write configuration or restart the process can effectively change every other permission, so treat it as an owner-level capability.

ACE and principal design

In server.cfg, ACE rules assign command permissions to groups and principals. A minimal pattern is:

add_ace group.admin command allow
add_principal identifier.fivem:{{ADMIN_IDENTIFIER}} group.admin

The double-curly value is a template variable: replace it with the administrator’s actual identifier before use. Prefer narrowly scoped command rules for routine moderators instead of granting every command. Test each rule with a non-owner account, because an inherited principal or a broad command allow line can grant more access than the visible group definition suggests.

What security settings should I use?

Leave Script Hook disabled in production with sv_scriptHookAllowed 0. The vanilla configuration warns that enabling it creates security issues; only consider a controlled exception when you understand the resource and the risk.

• Protect secrets. Keep the license key, database credentials, tokens, and provider credentials in protected files or the provider’s secret settings. Never publish a complete cfg containing them.
• Limit privileges. Separate txAdmin owners, technical administrators, and in-game moderators. Remove identifiers when staff leave.
• Consider endpoint privacy. sv_endpointPrivacy can hide player IP addresses from public reports. Confirm that your moderation and logging workflow still has the information it legitimately needs.
• Back up before edits. Save the working cfg and recipe before changing permissions, startup order, or synchronization mode.

Security is also an operational issue: a leaked key or unrestricted cfg editor can be more damaging than a misconfigured slot count. Keep the server’s management panel and game permissions documented so a replacement administrator can recover the setup without guessing.

How do I set up a server through txAdmin?

The documented txAdmin flow creates a basic server and generates the initial configuration. Follow these steps for a clean first launch.

1. Link your Cfx account in txAdmin.
2. Register the server when prompted.
3. Choose the FiveM Basic Server template.
4. Generate a registration key in the Portal.
5. Return to txAdmin and enter the key in the setup flow.
6. Run the recipe and let txAdmin generate the server files.
7. Save and run the generated server.
8. Inspect the console for resource, license, and endpoint errors before adding custom scripts.

After the first successful launch, compare the generated cfg with your intended baseline. Confirm that the endpoint, sv_maxclients, OneSync mode, Script Hook setting, and resource list are owned by the file or recipe you plan to maintain.

Why can’t my friends connect?

Most connection failures are caused by a port mismatch, a blocked firewall path, or a server that never reached a clean listening state. Work from the server outward instead of changing several settings at once.

1. Check the console. Resolve license errors, resource crashes, and bind failures first. A process that exits or never binds cannot accept players.
2. Compare ports. Match the running endpoint to the provider-assigned port or the port forwarded on your router. Verify both TCP and UDP declarations.
3. Check the host firewall. Allow the assigned port for the FXServer process and confirm that a cloud security group is not blocking it.
4. Check the router. For self-hosting, forward the port to the correct internal address and give that machine a stable local IP. Double NAT or carrier-grade NAT can prevent inbound connections even when the rule looks correct.
5. Test from outside your network. Ask a friend to connect while you watch the console. A local test does not prove that internet forwarding works.
6. Check panel ownership. If txAdmin or the host regenerates server.cfg, your manual endpoint edit may not be the one actually running.
7. Revert the last change. Restore the known-good cfg, restart, and then reintroduce one change at a time.

If the server is visible but joining stalls, check that the advertised endpoint and the listening endpoint are identical. If only some players fail, compare their network path and region rather than immediately raising the slot cap; the official settings do not establish a universal networking prescription for every geography.

What should I monitor after launch?

Monitor the console and txAdmin during real sessions, especially when the group reaches its normal peak. Look for repeated resource errors, failed database calls, long-running commands, unexpected restarts, and players being rejected at the configured cap.

• Record the active player count and the cap you selected.
• Note which resource was added before a new error appeared.
• Keep restart schedules predictable and announce maintenance to the group.
• Review txAdmin roles whenever staff responsibilities change.
• Increase sv_maxclients only after checking the current artifact, Portal eligibility, OneSync requirement, and observed behavior.

There is no source-supported hardware number that guarantees a particular player count. A role-play framework with database-heavy scripts can behave very differently from a vanilla session at the same cap, so use your own logs and player experience to decide whether the next change is a resource fix, a hosting change, or simply a smaller advertised population.

Which configuration is best for common group sizes?

Use these as starting points rather than promises of capacity. They keep the configuration aligned with the documented slot and synchronization rules.

Situation	Recommended starting point	Reason
Private group under 16	OneSync on, cap close to the expected peak, vanilla resources, and the assigned endpoint.	Small configuration with little unused capacity to operate.
Group of 16–48	OneSync on, cap slightly above the normal peak, dependency review, and least-privilege txAdmin roles.	Provides room for regular sessions without implying unlimited performance.
More than 48	OneSync on; verify the current artifact and eligible Portal tier before raising the cap.	Cfx support places additional requirements above 48 slots.
More than 64	OneSync on and the required current artifact and subscription conditions.	Values above 64 require OneSync on.
Legacy-only resource	Keep the dependency isolated, use legacy only when necessary, and document the trade-off.	Legacy is a compatibility mode with documented performance and graphical drawbacks.

For most private groups, the first row is the right place to begin. Grow the cap only when the group’s real concurrency and the server’s measured behavior justify it.

Frequently Asked Questions

Can I change the slot limit without reinstalling the server?

Yes. Change sv_maxclients in the configuration that txAdmin actually launches, then restart the server. If the new value is above 48, verify the current artifact and eligible Portal subscription first; values above 64 also require OneSync on.

Should I use start or ensure for resources?

Use the startup form required by the resource and its recipe, but ensure is useful when you want a resource started at launch and restarted if it stops. The important safeguard is dependency order: load prerequisites first and validate the generated cfg in txAdmin before restarting.

Can two FiveM servers run on the same machine?

They can, provided each instance has its own endpoint port and separate data and configuration paths. Forward or expose each assigned port independently, and check that neither process is trying to bind the other instance’s TCP or UDP endpoint.

What is the safest way to recover from a bad config edit?

Stop the server, restore the last known-good cfg or recipe backup, and launch it before making another change. If the server starts, add the recent edits one at a time while watching the console so you can identify the specific resource, permission, or endpoint line that caused the failure.