No One Survived Dedicated Server Setup Guide 2026

A No One Survived dedicated server can launch without errors and still remain invisible, load the wrong world, or put hours of progress at risk. One missed port, outdated build, or unsafe shutdown can make a healthy server look broken.

The current verified setup uses the official Windows x64 server tool, installed through SteamCMD with App ID 2329680. Allow UDP 7777 and UDP 27015 by default, then configure WRSH\Saved\Config\WindowsServer\Game.ini. Start with the supplied StartServer.bat, match the client and server versions, and stop the server before backups or updates. No native Linux server, official RCON interface, or Steam Workshop workflow is currently documented.

This guide covers hardware, installation, networking, Game.ini, admin access, updates, backups, and troubleshooting in a practical order. You will learn how to keep the server visible, protect its world, and recover cleanly when something goes wrong.

No One Survived Dedicated Server: Quick Facts

2026 Latest Updates: No One Survived reached full release on December 27, 2025. As of August 19, 2026, the latest identifiable game version is 1.0.0.5, announced on June 22, 2026. The dedicated-server public branch was updated on June 23, 2026, to build 23797477. The server remains a separate Windows x64 Steam Tool under App ID 2329680. No official native Linux deployment is documented.

Official Dedicated Server Support Status

No One Survived has an official dedicated server distributed as a separate Steam Tool. It is designed for persistent multiplayer worlds. This lets you run a server that stays online without relying on one player’s PC. When set up on suitable hardware, storage, and networking, it can be stable and predictable.

Supported Operating Systems

Practical Windows Targets

• Windows 11
• Windows Server 2022 or 2025
• Fully patched Windows Server 2019 or 2016 for compatibility with the developer’s documented minimum

These are practical Windows targets for the server. You get the Windows server executable distributed through Steam and updates through SteamCMD. This is the platform currently shown by the confirmed Windows 64-bit server launch configuration.

Not Confirmed As Native

• Linux dedicated server builds

Windows and Linux Support Expectations

Use Windows x64 for the documented No One Survived dedicated-server workflow. No native Linux build or official Linux deployment process is currently documented.

Experienced administrators may try running the Windows server through Wine, but this community workaround is unsupported.

Game or compatibility-layer updates may disrupt startup, networking, automation, or process management. Test updates separately and maintain recent backups if you choose this route.

Before installation, confirm the host operating system, allow UDP 7777 and 27015, and locate WRSH\Saved\Config\WindowsServer\Game.ini. Choosing the supported platform first removes a major source of uncertainty when diagnosing launch, networking, or configuration problems.

No One Survived Dedicated Server Installation Guide

Follow these steps to install a No One Survived dedicated server.

What This Server Actually Needs to Work

Before touching SteamCMD, understand this:

• The current confirmed server path is Windows-first
• Networking usually affects visibility more than hardware
• First boot can look slow or unresponsive
• Config mistakes can cause crashes, failed startups, or settings that do not apply
• Many failures come from skipped steps, missing runtime files, networking mistakes, or config errors

Keep that in mind as you proceed.

1. Before You Start (Do Not Skip)

Confirm the following before installation:

• A current Windows x64 host, preferably Windows 11 or Windows Server 2022/2025
• Administrator access for installation and firewall configuration
• At least 30 GB of free SSD or NVMe space
• Permission to allow UDP 7777 and UDP 27015 in the host or provider firewall
• A public IPv4 address and router access only when hosting behind home IPv4 NAT

If normal inbound IPv4 is unavailable, request a public address from the ISP or use hosting that supplies a reachable public endpoint.

2. CGNAT Check (Critical Reality Check)

CGNAT silently breaks normal public port forwarding.

How to Check It

1. Find your public IPv4 address through a reputable external IP-checking service.
2. Compare it with the WAN IPv4 address shown by the router.
3. If they differ, inspect the WAN address:
   • 100.64.0.0/10 commonly indicates CGNAT.
   • 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 indicates private upstream addressing or double NAT.
4. Ask the ISP whether the connection supports unsolicited inbound IPv4 traffic.

An address mismatch proves upstream translation, but it does not by itself prove CGNAT. The 100.64.0.0/10 shared address range commonly used for CGNAT is defined in IETF RFC 6598.

