Barotrauma Dedicated Server Setup Guide 2026

A Barotrauma dedicated server keeps your crew’s campaign available even when the original host is offline. But launching the process is only the beginning; visibility, mod compatibility, and save recovery determine whether it stays usable.

To host one in 2026, install Steam App 1026340 with SteamCMD or Steam Tools and launch DedicatedServer.exe on Windows or ./DedicatedServer on Linux. Configure serversettings.xml, allow UDP 27015 for gameplay, and allow UDP 27016 for queries and public discovery. Test Direct Join and save persistence on a vanilla server before enabling content mods or third-party LuaCs mods. Back up the campaign’s .save and matching _CharacterData.xml files before updates or mod changes.

The real work is keeping ports, permissions, mods, and campaign files aligned over time. This guide covers the complete Windows and Linux setup, followed by visibility, administration, backups, Docker, performance, and troubleshooting.

Barotrauma Dedicated Server: Quick Facts

Barotrauma Dedicated Server Status in 2026

The current stable release is Barotrauma 1.13.4.0, released June 18, 2026. The standalone dedicated-server tool remains available as Steam App ID 1026340 for Windows and Linux. Home & Harbor remains upcoming rather than a live server feature.

Quick Reality Check: When You Should (and Shouldn’t) Run a Dedicated Server

A Barotrauma dedicated server is not always the right choice. It adds setup work, stricter rules, and ongoing maintenance; managed dedicated server hosting can reduce that operational burden. Use it only when the benefits are clear.

Dedicated servers make sense when you have:

• Sessions that must remain available without the original player host
• A public server with drop-in players
• Heavy mods that change mechanics or progression
• Long-running campaigns that rely on persistent saves

Dedicated servers may be unnecessary when you have:

• Small private groups that do not need always-online persistence
• Short vanilla sessions
• Casual play that starts and stops often

If you need host-independent availability, server-side control, and repeatable maintenance, consider a dedicated-server process.If you only need casual sessions where the host is always present, peer hosting is usually simpler.

Barotrauma Dedicated Server Setup: The Fast, Correct Way

To host a Barotrauma dedicated server, install Steam App 1026340 with SteamCMD, launch DedicatedServer.exe on Windows or ./DedicatedServer on Linux, and allow UDP 27015 and 27016.

Run the server once to generate serversettings.xml, stop it before editing, test a vanilla connection with Direct Join, and back up the campaign before adding mods.

Step 1: Install the Dedicated Server Correctly

Use either the standalone Barotrauma Dedicated Server tool or the DedicatedServer executable included with a current Barotrauma installation.

Recommended path:

• SteamCMD using the Barotrauma dedicated server app ID
• Barotrauma Dedicated Server from Steam’s Tools section for local setups

Keep an independent SteamCMD directory for a 24/7 host when you need separate updates, and keep the server, clients, and enabled mods on compatible versions.

SteamCMD makes installation, validation, and scripted updates repeatable; a process supervisor still handles restarts.

Step 2: Generate and Configure the Core Files

Set core configuration before the first public test, and restart the server after later config changes.

Primary files that matter:

• serversettings.xml for server name, password, visibility, ports, game mode, vote settings, and player limits
• Campaign mode selection matters for persistence
• Backups and clean shutdowns reduce data loss more reliably than auto-restart settings

Long campaigns rely on the correct multiplayer save pair, compatible content packages, clean shutdowns, and tested backups.

Do not enable content mods or third-party LuaCs mods until the vanilla server passes its connection tests.

Step 3: Open Ports at Every Layer

Network configuration is a common source of public connection and listing failures.

Default ports:

• 27015 UDP for gameplay
• 27016 UDP for Steam query and browser visibility

UDP 27015 is required for default gameplay connections; UDP 27016 handles the default query and browser-listing path.

Check both layers:

• Router or provider firewall
• OS firewall on the server

Avoid overlapping UPnP and manual mappings for the same ports. Explicit forwarding is generally more predictable for a permanent home-hosted server.

Step 4: First Boot Must Be Vanilla

Start the server with:

• No mods
• No third-party LuaCs or C# mods
• Default permissions

Verify three things:

• Server appears in the Steam server browser
• Players can join using IP and port
• Saves persist after restart

If the server does not appear:

