fps.limit (Rust server ConVar)

fps.limit caps how many frames per second the Rust server process runs. The server prints no help text for it on build 25582902; on our test server it reads 256, the value Panelra writes by default.

A cap, not a target

The server runs as fast as it can up to the cap. Right after a restart, with no players and about 78,700 entities on a 4 vCPU host, our test server's serverinfo reported:

"Framerate": 202.0

with fps.limit at 256. Raising the cap does nothing when the server cannot reach it. To see the current rate, run server.fps, or read Framerate from serverinfo over RCON.

server.tickrate is a different setting: the help text calls it the "Number of server simulation ticks per second". It is 30 on our server. Do not change one expecting the other to follow.

Applying and keeping it

It can be changed on a running server:

fps.limit 256

For keeping it, the order in which files are read matters. Unlike most gameplay ConVars, server.writecfg does save fps.limit: our test server's serverauto.cfg has fps.limit "256". But server.readcfg runs serverauto.cfg first and server.cfg second, so a line in server.cfg wins over a saved value. If you set a new cap over RCON, save it with writecfg, and still have an old line in server.cfg, the old value comes back on the next reload. Keep one source: server.cfg.

Choosing a value

Whatever you choose, watch the real frame rate with players online rather than the cap. A server that stays well below its cap under load will not get faster from a higher one.

In Panelra

FPS limit is in Settings, from 10 to 500, default 256. Panelra writes it to the generated server.cfg and applies it with server.readcfg, without a restart, and reads it back over RCON to confirm the server took it. Server monitoring shows each server's live FPS next to its player and entity counts, so you can check the real rate against the cap.