BeamMP max players: server limits, MaxCars and lag

A BeamMP server has no hard player cap of its own. MaxPlayers accepts any number from 1 upwards, and the server program will relay for as many people as you let in. The limit you actually hit is somewhere else: every player's PC has to simulate every car on the server, so the real ceiling is the total vehicle count, MaxPlayers multiplied by MaxCars, measured against the weakest PC in the session. For a mixed public crowd that means roughly 10-12 players with 1-2 cars each. A group of friends with strong CPUs can run 20 or more with one car each. Past about 30 vehicles in the same area, almost nobody's machine keeps real-time physics.

The server itself is the cheap part. It uses little CPU and memory, and its cost grows with bandwidth, which rises with the square of the player count. This post covers where each limit comes from, how to estimate traffic, what causes the stutter and teleporting people call lag, and how to size MaxPlayers and MaxCars for the server you want to run. For installation, the auth key and the rest of ServerConfig.toml, start with the BeamMP server guide.

Why the limit is on the players' PCs#

BeamNG.drive simulates every vehicle as a soft-body structure of hundreds or thousands of nodes and beams, at a physics rate far above the frame rate. That is what makes the crashes look right, and it is expensive. A modern desktop CPU can keep a handful of vehicles in real time. Past that, BeamNG does not drop detail - it slows the simulation down, and you see cars moving in slow motion while the clock ticks normally.

BeamMP does not change that model. Each client runs its own vehicles authoritatively and also runs a local simulation of every other player's vehicles, corrected by the position and state updates that arrive through the server. The server sees none of the physics. It authenticates players, keeps track of who owns which vehicle, relays updates and runs Lua plugins.

So when ten players each have two cars out, every one of the ten PCs is simulating twenty vehicles. A player with a fast CPU and a player with a five-year-old laptop are asked to do exactly the same work, and the laptop decides how the session feels for its owner. Nothing on the server side can take that load off them. A larger hosting plan does not help a client whose CPU is pinned.

Two consequences are worth stating plainly:

• Doubling the players roughly quadruples the total work. Twice as many PCs each simulate twice as many cars. That is why a server that felt fine at 8 feels broken at 16, and why lowering MaxCars buys more headroom than any other change.
• Server-side performance graphs will usually look calm while players complain. The server's CPU is not where the work is. Before upgrading anything, ask what the complaining players' frame rates and simulation speed look like.

MaxPlayers and MaxCars: what they actually do#

Both settings live in the [General] section of ServerConfig.toml. The defaults written by current server builds are conservative:

[General]MaxPlayers = 8MaxCars = 1Private = true

MaxCars is per player, not per server. There is no built-in server-wide vehicle cap, so the worst case is always the product of the two numbers. A server with MaxPlayers = 20 and MaxCars = 3 permits 60 vehicles, and on a crowded evening it will get close.

A few details catch people out:

• Everything a player spawns is a vehicle. Trailers, props and AI traffic spawned from the client each take a slot against MaxCars. So, on most versions, does the walking mode (the unicycle), which is why a player on a MaxCars = 1 server who gets out to walk can find their car removed. If your server is built around trailers or towing, MaxCars = 2 is the practical minimum.
• Spawning is the expensive moment. When a vehicle spawns or is edited, every client has to load and build it, and BeamNG freezes briefly while it does. On a busy server, players resetting or swapping cars produce a stream of small hitches for everybody else. BeamMP's client offers a queue in its multiplayer options that holds remote spawns and edits until a convenient moment; option names have changed between client versions, so look in the Multiplayer section of the in-game settings for yours.
• The limits are enforced, not advisory. A vehicle over the MaxCars limit is deleted rather than refused politely, and a player over MaxPlayers is turned away at the door.

If you want rules smarter than "N per player" - a server-wide cap, different limits for staff, no heavy trucks after a certain player count - that is a Lua plugin, covered below.

Bandwidth per player and how it scales#

The server's traffic is easy to model once you see the shape. Every vehicle's owner sends a stream of position, rotation, velocity and input updates to the server. The server forwards each of those streams to every other player. Electrics and damage updates add more when something happens - lights, horn, a crash - and spawn and edit events carry the full vehicle configuration.

That gives the server's outbound traffic a quadratic shape:

outbound ≈ players × (players - 1) × cars per player × per-vehicle streaminbound  ≈ players × cars per player × per-vehicle stream

The per-vehicle figure depends on the client version, how fast cars are moving and how often they are damaged, so measure it rather than trusting a number from a forum. What you can rely on is the scaling. Holding everything else equal:

