Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Playing with friends? Godlike.Host runs hosted Rust servers from 10 data-center locations, with free DDoS protection.
To wipe a Rust server, stop it, back up its current world data, remove the map and save data (or change the server seed/world size), and start it again. That creates a map wipe while retaining player blueprints. A blueprint wipe also removes learned blueprints, and a forced wipe is the monthly map reset required by Facepunch. The exact files and panel labels vary by host, so never delete the entire server directory without identifying what stores the world, saves, blueprints, configuration, and logs.
This guide explains the three wipe types, the reported 2026 forced-wipe date, file-based and control-panel procedures, automation limits, validation checks, and recovery steps when an old map or unexpected blueprint state returns.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
Rust Key Cards, Rust Red Key Card, Cobalt Restricted Access Cards, Rust Gift For Gamers, Blue Key... | $25.00 | Buy on Amazon |
| 2 |
|
Rust Video Game Notebook | $15.00 | Buy on Amazon |
| 3 |
|
Rust Game Props Large Furnace (S) | $14.99 | Buy on Amazon |
Rust wipe types: choose the reset before touching files
“Wipe” does not always mean the same reset. Decide what players should lose first; otherwise you can remove blueprints accidentally or leave the old world in place.
| Wipe type | Why it happens | What resets | What normally remains | Who controls it |
|---|---|---|---|---|
| Forced wipe | A Facepunch update changes map generation and requires every server to generate a fresh map. | The map, buildings, inventories, and map seed. | Blueprint status depends on whether Facepunch separately announces a blueprint wipe. | Facepunch sets the global update; each server owner restarts and generates the new world. |
| Map wipe | A scheduled reset chosen by the owner, community, or host. | Buildings, inventories, the current map, and its seed. | Learned blueprints. | The server owner or hosting provider. |
| Blueprint wipe | A deliberate reset of progression, usually announced by Facepunch or selected by a private server. | Everything removed by a map wipe, plus learned blueprints. | Only data that is not part of world, inventory, or blueprint progression. | Facepunch for official forced blueprint wipes; private-server operators for their own schedules. |
A forced wipe is therefore not a fourth kind of data reset. It is a developer-required map reset, with blueprint behavior determined separately. Tell players exactly which type you are performing in your announcement.
#1 Best Overall
- Inspired by the Rust Video Game – These cards replicate the iconic keycards found in Rust (Red, Blue, Green).
- High Quality PVC Plastic – Printed on both sides, durable and water-resistant. Not a sticker.
- Great Rust Gift Idea – Perfect for fans of Rust, whether for cosplay, loot-themed gifts, or collection.
- Wallet-Size Replica – Standard 3.375x2.125 inches, 30 mil thick—fits in any wallet.
- NOT a sticker*
When is the next Rust forced wipe in 2026?
Third-party wipe trackers currently report Thursday, November 5, 2026 at 19:00 UTC (approximately 2:00 p.m. Eastern Time). They list October 1, 2026 as the previous forced wipe and December 3, 2026 and January 7, 2027 as later dates. November 5 falls on the first Thursday of the month, matching the commonly observed pattern.
This date is not an official Facepunch confirmation. As of October 14, 2026, no Facepunch announcement confirming November 5 was identified. Treat the tracker date as a planning estimate and verify the announcement on Facepunch’s Rust news page or in the Steam patch notes before scheduling maintenance, advertising a wipe event, or promising players a specific time. A patch can change timing, and a server still needs time to download and restart after the update.
Prepare the server before a wipe
Most wipe failures happen before the deletion step: the wrong server identity is selected, a backup is missing, or the owner assumes a panel task ran when it did not. Use this preparation sequence for a manual or scheduled wipe.
- Choose the reset scope. Write down “map only” or “map plus blueprints.” Do not use an all-data reset if players are meant to keep their blueprints.
- Announce the maintenance window. Include the date, time zone, expected downtime, wipe type, and whether blueprints will remain. Post the same information in the server’s community channels and in an in-game message if the server is online.
- Record the server identity and settings. Confirm the instance, region, port, world size, seed, hostname, and configuration file you intend to change. This prevents wiping a test instance or a different server on the same machine.
- Make an offline backup. Stop the server first, then copy the current map, save data, blueprint data, configuration, and any custom scripts to storage outside the live server directory. Label the backup with UTC date, server identity, and wipe type.
- Check access. You need file-manager or SFTP access for a file wipe, or administrator access to the provider’s game panel for a scheduled wipe. If the host does not expose world and blueprint storage, ask its support team which control performs each reset.
- Schedule a rollback plan. Keep the backup until players have connected to the new map and you have completed validation. A backup is useful only if you know how to stop the server and restore the original files.
How to perform a manual map wipe
The file-based method works when you control the server files. Names and directory layouts differ between hosts, so identify files by their role and the server identity rather than copying a path from an unrelated provider.
1. Stop the Rust server cleanly
Use the host panel’s Stop button or the operating system service you normally use. Wait until the process exits and the console stops writing save messages. Never delete a live map while the server is running: the process can recreate files, keep handles open, or write the old state back during shutdown.
2. Back up the current world
Copy the map and save data, and keep a separate copy of blueprint data if blueprints are to survive. Include configuration and logs so you can prove which instance was wiped. A compressed archive is convenient, but test that it can be opened before deleting anything.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
3. Identify the live map and save data
Open the server’s configured identity or save location and find the files generated for the active world. The exact filenames, extensions, and subdirectories depend on the hosting platform and launch configuration. If several identities exist, compare the configured identity and most recent modification times with the instance you stopped.
4. Choose one map-reset method
- Remove the map and save files: delete or move the files that store the generated map and world state, while leaving configuration and blueprint data in place.
- Change the generation settings: change
server.seedand/orserver.worldsizein the server configuration, then restart. A new seed produces a different map; changing world size also changes generation and should be done only when you intend to alter the map’s dimensions.
Moving files into a dated backup directory is safer than permanent deletion. Do not remove the entire server identity directory: that can erase blueprints, administrator settings, custom configuration, or logs that were not part of the map wipe.
5. Preserve blueprint data for a map-only wipe
Blueprint storage must remain untouched when the promised reset is map-only. If you cannot distinguish blueprint data from world data, stop and ask the host for the file mapping rather than guessing. A map wipe that accidentally removes blueprints is a blueprint wipe from the players’ perspective.
6. Start the server and watch generation
Restart the instance using its normal launch method. The first start can take longer while a new map is generated. Watch the console for errors, confirm that the configured seed and world size are the intended values, and wait until the server reports that it is ready for connections.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
7. Test as an administrator and as a normal player
Connect from the game client, verify that the spawn area and terrain are new, and check that an existing test account has the expected blueprint state. Confirm that the server name, description, password, plugins, administrator permissions, and connection address are still correct. Only then tell players that the wipe is complete.
How to perform a blueprint wipe
A blueprint wipe combines the map-reset procedure with removal of learned blueprint data. There is no supported fixed March, June, September, and December blueprint cycle to rely on. Facepunch announcements determine official forced blueprint wipes, while private servers can select their own schedule.
Facepunch has previously announced a full reset in its “Pivot Or Die” news post, writing: “today, we’re wiping all Blueprints, wiping all servers, and drastically reducing tech tree and research costs.” That announcement also did not commit to a monthly blueprint wipe. A later community update described a forced blueprint wipe accompanying a December 2 update and said such wipes should be rare. Those statements are why a tracker’s repeating quarterly dates should not be treated as an official calendar.
Safe procedure
- Stop the server and create the same complete backup used for a map wipe.
- Remove or reset the files that store learned blueprints, using the host’s documented control or support instructions. The exact file names and commands are not universal.
- Remove the map and save data, or change the seed/world size, so the world reset matches the announcement.
- Restart, connect with a test account, and verify that previously learned blueprints are no longer available.
- Keep the backup until players have confirmed that the reset is intentional and the server is stable.
If your provider offers a single “wipe all” action, read its description carefully. Some controls reset only the map; others can also remove blueprints, player data, or configuration. When the scope is unclear, request written confirmation from support before using it.
Using a hosting panel’s scheduled-wipe tool
Some game hosts provide a scheduled-wipe option instead of requiring direct file access. The labels and available fields differ by provider, so the following is a provider-neutral workflow rather than a promise that every panel has these controls.
- Open the Rust server in the provider dashboard and locate the scheduled-wipe, world-reset, or task scheduler page.
- Select the wipe scope. Confirm whether the option means map only or includes blueprints; do not infer this from the word “wipe” alone.
- Enter the date and time with the panel’s stated time zone. If it accepts UTC, use UTC consistently with your community announcement. If it displays local time, convert the planned UTC time and record the conversion.
- Save or enable the schedule, then check the task list for the next-run time and the target server identity.
- Create an in-game console announcement shortly before the wipe if the panel supports scheduled console commands. State the exact restart time and reset scope so players can log out safely.
- After the task runs, inspect the panel log and server console. A scheduled task that shows “completed” but leaves the old seed or map files may have targeted the wrong identity or lacked permission.
Panel scheduling reduces file-handling risk, but it does not remove the need for backups, timezone checks, or post-wipe testing. Because panel interfaces change, follow the host’s current documentation for the exact button names.
Automating wipes with Oxide or uMod
Administrators often automate a recurring wipe announcement and reset with server-modification tooling. However, there is no single universal Oxide/uMod wipe command or plugin configuration that applies to every installation, and plugin names and syntax change. Do not paste an unverified command into a production console.
If you use automation, require it to perform these functions:
- Target the correct server identity and scheduled day.
- Announce the reset in chat before shutdown, including the timezone and wipe scope.
- Stop or restart the server in a controlled order rather than deleting files while the process is active.
- Create or retain a dated backup before destructive operations.
- Keep map-only and blueprint-wipe actions separate.
- Write a timestamped result to a log and alert an administrator when a step fails.
Test the automation on a disposable instance first. After an update, verify compatibility before re-enabling it; a plugin that worked last month can fail when the game, server framework, or configuration format changes.
Manual files versus a panel schedule
| Method | Best for | Advantages | Risks and obligations |
|---|---|---|---|
| Manual file-based wipe | Owners with SFTP or filesystem access and a small number of instances. | Direct control over exactly which map, save, and blueprint data is retained. | Higher risk of deleting the wrong files; requires a clean stop, backup, and restart. |
| Hosting-panel schedule | Owners who want a recurring date without managing files. | Centralized scheduling and, on some hosts, built-in announcements or restart handling. | Labels and timezone behavior vary; scope may be ambiguous; you must verify that the task actually ran. |
| Automation/plugin workflow | Communities running repeatable wipes across multiple instances. | Can coordinate announcements, backups, and restarts. | Plugin commands are installation-specific and can break after updates; testing and monitoring are essential. |
How often should a server wipe?
Guides commonly describe weekly or biweekly map wipes between forced wipes, with blueprints retained until the next blueprint wipe. That is a community practice, not a Facepunch rule. A competitive server may prefer frequent map turnover, while a building-focused community may keep one map longer. Publish your cadence on the server description and community channel, and distinguish your voluntary schedule from the monthly forced wipe.
Rank #3
- Acrylic Painting Pla Plastic
Private servers can choose their own blueprint schedule. Do not present a private decision as an official Rust calendar, and do not promise a blueprint wipe on a date unless you control the server or have a current Facepunch announcement.
Troubleshooting after a wipe
The old map comes back
Stop the server and check that you edited the active server identity, not a similarly named test directory. Confirm that the map and save files were moved or deleted and that the launch configuration is not pointing to another save location. If you changed the seed, verify the console shows the new value. Restore the backup only if you need to roll back; otherwise remove the stale files again while the process is stopped.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Players lost blueprints during a map-only wipe
First determine whether the blueprint data was deleted or whether the server started with a different identity that has no prior progression. Stop the server, preserve the current state for diagnosis, and restore only the backed-up blueprint data after confirming it belongs to the same server identity. Do not overwrite the new map or save files when restoring progression.
The server starts but players cannot connect
Read the startup console for generation errors, port-binding failures, missing files, or an update mismatch. Verify that the server finished loading rather than merely launching a process, and confirm that its public address and port did not change. If the forced wipe coincided with a game update, ensure the server installation and clients are on compatible versions before changing wipe files again.
The scheduled task did not run
Check the panel’s timezone, enabled status, next-run time, and target instance. Review task and server logs for permission or restart errors. If the panel reports success but the seed and map are unchanged, run the provider’s documented manual reset or contact support with the task timestamp and server identity.
The wipe happened at the wrong local time
Convert the intended UTC time using the date-specific offset; Eastern Time, for example, is on standard time in November after daylight saving time ends. Put both UTC and a familiar local time in announcements, and use one canonical timezone in the panel and automation.
Recommended Free Tools
A plugin or custom script prevents startup
Disable the recently changed automation or plugin, restart with the backed-up configuration, and confirm that the base server can generate a map. Then update or reconfigure the extension according to its current documentation before re-enabling the wipe workflow.
Post-wipe validation checklist
- New terrain and structures are visible at multiple locations.
- The intended seed and world size appear in the server configuration or startup output.
- Inventories and player-built structures from the previous map are gone.
- Blueprints match the announced scope: retained for a map wipe, cleared for a blueprint wipe.
- The server name, description, password, administrator permissions, and connection details still work.
- Plugins, scheduled tasks, chat announcements, and backups remain available.
- A normal player can join, spawn, craft, and disconnect without errors.
Once these checks pass, publish the completion notice and keep the pre-wipe backup until the next routine backup cycle. For future wipes, record the actual run time and any corrections so the next announcement and schedule use the same timezone and server identity.
Bottom line
A reliable Rust wipe is a controlled data reset, not simply a restart: define whether blueprints are included, stop the server, back up the correct identity, remove or regenerate only the intended world data, restart, and verify the result. The reported November 5, 2026 forced wipe should be treated as provisional until Facepunch confirms it; blueprint wipes have no fixed official quarterly calendar.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

