Soulmask Dedicated Server Setup: The Ultimate Guide 2026

Your Soulmask world dies the moment the host closes their laptop.

That is the core problem with co-op hosting. One player’s PC carries the entire world, their RAM, their internet connection, and their power schedule.

When they disconnect, everyone loses access. When their connection spikes, everyone lags. When the game crashes mid-save, progress disappears with no clean recovery path.

A dedicated server fixes all three. The world runs on its own machine, 24/7, independent of any player’s setup. Tribes come and go. AI activity scales. The server stays live.

This guide covers everything you need to run a Soulmask dedicated server, including Windows, Linux, and Docker setups, the correct App IDs, port configuration, save management, and the specific failures that break most first installs.

This is a post-1.0 setup guide, updated for Soulmask’s April 2026 full release, Shifting Sands support, and current private-server behavior.

If you have already tried once and hit errors, the troubleshooting section covers the ones the official documentation misses.

Key Takeaways

• A Soulmask dedicated server is better than co-op hosting when you need 24/7 uptime, server-side saves, admin control, and stable access for growing worlds.
• Use the correct SteamCMD app ID before installing the server: 3017310 for Windows and 3017300 for Linux, unless official documentation changes.
• Soulmask needs the right ports open to work properly. Use 8777/UDP for game traffic and 27015/UDP for query/listing. Admin access uses separate TCP ports.
• Start with at least 16 GB RAM for a small Soulmask server. Use 24 GB to 32 GB for public, long-running, or high-activity servers.
• Linux is usually better for 24/7 Soulmask hosting because it gives cleaner restart control, lower baseline overhead, and better automation.
• Soulmask uses different configuration layers. Startup parameters control ports, name, passwords, and runtime behavior, while GameXishu.json controls gameplay rules.
• Always stop the server before updates or config edits. Updating or editing files while the server is live can cause ignored changes, bad saves, or rollback issues.
• Back up the full WS/Saved/ directory before every update. Keep off-server backups because local-only backups do not protect against disk failure or compromise.
• Docker can work for Soulmask, but only if ports, memory limits, and save volumes are mapped correctly. Missing volumes can reset data after rebuilds.
• If the server does not show in the browser, check 27015/UDP first. If direct IP also fails, check 8777/UDP, firewall rules, NAT, version match, and logs.

Quick Answer: To set up a Soulmask dedicated server in 2026, install the server with SteamCMD, use app ID 3017310 for Windows or 3017300 for Linux, open UDP 8777 and UDP 27015, configure launch parameters, then edit GameXishu.json after the first startup. Use at least 16 GB RAM and back up WS/Saved before every update.

Soulmask 1.0 also makes map planning more important. Cloud Mist Forest uses Level01_Main, while Shifting Sands uses DLC_Level01_Main and requires the Shifting Sands DLC. Private servers that want cross-map travel need two linked server instances with unique ports and cluster settings.

Quick Reference:Windows dedicated server app ID: 3017310 Linux dedicated server app ID: 3017300 Game port: 8777/UDP Query/listing port: 27015/UDP Telnet/Echo admin port: 18888/TCP RCON port: 19000/TCP, optional Gameplay settings file: WS/Saved/GameplaySettings/GameXishu.json

For baseline private-server behavior, compare your setup against the Soulmask private server documentation before changing ports, saves, or admin settings.

Dedicated server mode note: Survival Mode is the safe default for private dedicated servers. Tribe Mode and Warrior Mode are temporarily disabled for private servers and remain limited to single-player and co-op until developer support changes.

How Soulmask Dedicated Servers Actually Work?

Soulmask runs its world simulation as a server process. When hosted as a dedicated server, that process becomes the single authority for saves, AI, and player connections. If networking, ports, memory, or storage are misconfigured, the server may run but remain unreachable or unstable.

Peer-Hosted Sessions vs Dedicated Servers

Peer-hosted sessions

• One player’s game instance hosts the world
• World simulation stops when the host leaves
• Saves depend on the host’s machine state
• Performance varies with the host’s hardware and network

Dedicated servers

• The server runs as its own process
• The world stays online without any player connected
• Saves write server-side, not client-side
• Admin control and backups work consistently

This separation is what enables persistence and stability.

What the Soulmask Server Process Actually Does?

When you start a Soulmask dedicated server, it:

• Loads the existing world data or creates a new one
• Initializes AI, tribe logic, and world simulation
• Opens network listeners for player connections
• Registers itself so players can discover or connect to it

Players connect to the server, not to another player. The server remains active even with zero players online.

Server Discovery and Visibility

Soulmask servers can be joined in two ways:

• Through the in-game server list
• By direct connection using an IP and port

If a server runs but does not appear in the list, the most common causes are:

• Network ports not reachable from outside
• Firewall rules blocking discovery traffic
• Mismatched port settings between the server and router or cloud firewall

This behavior is common across Steam-distributed multiplayer games, although Soulmask server visibility still depends on the configured query port, firewall rules, and current server status.

