Set Up a Rust Server: The Complete 2026 Guide

For a stable community server, a Linux system with NVMe storage is recommended, with at least a minimum amount of RAM as an absolute lower limit, installed via SteamCMD with app ID 258550. If you only play with friends, a home PC or a small VPS will do; if you want to run a community, you need dedicated or managed hosting with real DDoS protection. The next concrete step: download SteamCMD and pull the server files, or order a preconfigured server directly.

In short:

• A Rust server should run on a Linux system with an NVMe SSD, have enough RAM for the map size, and use a stable public IP.
• A VPS is enough for smaller communities; larger groups benefit from dedicated or managed hosting with DDoS protection and simple management tools.
• Storage requirements grow with the map size. Solid processor performance needs only a few fast cores, while RAM and SSD performance are what matter most.
• Installation is done via SteamCMD with app ID 258550, and a secure, separate system user is recommended.
• For stable operation, regular backups, a strong RCON password, and careful port forwarding are essential.

Table of Contents

• Hosting options: home PC, VPS, dedicated, or managed?
• How much RAM and what hardware does a Rust server need?
• How do you install a Rust server with SteamCMD?
• Configuring the start script and server.cfg correctly
• Backups, wipes, and mods: keeping the server stable in the long run
• Which ports do I need to open for a Rust server?
• E-E-A-T: When is professional hosting worth it?
• Author's perspective: the short checklist before going live
• Nexthosting as a shortcut to a ready-to-use Rust server
• Sources
• FAQ

Hosting options: home PC, VPS, dedicated, or managed?

Your choice of host determines latency, reliability, and how much time you spend on maintenance. A home PC sounds tempting because it costs nothing extra, but it has three real problems: round-the-clock power consumption, an internet connection that is rarely built for upload, and a risk called CGNAT. Many German internet providers no longer assign a public IPv4 address directly to the router and instead put several customers behind the same external address. You can check whether this applies to you by comparing the WAN IP in your router with an external service such as whatismyip.com. If the addresses do not match, no stable connection can be established from outside, no matter how well the port forwarding is configured.

VPS and dedicated servers solve this problem structurally: they sit in a data center on a real public IP, usually with better connectivity and lower latency to players than a private cable connection. Dedicated hardware also delivers raw I/O performance because it is not shared with other tenants.

For getting started, a smaller VPS such as the Nexthosting VPS Einfach is often enough. Once the community grows, it is worth moving to a more powerful model such as VPS Standard or straight to VPS Ultra. Managed hosting goes one step further: the server panel, DDoS protection, and in some cases a preinstalled Rust environment are already set up, so you do not have to write systemd units or maintain firewall rules yourself.

In short, here is when each model fits:

• Home PC: only for testing or for a small circle of friends without a CGNAT problem.
• VPS: a good middle ground between cost and control, ideal for 10 to 50 players.
• Dedicated server: makes sense for larger communities with high I/O load and many simultaneous players.
• Managed hosting: the right choice if you want to save time and do not want to deal with server administration every day.

How much RAM and what hardware does a Rust server need?

Facepunch specifies a minimum amount of RAM as the absolute minimum for a Rust dedicated server, but that is a lower limit, not a target value for production use. If you want to run an active community with several dozen players, you should plan for plenty of RAM for a medium to large community. The reason lies in the map size: a larger map seed produces significantly more loaded objects, terrain data, and procedural content in memory, and this size drives RAM requirements more than the player count alone.

Important: NVMe SSDs are practically mandatory for Rust, not optional. The server continuously writes save data, loads chunks, and processes entity data, which on classic HDDs leads to noticeable I/O delays and shows up for players as rubberbanding and lag spikes. Even SATA SSDs reach their limits on larger maps, because the parallel access load is higher than in most desktop workloads.

For the CPU, single-thread performance matters most, because the Rust server engine cannot spread calculations across many cores at will. A processor with a high clock speed and a few fast cores almost always beats a server Xeon with many slow cores.

A few practical points that belong on every checklist:

• Keep an eye on swap usage: as soon as the server starts swapping, stutters and timeouts are guaranteed. It is a warning sign of too little RAM.
• Monitor disk I/O regularly, for example with iostat or iotop on Linux, to spot bottlenecks early.
• Plan bandwidth realistically: for 100 players, you should calculate with several Mbit/s of sustained throughput, not just peak values.
• For very large maps (for example very large worlds with a high map size), choose a generous RAM buffer, since large seeds push requirements far beyond the Facepunch minimum specification.