• Check the Steam browser directly
• Use Barotrauma’s Direct Join option with IP:27015 or your configured game port
• Review console output and the ServerLogs directory; check servercrashreport.log after a fatal crash

Do not move forward until vanilla works.

Step 5: Add Mods Carefully and Incrementally

Mod changes are a common source of version, load-order, and campaign-compatibility problems.

Safe workflow:

• Subscribe to mods on a Barotrauma client first, then copy the installed mod folders to the server
• Place mod folders in the correct server directory
• Enable content packages in config_player.xml
• Control load order to prevent conflicts

Important warnings:

• Some mods are client-only
• Some mods can make an existing campaign incompatible when added mid-campaign
• Changing load order can make an existing campaign incompatible

Add one change at a time. Restart and test after each step

Installation Paths: Choose the Right One for Your Use Case

Choose an install method that matches how you plan to update, supervise, and back up the server.

Option 1: Windows Dedicated Server (Local or VPS)

This option uses the graphical Steam client and familiar Windows administration tools.

When This Option Makes Sense

• Local hosting on your own PC
• Windows-based VPS
• Testing, learning, or small private crews

Where The Server Comes from

• Steam Library
• Switch filter to Tools
• Install Barotrauma Dedicated Server

The Steam Tools entry is a separate installation, although the normal Barotrauma installation also includes a supported DedicatedServer.exe.

Files That Matter

• serversettings.xml for name, password, visibility, ports, game mode, vote settings, and player limits
• Current Windows multiplayer saves default to %LocalAppData%\Daedalic Entertainment GmbH\Barotrauma\Multiplayer; Data/Saves/Multiplayer is a legacy location

Pros

• Simplest setup
• Fewer dependency issues
• Clear console output

Cons

• Windows licensing and update-management overhead may matter on a rented host
• Inbound UDP traffic may remain blocked until Windows Defender Firewall rules are added

Critical Requirements

• Add inbound UDP rules for 27015 and 27016 using Windows Firewall with Advanced Security
• Allow UDP 27015 and UDP 27016
• Verify server browser visibility after launch

Common Beginner Mistakes

• Letting the built-in server and standalone server drift onto different versions
• Editing generated configs while the server is running or failing to restart after changes
• Adding mods before vanilla validation

Option 2: SteamCMD Dedicated Server

SteamCMD is a practical option for independent installs, validation, and scripted updates on an always-online host.

Why Use SteamCMD

• Supports anonymous installation of App ID 1026340
• Clean headless operation
• Supports repeatable scripted updates and file validation

Where to Get SteamCMD

• Valve’s official SteamCMD documentation

Barotrauma Dedicated Server App ID

• 1026340

Install Structure

• SteamCMD creates a clean server directory
• Linux multiplayer saves default to ~/.local/share/Daedalic Entertainment GmbH/Barotrauma/Multiplayer; Windows uses %LocalAppData%\Daedalic Entertainment GmbH\Barotrauma\Multiplayer

Install Command Structure

./steamcmd.sh \
  +force_install_dir /opt/barotrauma \
  +login anonymous \
  +app_update 1026340 validate \
  +quit

Update Workflow

• End the active round and stop the server
• Back up saves, configuration, permissions, and the current mod manifest
• Run app_update 1026340 validate
• Restart and verify the version, Direct Join, campaign load, mods, and admin access

This is a reliable install path for many long-term Barotrauma dedicated servers because it keeps updates and validation repeatable.

Option 3: Linux Dedicated Server

The 64-bit Linux dedicated server is supported, and Ubuntu 24.04 works without the older OpenSSL workaround described for some previous releases.

Common Ubuntu Versions

• Ubuntu 24.04

Common Linux Startup Checks

• Distribution-specific dependency or shared-library errors
• Incorrect working directory
• Missing execute permissions or incorrect file ownership
• Missing or misplaced steamclient.so when Steam initialization fails

OpenSSL Compatibility Reality

Ubuntu 24.04 works without the older OpenSSL workaround according to the current hosting guidance. Install compatibility packages only when a specific startup error and current distribution documentation require them.

Directory Path Requirement

• The server must run from its install directory
• Use absolute paths in scripts
• Relative paths can resolve against the wrong working directory in scripts or services

Executable Permission

chmod +x DedicatedServer

Persistent Session Requirement