Why Do Ports Matter More Than Installation?

A Soulmask server can be:

• Installed correctly
• Running without errors
• Fully loaded

…and still be unreachable.

That usually means the server process is running, but incoming traffic never reaches it. This is why port configuration and firewall rules matter as much as the install commands.

Memory Usage During Startup

Soulmask servers allocate most of their memory during startup.

At launch, the server loads:

• World state
• Tribe and AI data
• Simulation parameters

This causes a temporary memory spike before usage stabilizes. If the system runs out of available memory at this stage, startup can fail or the server can terminate early.

In many cases, errors appear only in log files, not in the terminal output. This makes memory-related failures easy to miss if logs aren’t checked.

Soulmask Server Requirements

A Soulmask dedicated server needs enough RAM, CPU, storage, and open UDP ports to run persistent world simulation without connection or save failures.

Hardware Sizing

These tiers reflect safe planning ranges for multiplayer survival servers, not official Soulmask player limits. Use them as safe starting points.

For public worlds or long-running tribes, a bare metal dedicated server is usually a better fit than shared hosting because CPU, RAM, storage, and network capacity are reserved for one environment.

Small Private Server (Friends, Short Sessions)

Best for learning and casual play.

• CPU: 2–4 modern cores
• RAM: 16 GB minimum
• **Storage:**30 GB minimum SSD
• OS: Windows or Linux

This tier works for small groups when player count, tribe size, and world activity stay modest. Servers with too little memory may start but fail under load or become unstable during restarts.

Medium Community Server (Persistent Worlds)

Best for shared worlds with regular uptime.

• CPU: 4–6 cores
• RAM: 24 GB recommended
• **Storage:**50–100 GB SSD or NVMe recommended with backups
• OS: Linux preferred

As worlds age, memory usage grows. More tribes and AI entities increase pressure even if player count stays the same. Storage speed starts to affect save and restart times.

Large Public Server (High Activity, Long Uptime)

Best for public or heavily modded environments.

• CPU:8+ cores
• RAM: 32 GB or more recommended
• **Storage:**100 GB+ NVMe strongly advised with backups
• OS: Linux

This tier gives headroom. It helps reduce restart failures and peak-activity instability. These numbers reflect operational safety, not minimum launch requirements.

Why Memory Headroom Matters

Soulmask servers allocate a large portion of their working memory early in the server lifecycle. This includes world state, simulation data, and runtime systems required before players connect.

If available memory is tight:

• Startup can fail
• The server may stop before advertising itself
• Errors may appear only in logs

This is why memory-related issues often look like networking or install problems.

Why Storage Speed Affects Stability

Soulmask servers write and read world state during saves, restarts, and updates. Slower disks increase:

• Save duration
• Restart time
• Risk of stalled shutdowns

SSD or NVMe storage can reduce these delays. This does not change gameplay logic, but it can improve operational reliability during maintenance and peak activity.

CPU: Important, but Rarely the First Limit

Soulmask can use multiple threads, but many server issues appear first as memory, storage, or networking limits before CPU saturation. CPU upgrades help when CPU usage is the observed bottleneck. They do not fix RAM exhaustion, blocked ports, bad launch parameters, or visibility issues.

What Actually Increases Load Over Time

Load grows from:

• World age
• Tribe count and size
• AI and world activity
• Concurrent players

Player count alone is a poor sizing metric.

Under-Provisioning: What Really Happens

Low headroom often causes:

• Failed restarts
• Invisible servers
• Unstable saves due to forced shutdowns

Crashes don’t always corrupt data, but abrupt termination during writes increases risk. Proper memory headroom and clean shutdowns reduce this risk.

Soulmask Server Ports & Networking

If your Soulmask server starts but players cannot find or join it, the cause is often networking. Soulmask requires two reachable UDP ports for gameplay and query traffic by default. If either one is blocked or mismatched, the server may appear offline even when running.

How Players Connect to a Soulmask Server

Players join Soulmask servers in two ways:

• Through the in-game server list
• By direct IP connection (IP + port)

Both methods require the server to be reachable from outside the host machine. A running server process alone is not enough.

The Two Ports Soulmask Uses

Soulmask dedicated servers rely on two separate UDP ports per server instance for player traffic and server listing.

Default ports (unless changed in startup parameters):

• Game port: 8777/UDP Handles player connections and gameplay traffic.
• Query / listing port: 27015/UDP Used for server discovery and listing in Steam-based browsers.

If either port is unreachable, players may see connection or listing problems.

Why the Server Shows “Not Showing”

This is a common failure pattern:

• The server process starts
• Logs show no fatal errors
• Players cannot see the server in the list

Common causes include:

• 27015/UDP is blocked by a firewall, router, or provider rule
• The query port does not match the configured value
• Multiple servers share the same query port

Direct IP may still work when listing does not.

When Port Forwarding Is Required