If You Have CGNAT

You have three real options:

• Request a public IPv4 from your ISP
• Use a hosted server
• Use advanced tunneling (not beginner-friendly)

If CGNAT exists, your server will not be reachable from outside through normal router port forwarding.

3. Required Runtime (This Prevents Instant Crashes)

Microsoft Visual C++ Runtime (Mandatory)

If this is missing, the server may not start.

Install

• Microsoft Visual C++ Redistributable 2015–2022 (x64)
• Download the latest Microsoft Visual C++ x64 Redistributable from Microsoft

Symptoms When Missing

• VCRUNTIME140.dll missing
• MSVCP140.dll missing
• The server window opens and closes instantly

Install it once. This fixes many instant-startup failures caused by missing runtime DLLs.

4. Launch Command Reference

After installation, run the package-supplied StartServer.bat first. If it points to an invalid path or fails to start the current package, use the root executable as a fallback:

"C:\NoOneSurvivedServer\WRSHServer.exe" -server -log -port=7777 -queryport=27015

The -log parameter helps with diagnosis. Custom ports require matching UDP firewall and forwarding rules. Running multiple instances also requires isolated data, configuration, ports, and process management.

5. SteamCMD Installation

SteamCMD is the cleanest documented way to install and update this server.

Why:

• No launcher
• No full game client install
• Lower risk of version mismatch
• Clean update control

Create Directories

Run PowerShell as Administrator:

mkdir C:\SteamCMD

mkdir C:\NoOneSurvivedServer

Do not install into Program Files.

Windows permission control can break updates and logging.

Install SteamCMD

• Download the SteamCMD ZIP through Valve’s official SteamCMD documentation
• Extract into C:\SteamCMD
• Run steamcmd.exe once to let it update

6. Installing the No One Survived Dedicated Server

Use the dedicated server App ID 2329680 for production installs.

SteamCMD Install Flow

force_install_dir C:\NoOneSurvivedServer

login anonymous

app_update 2329680 validate

quit

This installs the dedicated server tool. Confirm the install by checking for WRSHServer.exe and the expected WRSH folder structure.

7. Network Requirements (This Is Where Most People Fail)

Required Ports

Both ports matter. If one is blocked, the server may be invisible or unreachable.

Windows Firewall Rules

Run once as Administrator:

netsh advfirewall firewall add rule name="NOS Game UDP 7777" dir=in action=allow protocol=UDP localport=7777

netsh advfirewall firewall add rule name="NOS Query UDP 27015" dir=in action=allow protocol=UDP localport=27015

Verify:

netsh advfirewall firewall show rule name=all | findstr NOS

8. Router Port Forwarding (Home Hosting Only)

When hosting behind home IPv4 NAT, Windows Firewall rules alone do not make the server publicly reachable.

Access Router

• Open the router’s documented management address.
• Sign in with its unique administrator credential.
• Check the device label or ISP/vendor documentation if the address or credential is unknown.
• Replace any unchanged default administrator password.

Forward These Ports

Find LAN IP:

ipconfig

9. Starting the Server

Primary Launch Method

Run C:\NoOneSurvivedServer\StartServer.bat. If the supplied batch file contains an invalid path, use C:\NoOneSurvivedServer\WRSHServer.exe -server -log as a fallback.

Use administrator privileges only for installation or firewall changes that require them. Run the server under a dedicated non-administrator account where practical.

10. First Boot Behavior

The first startup can look slow or unresponsive.

Normal Behavior:

• Startup may take several minutes depending on hardware and world state
• Console pauses
• High disk usage
• Window marked “Not Responding”

Do not close the server unless logs show a real failure.

Killing the process during first boot can interrupt setup or save initialization.

11. Confirming a Successful Launch

Port Binding Check

netstat -ano | findstr ":7777"

netstat -ano | findstr ":27015"

If netstat shows UDP endpoints bound to these ports, correlate the PID with the server process. A local binding does not prove public reachability, so also confirm readiness in the logs and test discovery or joining from an external network.

Log Location

WRSH\Saved\Logs

Logs grow continuously while the server runs.

12. File Structure