The jump from 8 to 16 players at one car each costs four times the upload, and 30 players with two cars each costs thirty times what the default config does. Inbound traffic stays linear and small; as with nearly every game, outbound is the side that fills. Game server bandwidth per player covers that asymmetry across games, and why steady-state traffic is rarely the real problem.

The bursts matter more than the steady state. Every byte in Resources/Client is sent to each joining player who does not already have it. A 2 GB mod pack with five people joining at the start of an event is 10 GB going out in a few minutes, competing with the vehicle streams of everyone already driving. That is often the moment a session that was smooth suddenly rubber-bands for all, and it has nothing to do with player count. Keep the pack lean, tell people its size in advance, and ask regulars to join early before an organised event.

On your own Linux machine, the quickest way to see the real numbers is to watch the port while a session is running:

$ sudo iftop -i eth0 -f "port 30814"$ vnstat -l -i eth0

iftop shows live traffic per connection, which also reveals which player is downloading the mod pack. vnstat -l gives a running total for the interface. Note the figures at a busy moment with a known player and car count, divide, and you have your own per-vehicle number to plug into the formula.

For a home host, the upload is the wall. A residential line with 20-40 Mbit/s up is fine for a small group and runs out quickly at the top of that table, especially while somebody is downloading mods. A datacentre uplink has headroom for any realistic BeamMP server, but unmetered is not unlimited, and a public server pushing a multi-gigabyte pack to strangers all day is the kind of traffic that question is about.

Sizing table: players, cars and server resources#

Two different things need sizing, and they are easy to mix up. The first is the session - how many vehicles you ask players' PCs to simulate. The second is the server - RAM, CPU and bandwidth for the relay program.

Start with the session. These are working figures for a public or semi-public server where you do not control the players' hardware:

Close racing and demolition derby deserve their own row. Crashes are the most expensive thing BeamNG simulates, collisions between remote vehicles are where desync shows up most, and in a derby every car is in the same small arena. A twelve-car derby is a harder load than a forty-car cruise spread over Italy, because in the cruise most vehicles are far away and moving smoothly.

Then the server. The relay is light, and memory is mostly the program, the Lua state and buffers for in-flight mod transfers:

CPU on the server is single-thread work most of the time. If it is high with a modest player count, the cause is almost always a Lua plugin running a fast timer or doing heavy JSON work in a spawn handler, not the number of players. BeamMP Lua plugins and races shows how to time handlers with Util.DebugExecutionTime(). Disk is whatever your mod pack weighs plus a little; see how much storage a game server needs for the general picture.

On RE:NODE the BeamMP plans run from 2 GB with one vCPU up to 8 GB with three, on NVMe, and the CPU is a hard share rather than a burst. For BeamMP the lower tiers cover nearly every server, because the expensive part happens on the players' machines; a bigger plan is worth it for a large mod pack's disk space or plugins doing real work, not for raising MaxPlayers.

What causes lag and desync#

"Lag" covers at least five different problems on a BeamMP server, and they need different fixes. Telling them apart takes a minute of asking the right questions.

Slow motion for one player. Their CPU cannot keep the physics in real time with the number of vehicles nearby. BeamNG slows the simulation rather than skipping, so on their screen everything moves slowly, and on everyone else's screen their car moves strangely. This is the most common complaint on a busy server and it is entirely client-side. Fewer vehicles fixes it; nothing else does.

Remote cars jittering, teleporting or driving through walls. Missing or late updates. Each remote car is simulated locally between updates and then corrected, and when updates are lost the correction is large and visible. If one player's car does it on everyone's screen, the problem is that player's connection. If every remote car does it on one player's screen, it is the viewing player's connection. If everyone sees it from everyone at the same moment, look at the server's upload - often a mod download or a burst of joins. Latency, jitter and packet loss explains how to tell the three apart with a ping test.

Collisions that do not agree. Two players crash, and each sees a different result. This is built into the architecture: each car's owner is authoritative for its own physics, and the other car on their screen is a prediction from slightly old data. At 100 ms of latency between two players, a car at 100 km/h is nearly three metres away from where the other player thinks it is. Contact sports on BeamMP work best between players with low ping to the same server, which is the real argument for hosting near your players. Some servers turn collisions off for public cruising for exactly this reason, through a plugin or a client mod; check what your version offers.

Everyone freezes for a second. A vehicle spawn or edit, almost always. Heavy modded vehicles with high node counts make it worse. A server where people constantly respawn because they keep crashing will feel stuttery for everyone. The client-side queue helps; a plugin that limits spawn frequency per player helps more.