You must forward ports if:

• You host the server on a home network
• The machine sits behind a router using NAT

Port forwarding maps outside traffic to your server’s internal IP.

Typical setup:

• Forward 8777/UDP → server LAN IP
• Forward 27015/UDP → server LAN IP

Without this, outside players cannot reach the server.

NAT vs Cloud Firewalls

Home hosting

• Uses NAT
• Requires router port forwarding

Cloud or dedicated servers

• Usually public IP access, but provider firewalls, NAT, or security groups may still apply
• Use software firewalls, provider firewalls, or security groups

On cloud servers, you must:

• Allow ports in the provider firewall (if enabled)
• Allow ports in the OS firewall

Opening one but not the other can cause a silent connection failure.

UDP vs TCP: What You Should Open

Soulmask player and query ports are UDP-based by default, while Telnet/Echo and RCON admin ports use TCP.

Best practice:

• Open UDP 8777 and UDP 27015 for players
• Do not rely on TCP as a fallback for gameplay/query traffic
• Confirm the server is actually listening on UDP

If UDP traffic cannot reach the server, it may not appear or accept player connections.

RCON and Admin Access

Soulmask supports remote administration features, including RCON-style access.

Key points:

• Admin ports are separate from gameplay ports
• They do not affect server listing
• Exposing them publicly is optional and risky

Public Soulmask servers should also consider a DDoS protected dedicated server when open UDP ports, server visibility, and public player access are part of the setup.

If you enable RCON, also configure 19000/TCP and restrict it with a strong password and trusted IP rules.

How to Test Correctly

Do not trust:

• “The server is running.”
• “It works on LAN.”

Always test:

• From an external network
• Using direct IP
• After a full restart

If outside traffic reaches the server and players can join, the network path is working.

Soulmask Dedicated Server Setup Overview (Choose Your Path)

You can run a Soulmask dedicated server three ways. Pick based on your skill level, uptime needs, and how much control you want. The setup steps differ, but the core rules stay the same: correct app ID, open ports, clean shutdowns, valid configs, and reliable backups.

Option 1: Windows Dedicated Server

Best if you want the fastest path to a testable Soulmask dedicated server.

• Familiar environment
• Simple file paths and tools
• Easy testing on a home PC

Choose Windows if:

• You’re new to server hosting
• You want quick setup and local testing
• Downtime and restarts are acceptable

Trade-off: higher memory overhead and more manual update/restart control.

Option 2: Linux Dedicated Server

Best for long-running, automated, and public Soulmask servers.

• Lower OS memory usage
• Cleaner uptime control under load
• Cleaner automation options

Choose Linux if:

• You want a stable 24/7 server
• You expect more players or larger tribes
• You plan regular updates and backups

Trade-off: steeper learning curve.

Option 3: Docker-Based Server

Best for controlled environments and repeatable builds.

• Consistent setup across machines
• Easy rebuilds and migrations
• Clear separation of server and system

Choose Docker if:

• You already understand Linux basics
• You want repeatable deployments
• You plan multiple servers or automation

Trade-off: more setup steps and stricter port handling.

Soulmask Dedicated Server Setup on Windows

Windows offers the easiest entry point for hosting and testing a Soulmask dedicated server. The setup relies on SteamCMD, a clean directory layout, and a repeatable startup script. Windows works well for testing and small servers but needs manual update, restart, and resource control for long-running use.

How the Windows Setup Model Works?

On Windows, Soulmask runs as a standalone server process. You do not host through the game client.

The server files are downloaded and updated using SteamCMD, which is Valve’s command-line toolfor server deployments.

This matters because:

• The server can run without Steam logged in
• Updates stay separate from your personal game install
• You control exactly when updates happen

Installing SteamCMD (What It Does)

SteamCMD handles:

• Downloading server files
• Updating existing installs
• Verifying file integrity

Install it in a short, simple path, such as:

C:\SteamCMD

Avoid long paths, spaces, special characters, and protected folders such as Program Files. Windows path limits and permissions cause startup failures more often than bad commands.

Downloading the Soulmask Server Files

SteamCMD downloads files using an App ID.

Use the current platform-specific Soulmask dedicated server app ID.

Current app IDs:Windows dedicated server: 3017310Linux dedicated server: 3017300

Recheck these IDs after major patches before updating a published guide.

Windows SteamCMD install command:

steamcmd.exe +login anonymous +force_install_dir C:\SoulmaskServer +app_update 3017310 validate +quit

Use 3017310 for Windows unless official Soulmask documentation changes. Linux uses a different dedicated server app ID: 3017300.

Recommended Directory Structure

Keep tools and server files separate:

C:\SteamCMD → SteamCMD tool

C:\SoulmaskServer → Soulmask server files

This layout:

• Makes updates predictable
• Keeps logs and configs easy to locate
• Prevents accidental overwrites

Do not move the server directory after installation. SteamCMD tracks file paths.

Startup Script: Why You Need One

