How to Host a Rust Server: Choose and Verify Your Setup

To host a Rust server, run its dedicated server process on a suitable Windows or Linux machine, configure access, then prove that a player can join and the world survives a restart. If you’re figuring out how to host a Rust server for friends, start with those outcomes. A downloaded folder or a running process is only part of the job. This guide helps you choose a documented installation route and check the result before everyone starts building. It covers PC Rust; Console Edition uses a separate ecosystem. The routes below were checked against current documentation, not a hands-on game session.

Choose how to host a Rust server for your group#

Choose the machine you will operate first, then follow the installation instructions for its operating system. You do not need a different dedicated package just because the computer sits in a spare room instead of a datacenter. What changes is who controls the hardware, the network, and the startup process.

An existing container or hosting panel adds another layer. Before choosing it, identify its maintained installation instructions, persistent storage, port allocations, and supported update procedure. This guide does not certify a particular image or panel template. For a first setup without those dependencies, the documented Windows or Linux route is easier to trace when something fails.

If you want to delegate infrastructure, compare the hosting requirements that matter to your group. Our Rust PC hosting page provides the product and availability route, but availability was closed and registrations went to a waitlist when checked for this guide. Do not schedule an immediate move on the assumption that a listed plan can be provisioned today.

Check the machine and incoming connection first#

Check available resources while the machine is doing its normal work. Installed memory is not the same as memory left for the server. On a gaming PC, include the Rust client, voice chat, and whatever else you normally leave open. A spare machine avoids that combined workload, but age alone does not tell you whether its CPU or storage is suitable.

Facepunch’s setup requirements currently list 12 GB of free RAM and 15 GB of disk space, with SSD or NVMe preferred. These are a starting point, not a promise for every map or population. Leave space beyond the installation for saves, logs, and backup copies. Plan to observe the actual workload before increasing the player group or adding plugins.

Next, identify who controls incoming traffic. At home, that may involve both the computer firewall and your router. On a rented machine, a provider firewall can sit in front of the operating system firewall. Write down which layers exist so a failed connection does not turn into random setting changes across three dashboards.

If your ISP uses an upstream NAT arrangement you cannot configure, ask about a usable incoming connection before relying on home hosting for remote friends. A router rule cannot configure equipment controlled by the ISP. You can still test on your local network while resolving that question. Keep the first world disposable until the intended connection path works.

Install the dedicated package for your operating system#

Use SteamCMD to obtain the dedicated server, following the current official installation instructions. Facepunch identifies the dedicated package as App ID 258550 and documents anonymous installation. The server download does not require a second paid player account; the client used to join still needs Rust.

On Windows, follow the SteamCMD and batch-file sections. On Linux, follow the Linux installation section, including making the supplied startup script executable and editing its configuration. Choose a permanent installation directory before downloading. Keep the server files together so the launch process and the person making backups can find the same installation later.

Avoid the old quick-install ZIP even though it remains on the wiki. Facepunch explicitly warns that its historical automation claims are obsolete. A shortcut that hides installation and startup inside an old script makes it harder to distinguish an update failure from a server failure.

Before launching, record three things: the installation directory, the startup file you will actually run, and the stable release branch you intend to use. Confirm the dedicated files downloaded successfully and that the launch file points at that installation. Do not accidentally build a test around an alternate branch while your friends use the regular client.

Keep the first launch vanilla. A plugin framework introduces another update dependency and another source of errors before you have established a working baseline. You can evaluate modifications after the same unmodified world accepts a client and restarts correctly.

Start one identifiable world and read its log#

Give the first world a stable identity and keep its launch settings unchanged through the acceptance test. Identity is the server’s data selection, not just the name players see in a browser. Record it alongside the map settings and installation directory; those notes become useful immediately if a restart appears to produce a fresh world.

For an example identity named friends-test, the configuration location relative to the installation is:

server/friends-test/cfg/server.cfg

Use the configuration and launch instructions for the route you selected. If settings appear inconsistent, inspect both sources before editing more values. Do not assume the visible startup file is the only place controlling the server, particularly when a panel supplies its own overrides.

Start the process and follow the log until initialization completes. Facepunch documents this readiness message:

Server startup complete

Treat it as permission to begin connection tests, not proof that every part of hosting works. If startup fails, retain the error and the surrounding log lines, identify which installation stage failed, and correct that cause before adding automatic restart loops. Repeating a broken launch can bury the useful error in noise.