Use screen, tmux, LinuxGSM, or a process supervisor if the server must continue after an SSH session closes.

screen -S barotrauma ./DedicatedServer

or tmux if preferred.

Confirm Server started, test from an external network, and review saved logs before treating the Linux service as healthy. For host-level firewall configuration, follow Ubuntu’s official UFW documentation.

Core Configuration That Actually Matters (serversettings.xml Explained)

serversettings.xml controls identity, ports, visibility, authentication, player limits, tick rate, and other runtime options. A process can start locally even when a firewall, NAT rule, or listing setting prevents public access.

Server Visibility (Why Your Server Doesn’t Show)

Visibility depends on correct identity, ports, and Steam registration.

Key Settings:

• Set ServerName to a recognizable name
• Set IsPublic="True" for public discovery
• Set Port="27015" for the default gameplay port
• Set QueryPort="27016" for the default query port

What Matters:

• The query port in serversettings.xml must match the port opened in your firewall
• The default query port is 27016 when the game port is 27015
  • Game port: 27015
  • Query port: 27016

Common Misunderstandings:

• Visibility is not locked by state files
• The Steam server browser caches results

If you change visibility or ports:

• Restart the server
• Allow time for the listing to refresh, then recheck the browser and Direct Join

How to Verify Visibility:

• Check Steam server browser directly
• Test direct connect with IP:27015
• Review logs for Steam registration messages

Password (Private vs Public Control)

Passwords control access behavior, not just privacy.

Examples:

<serversettings password="" /> <!-- No password -->
<serversettings password="replace-with-a-strong-password" /> <!-- Password protected -->

What Matters:

• Empty password means players can join without a password
• Any password value requires players to enter that password, while IsPublic controls browser visibility

Changes require a restart. Do not rely on hot reload.

Max Players (Stability Control)

Player limits directly affect stability.

Example:

<serversettings MaxPlayers="8" />

Guidelines:

These are editorial starting points, not official requirements:

Why This Matters:

• Higher player counts increase network events
• CPU contention, packet loss, or mod load can contribute to lag and desynchronization
• An interrupted disk write can leave the newest save unusable, so keep versioned backups

If the server cannot maintain stable simulation under the tested player, bot, submarine, and mod load, reduce the workload or use faster CPU resources.

Ports, Visibility & “Why My Server Doesn’t Show”

A server can start locally yet remain absent from public discovery or unreachable from the Internet. Check the configured ports, IsPublic, firewall rules, NAT, public addressing, and game version separately.

Default Game and Query Ports

Barotrauma’s default dedicated-server configuration uses two UDP ports for different functions.

• Game Port (Default 27015)

Used for player connectionsOpen UDP

• Query Port (Default 27016)

Used for Steam server browser listingOpen UDPDefault is 27016 when the game port is 27015

If the query port fails, the server can run fine and still never show.

Why the Query Port Gets Missed

A server may accept gameplay traffic on UDP 27015 while remaining undiscoverable if UDP 27016, QueryPort, or IsPublic is misconfigured.

Common Causes:

• Query port not opened in the firewall
• Query port opened, but not set in serversettings.xml
• UDP blocked at router, OS firewall, or provider firewall

Typical Symptoms:

• Works locally
• Friends cannot find it
• Join attempts fail or time out

UPnP vs Manual Port Forwarding

UPnP can create mappings automatically when the router and network permit it, but explicit forwarding is easier to audit on a permanent host.

• UPnP can map different ports after restarts
• UPnP can conflict with manual forwarding rules
• Steam listing is more reliable when the game and query ports stay fixed

Best practice for dedicated servers:

• Disable UPnP
• Forward ports manually
• Keep ports fixed across restarts

After creating manual rules, verify them from a device outside the local network.

CGNAT: When Normal IPv4 Port Forwarding Will Not Work

If your ISP places the connection behind carrier-grade NAT, normal inbound IPv4 forwarding on your router cannot create a public route to the server.

Signs you are behind CGNAT:

• Port forwarding rules look correct
• Firewalls look correct
• The server works on the LAN
• The server never becomes reachable publicly

Fast Check:

curl ifconfig.me

Compare the result with your router’s WAN address. A mismatch can indicate CGNAT, double NAT, a VPN, or another upstream translation layer, so confirm with your ISP.

Fix Options:

• Use a VPS
• Request a public IPv4 from your ISP
• If your ISP supports it, try IPv6 (not every client setup will behave the same)

Do not keep debugging ports for hours if CGNAT is the real issue.

How to Verify in the Right Order

Local Check

• Start the server
• Join using localhost or LAN IP
• Restart once and confirm saves still load

Public Connectivity Check

• Try direct connect using PublicIP:27015
• If this fails, check the public IP, UDP 27015, firewalls, NAT or CGNAT, server version, and authentication logs

Browser Listing Check

• Search in Steam server browser
• Allow time for registration, refresh the listing, and compare the result with Direct Join
• If Direct Join works but listing fails, check IsPublic, QueryPort, UDP 27016, registration messages, and browser filters.

Admins, Permissions & Moderation

Admin commands can fail when the connected account does not match the stored ID, the role lacks a required permission, a command was not granted, or a manually edited permissions file is invalid.

How the Permission Model Actually Works

Barotrauma permissions are tied to player IDs in clientpermissions.xml. Use the same ID format shown in the generated permissions file.

The model is strict:

• The player ID identifies the player
• Permissions are mapped to that player ID
• Commands work only if the player ID and permissions match

If the player ID is wrong, the admin entry will not match the player. The server may not warn you clearly.

Getting the Correct Player ID Format (This Matters)

Check the generated clientpermissions.xml file and use the same player ID format it expects. Copy the authenticated account ID exactly as the current server reports it; Steam and Epic/EOS identities can use different representations.

Correct ways to get it:

• Steam profile or player lookup
  • Use the player’s Steam profile or lookup tools to find the right ID, then convert it only if your permissions file requires that format.
• In-game console
  • Use the in-game or server console to list connected players and IDs when available

clientpermissions.xml: The Control File

This file controls admin and moderator permissions for players listed in the permissions file.

File location

The standard file is Data/clientpermissions.xml under the active dedicated-server installation.

If the file is missing or empty, the server may create a default permissions file, but no custom admin access exists until a valid player entry is added.

Structure

<?xml version="1.0" encoding="utf-8"?>
<ClientPermissions>
<Client accountid="STEAM_1:1:12345678" name="Owner" permissions="All" />
<Client accountid="STEAM_1:1:87654321" name="Moderator"
          permissions="Kick, Ban, ManageRound" />
</ClientPermissions>

Changes require a server restart. Where possible, use giverank, giveperm, and showperm, then use help <command> to confirm current syntax before editing XML manually.

Console Access vs Command Permissions

These are separate concepts.

• In-Game Console Access
  • Players can open the client console, but commands run only when the server grants the required authority
  • Console visibility does not grant admin permissions
• Command Permissions
  • Decide which admin commands actually run
  • Defined in clientpermissions.xml

A player can open the console and still have commands fail. This happens when their player ID lacks the required permission flags. Server-side console access still implies full control. Do not share it.

Permission Flags That Actually Matter

Common Flags:

• All — Full admin
• Kick — Remove players
• Ban — Ban players
• ManageRound — Start and end rounds
• SelectSub — Choose submarines
• ManageCampaign — Campaign control
• ConsoleCommands — Run admin console commands

Best-Practice Permission Strategy

Use minimal access.

• One owner with full control
• Admins only when needed
• Moderators with limited scope
• Never share server console access, unrestricted admin files, or credentials
• Avoid blanket permissions unless the player truly needs full admin access

This approach reduces abuse, mistakes, and server damage.

This is a safer way to manage Barotrauma dedicated server admin roles and control Barotrauma dedicated server commands with fewer permission mistakes.

Barotrauma Dedicated Server Mods: What Actually Works

Mods can block joins, cause download loops, or make a campaign incompatible when the server and clients do not resolve the same enabled content packages. Test the exact package versions, dependencies, and order before using the pack with a long-running campaign.

Why Mods Are Harder on Dedicated Servers

Dedicated servers load the content packages configured for the server process.Compatibility requirements:

• Clients must match the server’s enabled package versions before joining
• Preserve the package order from a tested client configuration
• Client-only mods should not be added to the server’s required package list
• Some mods add persistent content or state that an existing campaign may depend on

A package mismatch may reject or stall a client even when the server process remains online; other mod faults can also destabilize the process.

A Reliable Workflow for Dedicated Server Mods