On Windows, you should always start the server through a startup script, not by clicking the executable.

A startup script:

• Sets ports
• Defines server name
• Applies admin credentials
• Keeps restarts consistent

This is usually a .bat file placed in the server directory.

Why this matters:

• Manual launches can miss required parameters
• Ports may not match your intended launch settings
• Debugging becomes harder

Where Soulmask Config Files Are Created

Soulmask generates configuration files after the first successful server launch.

The exact location depends on how the server is built and may be:

• Inside the server directory
• Inside a Saved or Config subfolder
• Logged in the server output during startup

Best practice:

• Start the server once
• Watch the console or log output
• Note where config files are created
• Stop the server before editing anything

Start the server once, then confirm generated config paths from the server files or logs before editing.

Editing Configs on Windows: Safe Practice

Do not edit configuration files while the server is running.

Why:

• Some servers only read configs at startup
• Runtime edits may be ignored
• Partial writes can occur during active file access

Safe workflow:

• Stop the server
• Edit configs
• Save changes
• Restart using the same script

This avoids unpredictable behavior.

Common Windows-Specific Issues

Windows servers fail for repeatable reasons:

• OS restarts or sleep Disable sleep, hibernation, and automatic reboots.
• Memory pressure Windows reserves more memory than Linux. Leave extra headroom.
• Permissions Run the server from a directory you own, not Program Files.

These issues are usually environmental, not Soulmask bugs.

Updating the Server on Windows

Updates are manual by design.

Standard flow:

• Stop the server cleanly
• Run SteamCMD again with the same install directory
• Let it update files
• Restart using your startup script

Do not update while the server is running. Always control shutdowns yourself.

Soulmask Dedicated Server Setup on Linux

Linux is the preferred platform for long-running Soulmask servers because it gives you tighter process control, predictable restarts, and lower baseline resource usage at the OS level. The setup takes more effort than Windows, but uptime and control improve.

Why Linux Is Used for Long-Running Servers

Linux is built for server workloads.

• No forced background restarts
• Explicit control over processes
• Clear separation between system and application

This does not mean Linux never needs reboots. Kernel updates still require them. The difference is you control when, not the OS.

How the Linux Server Model Works?

On Linux, you run Soulmask as a dedicated user process, not as root.

The typical model:

• One Linux user owns the server files
• SteamCMD downloads and updates files
• A script or service starts the server

This keeps the system secure and predictable.

SteamCMD on Linux

SteamCMD works the same way on Linux as on Windows:

• It downloads server files
• It updates existing installs
• It validates files when needed

Important rules:

• Do not run SteamCMD as root
• Keep a fixed install directory
• Use the same directory for updates

Use app ID 3017300 for Linux unless official Soulmask documentation changes. Using the wrong app ID causes broken or incorrect installs.

Linux User Permissions

Create a dedicated user for the server.

Why:

• Prevents accidental system access
• Keeps file ownership clean
• Avoids permission errors during runtime

What to ensure:

• The server user owns the install directory
• The server user can write logs and save data
• Startup scripts have execute permission

Permission errors usually surface in logs or service output, not as silent failures.

Startup Scripts vs Service Managers

You have multiple valid options.

Shell script

• Manual start and stop
• Simple and transparent
• Good for testing

Service manager (systemd, OpenRC, runit)

• Auto-start on boot
• Restart on crashes
• Clean shutdown handling

systemd is common on modern distributions, but it is not mandatory. The correct choice depends on your distro and comfort level.

systemd: Conceptual Overview

If your system uses systemd, it can:

• Start the server on boot
• Restart it if it crashes
• Stop it cleanly during shutdown

You do not need advanced systemd knowledge. A basic service definition is enough. If your system does not use systemd, use the native service manager or a supervised script.

Editing Configuration Files Safely

Best practice applies regardless of OS:

• Stop the server before editing configs
• Save changes
• Restart the server

Why:

• Many servers read configs only at startup
• Live edits may be ignored
• Behavior varies by application

This is a general server rule, not a Linux or Soulmask-specific quirk.

Firewall and Networking on Linux

Linux servers often block inbound traffic by default.

Before testing:

• Confirm required ports are allowed by the OS firewall
• Match firewall rules to your server’s configured ports
• Test from an external network

If ports are blocked, the server may run but remain unreachable.

Linux Distribution Expectations

Most Soulmask Linux setups target:

• Ubuntu Server
• Debian
• Other mainstream server distributions

Package names and install steps vary by distro. Always follow distro-specific SteamCMD instructions rather than copying commands blindly.

Linux SteamCMD install command: steamcmd +login anonymous \

+force_install_dir ~/soulmask-server \

+app_update 3017300 validate \

+quit

Use 3017300 for Linux unless official Soulmask documentation changes. Validate checks file integrity during updates. Do not move the install directory after deployment.

Soulmask Dedicated Server Using Docker