C:\NoOneSurvivedServer\

├─ WRSHServer.exe

├─ WRSH\

│ └─ Saved\

│ ├─ Config\

│ │ └─ WindowsServer\

│ │ └─ Game.ini

│ ├─ SaveGames\

│ └─ Logs\

Knowing this directory structure makes configuration and troubleshooting considerably easier.

13. Game.ini – Core Server Control

Location

WRSH\Saved\Config\WindowsServer\Game.ini

Minimal Working Example

[ServerSetting]

SaveName=MySave

OpenMap=Map01

ServerName=MyNoOneSurvivedServer

NeedPassword=False

Password=

MaxPlayers=8

AdminPassword=CHANGE_THIS_ADMIN_PASSWORD

Rules:

• Stop the server before editing and restart it afterward.
• OpenMap=Map01 and OpenMap=Map02 are documented values. Map03 exists in the game, but its dedicated-server value is not confirmed.
• MaxPlayers accepts values from 2 to 50, but the server should be load-tested before raising the limit.
• NeedPassword=False with an empty Password= disables the join password.
• Use a unique AdminPassword, join the server, and press Alt + Shift + O to open the administration panel.
• No official RCON, remote moderation console, player whitelist, chat-command set, or Steam Workshop workflow is documented.

14. Save Files and Backups

The principal world-save directories are:

• WRSH\Saved\SaveGames\WorldSaves
• WRSH\Saved\SaveGames\AutoSave

Also protect WRSH\Saved\Config\WindowsServer\Game.ini and Engine.ini.

For an application-consistent backup, stop the server gracefully, confirm that the process has exited, and copy these files into a timestamped directory. Keep at least one recent copy outside the server’s primary disk. Do not merge a backup over damaged live files during restoration.

15. Updating the Server Safely

force_install_dir C:\NoOneSurvivedServer

login anonymous

app_update 2329680 validate

quit

Always

• Stop server
• Back up WorldSaves, AutoSave, Game.ini, and Engine.ini after the server has stopped
• Update
• Restart
• Join and test

Never update while players are connected.

How Players Join Your Server

Standard Method

1. Launch game
2. Multiplayer
3. Private Server
4. Search the exact server name
5. Enter the password if set

Local Test

Use the Private Server menu first. If direct IP entry is available in the current build, a local test can confirm basic server readiness. It cannot verify router forwarding, provider firewalls, CGNAT, or public reachability, so complete a separate join test from an external network.

16. Common Failures (Fast Diagnosis)

Server closes instantly

├─ Missing DLL → Install Visual C++ Runtime

├─ Port bind error → Firewall or port conflict

└─ Silent exit → Check Logs

Server invisible

├─ Startup incomplete, wrong region, or client/server version mismatch

├─ Intended Game.ini not loaded or exact server name not used

└─ UDP 27015 or UDP 7777 blocked by firewall, NAT, or CGNAT

Can see but cannot join

├─ UDP 7777 blocked or forwarded incorrectly

├─ NAT loopback affecting local public-IP testing

└─ Client/server version mismatch or server startup incomplete

17. Backup Strategy, Save Safety, and Disaster Recovery

Tested versioned backups or application-consistent snapshots provide dependable recovery points after crashes, failed updates, power loss, and administrative mistakes. Without a verified restorable copy, the world has no dependable rollback point.

Where No One Survived Saves Live

All critical server data lives here:

C:\NoOneSurvivedServer\WRSH\Saved\

What matters inside:

• SaveGames\ → world data (highest priority)
• Config\WindowsServer\ → Game.ini and server rules
• Logs\ → troubleshooting only, not required for restore

If SaveGames is lost and no recoverable copy exists, the world cannot be restored.

What Must Be Backed Up

At minimum:

C:\NoOneSurvivedServer\WRSH\Saved\SaveGames

C:\NoOneSurvivedServer\WRSH\Saved\Config\WindowsServer

Best practice:

• Back up the entire Saved directory
• Exclude binaries; they can always be reinstalled

Manual Backups Before Risky Actions

Take an offline backup before updates, save migration, manual save repair, major configuration changes, or destructive troubleshooting.

