Edit server.cfg from the dashboard

import { Steps } from ‘@astrojs/starlight/components’;

CerebRUST can read and write your server’s server.cfg. Changes take effect immediately, without a restart, and stay put afterwards.

That needs one thing your host almost certainly already gives you: SFTP details.

Your server’s name and blurb need none of this

Setting server.hostname, server.description, server.url and server.headerimage works on any server running the CerebRUST plugin, with nothing connected — the change appears in the server browser within seconds. Connect SFTP or a panel to make it survive a restart. See where a save actually goes.

Connect SFTP

1. Find your SFTP details

   Your host shows them somewhere as a hostname, a port, a username and a password. On Pterodactyl and Pelican they are on the server’s main page under SFTP Details.

2. Add them in CerebRUST

   Go to your server → Integrations → SFTP. Paste the host in full, including the port — sftp://your-host.example:2022 — then the username and password.

3. Test, then save

   Test connection checks three things: that the login works, that CerebRUST can find your Rust server’s folder, and that the account is allowed to write. Save refuses if any of them fail, because an integration that has never connected is worse than none at all.

Only the server’s owner can do this

An integration is a credential for the machine your server runs on, so it is deliberately restricted to the account that owns the server in CerebRUST. Your admins cannot see it or change it — but once it is connected, they can use it to edit the config.

What CerebRUST does with the password

It is encrypted before it is stored and is never sent back to your browser — the field on the page stays blank, and leaving it blank when you save keeps the password you already gave. It is only ever used to reach your server.

CerebRUST also remembers your host’s SSH key the first time it connects. If that key ever changes, it refuses to connect until you remove and re-add the integration. Hosts do occasionally rebuild a machine, so this can be a false alarm — but it can also be somebody standing in the middle, and the two look identical from here.

The order to do things in

A brand-new server has no server.cfg, and CerebRUST does not know it exists until the plugin reports in — which needs the server to have started. So:

1. Create the server with your ingest token and start it. It boots on Facepunch’s defaults and generates a default map.
2. Connect SFTP and configure it in CerebRUST.
3. Restart. Settings read at startup — world size, seed, level — take effect now, which means the map from step 1 is replaced.

It is not elegant, and it is deliberate: the alternative is CerebRUST trying to know about servers before they exist. If the seed and size of your very first map matter to you, do steps 2 and 3 before letting anyone join.

Rust never writes server.cfg itself — it exists only if somebody ran server.writecfg or created it by hand — so an empty config on a new server is normal. CerebRUST creates the file on your first save, along with the cfg folder if that is missing too.

Edit the config

Anything your host sets on the command line wins at boot

A game server can be given settings as startup arguments, and those override server.cfg every time it boots. Saving here still works — CerebRUST asks the server to re-read the file, so your change applies straight away — but on the next restart the command line is applied first and wins again.

Most panels pass the server name, description and player limit that way. The CerebRUST egg passes none of them, which is the whole point of it: on that egg server.cfg is the only source of truth.

Your server → Configure → Rust server file. Two tabs, both of which save the same way:

• Settings — the convars most owners actually change, with sensible ranges, descriptions and a warning where one applies.
• Raw file — the whole server.cfg as text, for anything not on the Settings tab.

Saving writes the file and then asks the plugin to re-read it, so the change is live within a couple of seconds and survives the next restart. Anything CerebRUST does not model — your comments, your own convars, your ordering — is left exactly as it is.

A description can span several lines

Type line breaks into the description normally. server.cfg is one command per line, so CerebRUST stores them as \n in the file — which is what Rust expects, and what makes a multi-line description render properly in the server browser. Reading it back turns them into real line breaks again.

Two things worth knowing

Deleting a setting does not undo it. Rust applies the file; it has no way to un-apply something the file no longer mentions. Clearing a setting on the Settings tab writes its default back, which genuinely reverts it. Deleting a line on the Raw file tab does not take effect until the server restarts, and CerebRUST tells you which lines that applies to.

World size, seed and level wipe the map. They are read when the world is generated, long before anything CerebRUST can talk to exists, so no amount of saving applies them to a running server. The restart that does apply them generates a new world, and every base on the old one is gone. Those three are marked in red for exactly that reason.

Where a save actually goes

A Rust setting can live in up to three places, and which one wins depends on how your host starts the server — something CerebRUST cannot see from the outside. So rather than guessing, it writes everywhere it can reach and tells you which those were:

Where	What it means
Running server	Applied now, over the plugin. Reverts on restart unless something below also took it.
server.cfg	Saved to the file over SFTP or your panel. Survives a restart — unless your host overrides it.
Game panel	Saved as a startup variable. This is the one that beats the file on most panels.

Each one is listed after a save with a line saying what happened, including the ones that were skipped and why. If a setting could not be written anywhere, the save fails and says so — it will never tell you it saved something it did not.

Why the panel matters here. Most panels pass settings like the world size and seed on the startup command line, and command-line settings beat server.cfg at boot. Connect your panel on the Integrations page and CerebRUST writes them where they are actually read from. The CerebRUST Pterodactyl egg deliberately passes none of them, so on that egg the file is the only truth and there is nothing for the panel to override.

Undo

Every save keeps the file as it was beforehand, on the same page, with who changed it and when. Restore puts one back — and because a restore is itself a save, it too can be undone.

This matters most on the Raw file tab, where a save is live the moment it lands.

If something goes wrong

What you see	What it means
“could not reach…”	Wrong host or port, or your host’s firewall. Check the port — it is rarely 22.
“the username or password was rejected”	Wrong credentials. Some hosts want user.serverid as the username.
“no Rust server directory was found”	CerebRUST looks for a server/<identity> folder. Your SFTP account may start somewhere other than the server’s own directory, or the server may never have been started. A missing server.cfg is not the problem — see above.
“the account cannot write”	A read-only SFTP account. Editing needs write access.
“the host’s SSH key has changed”	See above. If your host rebuilt the machine, remove and re-add the integration.
“Saved. The server could not be asked to reload”	The file was written. Your server was down or unreachable, so the change applies when it next starts.