A p95 value for storage access times is a good metric on heavily loaded servers to tell whether the disk is becoming a bottleneck, long before players notice it as lag.

How do you install a Rust server with SteamCMD?

Installation runs through SteamCMD, Valve's official command-line tool for managing Steam content without a graphical interface. Rust itself has the Steam app ID 258550, and you need exactly this ID for the installation command.

Here is the step-by-step process:

1. Download SteamCMD. On Windows, extract the archive into a folder such as C:\rustserver\steamcmd. On Linux, install the package via your package manager or download it directly as an archive and extract it into a dedicated directory, for example /home/rustserver/steamcmd.
2. Create a separate system user (Linux). Create a dedicated, unprivileged user for the server process, for example with adduser rustserver. This prevents a compromised server process from gaining access to the entire system.
3. Set the installation directory. Choose a clear path, such as /home/rustserver/rust, and make sure the new user has full write permissions on it.
4. Install the Rust server files. The key command is: steamcmd +login anonymous +force_install_dir /home/rustserver/rust +app_update 258550 validate +quit This command logs in anonymously, sets the target directory, downloads the current Rust server version, and validates the files in the same step.
5. Check file permissions. Make sure all files belong to the server user, not root, otherwise you will run into startup problems later.

Pro tip: Run validate again after every major Rust update, even if the server seems to start normally. Facepunch changes build structures between patches more often than you would think, and damaged or missing files otherwise only show up with the first player complaint ticket.

On Windows, the identical command runs via steamcmd.exe, either interactively in the console or as a batch file with the same parameters. It is important to put the installation path in quotation marks if it contains spaces, otherwise the command breaks off midway.

A note on branches: Rust occasionally offers beta or staging branches for testing new features. For a production server, you generally stay on the default branch, unless you deliberately run a test server for mod compatibility before a major update.

Configuring the start script and server.cfg correctly

The server is started from a command line with a series of flags that define the server's network settings, identity, and behavior. The Facepunch community generally recommends the parameters -batchmode -nographics so that the server runs without a graphical interface and without unnecessary rendering load.

The most important flags at a glance:

• +server.ip 0.0.0.0 binds the server to all available network interfaces.
• +server.port the default game port sets the game port, usually UDP.
• +server.identity "myserver" defines a unique folder name for save data and configuration.
• +server.worldsize 4000 determines the map size, which is directly responsible for RAM requirements.
• +server.maxplayers 100 sets the maximum number of players.
• +rcon.port the default RCON port and +rcon.password "aSecurePassword" enable the remote console.

A simple Linux start script (start.sh) looks like this:

#!/bin/bash
cd /home/rustserver/rust
./RustDedicated -batchmode -nographics \
  +server.ip 0.0.0.0 +server.port the default game port \
  +server.identity "myserver" +server.worldsize 4000 \
  +server.maxplayers 100 +rcon.port the default RCON port \
  +rcon.password "aSecurePassword" +rcon.web 1

On Windows, this corresponds to a .bat file with the same parameters, invoked via RustDedicated.exe instead of ./RustDedicated.

The question of what belongs in server.cfg and what belongs on the command line confuses many beginners. The rule: anything that rarely changes and must be fixed at startup (IP, port, identity, world size) belongs in the startup flags. Anything you want to adjust at runtime via RCON (decay rates, PvE settings, message texts) belongs in server.cfg in the identity folder.

When hardening RCON, what matters most is a long, random password, never a default value. +rcon.web 1 enables the browser-based RCON interface, which you should only use over an encrypted connection and ideally with IP restrictions.

For production use, a systemd service is a far more robust solution than a simple terminal window or a screen session. A systemd service with a restart policy catches crashes automatically, so you do not have to get up at night. An example unit sets Restart=on-failure, defines the appropriate system user, and sets environment variables such as LD_LIBRARY_PATH to avoid typical linker errors on Debian-based systems. You should also set up log rotation, otherwise the log files grow uncomfortably large after a few weeks.

Backups, wipes, and mods: keeping the server stable in the long run

A Rust server that is up and running is far from done needing attention. Before every major patch and every planned wipe, a backup routine is a must, and it should secure three things: the map and save files in the identity folder, the player data, and the server.cfg including the Oxide or uMod configuration. A daily automated backup via cron job is enough for most communities; before wipes, we also recommend a manual snapshot right before the restart.

