Set Up a Rust Dedicated Server on Windows: Save and Reload

To set up a Rust dedicated server on Windows, install App ID 258550 with SteamCMD, launch a named server identity, then save and reload that identity before opening network access. You need to distinguish a successful download from a working server and a successful player connection. This guide gives you one Windows installation path and those separate checks. We tested a fresh dedicated installation, startup, save and reload on Windows 11; no Rust client was available for a player-entry test. The client steps below follow Facepunch’s documentation and remain a check you must complete. This is for PC Rust.

Prepare your Windows Rust dedicated server workspace#

Give the dedicated process its own installation folder and enough unused resources to run alongside everything else on the computer. The server is not a mode inside your installed Rust client. Closing the client does not necessarily stop the server, and updating one package does not establish that the other is current.

Facepunch’s installation guidance lists 12 GB of free RAM and 15 GB of disk space, with SSD or NVMe storage preferred. Read “free” literally: memory already occupied by Windows, browsers and the game client is not available to the dedicated process. These figures are starting guidance, not evidence that a particular map, plugin stack or player count will fit.

Use a simple directory layout you can recognize later:

These paths are examples. If you choose another drive, change every corresponding path before running commands. Avoid a temporary download folder that you regularly empty. Start with a new installation directory; the instructions should not operate on a world your friends already use.

Keep this first world disposable. The small map used below exercises startup and persistence; it is not a recommendation for a group’s long-term map. If you still need to choose between a spare PC, Linux or a managed service, first choose your server setup route.

Install the public server through SteamCMD#

Install the vanilla dedicated package with an explicit destination before adding scripts or plugins. Facepunch documents anonymous installation, so a second paid player account is not required for this download. Use the normal public package while testing with the normal client; do not introduce an alternate branch during the first installation.

1. Download and extract Valve's tool

   Create the SteamCMD folder above. Download the Windows SteamCMD archive linked from Facepunch’s SteamCMD section, then extract it there. Confirm that the executable is inside that folder rather than still inside the ZIP archive. Use the linked Valve download, not a repackaged server manager.

2. Install into the dedicated folder

   Open PowerShell and run the command below. The installation destination comes before login. Leave the console open until SteamCMD finishes its download and verification; the folder appearing on disk is not the completion signal.

& 'C:\RustTools\SteamCMD\steamcmd.exe' `
  +force_install_dir 'C:\RustServers\WindowsTest' `
  +login anonymous `
  +app_update 258550 validate `
  +quit

The successful installation in our test printed:

Success! App '258550' fully installed.

Check that the destination now contains the dedicated executable:

Test-Path 'C:\RustServers\WindowsTest\RustDedicated.exe'

That check should return True. If installation failed, preserve SteamCMD’s actual error and resolve it before writing a launch script. Do not interpret a partial directory as a usable installation.

Skip the historical quick-install ZIP on the wiki: Facepunch itself warns that its old automatic-update behavior is obsolete. Also keep this command out of a continuous restart loop. Repeatedly updating and relaunching hides whether a failure came from downloading files, starting the process or loading the world. This first-install procedure is not a backup plan for an existing modded server.

Launch one local-only world with a stable identity#

Start a single vanilla process bound to the local computer, with an explicit identity and log file. That gives you a small, understandable test before router or firewall changes enter the picture. The loopback address limits this example to the Windows host itself; another PC cannot use it to join.

Run the following from PowerShell after checking that the example ports are not already assigned to another service. Keep the command and its working directory together in your notes. PowerShell’s continuation backticks must be the final character on their lines.

