A Rust server doesn't need a GPU, but it is heavy on memory and single-core performance. The larger the map, the more players online, and the denser the buildings and entities, the higher the resource requirements. Below is a conservative starting point for buying a VPS, not a hard guarantee of concurrency:

The LinuxGSM Rust page lists a minimum of 9GB of memory and notes that larger maps will increase requirements further. So don't force a production server onto a 4GB or 8GB VPS, and don't treat swap as a substitute for memory. For CPU, prioritize stable single-core performance rather than just comparing vCPU counts.

The data center should be close to your main players, and you should confirm the provider allows game servers, has UDP protection and sufficient traffic. For public servers, also pay attention to DDoS scrubbing policies, ban rules after attacks and the cost of changing IPs. Before buying, you can refer to the game server VPS recommendations and configuration guide.

This article chooses LinuxGSM because it directly matches Rust's SteamCMD update, RCON, wipe and backup workflows. If you need to manage Rust, Minecraft, Palworld and CS2 in a single panel, the Pterodactyl game server panel on a VPS is a better fit.

This article explicitly uses the following ports to avoid relying on automatic derivation:

Facepunch documentation states that server.port and server.queryport are both UDP and cannot be the same; if the query port is not explicitly set, it is derived from the game port or RCON port. RCON is a management entry point and must never be exposed naked to the entire internet.

When preparing a separate domain (for example rust.example.com), you only need to add an A record pointing to the VPS public IPv4. The regular Cloudflare orange-cloud proxy does not forward Rust UDP traffic, so set it to DNS only.

First update the system and install basic tools:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates ufw tmux unzip tar bzip2

Create a dedicated user; don't let the Rust server run as root long-term:

sudo adduser rustserver
sudo usermod -aG sudo rustserver
sudo -iu rustserver

During installation LinuxGSM may need sudo to install system dependencies. After installation is complete and you've confirmed the service runs, you can remove its sudo privileges from another admin account:

sudo deluser rustserver sudo

Before doing this, make sure you still have another working sudo admin account so you don't lock yourself out of the system.

All the following commands are run as the rustserver user:

cd /home/rustserver
curl -Lo linuxgsm.sh https://linuxgsm.sh
chmod +x linuxgsm.sh
bash linuxgsm.sh rustserver
./rustserver install

The installer checks dependencies and downloads the Rust Dedicated Server via anonymous SteamCMD login. After installation, first check the details:

./rustserver details
./rustserver validate

details shows the config directory, ports, logs and service status; validate validates files with SteamCMD. Don't force validate on every normal start, as it increases startup time and disk I/O; it's better suited for failed installs or corrupted files.

First generate a random RCON password and save it to your password manager:

openssl rand -hex 24

Edit the instance config:

nano /home/rustserver/lgsm/config-lgsm/rustserver/rustserver.cfg

Write the parameters you need to override:

ip="0.0.0.0"
port="28015"
queryport="28017"
rconport="28016"
appport="28082"

rconpassword="替换为刚生成的随机密码"
rconweb="1"

servername="My Private Rust Server"
gamemode="vanilla"
serverlevel="Procedural Map"
seed="20260815"
worldsize="3000"
maxplayers="20"
saveinterval="300"
tickrate="30"
tags="monthly,vanilla"

maxbackups="8"
maxbackupdays="14"
stoponbackup="on"

Don't edit _default.cfg directly. LinuxGSM explicitly states that the default file will be overwritten on updates; write customizations into common.cfg or the current instance's rustserver.cfg.

Restrict config file read permissions:

chmod 600 /home/rustserver/lgsm/config-lgsm/rustserver/rustserver.cfg

Map size allows 1000-6000, but large maps consume more memory, disk and generation time. Small private servers are easier to stabilize starting at 3000. seed determines the procedurally generated map; before changing the seed or map size you must back up and treat it as a new wipe.

Start the server:

cd /home/rustserver
./rustserver start
./rustserver details
./rustserver monitor

Enter the console to watch the first map generation:

./rustserver console

Once you see the service has finished starting, press Ctrl+B, then press D to detach from tmux. Don't press Ctrl+C, as that will terminate the server process.

View logs:

tail -n 200 /home/rustserver/log/console/rustserver-console.log
tail -f /home/rustserver/log/console/rustserver-console.log

If the specific log file name changes, use the path output by ./rustserver details.

First keep the current SSH session open and allow SSH:

sudo ufw allow OpenSSH
sudo ufw allow 28015/udp
sudo ufw allow 28017/udp

Replace the example address below with your admin computer's fixed public IP, allowing only that address to connect to RCON:

sudo ufw allow from 203.0.113.10 to any port 28016 proto tcp

Open this only if you need Rust+:

sudo ufw allow 28082/tcp

After confirming the rules, enable the firewall:

sudo ufw status numbered
sudo ufw enable
sudo ss -lunp | grep -E ':28015|:28017'
sudo ss -lntp | grep -E ':28016|:28082'

The cloud provider security group must also be configured with the same protocols. The most common mistakes are opening 28015 as TCP only, or opening the game port but missing 28017/UDP, so players can connect directly but the server can't be found in the server list.

In the Rust client, press F1 to open the console and enter:

connect rust.example.com:28015

You can also use the public IP directly. Before the first connection, enter the server console to add an Owner:

ownerid 76561198000000000 "AdminName" "Server owner"
server.writecfg
save

Replace the example SteamID64 with your real ID. Facepunch documentation states that after adding an admin you must run server.writecfg, and permissions take effect only after the player reconnects.