This is the safest practical workflow for managing Barotrauma dedicated server mods.

Step 1: Subscribe Locally

• Subscribe to mods on a client machine
• Let Steam download all dependencies

Installed Barotrauma Mod Paths

Windows

%LocalAppData%\Daedalic Entertainment GmbH\Barotrauma\WorkshopMods\Installed

Linux

~/.local/share/Daedalic Entertainment GmbH/Barotrauma/WorkshopMods/Installed/

Step 2: Copy Mod Folders

• Copy the entire mod folder
• Preserve folder structure
• Copy the folder to a server-side mod directory, such as [server root]/LocalMods/WORKSHOP_ID/, and use that same path in config_player.xml

Do not copy partial files. Only rename folders if the server config path requires a corrected mod folder name.

Step 3: Enable Content Packages

Mods are enabled through configuration, not the UI.

Example configuration:

<contentpackages>
<corepackage path="Content/ContentPackages/Vanilla.xml" />
<regularpackages>
<package path="LocalMods/WORKSHOP_ID/filelist.xml" />
</regularpackages>
</contentpackages>

Load order matters:

• Preserve the order from a tested client configuration
• Follow each mod author’s dependency and compatibility instructions
• Retest the pack after any package update or reorder

Restart the server after every change.

Why SteamCMD Mod Downloads Are Painful

SteamCMD can download Workshop items, but dedicated server mod handling can be more manual than client-based installs.

You can run:

workshop_download_item 602960 WORKSHOP_ID

SteamCMD does not automatically build a complete, tested Barotrauma package order. Record each Workshop ID, verify dependencies, and confirm the resulting config_player.xml paths before launch.

This is why many admins download mods through a client, then copy the installed mod folders to the server. It is slower, but easier to verify.

Add Mods One at a Time

When building or diagnosing a pack, add and test one change at a time.

Correct Process:

• Add one mod
• Restart the server
• Join and test
• Check logs
• Repeat

If something breaks, you know exactly which mod caused it.

How Client Auto-Download Actually Works

Clients must match the server’s enabled content packages.

Process:

1. Server sends the required content package list
2. Client checks installed content and Workshop availability
3. Missing content may need to download through Steam Workshop or from the server, depending on settings and availability
4. Join completes once enabled content packages, versions, and load order match

If players are stuck at “downloading content,” possible causes include:

• Mod is private, delisted, or deleted
• Content package path or Workshop reference is wrong
• Steam Workshop access is broken

Back up the campaign and previous mod manifest before adding or removing anything mid-campaign.

Higher-risk changes include:

• Mods that add persistent items, creatures, or progression data
• Submarine and balance overhauls
• Changes to required package order

Lower-risk changes still require testing and include client-only visuals, third-party LuaCs scripts that do not persist campaign state, and mods explicitly documented as save-compatible.

Third-Party LuaCs Mods on Barotrauma Dedicated Servers

Vanilla Barotrauma does not include a Lua runtime. Lua support comes from the third-party LuaCsForBarotrauma mod loader and compatible Lua or C# mods.

Server-side scripts can react to game events, add moderation tools, and modify gameplay through the loader’s exposed APIs. Their capabilities and risks depend on the loader version and each mod’s implementation.

Before using LuaCs mods in a campaign:

• Match the loader, server, client, and mod versions.
• Test the exact pack on a non-production campaign.
• Avoid unknown scripts and unrestricted admin hooks.
• Monitor repeated stack traces, simulation stalls, and sustained memory growth.
• Keep a pre-change campaign backup and mod manifest.

Saves, Persistence & Backups

Campaign recovery depends on knowing the active save location, backing up the complete save pair, and preserving the compatible game and mod state.

Where Barotrauma Server Saves Live

Your server saves live on the server, not the client.

Common Locations:

Windows

%LocalAppData%\Daedalic Entertainment GmbH\Barotrauma\Multiplayer

Linux

~/.local/share/Daedalic Entertainment GmbH/Barotrauma/Multiplayer

A multiplayer campaign uses a .save file and its associated _CharacterData.xml file; back up and restore both together.

If the active save directory is lost without backups, the campaign can be lost.

Data/Saves/Multiplayer is a legacy location, so check it only when migrating an older installation.

Why Saves Corrupt or Reset