Keep one server instance running for this test. Two launch windows or an old background service make it surprisingly easy to connect to one process while changing another process’s files. A single named installation, one launch method, and one log keep the evidence understandable.

Prove the connection your friends will use#

Test from the intended player path, because a successful connection on the server machine does not prove that a remote friend can join. Use the actual game port from your running configuration. The addresses below are examples, not values to paste into your router.

1. Connect on the same machine when applicable

   Open PC Rust, press F1, and use the local command below if the server uses game port 28015. A successful join confirms the client can reach that local process. Skip this step on a headless remote machine.

connect localhost:28015

For a second computer on your home network, use the server computer’s LAN address instead of localhost. Localhost always means the computer entering the command. If the server’s LAN address were 192.168.1.50, the example would be:

connect 192.168.1.50:28015

Then have one friend outside the home network test the public game endpoint after you configure the required incoming access. Use Facepunch’s connection documentation for the address distinction. Record which of these tests passes; that narrows a failure to a useful part of the route.

Do not open every port because a generic checklist says to. Read the actual assignments, and keep remote administration restricted with a unique secret. A generic TCP port-check result does not validate UDP gameplay. Likewise, appearing in a list and accepting direct connections are separate checks. Diagnose the failed path before changing otherwise working settings.

Restart and confirm the same world returns#

Verify persistence with something you can recognize inside the world, not only a timestamp on disk. Join the disposable test world and place a small building somewhere you can find again. Note its location and appearance. Keep the world identity and map settings recorded before stopping anything.

1. Save and stop through server administration

   Use the documented graceful shutdown for your route. Facepunch documents the command below from an authorized administrator’s client console as saving and closing the server. It requires server administrator permissions; an ordinary player cannot use it to shut down the world.

sv quit

Bare quit in the client console closes your game instead. See the distinction in Facepunch’s useful commands. On a managed service, confirm what its stop control does. If you have not established an authorized, graceful shutdown route, resolve that before treating the persistence check as complete.

After the process has stopped, inspect the active identity’s save files. Relaunch through the same startup method without changing the identity or map configuration, reconnect, and find the test building. If it is missing, stop the rollout and compare the installation, identity, settings, and logs from both launches. Do not delete files to make the symptom disappear.

Passing this test establishes that this world survived this restart. It does not prove you have a backup. Facepunch’s server file guide distinguishes terrain, saved entities, player databases, and other data. Copying only a map file is not enough to preserve the group’s progress. Build recovery around the actual data inventory once this first persistence check passes.

Set admission rules before sharing the address#

Decide who may join before distributing the endpoint widely. Hosting for friends does not automatically make a server private. A friendly server name, an unpublished address, or a remote administration password does not establish player admission control.

Use a documented policy appropriate to your setup. Facepunch provides a hidden, whitelisted server procedure; follow the complete method and its explanation instead of copying a single queue setting from a discussion. A hosting panel may implement access differently, so confirm the mechanism it actually supports.

Keep that admission test separate from the network test. A rejected player might demonstrate that access control works, while a timeout may mean the connection never reached the server. Record the result you expected and the result you observed. Your acceptance record should show both that invited friends can play and that the policy does what you intended.

Hand over a server someone can maintain#

Finish the setup with a short operating record another administrator can use. Include the installation location, identity, launch method, log location, game endpoint, update responsibility, and backup location. Keep passwords in appropriate private storage rather than putting them in the shared game invitation.

Assign someone to updates and someone who can cover when that person is unavailable. Rust’s behavior changes over time: the September Breach and Clear update improved saving and loading for several events across restarts. That is a reason to read current release notes and repeat acceptance checks after relevant changes, rather than rely indefinitely on an old startup recipe.

Set up supervised startup only after the manual route works. Verify the intended process returns after an operating system reboot, and that logging still leads you to the active installation. Automatic relaunch is useful, but it cannot repair a wrong path or tell you whether your backup contains the expected world.

Before the disposable test becomes the group’s real home, keep a consistent backup and demonstrate recovery in an isolated destination. Avoid overwriting the only working world for that demonstration. The final handoff is concrete: the chosen machine runs the intended process, a friend joins through the right network, the same world returns, admission rules hold, and a named person knows how to maintain it.