Rust Server Config Editor: server.cfg, users.cfg and Plugin Configs

A Rust server is configured through a handful of files it keeps in its cfg folder — server.cfg for gameplay convars, users.cfg for owners and moderators, bans.cfg for bans — plus, if you run a modding framework, a pile of per-plugin JSON configs. The Rust Server Config Editor on a Loafhosts server pulls all of that into one place. You get a friendly form for the gameplay settings in server.cfg, a universal search across every convar in the file, raw editors for the users and bans lists and any plugin config, and a setup tab that owns your ports, world size, seed, and server name. This guide walks through exactly what the Config Editor does, what each tab is for, which settings are locked and why, and how your edits actually reach the server. Everything below describes the panel as it really behaves — no invented buttons.

Where to Find the Config Editor

Open your Rust server in the panel and look in the left-hand server sidebar for Config Editor. The page header reads Config Editor and carries a small pill showing your modding framework — vanilla, oxide, or carbon — so you always know which surface you are looking at. The editor is Rust-only: the sidebar item checks the server when it loads and quietly hides itself on any non-Rust game, so you will only ever see it where it applies.

Across the top of the page are three tabs: Server setup, server.cfg (form), and Files (raw). The editor opens on Server setup.

Note: The Config Editor only appears on Rust servers — it self-checks on load and hides on every other game.

Note: The framework pill (vanilla / oxide / carbon) next to the title reflects your server’s FRAMEWORK setting and decides whether plugin configs show up.

Note: Editing here uses the standard config read and config update sub-user permissions, so a sub-user needs those to view or save.

The Server Setup Tab: Ports, World, and Core Settings

The Server setup tab surfaces the most-changed startup settings as a tidy form, grouped into General, World, and Connection & Ports. These are the same values you would otherwise set on the server’s Startup tab — the Config Editor just gives them a friendlier home. Saving here writes them to your server’s startup variables, and the change applies on the next restart.

Under General you have your server name (the hostname shown in the browser, up to 100 characters), max players, the save interval in seconds, a multi-line server description (up to 1500 characters, with your line breaks preserved exactly as players will see them), and your server website URL. Under World you have the world size, the world seed, and the map (level), which is normally Procedural Map. Under Connection & Ports are the three secondary ports: the app port for the Rust+ companion app, the query port that feeds the server browser, and the RCON port for remote admin.

The world size is a dropdown of preset sizes — 1000, 1500, 2000, 2500, 3000, 3500, 4000, 4500, 5000, and 6000 (there is no 5500 option) — and sizes of 4500 and above are flagged as high-RAM, because a bigger map needs more memory and takes longer to generate. The world seed has a Randomize button next to it for grabbing a fresh procedural layout; remember a new seed only takes effect on a wipe.

Tip: Changing the world seed gives you a different map, but the new map only appears after a wipe — pair a seed change with a map wipe.

Tip: Keep your server name under about 60 characters so it isn’t cut off in the in-game server list, even though the field allows up to 100.

Note: The server description is multi-line — press Enter for a new line and the editor keeps the breaks intact.

How the Ports Are Handled

The app, query, and RCON ports are allocated automatically from your node’s free port pool, so in normal use you never have to touch them. They do appear as editable number fields, though — you can type a specific port into any of the three and save it, as long as it is a whole number between 1024 and 65535. The setup tab shows a small status banner telling you whether your ports are ready, were just auto-configured, or still need setting up, and there is a Re-allocate ports automatically action if you ever need the panel to claim fresh ports for you. Whichever port you set has to stay open and allocated on the node, so the safest path in normal use is to let the panel allocate them. After any port change, restart the server to apply it.

Note: Ports are pulled from your node’s free port pool automatically — you normally don’t need to change them.

Note: Port values are validated to the 1024–65535 range, and a re-allocation only takes effect after a restart.

The server.cfg Form and Universal Search

The server.cfg (form) tab is where the gameplay convars live, and it has up to three parts. The top section, Gameplay convars, is a typed form: real toggles for booleans, number boxes for numeric convars, and text fields for the rest. Below it is Search every convar in server.cfg, a type-to-search box — it starts out prompting you to “type to search across every convar,” and as you type it filters the whole file by convar name or value and shows the matches inline, so you can edit anything, even convars that don’t have a dedicated widget. Finally, if your server.cfg contains convars that have no preset widget, they are gathered into an Other convars in server.cfg card at the bottom, each shown as a plain editable text field.

The friendly form deliberately covers the vanilla convars that have a clear, safe meaning and no competing panel setting. That includes PvE mode (turn PvP off), radiation, building stability, game mode, global chat, tick rate (10–30), the decay multiplier and upkeep period, max team size, the idle-kick timer and its mode, the in-game tip text, and whether chat is logged to the console. Each field shows a short note about whether the change applies immediately or wants a restart, so you know what to expect after saving.