Save loss or load failure can have several causes. Possible contributors:

• Server crash during autosave
• Mod added or removed mid-campaign
• Load order changes
• Disk write failure
• Forced shutdown or power loss

After a crash, forced shutdown, update, or mod change, verify the campaign loads before deleting the previous backup.

Backup Strategy That Actually Works

Backups must be boring and frequent.

Always Back Up:

• Before server updates
• Before mod changes
• Before Lua changes
• Before long sessions

Manual Backups

• Stop the server
• Copy the target campaign’s .save and matching _CharacterData.xml, plus the configuration and mod manifest needed to reproduce the server
• Store it outside the server path

Automated Backups

• Use scheduled jobs or scripts
• Back up daily or before restarts
• Keep off-host backup storage because the game maintains only three local save-backup slots

Automation saves time. Manual backups before risky changes prevent the worst recovery problems.

Restore Best Practices

Restoring the wrong files can cause more damage.

Process:

• Stop the server
• Restore the target .save and matching _CharacterData.xml from the same backup set
• Match the exact mod set and load order
• Start the server once and verify

Never Restore:

• Only one file from a campaign’s .save and _CharacterData.xml pair
• Saves from a different mod setup
• Files copied while the server was running

If the save does not load, stop. Do not keep restarting.

Docker & Containerized Barotrauma Servers

Docker deployments are possible through community images or custom containers, but Barotrauma does not publish an official Docker image. Treat the container definition, persistent volumes, update behavior, and support policy as third-party components.

When Docker Makes Sense

Docker is useful when you need:

• Repeatable deployments across machines
• Fast rebuilds after failure
• Infrastructure-as-code workflows
• Clean separation between host and game files

It fits CI-style environments and experienced VPS setups.

Community-Maintained, Not Official

Barotrauma does not ship an official Docker image, so Docker setups rely on community-maintained images or custom containers.

Reality Check:

• Images are community-built
• Quality varies
• Updates can lag behind game releases
• Debugging is on you

If something breaks in a community image, support depends on that image maintainer or your own troubleshooting.

Pros and Cons of Docker

Pros

• Clean, reproducible environment
• Repeatable image versions when tags are pinned and persistent data is backed up separately
• Simple redeploys after crashes

Cons

• Extra abstraction hides problems
• Harder to debug mods and saves
• SteamCMD downloads and Workshop metadata require separate validation
• Incorrect mounts or ownership can make persistent saves and mods unavailable to the container

Docker trades simplicity for control.

Mod Persistence Challenges

Mods are the main pain point.

Common Failures:

• Mods lost on container rebuild
• Incorrect volume mounts
• Broken load order after updates

Rules You Must Follow:

• Mount the server’s LocalMods directory, or the exact mod directory referenced by config_player.xml, as a persistent volume
• Mount the save directory explicitly using a persistent Docker volume
• Never rely on container filesystem for data

If a save volume is missing or mounted at the wrong path, the container may start with an empty data directory; correct the mount before creating or overwriting campaign data.

Security Baseline

• Run the server as an unprivileged account, not root or Windows Administrator.
• Keep RequireAuthentication="True" on Internet-facing servers.
• Use a strong password for private communities; IsPublic="False" is not access control.
• Keep EnableDoSProtection="True" and expose only the required UDP ports.
• Grant admins the minimum required permissions and keep off-host backups.

Troubleshooting Matrix

Use this troubleshooting matrix when the server runs but players cannot join, mods fail, admins lose access, or saves stop loading.

Build a Barotrauma Server That Stays Reliable

A reliable Barotrauma dedicated server comes from disciplined setup, not one magic setting. Install the correct server application, align UDP 27015 and 27016 across every network layer, validate a vanilla connection, and introduce mods gradually.

Keep permissions controlled, review logs after failures, and back up the complete campaign save pair before updates or configuration changes.

Once the software is configured correctly, dependable infrastructure helps keep campaigns responsive and consistently available.

Fast CPU performance, stable low-jitter networking, reliable storage, and predictable resources matter most as player counts and mod workloads increase.

RedSwitches provides dedicated server infrastructure with full control, global deployment options, DDoS protection, and expert support for long-running multiplayer workloads.

Combined with the practices in this guide, it gives your crew a stronger foundation for campaigns that remain stable, recoverable, and ready for the next dive.