Rust Console Admin Commands Not Sticking? Save Them So They Survive a Restart

Why your settings reset after a restart

Console has no F1 developer console and no plugins, so every admin change runs over WebRCON through a bot or your host panel. When you type a command over that RCON console, you change the value the server is running right this second. It applies instantly, which is exactly why it feels permanent.

But the server also keeps a saved config that it reads fresh every single time it boots. Your live command never touched that saved config. So the next time the server restarts, it loads the old saved values and your live change is simply overwritten. Nothing is corrupted and nothing crashed. The setting was just never written down.

This is the whole trap. A convar you set at 2am works perfectly all night, then the reboot reads the config, sees the old default, and puts it back. If you want the full picture of what you can run live in the first place, the guide to running admin commands over RCON lists the commands worth knowing before you start changing settings.

Which settings stick and which quietly vanish

Two different places hold your settings, and they behave in opposite ways. Knowing which is which tells you exactly what will survive a reboot.

Your G-Portal or Nitrado panel: anything you change in the host's server settings or config area is stored by the host and reloaded on every boot. Worldsize, slot count, the server name, and every setting the panel exposes will stick because the host writes it back on startup.

Live RCON commands: convars you push over the bot console only change the running server, and these are the ones that revert. The usual suspects are gather scale (default 1, most owners run 1 to 3), decay set to 0 for no decay, the PvP Mode and player-vs-building toggles that turn a server PVE, the TC upkeep toggle, the blueprint unlock toggle, fps.max, and time control. Set any of these live and they hold until the next reboot, then they are gone.

Save a live setting so it survives a reboot

The fix is to write your live values into the saved config, so the server loads them on boot instead of the old defaults. Four steps:

1. Set the convar live over RCON and confirm the value is right in game. 2. Run server.writecfg over the same RCON console. This writes the current running values into the server's saved config, so they load on the next boot. 3. If the same setting also exists in your host panel, set it there too so the panel and the running server agree. Do not leave a value fighting between the two. 4. Restart the server once on purpose and re-check the setting.

That last step matters on console. Some host panels rewrite the config on boot from whatever is entered in the panel, so where a setting is exposed in the panel, the panel wins and you should put it there. server.writecfg is for the convars the panel does not expose. Test with one deliberate reboot and you will know for certain which method saved which setting.

The restarts that reset you: patches, nightly reboots, and wipes

Every one of these reloads the saved config, so anything living only in the running server gets wiped along with it.

Nightly scheduled restarts you set for performance. Scheduled wipes, since most servers wipe weekly, often Thursday around 18:00 UTC, or biweekly, and a wipe reboots the server. If you run those on a timer, the guide to scheduled wipes and restarts on G-Portal is worth a look so the reboot lands when you expect it.

Then there are Facepunch patches. On G-Portal the server auto-updates and reboots when Facepunch ships an update, frequently the same Thursday. That reboot also knocks your bot offline until it reconnects, which is a separate headache if the bot does not come back on its own. If yours tends to stay down, read why a bot keeps dropping after a reboot and what a reliable one does differently. Crashes force the same fresh boot from config. If your settings are saved and mirrored in the panel, none of these touch them. If they are not, every reboot is a quiet reset.

Let a bot re-apply your settings on every reconnect

Even with everything saved, there are settings you enforce on a schedule or want re-applied the moment the server comes back: a PVE ruleset, time of day, event cadence, boosted gather for a wipe weekend. The hands-off fix is a bot that reconnects automatically after every reboot and re-applies your configured settings, so a patch reboot or a wipe never quietly changes how your server plays.

This is why bot reliability is not a nice-to-have. A bot that drops after a patch and never returns leaves your server running on stale defaults with nobody watching, which is the exact scenario behind a bot that stops working after a restart. The point of automation is that you stop babysitting it.

Vantic reconnects on its own after a G-Portal patch reboot and re-applies your settings, so what you configured on Monday is still true after Thursday's wipe. That is the difference between saving your config once and actually trusting it to hold.

A two-minute check before your next wipe

Run this quick pass and you will never chase a phantom reset again.

Set your gather, decay, PvP and player-vs-building, upkeep, and blueprint toggles the way you want them. Run server.writecfg to save the live ones. Mirror anything the panel exposes into the panel so the host does not overwrite it on boot. Do one deliberate restart and confirm every value held.

Last, confirm your bot reconnects after that restart, because a wipe reboot is the same event and you want it back online before the first players load in. The first 24 to 48 hours after a wipe is your peak population, so you want a server that boots in the right state and a bot already reconnected before that rush hits.

Frequently asked questions

Keep reading

Why your Rust Console bot keeps disconnecting · Bot stops working after a restart · Schedule automatic wipes and restarts on G-Portal · The admin commands over RCON cheat sheet · The wipe day checklist