Common daily management commands:

status
players
save
say Server will restart in 5 minutes
kick SteamID64 "reason"
ban SteamID64 "reason"

Anything you can do through the SSH console doesn't need RCON exposed. If you really need a remote panel, restrict 28016/TCP to the admin's fixed IP, or allow only WireGuard/Tailscale private network access.

Vanilla servers don't need plugins. Install Oxide/uMod only when you explicitly need whitelist, permissions, queues, teleport or management features:

cd /home/rustserver
./rustserver mods-install
./rustserver restart

LinuxGSM's Rust documentation states that plugin files are located at:

/home/rustserver/serverfiles/oxide/plugins/

Configuration is usually located at:

/home/rustserver/serverfiles/oxide/config/

After a Rust update, Oxide/uMod may need to be updated in sync:

./rustserver mods-update
./rustserver restart

Install only one plugin at a time, record the source and version, and back up saves first. Get plugins from the official uMod page or the project repository; don't drop DLLs, scripts or archives reposted on forums directly onto a production server.

LinuxGSM provides three key commands:

./rustserver monitor
./rustserver update
./rustserver backup

Edit crontab as the rustserver user:

crontab -e

Add:

*/5 * * * * /home/rustserver/rustserver monitor > /dev/null 2>&1
*/30 * * * * /home/rustserver/rustserver update > /dev/null 2>&1
30 5 * * * /home/rustserver/rustserver backup > /dev/null 2>&1
0 6 * * 0 /home/rustserver/rustserver update-lgsm > /dev/null 2>&1

monitor tries to recover when the process is offline, and update checks for SteamCMD updates and only updates and restarts when needed. The stoponbackup="on" in the backup config prioritizes file consistency, so the daily 05:30 run may cause a brief outage; adjust it based on player activity times and announce it in advance.

LinuxGSM's local archives by default cannot withstand VPS disk failure, account bans or data center incidents. Regularly sync the backup directory encrypted to another object storage or off-site server, and actually perform recovery drills. For off-site strategies, see the VPS backup and recovery drill guide.

A Rust wipe is not "delete a few files and try again". First announce the shutdown, save the world and create an extra backup:

cd /home/rustserver
./rustserver backup

Reset only the map, keeping player blueprints:

./rustserver map-wipe

Reset the map and all player blueprints:

./rustserver full-wipe

LinuxGSM documentation clearly distinguishes the two; Facepunch also points out that forcibly renaming old saves to bypass protocol changes is dangerous. Before running a wipe, record the seed, world size, plugin list and current backup files, and don't put unverified wipe commands into unattended cron.

Rust usually releases larger updates monthly and may also release hotfixes. The safe upgrade order is as follows:

1. Notify players in advance;
2. Run save in the console;
3. Run ./rustserver backup;
4. Run ./rustserver update;
5. If using plugins, then run ./rustserver mods-update;
6. After starting, check logs, map, player data and plugins;
7. Re-test 28015/UDP and the server list from an external network.

Use this only when you encounter corrupted files or abnormal SteamCMD state:

./rustserver validate

Don't manually delete serverfiles/server/rustserver/ without a backup. That identity directory contains the map, saves, blueprints, admins, bans and Rust+ pairing data.

Look at real resources first; don't reinstall right away:

free -h
vmstat 1 10
top
df -h
df -i
iostat -xz 1 10
./rustserver details
./rustserver monitor

Common diagnostic order:

1. Memory nearly exhausted and continuous swap: reduce map size, reduce plugins or upgrade memory;
2. Single core pegged for long periods: reduce entity and plugin load, switch to a VPS with higher single-core performance;
3. High disk latency: confirm NVMe is used, check whether backups and logs are competing for I/O at the same time;
4. Server not found in the list: check 28017/UDP, cloud security group and query port;
5. Players' direct connections time out: check 28015/UDP, listen address and DDoS scrubbing status;
6. Plugins error after update: update Oxide/uMod and plugins, and if necessary verify with Vanilla first;
7. Rust+ offline: check 28082/TCP and whether the server can make outbound connections to the Facepunch Companion service.

Expanding the map from 3000 to 4500 is not a free "content upgrade"; it directly increases generation time, memory, disk and entity scale. Validate with peak-hour data first, then adjust gradually.

• The VPS meets the memory requirements of the current map and player count, using NVMe
• Rust runs as a dedicated rustserver user, not as root
• 28015/UDP and 28017/UDP are reachable from external networks
• 28016/TCP allows only admin fixed IPs or VPN
• 28082/TCP is not open when Rust+ is unused
• RCON uses a random strong password, config file permissions are 600
• Admin SteamID64 is written and server.writecfg has been run
• The monitor, update and backup scheduled tasks actually execute
• Local backups have an off-site copy, and a recovery drill has been completed once
• Before a wipe there is an announcement, save, backup and a clear map/full choice
• Plugin sources are trusted, and Oxide/uMod is checked in sync after Rust updates
• Single-core, memory, swap, disk latency and UDP packet loss have been checked at peak hours

If it's just 3-10 people playing with friends, starting with a 3000 map, 12-16GB of memory and as few plugins as possible is usually more stable than chasing a large map and complex gameplay from the start. If you've just deployed a Minecraft Java server, you can also compare the VPS Minecraft Java server tutorial to see the differences between the two types of game servers in memory, ports and backups.

• Facepunch: Creating a server
• Facepunch: Rust+ Server
• LinuxGSM: Rust Server
• LinuxGSM: Rust configuration and wipe
• uMod: Rust