Stop the server gracefully and confirm that its process has exited. Then run PowerShell with an account that can read the server data and write to the backup destination:

$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm"

$source = "C:\NoOneSurvivedServer\WRSH\Saved"

$destination = "D:\NOS_Backups\Manual\$timestamp"

robocopy $source $destination /E /COPY:DAT /R:2 /W:5

Replace D:\NOS_Backups with a valid location on a secondary disk or backup volume before running this command.

Check the robocopy result and confirm that the destination contains the expected saves and configuration. Exit codes 8 or higher indicate a copy failure. This is an offline file backup, not a storage snapshot. Microsoft’s Robocopy documentation lists the supported copy options and exit-code meanings.

Automated Backups

Do not schedule a raw robocopy operation against active save files. A tested maintenance job should:

1. Warn connected players.
2. stop the server gracefully;
3. confirm that the process has exited;
4. copy the saves and configuration into a new timestamped directory;
5. check the copy result and verify the destination;
6. delete only validated timestamped backup directories after the new backup succeeds
7. restart the server and perform a health check.

Run the job under a dedicated account with read access to the server data and write access only to the approved backup destination. Do not use -ExecutionPolicy Bypass or highest privileges unless a documented requirement makes them necessary. Choose the schedule according to the amount of progress your group can accept losing.

Backup Storage Recommendations

Never store backups on the same disk only.

Recommended locations:

• Secondary internal drive
• External USB drive
• Network share (NAS)
• Cloud-synced folder (OneDrive, S3, etc.)

Rule:

• One local copy
• One off-site copy

Backup Size and Retention Planning

Backup size varies with the world, player data, autosaves, configuration, and backup method. Measure the first verified backup instead of relying on an unsupported size estimate.

Retention guidance:

• Keep multiple recent restore points based on available storage and acceptable progress loss.
• Preserve manual backups from major updates and milestones.
• Maintain at least one recent copy outside the server’s primary disk.

Disk space is cheaper than rebuilding a lost world.

Backup Verification

A backup is dependable only after a successful restore test.

Verify Backup Integrity

1. Stop the test server.
2. Restore the backup into a separate test directory.
3. Start the test instance with isolated ports and data.
4. Confirm that the world loads, player data exists, and recent expected changes are present.
5. Test after creating the workflow, after script or storage changes, and periodically according to the world’s value and risk.

Restore and Rollback Procedure

1. Stop the production server completely.
2. Rename the current WRSH\Saved directory as an incident copy.
3. Create a clean WRSH\Saved directory from the selected backup instead of merging files over the damaged state.
4. Compare older configuration files with the current format before reusing them.
5. Start the server and verify the world, player data, settings, and logs.
6. Keep the incident copy until the restored world has been fully validated.

Never restore while the server is running.

How Backups Protect Against Updates and Crashes

• Updates usually change binaries, but configs or generated files may also be affected
• Crashes can interrupt disk writes
• Admin errors can corrupt configs

Backups can convert these problems from permanent losses into recoverable incidents.

System Requirements and Realistic Hardware Sizing for Stable Servers

There is a big difference between a server that starts and a server that stays playable. Low hardware may be enough for testing, but larger worlds and active groups need more CPU, RAM, and storage headroom.

Minimum Functional Setup

This works only for testing or very small groups:

• CPU with adequate single-core speed
• 8 GB RAM
• SSD storage
• Stable network connection

You may see stuttering during combat or longer save times as world data grows.

Recommended for Real Play

Cat Play Studio lists 4 GB minimum and 8 GB preferred RAM for the 16 km² map, and 8 GB minimum and 16 GB preferred RAM for the 64 km² map. These figures appear to cover the server process, so the Windows host needs additional memory.

For a practical deployment, use:

• A modern CPU with strong per-core performance
• 8 GB host RAM for a small test server or 16–32 GB for larger deployments
• At least 30 GB of free SSD or NVMe storage
• A stable wired connection with a reachable public endpoint

These are operational recommendations, not official performance guarantees. Monitor CPU, RAM, storage, and network use under your actual map, world, and player load.

RAM usage rises as bases expand, zombies persist, and world state grows. Storage also increases over time due to saves and backups. Plan for both from day one.