Set-Location 'C:\RustServers\WindowsTest'
& '.\RustDedicated.exe' -batchmode -nographics `
  +server.identity 'b02-windows-proof' `
  +server.ip 127.0.0.1 `
  +server.port 29181 `
  +server.queryport 29182 `
  +server.maxplayers 4 `
  +server.worldsize 1000 `
  +server.seed 1234 `
  +server.hostname 'Windows local test' `
  +rcon.ip 127.0.0.1 `
  +rcon.port 29183 `
  +app.listenip 127.0.0.1 `
  +app.port 29184 `
  -logfile 'C:\RustServers\WindowsTest\first-start.log'

The game port here is 29181, not the frequently copied 28015. The query port is separate. No RCON password is supplied or remote administration opened by this example. Our automated test used an additional temporary credential on loopback to collect console responses; you can use the server console directly.

The 1000 map and 4 player ceiling are disposable test settings. Neither is a measured capacity recommendation. Do not expand the test into a live community simply because the process starts with those values.

The identity selects the server’s data directory. Its name is not a password or an admission rule. For a verified two-instance identity-to-save check, see our Rust server identity guide. A configuration file for this identity, if you create one later, belongs here relative to the installation:

server/b02-windows-proof/cfg/server.cfg

For now, avoid duplicating these settings in another file. Once the baseline works, the Rust settings guide helps you separate identity, launch arguments and persistent configuration. If a value differs from what you expect, inspect the running value and every configuration source before editing several places at once.

Read the log before diagnosing a connection#

Wait for readiness in the log from this launch before trying to join. First-world generation does work that a later restart may reuse, so a quiet interval or a burst of map messages does not by itself establish a hang. Equally, a running executable does not prove initialization finished.

Facepunch documents this completion marker:

Server startup complete

Use the log’s timestamp to make sure you are reading the current attempt. Before a later launch, change only the log filename so the old marker cannot fool you. Keep the installation, identity, seed and size unchanged for the reload test.

In the server console, query these values individually:

version
server.identity
server.port
server.queryport
status

Record the responses with the installation path. Our fresh installation used dedicated build 25353106 on Windows 11 Pro build 26200; its runtime reported protocol 2633.288.1. That is a dated verification record, not a version you should pin forever. Install the current compatible public build when you follow the guide.

If the server exits or prints an error before readiness, retain the first useful error and its context. Use the dedicated-server troubleshooting sequence to identify the failed stage. Opening ports cannot repair a process that never finished loading.

Save, stop and reload the same world#

Prove that the process can reload its existing save before giving the world to your group. A generated map file and a saved world are different evidence: terrain generation alone does not prove that the simulation state was written and read back.

1. Request a save and inspect completion

   Enter the save command below in the server console. Wait for the log’s saving-complete message, then inspect the identity directory. Record the save filename and modification time rather than assuming that the newest file anywhere in the installation belongs to this world.

2. Shut down the process cleanly

   Enter the quit command after saving completes. Wait for the server process to exit. Do not launch a second instance while the first is still shutting down, and do not use Task Manager’s end-process action as the normal stop procedure.

3. Repeat the launch with the same data selection

   Run the same launch command, changing the log filename to second-start.log. Confirm readiness again and inspect the new log for loading entities from the existing save. Re-query the identity and ports so you know the second launch selected the same server.

server.save

After the log reports completion:

quit

Our test performed both launches with zero players. The first wrote a save under the named identity; the second loaded entities from that save, reached readiness and shut down cleanly. This verifies dedicated-process persistence. It does not demonstrate that a player’s building, inventory or permissions survived a real session.

Once real progress matters, use the server-data management checklist to identify the complete recovery set. A successful same-folder restart is useful evidence, but it is not a restored backup on another machine.

Complete the PC client acceptance check#

Use a licensed PC Rust client on this same Windows computer to verify actual entry. This is the part we could not test in our environment. Facepunch documents opening the client’s F1 console and connecting to localhost; use the game port from this guide’s launch command:

connect localhost:29181

Enter that in the game client’s console, not PowerShell or the server console. The connection must finish and place you in the intended world before you count it as a pass. A connection attempt in a log is weaker evidence than reaching the playable world.

Check the visible server identity against your notes and create a recognizable disposable object. Leave normally, repeat the clean save-and-stop procedure, then reconnect after the same identity finishes loading. Confirm the object is still there. Record this separately from the zero-player save test; it closes a different gap.

If you need administrator access for your testing, use your actual account and the administration and access guide. Do not paste a placeholder account ID into an owner command or assume that being on the hosting PC automatically gives your client the intended role. Player entry and administrator authorization are separate checks.

If localhost fails, investigate the client/server versions, actual game port and server log before changing the router. The current example deliberately listens on loopback. It is not ready for another computer on your LAN, and forwarding a public port does not change that. Keep firewall and external-access work as the next stage after this local test passes.

Decide whether this Windows host is ready for friends#

Invite the group only when you have evidence for the path they will actually use. A Windows install can pass every dedicated-process check here while the host remains unsuitable for unattended evenings or unreachable from outside your home.

Keep a short acceptance record:

Do not treat the last three rows as automatic consequences of the first three. For the next network stage, return to the complete hosting route and connection checks. Keep administrative services restricted, and test privacy separately if your goal is a friends-only world.

Self-hosting remains reasonable when you can maintain the PC, network and recoverable data. For a managed alternative, we recommend Game Hosting’s Rust PC hosting with an integrated panel, free backups and DDoS protection. Confirm the import requirements and verify your progress on the destination before moving the group.

Keep the successful launch command, logs and identity notes together. They are the baseline against which you can judge later changes. Add networking, regular backups and modifications one at a time, repeating the relevant acceptance check after each change.