Docker can give you repeatable builds and clean restarts when ports, volumes, and memory limits are configured correctly.

It also adds networking, persistence, and memory layers that can make Soulmask unreachable or unstable if you map ports, volumes, or RAM limits incorrectly. Use Docker only if you understand container networking and persistence.

What Docker Actually Solves

Docker standardizes the runtime environment.

• More consistent runtime dependencies across deployments
• Same startup behavior across machines
• Easier rebuilds after crashes or updates

This helps when you:

• Move servers between hosts
• Run multiple Soulmask instances
• Want predictable recovery behavior

Docker does not change Soulmask’s game logic or performance model.

Soulmask Ports in Docker

Soulmask uses default ports that must be mapped explicitly unless you change them in launch parameters.

Common ports:

• Game traffic: 8777/udp
• Steam query / listing: 27015/udp
• **Echo / admin port:**18888/tcp (used for Telnet/Echo remote management)
• RCON port: 19000/tcp (optional, only when RCON is enabled)

If gameplay or query ports are missing or mismatched, the server may run but remain unreachable. If admin ports are missing, remote admin access may fail.

How Docker Networking Changes Everything

On bare metal:

• Soulmask binds directly to the host IP
• You open ports once at the OS or cloud firewall

With Docker:

• Soulmask binds inside the container
• You must expose container ports to the host

Traffic path:

1. Soulmask listens on container port
2. Docker maps container → host port
3. Host or cloud firewall allows traffic

All three layers must agree.

Port Mapping Example

docker run -d \

-p 8777:8777/udp \

-p 27015:27015/udp \

-p 18888:18888/tcp \

-p 19000:19000/tcp \

your-soulmask-image

Rules:

• Left side = host port
• Right side = container port
• Protocol must match (udp vs tcp)

Docker never opens firewalls for you.

Docker Images and Port Differences

Community Soulmask Docker images exist, but you should not assume they are official or that they share the same internal paths and ports.

Community images may:

• Rebind internal ports
• Wrap startup scripts
• Expose different defaults

You must always inspect:

• Dockerfile
• docker-compose.yml
• Image documentation

Never assume internal ports, paths, or startup commands match another image.

Persistence: Volumes Are Mandatory

Without volumes, you lose:

• Saves
• Configs
• Logs

Example bind mount:

-v /opt/soulmask/data:/path/required/by/your/image

The correct volume path keeps world data and configs across restarts.

No persistent volume can mean fresh data after container rebuilds or removals.

Memory Limits: Docker Can Stop Your Server

Docker containers respect memory limits.

If Soulmask exceeds its limit:

• The container may be stopped by the runtime
• No guaranteed graceful shutdown
• Possible save loss

Set memory explicitly:

–memory=16g

Or in Compose:

mem_limit: 16g

Do not under-allocate RAM.

Restart Policies (Crash Recovery)

Docker does not restart containers by default.

Use:

–restart unless-stopped

This:

• Restarts after crashes
• Survives host reboots
• Avoids manual babysitting

Without this, a crash can leave the server offline until you restart it manually.

Common Docker Failure Patterns

Most Docker issues are configuration mistakes.

• UDP mapped as TCP
• Missing Echo port
• Firewall open on host but closed in cloud
• No volume for saves
• Memory limit too low

Symptoms:

• Server runs
• Server never appears
• Direct IP fails

These are usually deployment mistakes, not Soulmask bugs.

What Docker Does Not Change

Docker does not:

• Increase player limits
• Reduce RAM needs
• Fix bad configs
• Bypass network rules

It controls how Soulmask is packaged and started, not the game’s core performance model or server rules.

When Docker Makes Sense

Use Docker if:

• You automate deployments
• You version server configs
• You run multiple instances

Avoid Docker if:

• This is your first server
• You want the shortest setup path
• You debug interactively

Linux without Docker is usually simpler for first-time Soulmask server admins.

Soulmask Server Configuration Files Explained

Before changing any values, you need to understand how Soulmask separates startup behavior, engine rules, and gameplay logic.

Soulmask uses three configuration layers. Each layer controls a different class of behavior. They are not interchangeable, and changing the wrong one often has no effect.

Configuration Layer 1: Startup Parameters

Purpose: Server identity and runtime behavior

Startup parameters are passed when you launch the server. They define how the server starts, not how the game plays.

Typical use cases:

• Server name and visibility
• Player limits
• Passwords and admin access
• Port bindings

Where they live:

• Windows: inside your startup .bat file
• Linux: inside a launch script or systemd service
• Docker: inside command: or ENTRYPOINT

Key rule:

• Startup parameters apply only at launch
• Changing them requires a full restart

These settings may override gameplay defaults, but only for values explicitly exposed as launch flags.

Configuration Layer 2: Engine.ini

Purpose: engine-level behavior

Engine.ini controls supported Unreal Engine server-side settings used by Soulmask.

This may include supported networking or runtime behavior settings, but it should not be used for gameplay balance.