Anything not in that curated list still shows up — it lands in the Other convars card as a plain editable value rather than a typed widget, and it is also reachable from the search box. The convars you change are saved by the Save changes button, and the editor is careful with your file: it patches server.cfg in place, preserving your comments, blank lines, the order of your convars, and each convar’s existing quote style. If server.cfg doesn’t exist yet — for example on a brand-new server that has never started — your first save creates it.

Tip: Use the search box to find a convar by name or value — type a query and it scans the whole file, not just the convars with a friendly toggle. It only shows results once you start typing.

Note: Saving rewrites only the convars you changed; your comments, spacing, and convar order are kept exactly as they were.

Tip: Gather rates, instant craft, and day/night length are not vanilla convars — they need an Oxide plugin — so they are intentionally left out of the form to avoid settings that would silently do nothing on a vanilla server.

Why Some Convars Are Locked

In server.cfg you will see certain convars shown but locked, where you cannot edit them. Two groups are protected. The first is allocation, RCON, and identity: server.port, server.queryport, server.identity, app.port, and the rcon.* convars. The second is the convars the panel manages elsewhere: the hostname, max players, world size, seed, description, URL, save interval, and level — all surfaced on the Server setup tab — plus the server header image, which is set on your server’s native Startup tab (the Config Editor’s Server setup tab has no header-image field of its own).

The reason is a quirk of Rust itself: convars set in server.cfg take priority over the command-line arguments the server launches with. If both the form and server.cfg could set, say, the hostname, the file would silently win and the two would disagree. So the editor locks those keys in server.cfg and points you at the Server setup tab (for the host-managed ones) instead. For the server name and the server description specifically, you can clear that field on the setup tab to release the convar — at which point your own server.cfg value is honored again.

Note: Locked convars are protected on every path — the form, a batch save, and even a raw file edit all refuse to change them.

Note: In Rust, server.cfg overrides the launch arguments, so the panel locks the host-managed keys to keep the two from fighting.

Tip: Want your own server.hostname or server.description from server.cfg? Clear that field on the Server setup tab to hand the convar back to your file.

The Files (Raw) Tab: users.cfg, bans.cfg, and Plugin Configs

The Files (raw) tab lists every file in your cfg folder and gives each one a plain text editor. That list includes server.cfg itself — so you can open it as raw text here if you ever want to, though the server.cfg (form) tab is the friendlier way to edit it. Mostly, though, this is where you manage users.cfg and bans.cfg — the lists of ownerid and moderatorid entries and ban commands — by editing them directly.

You will also see serverauto.cfg in the list, but it is read-only. The server rewrites that file itself at runtime, so the editor refuses to save changes to it; anything you typed would just be overwritten on the next start, and the panel blocks the save rather than letting you lose the edit.

If your server runs a modding framework, this tab also surfaces your plugin configs. When FRAMEWORK is oxide, the editor lists every *.json under the Oxide config folder; when it is carbon, it lists the Carbon configs instead. Those are edited as raw JSON, and the editor validates the JSON before saving — a malformed config can crash the framework on load, so a broken file is rejected with the parse error instead of being written. On a vanilla server, the plugin-config section simply isn’t shown.

Note: serverauto.cfg is regenerated by the server, so it is listed read-only and saves to it are blocked to prevent data loss.

Note: Oxide and Carbon plugin configs are validated as JSON on save — an invalid file is refused so it can’t break your framework.

Tip: The modding section only appears once you’re running Oxide or Carbon; install one of those frameworks first and your plugin configs become editable here.

How Your Edits Reach the Server

It helps to know where each change actually lands. The Server setup fields write to your server’s startup variables and sync to the daemon, applying on the next restart. The server.cfg form and the raw cfg files are written straight to disk in the server’s cfg folder, and because the Rust egg doesn’t regenerate server.cfg, that file on disk is the single source of truth — your edits there persist across restarts. The editor is confined to two folders: the cfg folder and, when your framework enables it, the plugin-config folder. Any path outside those is rejected before it ever reaches the server, and there is a size cap (1 MB by default) on reading or writing a single file.

So in practice: change ports, world, and core settings on Server setup and restart; tweak gameplay convars on server.cfg (form) and save (many apply live, some want a restart — the note on each field tells you which); and manage owners, bans, and plugin configs on Files (raw).

Note: server.cfg on disk is the authority for gameplay convars and survives restarts — the panel never overwrites it from your startup variables.

Tip: When a field’s note says “Restart required” or “Restart recommended,” restart the server after saving so the change takes effect cleanly.

Note: The editor can only touch the cfg folder and the plugin-config folder, with a per-file size limit, so it can’t be used to reach the rest of the filesystem.