Scale by behavior, not only player count. Large bases and heavy AI loads can matter more than player numbers. This is where dedicated CPU allocation, fast NVMe storage, and stable bandwidth can help. Communities running several game instances or other network-heavy workloads can also compare RedSwitches high-bandwidth servers.

Network Requirements, Ports, and Firewall Rules

Many No One Survived server visibility and connection failures are not hardware issues. They are network mistakes. Ports get blocked. NAT breaks routing. Traffic never reaches the server.

How Server Traffic Actually Works

The server relies on two types of traffic:

• Game Traffic: Handles player movement, combat, AI, and world updates.
• Query Traffic: Lets the server appear in the server list and report status.

If query traffic fails, the server runs but stays invisible.If game traffic fails, players see high ping or cannot connect.

Both must work.

TCP vs. UDP: What Matters Here

The verified default inbound ports are:

• UDP 7777 for game traffic
• UDP 27015 for Steam queries and server-browser visibility

Do not expose TCP 7777 or TCP 27015 by default. Add another protocol or port only when the current server build, logs, or a listener check proves that it is required.

Firewall Rules vs. Router Port Forwarding

These are different layers. Windows or provider firewall rules are required, while router forwarding is needed only when the server is behind IPv4 NAT. Microsoft explains how to manage Windows Firewall from the command line when creating or checking inbound rules.

• Firewall rules control traffic on the server machine.
• Port forwarding controls traffic at the router level.

A common failure looks like this:

• Ports are open in Windows Firewall.
• Ports are never forwarded on the router.

Result: the server starts, but no one can join.

Why Does CGNAT Break Home Hosting?

Many ISPs use CGNAT. You do not receive a public IPv4 address.

When CGNAT is in place:

• Port forwarding does nothing.
• External players cannot reach your server through normal router port forwarding.

This is why home hosting can fail even when settings look correct. Hosted infrastructure avoids this limitation only when the selected plan includes a reachable public endpoint and permits the required UDP traffic.

NAT Loopback: The Local Test Trap

Hosting and playing from the same network can make public-IP testing confusing.

If your router lacks NAT loopback:

• The server works for outside players.
• You cannot connect using the public IP.

This leads people to think the server is broken. It is not. The network is.

Forum-Derived Failure Patterns

Common community-reported symptoms include:

• The server appears with ping 2000 or 0/0 players.→ Confirm startup completion, matching client/server versions, local UDP bindings, firewall rules, and router forwarding.
• The server never appears.→ Check the exact server name and region, loaded configuration, current versions, UDP 27015, UDP 7777, and external reachability.

Troubleshoot in this order: process and logs, loaded configuration and versions, local UDP bindings, host or provider firewall, router or CGNAT, and finally an external discovery or join test.

Hosting vs Self-Hosting: What Makes Sense for No One Survived Servers?

There is no single best hosting option. Compare your network, player group, availability requirements, budget, and tolerance for downtime before choosing.

Public communities should also consider DDoS-protected dedicated servers and confirm that mitigation supports the required UDP traffic.

Why Stable Infrastructure Matters for Survival Servers

Decision rule: Self-host when you control the network and can tolerate downtime. Choose dedicated hosting when availability, public reach, and infrastructure stability matter more.

Why RedSwitches Fits No One Survived Dedicated Server Hosting

A successful No One Survived server requires more than installing the correct Steam App. Windows support, public IPv4, UDP 7777 and 27015, sufficient resources, controlled updates, and reliable backups all help keep the world accessible and player progress protected.

Home hosting can work for smaller groups, but availability remains tied to a personal computer, power supply, upload connection, router, and ISP restrictions. As a world grows or requires continuous access, dedicated infrastructure provides greater control and removes many of these home-network limitations.

RedSwitches offers dedicated servers with configurable CPU, RAM, SSD or NVMe storage, high-bandwidth connectivity, DDoS protection, and multiple server locations. Before ordering, confirm that the selected configuration supports Windows, public IPv4, the required UDP traffic, and your preferred backup and management options.

These features do not replace correct configuration or tested backups. However, paired with the setup covered in this guide, they create a stronger foundation for a persistent No One Survived world that remains reachable, recoverable, and ready for players.