Typical location (generated after first run):

• Linux: Saved/Config/LinuxServer/Engine.ini
• Windows: Saved\Config\WindowsServer\Engine.ini

What belongs here:

• Supported engine and network settings
• Only documented runtime settings
• Low-level settings only when documented for Soulmask

What does NOT belong here:

• XP rates
• Damage scaling
• Tribe or gameplay balance

Important safety note:

• Unreal-style config files require correct section names and supported keys
• Invalid or unsupported keys may be ignored
• Syntax errors may fall back to defaults or log warnings

Do this before edits:

cp Engine.ini Engine.ini.backup

Restart required for all changes.

Configuration Layer 3: GameXishu.json

Purpose: gameplay rules and balance

This file controls how Soulmask actually plays.

Typical controls:

• XP and progression rates
• Damage multipliers
• Stamina and survival values
• Tribe and AI scaling

Location:

• Generated after first successful server start
• Stored inside the server’s Saved data directory
• Exact path depends on install method and platform

General pattern:

Location varies by host/build. Common path: WS/Saved/GameplaySettings/GameXishu.json. Search under WS/Saved/ or use your panel’s file manager path.

Critical rules:

• File must be valid JSON
• A syntax error can prevent loading or cause settings to fall back to defaults
• The server may fail to apply changes if the JSON is invalid

Validate before restart:

jq . GameXishu.json

Always restart after GameXishu.json edits.

Do not rely on hot reload behavior unless official documentation confirms it.

How These Layers Interact

These layers serve different purposes.

• Startup parameters define how the server runs
• Engine.ini defines how the engine behaves
• GameXishu.json defines how the game plays

Some values may appear to overlap. When they do, explicit startup flags usually take priority, but only for that specific value. There is no global “override everything” rule.

Safe Editing Rules

• Stop the server before edits
• Back up files every time
• Change one layer at a time
• Restart and verify before stacking changes

Most “config not working” reports come from:

• Editing the wrong file
• Editing the right file in the wrong layer
• Expecting live reloads that don’t exist

Soulmask Server Update & Maintenance Workflow

Here is how to update and maintain a Soulmask server while reducing save-loss and downtime risk.

How Soulmask Server Updates Work

Soulmask server files update through SteamCMD. SteamCMD updates server binaries and related files on disk.

What SteamCMD does not do:

• It does not stop a running server
• It does not wait for saves to finish

You must take the server offline before updating.

If you want help with OS updates, monitoring, security hardening, and recovery workflows, managed dedicated server hostingcan reduce the operational burden without removing your server control.

Correct Way to Stop the Server

Always use a graceful shutdown.

Choose the method that matches how you run the server:

• Foreground processCtrl + C
• systemd servicesystemctl stop soulmask.service
• Docker containerdocker stop soulmask
• **Manual process (last resort)**kill -SIGTERM

Do not use kill -9 unless the process is completely stuck. It skips cleanup and can interrupt save writes.

Where Soulmask Saves Data

Soulmask stores world data under the server’s Saved directory.

Typical layout:

Soulmask-Server/

└── WS/

└── Saved/

├── SaveGames/

├── Config/

└── Logs/

This directory is what keeps your world alive.

Backing Up Saves and Configs

Back up before every update.

Example:

tar -czf soulmask-backup-$(date +%Y%m%d-%H%M).tar.gz \

~/Soulmask-Server/WS/Saved/

Store backups off the server if possible.

Updating the Server via SteamCMD

Run SteamCMD only after the server is fully stopped.

steamcmd +login anonymous \

+force_install_dir ~/Soulmask-Server \

+app_update 3017300 validate \

+quit

What this does:

• Downloads updates
• Replaces changed files
• Checks file integrity

The validate flag checks file integrity and can repair missing or changed files.

Restarting the Server

Start the server the same way you normally do:

• Startup script
• systemd service
• Docker container

Do not rush the restart. First launch after an update may take longer.

Confirm the Server Loaded Correctly

After restart, verify all of the following:

• Server process stays running
• Server appears in the browser or accepts direct IP
• You can connect and spawn
• No critical errors in logs

Check logs:

~/Soulmask-Server/WS/Saved/Logs/

Update Cadence: What to Do in Practice

Use judgment, not autopilot.

• Private servers: update when you play
• Community servers: update during low traffic
• Public servers: announce downtime in advance

If a major patch drops, consider waiting a short period to see if hotfixes follow.

If an Update Breaks the Server

Roll back using your backup.

tar -xzf soulmask-backup-YYYYMMDD-HHMM.tar.gz -C ~/

Then restart the server.

Do not rely on SteamCMD rollback unless the developer exposes an older branch.

Your own backups are the safest rollback path.

Maintenance Checklist

• Stop the server cleanly
• Back up WS/Saved/
• Update with SteamCMD
• Validate files
• Restart
• Verify world loads

Soulmask Server Not Showing or Not Connecting

