How to Install Oxide on a Rust Server and Verify It

To install Oxide on a Rust server, match the official Oxide release to the server’s exact Rust protocol, stop the process, save a restorable baseline, install the operating-system-specific archive into the dedicated-server files, and restart. Then check the startup log and run oxide.version from the server console or RCON. That verifies the framework loaded; it does not prove a particular plugin works. This guide covers Rust PC dedicated servers and uses a Windows acceptance test. Keep the protocol check current because Rust updates can invalidate an otherwise correct Oxide build.

Match the Oxide release to your Rust protocol#

Check the Rust protocol on the server that will receive Oxide before downloading anything. On the server console or through RCON, run the documented version command and record the protocol exactly. Then open the official Oxide.Rust release notes and confirm that the newest release explicitly supports that protocol. A newer release number alone is not a compatibility guarantee.

As checked on October 14, 2026, the official Oxide release 2.0.7830 listed support for Rust protocol 2634.289.1, the October 13 hotfix protocol. An isolated Windows test of that Rust build reached startup complete with Oxide loaded. Treat those numbers as a dated example: check the live release notes and your own server output whenever you install or update. The release page is the authority for the supported Rust build; the uMod latest-version endpoint is a useful cross-check.

Check	What to record	If it does not match
Rust server version output	Full protocol and build details	Update or identify the actual server installation before choosing Oxide
Official Oxide release notes	Release number and supported Rust protocol	Wait for a matching release; do not install an older build as a guess
Download asset	Windows or Linux archive for the host OS	Download the matching asset from the official release page

The protocol match only establishes that the framework release targets that Rust build. It does not certify every plugin, extension, hosting panel, or server configuration. Keep those as separate checks. Facepunch’s dedicated-server guide documents the Rust server installation and SteamCMD update route; Oxide publishes its own installation procedure.

Stop the process and capture a recoverable baseline#

Stop the Rust dedicated-server process cleanly before changing files. Confirm the process has exited and that no panel task, scheduled update, or watchdog will restart it during the copy. A live process may continue writing files or load an inconsistent mixture of the old and new framework.

Make a recovery copy that includes the server installation and the data you need to preserve. At minimum, identify the world and player files, server configuration, framework files, and any plugin data that already exists. Record the server identity and the Rust protocol beside the copy so you can tell which build it belongs to. A backup of only the executable is not a world recovery point, and a folder copy is not verified until you can locate and restore it.

1. Record the active installation

   Write down the server root, identity, Rust protocol, and any separate paths used for saves or plugin data. Confirm which process and panel entry use those paths before copying files.

2. Stop and preserve the files

   Use the normal shutdown route, wait for the process to exit, then copy the required server files and persistent data to a separate location. Keep the copy untouched while installing Oxide.

3. Check the recovery copy

   Compare file counts and sizes or generate a manifest, then confirm the copy contains the expected world, configuration, and other persistent data. For important worlds, rehearse restoration on an isolated destination before relying on it.

Download the official archive for the server operating system#

Download the archive from the matching Oxide.Rust release on the official GitHub releases page. Choose Oxide.Rust.zip for a Windows server or Oxide.Rust-linux.zip for a Linux server. Verify the asset belongs to the release you matched to the Rust protocol. Do not use a third-party mirror or an archive left over from an earlier game build.

The release assets contain framework files, not a universal installer that selects your Rust version automatically. Save the archive outside the live server root, extract it to a temporary directory, and inspect the folder structure before copying. The purpose of the temporary extraction is to make the destination obvious: you should see the extracted contents that Oxide’s official guide says to place in the server’s RustDedicated_Data directory. Avoid creating an accidental extra nesting level by copying the outer folder instead of its contents.

Linux has a separate archive and file environment. This article’s load and rollback acceptance test was performed on Windows only; the release provides a Linux package, but the test does not establish that a particular Linux distribution, panel, or file-permission setup works. Follow the current official Linux instructions and check ownership and permissions for the account that runs the server. If the matching release does not provide a package for your operating system, stop and wait for documented support rather than substituting another build.

The official Oxide release listing and uMod latest Rust snapshot are the sources to recheck for the current version. Record the release number and asset name in your change notes so a later Rust update does not leave you guessing which files were installed.

Place the files in the dedicated-server installation#

With the process stopped, copy the extracted archive contents into the Rust dedicated-server root, following Oxide’s current guide. Its target is the RustDedicated_Data directory inside the server installation. Preserve the archive’s relative paths and merge the files into the matching directories; do not place the archive itself there or rename its contents to make them fit.

The server root is not the same as the persistent world folder, commonly organized below server/<identity>. Oxide framework files belong with the dedicated-server installation; they are not world-save files. Keep your baseline and persistent data separate from this file replacement so rollback does not accidentally delete the world.

1. Confirm the server is still stopped

   Check the process list or panel status and ensure no update task is running. The server must remain stopped while files are replaced.

2. Copy the extracted contents

   Follow the official Oxide guide and merge the archive contents into the server installation’s RustDedicated_Data path, preserving the directories inside the archive.

3. Review the destination before starting

   Check that the expected Oxide files are under the existing Rust server root and that you did not create a second nested RustDedicated_Data folder. Keep the original archive and recovery copy available.