Stutter that started after adding a mod. Some vehicle and map mods are much heavier than the stock content, or are broken for the current BeamNG version and spam errors every frame. Test by moving a mod out of Resources/Client and restarting. If a map mod is the problem, the cost is paid by every player for the whole session.

Controlling vehicle count with a Lua plugin#

MaxCars is a blunt tool. A plugin can enforce a total for the whole server, which is the number that actually matters to the clients. onVehicleSpawn fires before the vehicle is accepted, and returning 1 cancels it:

local SERVER_CAP = 24local function countVehicles()    local total = 0    for id, _ in pairs(MP.GetPlayers() or {}) do        local vehicles = MP.GetPlayerVehicles(id)        if vehicles then            for _ in pairs(vehicles) do total = total + 1 end        end    end    return totalendfunction capSpawn(playerID, vehicleID, data)    if countVehicles() >= SERVER_CAP then        MP.SendChatMessage(playerID, "Server vehicle limit reached. Remove a car first.")        return 1    endendMP.RegisterEvent("onVehicleSpawn", "capSpawn")

With this in place you can set MaxCars = 3 so that players have room for a trailer, and still be sure the server never asks a client to run more than 24 vehicles. The same handler is where you would refuse specific heavy models, or allow a higher count for staff by checking the beammp identifier. Test any plugin against your server version first - the API has changed between major releases, and the Lua plugin guide covers the event signatures in detail.

Keep handlers like this cheap. A spawn handler that loops over a few dozen vehicles costs nothing; one that decodes every vehicle's full configuration JSON on every spawn starts to show up in the server's CPU on a busy night.

Raising the limit safely#

When a server feels full, the order of changes matters. Most of the useful levers are free:

1. Lower `MaxCars` first. Going from 2 to 1 halves the client load and the bandwidth. Add a plugin cap if people need trailers.
2. Pick a larger map for bigger crowds. Cars far apart are cheaper to have around than cars in the same intersection, and they generate fewer collisions to disagree about. Gridmap and small arenas are for small groups.
3. Trim the mod pack. Every heavy vehicle mod raises the per-vehicle cost on every client, and the pack size decides how painful joins are.
4. Set expectations in the server description. "Recommended: 6-core CPU" in Description or your Discord saves you from players who join, run at half speed and blame the host.
5. Raise `MaxPlayers` in small steps. Go from 10 to 14, watch a full evening, then decide. Watch for players reporting slow motion, not just the server's own numbers.
6. Only then look at the plan. If server CPU is genuinely high, find the plugin first. If upload is the limit at home, a datacentre host fixes it.

A restart before a big session is good hygiene rather than a performance fix: it clears any stuck vehicle state and makes sure everyone starts on the same server version. Restart schedules that help covers when to schedule it. On RE:NODE the Schedules tab can run that restart, and a backup before it, on a cron expression.

Troubleshooting#

Players report slow motion as soon as the server fills. Too many vehicles for their CPUs. Lower MaxCars or MaxPlayers; a bigger server plan will not change it.

Everybody rubber-bands at the same moment. Check whether someone was joining and downloading the mod pack. If not, check the server's upload, especially on a home connection.

One player's car teleports on everyone's screen. That player's connection. Ask them to test packet loss to the server address over a wired link.

New vehicles disappear immediately after spawning. The player is at MaxCars, possibly counting a trailer or the walking unicycle. Or a plugin returned 1 from onVehicleSpawn.

Server CPU at 100% with a handful of players. A plugin. Remove plugins from Resources/Server one at a time, or time their handlers.

The server is full but the list shows free slots. The list refreshes on a delay. Players connecting by address get the real answer.

FAQ#

What is the maximum number of players on a BeamMP server?

There is no fixed maximum in the server; MaxPlayers takes any positive number. The working limit is client performance: busy public servers usually run 10-20, and very large events need one car each and players with strong CPUs.

Should I raise MaxPlayers or MaxCars?

For a public server, players. Each extra car per player adds a full vehicle to every client for every player connected, so MaxCars is the more expensive of the two. Keep it at 1-2 and raise player slots instead.

Does a better server plan reduce BeamMP lag?

Only when the server is the bottleneck, which is uncommon: a plugin using too much CPU, or a home connection running out of upload. Slow motion and collision disagreements come from players' PCs and connections.

Does the walking unicycle count as a car?

On most BeamMP versions, yes - it is spawned as a vehicle and counts against MaxCars. Allow at least two cars per player if you expect people to get out and walk.

How much upload does a BeamMP server need?

It grows with the square of the player count, so measure at a known load and scale from there. A small group fits on a home connection; twenty players with two cars each, plus mod downloads, needs a datacentre uplink.