Let’s match each failure symptom to its real cause and fix it without guesswork.

Log File Locations

Check logs before guessing.

~/Soulmask-Server/WS/Saved/Logs/

└── WS.log

Useful checks:

Steam-related issues

grep -i steam ~/Soulmask-Server/WS/Saved/Logs/WS.log

Startup or crash errors

grep -i error ~/Soulmask-Server/WS/Saved/Logs/WS.log

Verification Commands

Check ports are listening

ss -u -lpn | grep -E ‘8777|27015’

ss -t -lpn | grep -E ‘18888|19000’

Firewall status

sudo ufw status

sudo iptables -L -n

Memory check

free -h

If ports are not listening, the server is not exposing them on the host.

If ports are listening but traffic fails externally, check OS firewalls, provider firewalls, NAT, security groups, and port mappings.

RAM Clarification

Startup crashes are usually not fixed by lowering player count.

Why:

• Player limits affect runtime, not startup allocation
• Soulmask allocates core systems at launch

Correct fix:

• Add RAM
• Stop other memory-heavy services
• Avoid relying on swap as a RAM substitute

Startup Time Reality

First startup after update can take 1–3 minutes, longer on HDDs. Do not assume failure until logs stop progressing.

Performance Optimization for Stable Long-Running Servers

Let’s focus on what actually keeps Soulmask servers stable over long uptime, not guesses or brute force.

Player Caps vs Real-World Stability

Player count is one of the easiest load controls you have.

Each player increases:

• Simulation activity
• Network traffic
• Save pressure

Start conservative. Let the server run for hours. Increase caps only after confirming stable memory, CPU, storage, and network behavior.

Safe approach

• Raise player cap in small steps
• Observe behavior under real play
• Roll back at the first sign of instability

AI and World Activity: What You Can Control

Soulmask runs AI and world simulation continuously. You may not have direct controls for AI internals, but world activity still matters.

What increases load:

• Large tribes active at once
• Dense bases in small areas
• Many entities operating simultaneously

Practical guidance:

• Avoid stacking large player groups in one zone
• Spread bases geographically
• Limit large-scale automation clusters

This can reduce server pressure without relying on unconfirmed hidden settings.

Simulation Scope (What to Adjust Carefully)

Some simulation behavior is engine-driven and not always exposed.

Do not assume:

• Physics distance controls exist
• Safe tuning ranges are documented

If you experiment:

• Change one value at a time
• Test on a non-production server
• Watch logs and performance closely

If you can’t confirm a setting exists, don’t rely on it.

Memory Behavior and Long Uptime

Long-running servers often show gradual memory growth. This does not always mean a memory leak.

Common causes:

• Cached world state
• Player churn
• Accumulated runtime data

What matters is the trend.

Monitor memory:

free -h

ps aux | grep WSServer

If memory usage climbs steadily and never drops, schedule low-traffic restarts and investigate logs.

Restart Schedules

Restarts can clear accumulated runtime state.

Recommended baseline:

• Consider daily scheduled restarts for public servers if monitoring shows memory growth, degraded performance, or repeated log warnings
• Restart during low activity
• Announce downtime when applicable

Restart more often only if monitoring shows need. Restarts are maintenance, not failure.

Monitoring Logs the Right Way

Logs usually signal performance issues. Repeated high-volume logging can also add disk activity.

Watch for:

• Repeated warnings
• Save delays
• Network or timeout errors

Log location:

WS/Saved/Logs/WS.log

Quick checks:

tail -n 50 WS.log

grep -i error WS.log

Repeated errors can signal instability or misconfiguration.

Storage and Save Behavior

Save operations hit disk.

Warning signs:

• Lag during saves
• Log messages showing delayed writes

Best practice:

• Use fast storage
• Avoid disk-heavy background jobs
• Keep free disk space available

If saves slow down, players may feel lag or delayed shutdowns.

How to Scale Responsibly

Scale in this order:

• Lower player caps
• Reduce concentrated activity
• Improve monitoring
• Add RAM or faster storage
• Upgrade CPU when monitoring shows CPU is the bottleneck

Hardware helps most when load, configs, and network exposure are already controlled.

What a Healthy Server Looks Like

A stable Soulmask server:

• Runs for hours without crashes
• Uses memory predictably
• Saves cleanly
• Shows no repeating critical log errors

Security, Backups & Long-Term Stability

Let’s secure access and protect your world so one bad moment doesn’t wipe months of progress.

Password Hygiene (First Line of Defense)

Admin access equals full control.

Do this:

• Use long, unique admin passwords
• Change passwords after admin changes
• Store credentials offline

Avoid:

• Reused passwords
• Shared logins
• Plain-text notes on the server

One leaked admin password can compromise the server.

Admin Access Control

Admin rights should be rare.

Best practice:

• Grant admin access only when needed
• Remove access after tasks finish
• Keep admin count low

This follows least-privilege security. Fewer admins mean fewer mistakes.