uMod (Umod) is the established platform for Rust plugins and can be added to an existing installation later. After installation, plugins end up in the oxide/plugins folder, and many communities use whitelist plugins, for example, to control access before the official release. Important: after every Rust update, you should check whether uMod itself needs to be updated, because Facepunch patches occasionally change internal interfaces that plugins rely on.

A few points for ongoing maintenance:

• Backup intervals: daily and automated, plus before every wipe and major update.
• Check uMod for compatibility after every Rust patch before you reopen access to players.
• Review logs regularly to catch crashes, plugin errors, or unusual RCON access early.
• Configure automatic restarts via systemd, not via manual scripts that can be missed when a server crashes.

Pro tip: Plan fixed wipe cycles, for example every two to four weeks, and announce them in advance. An unannounced wipe is one of the most common reasons communities suddenly lose players, because bases they built disappear without warning.

Which ports do I need to open for a Rust server?

Connection problems are almost always a matter of ports, rarely a bug in the server itself. In practice, Rust needs three ports: the game port 28015 as UDP, the RCON and query port 28016 as TCP, and often an additional query port 28017 as UDP. Set all three explicitly in the startup flags instead of relying on implicit defaults. This prevents mix-ups between the query and RCON ports, which happen surprisingly often in practice.

The most common mistake is not in the Windows or Linux firewall itself, but one layer above: many admins only check the operating system firewall and overlook the firewall of the provider or cloud platform, which can block ports as well. A control panel with built-in firewall management noticeably reduces exactly this source of error, because port rules are managed centrally and visibly there.

Here is how to diagnose the problem:

1. First check whether the server is listening on the ports locally (netstat or ss on Linux).
2. Check the OS firewall (ufw, iptables, or Windows Defender Firewall) for matching rules.
3. Check the cloud or provider firewall in the customer portal. This is the step that is forgotten most often.
4. Test reachability from the outside with a port checker or a second device outside your own network.
5. For home hosting: check for CGNAT by comparing the router's WAN IP with an external service. If the addresses do not match, only a VPS, a tunnel service, or a static IP from your internet provider will help.

E-E-A-T: When is professional hosting worth it?

If you want to spare yourself port forwarding, systemd configuration, and I/O tuning, managed offerings such as Nexthosting provide ready-made firewall management, NVMe storage, and a control panel for Rust servers. This makes sense from the point where the community grows and downtime means real trouble.

Author's perspective: the short checklist before going live

Three things count before the first public launch: working backups, a hardened RCON password, and active monitoring. For stable community operation, I would never plan for less than 16 GB of RAM, regardless of what the minimum specification says.

— Erik

Nexthosting as a shortcut to a ready-to-use Rust server

If you do not want to handle the installation via SteamCMD, port forwarding across multiple firewall layers, and systemd hardening yourself, a ready-made Rust server at Nexthosting spares you exactly these sources of error. Instead of debugging cloud firewall rules or running into CGNAT problems with your own internet provider, the server runs directly on NVMe storage with prepared DDoS protection and a control panel that manages port rules, restarts, and backups in one place. This does not replace creativity in server configuration, but it does replace the organizational groundwork that otherwise costs hours before the first player can even join. If you want to get started right away, you will find the matching configuration on the Rust server page at Nexthosting and can start the order from there, without creating a system user or writing a systemd unit yourself.

Sources

• Creating a server - Rust Wiki
• Shattered
• how-to-set-up-a-rust-game-server - modcommunity (GitHub)
• uMod - Whitelist Plugin

FAQ

How do I connect to my Rust server?

Open the Steam console in the game with F1 and enter client.connect YOUR-IP:28015. Alternatively, you can add the server manually in the server list using its public IP address and the game port.

How do I set up a Rust server in general?

You install the server files via SteamCMD using the app ID 258550, configure startup flags for IP, port, and RCON, open the required ports in the firewall and the provider panel, and ideally start the process as a systemd service.

Which Rust server is suitable for beginners?

For getting started, a small VPS with 12 to 16 GB of RAM and NVMe storage is enough, for example in the range of an entry-level VPS at Nexthosting, combined with a smaller map size to keep resource requirements low.

Are there free Rust servers?

There is practically no permanently free, publicly reachable Rust server, because running a server costs electricity, bandwidth, and hardware. A home PC comes closest, but it often fails because of CGNAT or insufficient upload bandwidth.

How do I fix connection errors on my Rust server?

First check whether the server is listening on the ports locally, then the operating system firewall, and finally the provider or cloud firewall, which is the one most often overlooked. If the server remains unreachable, test for CGNAT by comparing your router's WAN IP with an external service.