If the panel hides the actual server root or only permits a limited upload area, do not guess at a path or upload into the world-save directory. Ask the host where framework files belong and whether the panel permits Oxide for your Rust plan. Game Hosting’s documented Rust panel lists vanilla and Carbon, not Oxide, so its general backup or restart features should not be read as Oxide compatibility.

Start Rust and verify that Oxide loaded#

Start the server normally and watch the complete startup output. Oxide’s guide identifies framework load messages as an early check, but a successful Rust boot by itself does not show that Oxide is active. Once startup completes, run oxide.version in the server console or RCON and confirm the reply names the expected Oxide.Rust release.

Evidence	What it confirms	What it does not confirm
Rust reports startup complete	The dedicated server reached its normal startup milestone	That Oxide or any plugin loaded
Oxide load messages appear	The framework participated in startup	That a selected plugin behaves correctly
oxide.version reports the expected version	The server-side Oxide command is available and identifies a release	Player access, plugin compatibility, permissions, or gameplay behavior

In the isolated Windows acceptance test on October 14, 2026, Rust protocol 2634.289.1 reached startup complete after installing Oxide 2.0.7830; server-session metadata reported modded: true and mod_framework: oxide, and RCON returned Oxide.Rust Version: 2.0.7830. That is evidence for the tested Windows build and release, not a guarantee for another server. The test did not install plugins, connect a client, or test Linux.

If the console does not recognize oxide.version, stop before installing plugins. Check the startup log for the first loader error, confirm that you installed the archive for the right OS and server root, and verify the archive matches the current Rust protocol. A normal vanilla startup with no Oxide markers usually means the files were not loaded or were replaced. Do not treat an arbitrary successful boot as proof.

Recheck Oxide after every Rust update#

Treat a Rust server update as a possible framework change. SteamCMD validates and replaces server files; Oxide modifies the server installation, so an update may restore vanilla files or make the existing Oxide release incompatible with the new protocol. This is expected maintenance, not proof that your world is damaged.

After an update, start with the server stopped long enough to inspect the new Rust protocol. Compare it with the official Oxide release notes, then check the startup log and run oxide.version. If the framework disappeared, install the matching official archive again only after preserving the updated server and persistent data. If no release supports the new protocol yet, keep the server on the documented compatible build or run vanilla according to your needs; do not force an older loader onto a newer Rust build.

Use this short update record each time:

Field	Before the Rust update	After the update
Rust protocol	Existing server output	New server output
Oxide release	Installed version	Release notes matching the new protocol
Loader check	oxide.version response	Startup log and oxide.version response
Recovery point	Existing baseline timestamp	New copy before framework replacement

uMod’s plugin installation documentation describes oxide.version as a version check. Keep in mind that updating the loader and updating a plugin are different changes: record and verify each separately. For planning a broader plugin stack, see how to register and maintain the framework alongside plugin dependencies.

Roll back to vanilla without deleting your world#

If Oxide fails to load or you need to return to vanilla, stop the process and restore the exact vanilla server files from your baseline, or reinstall the same Rust build through its documented SteamCMD route. Do not delete the entire server directory as a shortcut. Confirm the restore includes all files that the Oxide archive changed, then compare key file hashes or a file manifest against the saved baseline.

The isolated Windows test stopped Oxide cleanly, restored the exact 2,001-file vanilla baseline, and confirmed that RustDedicated.exe and Assembly-CSharp.dll matched their original SHA-256 hashes. Oxide-specific files were absent afterward; Rust started with modded: false, and RCON returned the same protocol and build. The world-data folder was kept separate from the file rollback. This demonstrates a vanilla rollback for that disposable test installation, not a production restore for every host.

1. Stop Rust and preserve the failed state

   Capture the relevant log and note the Rust and Oxide versions. Keep a copy of the current files for diagnosis before restoring anything.

2. Restore the matching vanilla server files

   Use the known-good baseline for the same Rust build or reinstall that build using the documented server update process. Do not overwrite or delete the separate world and plugin-data recovery copies.

3. Confirm vanilla startup

   Start the server and check the Rust protocol, normal startup completion, and absence of Oxide framework indicators. If you have a manifest or hashes, compare the restored files with the baseline.

Keep the Oxide test log, release number, Rust build and rollback manifest with your server notes. If you later choose to migrate from Carbon back to Oxide, that is a different operation involving plugin and data compatibility; follow the separate Carbon-to-Oxide recovery guide rather than treating a clean vanilla install as a data migration.

Quick answers

How do I install Oxide on a Rust server?

Match an official Oxide release to your Rust protocol, stop the server, preserve a recovery copy, install the matching operating-system archive into the server files, and restart it.

How do I know Oxide loaded on my Rust server?

Check the startup log for Oxide loading and run oxide.version in the server console or RCON; the response should identify the installed Oxide.Rust version.

Does Oxide work with every Rust update?

No. Confirm the Oxide release notes support the exact Rust protocol before installing, then check again after each game update.

Can I install Oxide while my Rust server is running?

Stop the dedicated-server process first. Replacing framework files while the process is live can leave a mixed installation and an unclear result.

Will a Rust update remove Oxide?

A SteamCMD update can replace modified server files with vanilla files. After updating, inspect the startup output and reinstall only an Oxide release that matches the new Rust protocol.