Where Admin Credentials Live

Soulmask admin access is commonly controlled server-side through passwords or configured admin tools.

Common patterns:

• Admin password passed as a startup parameter
• Admin authentication handled in-game using that password

If you run startup scripts or services, treat them as sensitive files.

Protect:

• Startup scripts
• systemd service files
• Any file containing passwords

What to Back Up

Back up state, not just saves.

Always include:

• WS/Saved/ (entire directory)

Why:

• This captures world data, character data, tribe data, and configs
• Exact sub-structure may change between versions

Also back up:

• Startup scripts (start_soulmask.sh)
• systemd service files (/etc/systemd/system/soulmask.service)
• Custom cron jobs

Backing up the full Saved/ directory avoids guesswork.

Backup Frequency

Minimum standard:

• Daily backups for active servers
• Before updates
• Before config changes

If players log in daily, back up daily.

Off-Machine Backups

Backups stored only on the same server are not enough.

Because:

• Disk failure can wipe local copies
• Compromise can delete all local copies
• Human error spreads fast

Use:

• Another machine
• Cloud storage
• Object storage

Off-machine storage improves recovery odds.

How to Restore a Backup

• Stop the server fully
• Move current WS/Saved/ aside
• Extract backup into original location
• Start server
• Confirm world loads and players can join

Test restores on a spare server when possible.

Backup Automation

Example cron job:

0 3 * * * /home/soulmask/backup.sh

Automated backups reduce missed-backup risk.

SSH & Server Access Security

Protect the machine itself.

Do this:

• Use SSH keys, not passwords
• Disable root SSH login
• Keep OS updates current
• Run Soulmask as a non-root user

Game security starts with server security.

Port Security

Only expose what players need.

Guidelines:

• Keep admin ports private
• Restrict admin access by IP if possible
• Separate player ports from management access

Unnecessary open ports increase attack surface.

How RedSwitches Supports High-Performance Soulmask Servers

Once configuration is correct, remaining stability issues usually come from hardware, memory, storage, or network limits.

Under heavy load, servers may face memory pressure, CPU contention, save delays, or network jitter. At that stage, hardware and network quality often become the constraint.

RedSwitches supports high-performance Soulmask servers by reducing the resource limits that commonly cause instability.

With dedicated server hostingF, you can size CPU, RAM, NVMe storage, and bandwidth around your actual player count, map plan, and backup schedule.

Our dedicated and bare-metal servers provide reserved hardware resources, reducing resource contention compared with shared hosting. This helps reduce slowdown, crash, and forced-restart risk when the server is correctly configured.

We also deliver consistent CPU performance. Dedicated cores reduce noisy-neighbor risk and provide more predictable performance than shared virtualized environments.

Combined with high-bandwidth, low-latency networking, this supports smoother connections and more reliable UDP traffic during combat and large events.

With global server locations, you can deploy closer to your players to reduce latency.

The result is a Soulmask server environment designed for better stability, cleaner scaling, and more predictable performance, so you spend less time fighting hardware limits.

FAQs

Q. What is the Soulmask dedicated server app ID?

Use app ID 3017310 for the Windows dedicated server and 3017300 for the Linux dedicated server. Recheck official sources after major patches before publishing or updating setup commands.

Q. What ports does a Soulmask dedicated server use?

Soulmask uses 8777/UDP for game traffic and 27015/UDP for query/listing by default. Telnet/Echo admin access uses 18888/TCP, and RCON can use 19000/TCP when enabled.

Q. Where is GameXishu.json in Soulmask?

GameXishu.json is commonly located at WS/Saved/GameplaySettings/GameXishu.json after the first successful server run. Stop the server before editing it.

Q. How many players can a Soulmask dedicated server handle?

A 16 GB server is a practical starting point for small groups. Stable player count depends on world size, tribe activity, AI behavior, settings, storage, memory, and uptime. Always scale after observing memory, CPU, storage, network behavior, and logs.

Q. Why does my Soulmask server not show up?

A common cause is blocked UDP ports. Soulmask requires 8777/UDP (game) and 27015/UDP (query). If direct IP works but listing does not, check 27015/UDP, server filters, version match, and listing delay.

Q. Is Linux better than Windows for Soulmask?

Usually, yes, for long-running servers. Linux usually uses less idle memory and offers cleaner process control, though kernel and security updates may still require planned reboots. Windows works but needs more headroom and controlled update/restart settings.

Q. Can I run Soulmask in Docker?

Yes. Docker can work well for repeatable setups when ports, volumes, and memory limits are configured correctly. You must map UDP gameplay/query ports, map TCP admin ports only when needed, and persist saves with volumes. Incorrect port mapping is a common failure point.

Q. How often should I restart my server?

For public or long-running servers, schedule restarts during low-activity periods only when monitoring shows memory growth, save delays, or repeated log warnings. This can help stabilize memory use and reduce degradation when the server shows a repeatable issue pattern.