Subnautica Dedicated Server Setup (2026): Nitrox 1.8.1 Guide

The original Subnautica has no official dedicated-server software. PC players can host a shared world using Nitrox, an unofficial multiplayer mod with a separate server process. It uses UDP port 11000 by default, and its developers recommend around five total players. Players can leave while the server remains available, provided the hosting machine stays running and reachable.

Getting there takes more than launching Nitrox: compatible versions, correct network settings, and recoverable saves all matter. This guide covers Windows setup, a Linux launch example, joining instructions, backups, and practical checks when friends cannot connect.

Subnautica Dedicated Server Quick Facts

What “Subnautica Dedicated Server” Means

Original Subnautica has no official dedicated-server package. PC players use Nitrox, an unofficial multiplayer mod with separate server and client components.

The Nitrox server stores persistent world data and coordinates supported synchronization. Each player runs a compatible Nitrox client to connect, explore, and build together. Some simulation remains client-dependent. A server password restricts access to people who know it.

The hosting machine and server must stay running and reachable, but individual players can close their games. When the last player disconnects, Nitrox saves the world and pauses its game clock and autosave timer until someone returns.

Nitrox recommends around five total players. Its advertised 100 slots are not a performance benchmark. The mod remains in alpha, with some game systems unsynchronized or nonworking, so plan for small-group co-op and realistic multiplayer limitations.

Nitrox Compatibility and Version Checklist

Version mismatches can cause compatibility warnings, failed connections, or inconsistent behavior. Once the server starts successfully, check these requirements before changing firewall or port-forwarding settings.

Subnautica Server Hosting Options

Nitrox runs a separate server process, which you can host on a home PC, a VPS, or dedicated physical hardware. Choose according to your group’s access needs, measured resource usage, and ability to maintain the server.

A small Nitrox group does not automatically need dedicated hardware. Start with a suitable host, measure its performance, and upgrade when a confirmed limitation justifies it. Hosting changes can address infrastructure constraints, but they do not remove Nitrox’s synchronization bugs.

Nitrox Server Hardware Guidance

Nitrox does not publish official CPU or RAM requirements. Start with a modern system that has sufficient free memory, reliable SSD storage, and stable networking, then monitor actual CPU and memory usage before upgrading.

Resources To Monitor

• CPU And Resource Consistency
  • Use a modern CPU that can provide reliable sustained performance alongside the operating system and other hosted services.
  • Small Nitrox groups may not need a large core count, so monitor actual CPU usage before upgrading.
  • Compare gaming dedicated server infrastructure against your measured workload when considering single-tenant hardware.
• RAM Headroom
  • Provide enough RAM for the operating system, Nitrox, active world state, and other running services.
  • If the host exhausts available memory, operating-system paging can reduce overall responsiveness.
  • Monitor memory usage during real sessions rather than estimating requirements from save-file size alone.
• Storage Guidance
  • Use reliable SSD storage for server files, logs, and backups.
  • NVMe may benefit a host running several storage-heavy services, but it is not a published Nitrox requirement.
  • Monitor storage activity before paying for a higher storage tier.

Networking: Ports, Firewall, And Subnautica Port Forwarding

Many Nitrox connection problems involve one of these three areas:

• You opened the wrong port or the wrong protocol.
• Windows Firewall blocked the server process.
• Your internet setup does not allow inbound traffic (CGNAT or strict ISP rules).

Confirm server startup and compatible versions first, then diagnose the connection route that fails.

The One Port You Must Get Right

Nitrox uses a single default port for gameplay traffic.

• Protocol: UDP
• Default Port: 11000

Keep it simple:

• Do not change the port unless you have a reason.
• If you run multiple servers on the same machine, give each server a unique port and write it down.

What changes when you host on a provider vs at home:

• At Home
  • Your router sits between your friends and your PC.
  • For direct inbound public IPv4 hosting, configure the required router mapping unless a verified automatic mapping or another supported route already handles it.
  • Your ISP may block inbound connections even if you forward correctly.
• On A Hosted Server
  • The server has a public IP on the internet.
  • Permit the configured UDP port in every applicable host firewall, provider firewall, security group, and provider NAT mapping.
  • You usually skip router problems completely.

Remote hosting removes home-router port forwarding, while home hosting avoids hosting fees but requires a suitable network configuration.

Firewall Checklist (Windows Host Or Windows Server)

Do this before port forwarding. A forwarded port does nothing if Windows drops the traffic.

Your goal: allow inbound UDP traffic to the Nitrox server process on port 11000.

Use this checklist:

• Allow The Nitrox Server Process
  • When you first start the server, Windows may ask for firewall permission.
  • Apply the inbound rule to the Windows network profile currently active on the host. Do not enable every profile automatically.
  • If the prompt never appears, create a manual inbound rule.
• Create An Inbound Rule For UDP 11000
  • Open Windows Defender Firewall with Advanced Security and follow Microsoft’s guidance on Windows Firewall rules.
  • Create a new inbound rule:
    • Type: Port
    • Protocol: UDP
    • Port: 11000
    • Action: Allow
  • Apply the rule to the network profile you use.
• Private vs Public Network Profiles
  • Private profiles usually match home networks.
  • Public profile often matches:
    • Coffee shop Wi-Fi
    • Mobile hotspots
    • Unknown networks
  • If your Windows network is set to Public at home, your Private-only rule will not work.
• Do Not Forget Subnautica
  • The Nitrox server process handles hosting, but the Subnautica client may also require a firewall exception.
  • If you see inconsistent behavior, allow the Subnautica executable too.
  • Scope the server’s inbound rule to its configured UDP port; client outbound traffic targets that port but may use a different local source port.

Quick rule: if local join works but friends cannot join, firewall and NAT are your first suspects.

Subnautica Port Forwarding (Home Hosting)

Port forwarding sounds scary. It is just one mapping:

Internet → Router → Your Host PC

1) Give Your Host PC A Static LAN IP

Do not forward to a device that changes IP every reboot.

• Set a DHCP reservation in your router for your host PC, or
• Manually set a static IPv4 address on the PC

You want the host PC to always stay something like 192.168.1.50.

2) Create The Router Forward Rule

Create a port forward entry:

• Name: Nitrox / Subnautica
• Protocol: UDP
• External Port: 11000
• Internal IP: your host PC LAN IP
• Internal Port: 11000

Save it. Restart your router if it behaves strangely.

3) Watch For CGNAT (This Breaks “Perfect” Port Forwarding)

CGNAT means your ISP does not give you a true public IPv4 address. Your router sits behind the ISP’s router layer. You can forward ports locally and still be unreachable from the internet.

Signs you might be behind CGNAT:

• Your router’s WAN address is in 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, or 192.168.0.0/16, or it differs from the public address reported by an external IP-checking service.
• Friends cannot connect even though:
  • Firewall rules are correct
  • Forwarding is correct
• Generic UDP probes can report “closed” when the application does not answer the probe; this result alone does not establish CGNAT.

What you can do:

• Request a public IPv4 address for ISP-level CGNAT. Use bridge mode only when double NAT is caused by networking equipment inside your premises.
• Use a private overlay that every player joins, or a tunnel provider that explicitly forwards the required UDP endpoint; an ordinary consumer VPN may not provide inbound access.
• Move hosting to a server with a real public IP.

4) Dynamic IP Reality (What To Tell Friends)

Many home connections change public IP over time.

Give your friends a simple rule:

• “If you cannot join and nothing changed, ask me for the new IP.”

If you want fewer interruptions:

• Use a dynamic DNS hostname, or
• Use a remotely hosted server with a stable public IP.

Testing Method That Catches Real Failures

Do not trust “it works on my Wi-Fi” tests. That proves nothing about internet reachability.

Localhost Test on the Hosting PC

• Start the Nitrox server.
• Join from the host PC using 127.0.0.1 and port 11000.
• If this fails, you have a local setup issue, not a router issue.

Next, test from another PC on the same LAN using the server machine’s private LAN IP and configured port. Confirm compatible versions on both machines. This tests the local network path and host firewall separately from localhost and internet access.

Phone Hotspot Test (Best Quick Reality Check)

This test checks whether a real Nitrox client can reach the server from an external network.

• Start the server on your home network.
• Disconnect a laptop or second PC from Wi-Fi.
• Connect that device to your phone hotspot.
• Join using your home public IP and port 11000.

If the hotspot connection works, basic external reachability is confirmed for that test.

Friend Test (The Final Proof)

Ask one friend to test before game night.

• Send them:
  • Your public IP
  • Port 11000
  • Password (if set)
  • A reminder to match versions

If one friend can join, the server is externally reachable. If another player cannot join, check that player’s server address, Subnautica build, Nitrox version, firewall, and network restrictions.

“Friends Can’t Join” Fixes

Windows Setup (Self-Hosted Or Windows Server)

This section is the clean “do it once, do it right” path. Most people break setup by mixing folders, running without permissions, or letting versions drift.

Pre-Flight Checklist

Before you install anything, check these:

• Game Install Exists
  • Install Subnautica on the machine that will host the Nitrox server.
  • If you are renting the host, review Windows dedicated server hosting and confirm Windows licensing and management responsibilities.
  • Confirm the server can read the compatible Subnautica installation; separately test normal game launch on each PC that will play.
• Nitrox Folder Placement Rules
  • Extract Nitrox from the ZIP archive into a writable folder. A separate folder such as C:\Nitrox\ is easier to maintain, but it is an organizational recommendation rather than a documented compatibility requirement.
  • Avoid protected or read-only folders. A simple path such as C:\Nitrox\ can make permissions and backups easier to manage.
• Admin Rights And Permissions
  • Run Nitrox as Administrator if you hit path or write errors.
  • Ensure the server account can read the application and game files and write to the actual Nitrox data and save directories. The server needs to generate configs and save data.

Skipping these checks can cause path or write errors that appear to be Nitrox problems but are actually caused by Windows permissions.

Install Nitrox The Clean Way

Follow this exact flow:

Download and Extract

• Download the Nitrox release.
• Extract the zip to a dedicated folder like C:\NitroxServer\.

Set Game Path in the Launcher

• Open the Nitrox launcher.
• Go to options.
• Select the Subnautica installation folder in the launcher’s options; do not select the executable file.

First Run That Generates Server Files

• Start the server once.
• Let it create its default config and folders.
• Stop it cleanly after the first run.

That first run matters. It creates the baseline structure you will edit later.

Start The Server And Create The Baseline Config

Now build the “stable default” server. Set these at minimum:

• Server Name
  • Use a recognizable world/save name and client-side server label; these are separate from the server.cfg properties.
• Password
  • Use a password for private co-op.
  • Public servers invite random joins and random problems.
• Admin Password
  • Set it and store it somewhere safe.
  • Do not share it casually.
• Port
  • Leave it at 11000 unless you have a conflict.
  • If you change it, you must update:
    • Firewall rule
    • Router forward
    • Every client’s server entry

Save Location Awareness:

Know where the server saves live.

Without an explicit override, Nitrox data normally resolves under %APPDATA%\Nitrox on Windows or the user’s .config/Nitrox directory on Linux. Saves normally sit beneath the data directory’s saves folder, with server.cfg inside the selected world folder. An absolute --data-path or a SavesFolderDir override can change these locations, so verify the active paths before backing up.

Nitrox 1.8.1.0 supports the --data-path argument for choosing where logs, cache, saves, and related server data are stored. The --game-path argument points Nitrox to the Subnautica installation, and the SUBNAUTICA_INSTALLATION_PATH environment variable can assist game-path detection. Review the selected world’s server.cfg and actual data/save paths before automating backups; Linux path settings use nitrox.cfg, while Windows uses registry-backed settings.

Backups depend on it.

If you cannot find the save directory, you cannot recover from corruption fast.

First Join Test (Local First, Then Remote)

Do not start inviting friends until you pass both tests.

Local Join Steps (Proves server runs)

• Start the server.
• Start Subnautica through Nitrox on the host PC.
• Add server:
  • Host: 127.0.0.1
  • Port: 11000
• Join.
• Confirm you can move, interact, and save.

If local join fails:

• Recheck game path
• Recheck permissions
• Recheck version match

Remote Join Steps (Proves internet access)

• Keep the server running.
• Confirm firewall rules.
• Confirm UDP 11000 forwarding if hosting at home.
• Ask one friend to join using:
  • your public IP
  • port 11000

What to check if local works but remote fails:

• Windows network profile changed to Public
• Inbound firewall rule missing for UDP 11000
• Router forward points to the wrong LAN IP
• Upstream CGNAT lacks the required inbound mapping, or separate ISP filtering blocks traffic

Fix those before you touch anything else.

Hosted Deployment (Always-On Nitrox Server)

Hosting on a remote server removes home-router port forwarding and provides a stable place to run the Nitrox process, backups, and maintenance tasks.

What Changes When You Host On A Provider

You gain:

• No home NAT drama
  • No port forwarding roulette every time the router resets.
• Availability independent of your playing PC
  • Your server stays online when your PC is off.
• Cleaner network paths
  • Your friends connect to one public IP that does not change every week.

You still must manage:

• Updates
• Backups
• Restarts

Remote hosting removes home-router forwarding from the server’s inbound path; provider rules, client restrictions, and maintenance still matter.

A Clean Server Layout

Keep your server organized from day one. It saves you during restores.

The following is an example administrator-created layout, not the default Nitrox directory structure:

• /NitroxServer/
  • server application files; the selected world’s server.cfg remains with its persistent world data
• /Saves/
  • save files and world state
• /Backups/
  • dated backup archives
• /Logs/
  • server logs for troubleshooting

Rules that prevent pain:

• Never store backups in the same folder as the live save only.
• Keep backups in a separate path, and ideally off-machine too.

Running Nitrox As A Service

If you want “always-on,” you need automatic startup and clean shutdown behavior. If you need help administering the host, consider managed dedicated servers and confirm whether the service scope includes your required Nitrox application tasks.

Automatic start on reboot:

• Configure the server so it launches when the machine restarts.
• Successful automatic startup reduces the time Nitrox remains offline after a reboot; it does not remove downtime during maintenance or a power interruption.

Clean stop/start procedure:

• Stop the server gracefully when possible.
• Do not kill the process unless it is stuck.
• A clean stop reduces the risk of interrupting an active save or file write.

Log Capture Basics:

• Keep logs enabled.
• Save logs with timestamps.
• Logs help you spot patterns:
  • Crash after updates
  • Errors during save writes
  • Connection spikes at certain times

Graceful shutdowns and tested backups reduce interrupted-write risk and provide a recovery path if world data is lost or damaged.

How To Join A Nitrox Subnautica Server

Joining is straightforward when players use the correct address, port, supported Subnautica build, and matching Nitrox release. Verify these details first when a connection fails.

How To Join From The Host PC

Use this method when the server runs on the same PC you play on.

• Open Subnautica through the Nitrox launcher.
• Go to the multiplayer/server list area.
• Add a server entry with:
  • Host: 127.0.0.1 (or localhost)
  • Port: 11000 (unless you changed it)
• Join and confirm the world loads.

If localhost join fails, you do not have an internet problem. You have a local setup problem. Fix game path, permissions, and version match first.

How To Join From The Internet

Use this method when friends join from outside your home network or you are hosting on a remote server.

Give your friends these details:

• Server IP
  • If you host at home: your public IP.
  • If you host on a provider: the server’s public IP.
• Port
  • Default: 11000.
  • If you changed it, everyone must match it.
• Password
  • Use one if it is a private server.

Basic privacy guidance that saves you headaches:

• Do not post your server IP publicly if you host at home.
• Use a password even for friends-only groups.
• If you must share in a public Discord, share it in DMs, not in a public channel.

Copy/Paste Join Info Card

Send this block to your group chat. It prevents back-and-forth.

Server Name: [Your Server Name]IP: [Public IP or Server IP]Port: 11000Password: [Your Password]Version Reminder: Everyone should run the same supported Subnautica build and Nitrox release.

Server Configuration And Admin Control

A stable Nitrox server starts with boring settings. Do not chase big numbers. Do not change ports every week. Do not hand admin rights to everyone “just in case.”

Core Server Settings

These settings decide how stable and manageable the server feels. Stop the server gracefully before editing the selected world’s server.cfg. Use these property names when configuring it:

• Server Name
  • Keep the selected world/save name and client-side server label recognizable; neither is a ServerName property in server.cfg.
• Password And Visibility
  • Set ServerPassword for a private group; its generated default is empty.
  • Public servers invite random joins, grief, and more support work.
  • If you want a clean co-op world, run private.
• Max Players
  • Set it to what you want to support, not what the config allows.
  • Around 5 players: the group size recommended by the Nitrox developers
  • Larger groups: possible, but experimental because current synchronization limitations still apply
  • Nitrox advertises 100 slots and defaults MaxConnections to 100, but this does not establish a hard cap or demonstrate reliable 100-player operation. Set the limit according to the group size you have tested.
• Port Changes
  • Avoid frequent port changes.
  • Every port change forces three updates:
    • Windows Firewall inbound rule
    • Router forwarding or provider firewall
    • Every client server entry
  • If you must change it, document it in your “join info card” and pin it in your server Discord.

Admin Access Rules

Admin access is power. Treat it like keys to your house.

• Admin Credential Handling
  • Use a strong admin password.
  • LocalhostIsAdmin defaults to True. If a proxy or tunnel makes remote players appear to connect from localhost, review this setting before exposing the service so those connections do not receive unintended administrative privileges.
  • Store it in one place you control.
  • Do not paste it into group chats.
• Who Gets Admin And Why
  • Give admin to one trusted person besides you, max.
  • Pick someone who:
    • Understands the version lock rule
    • Will not spawn items casually
    • Will restart the server properly
  • If everyone has admin, nobody respects ops discipline. That is how worlds get ruined.

Command Coverage (What You Actually Need)

Most groups only need a small set of actions. Keep your admin usage focused on stability and recovery. In the server console, use help to inspect available commands, save to request a world save, and stop to shut down gracefully. Confirm successful saving in the logs before maintenance.

Safe admin actions that help stability:

• Request save, verify successful completion in the log, then use stop before restarting; do not assume an autosave occurred while the server was empty or autosave was disabled.
• Restart the server if synchronization problems remain after the affected player reconnects and confirms matching versions.
• Kick a player who is stuck or bugged out, then let them rejoin cleanly.
• Use documented position-recovery commands only for a specific player-state problem after checking command help, permissions, and known issues.

Risky admin actions that damage the experience:

• Spawning items to “fix” every inconvenience.
• Using admin tools to skip progression.
• Teleporting and item spawning alter progression; use them deliberately and diagnose synchronization failures from logs.

Your goal is not to be a game master. Your goal is to keep the world stable and recoverable.

Operations Runbook

Most guides stop at “it runs.” That is not enough. A dedicated server is a routine. This runbook reduces avoidable outages and improves recovery when a failure occurs.

Backups That Actually Protect You

Backups must cover two things:

• Saves
  • Your world state.
  • Player data and progress.
• Config
  • The world’s server.cfg, passwords, port, admin settings, and launch information identifying the selected world and data path.

A backup that only grabs one of these is incomplete. Preserve the complete selected world folder, including its configuration and persisted player, world, entity, version, and global-root data.

Record the matching game build, Nitrox release, and path overrides. Autosave writes current state; it does not mean a separate backup archive is created every two minutes.

Backup rotation plan you can stick to:

• Daily Backups
  • Keep the last 7 days.
• Weekly Backups
  • Keep the last 4 weeks.
• If your group plays heavily, increase frequency.

Off-server copy rule (critical for hosted servers):

• Keep at least one copy outside the server machine.
• If the server disk fails or gets wiped, local-only backups die with it.

If you only do one thing from this guide, do this: keep backups off the machine that runs the server.

Restore Drill (Prove Your Backups Work)

Backups are not real until you restore one.

Run a restore drill the day you set up the server, following the principles in NIST’s backup and recovery guidance:

1. Stop the server cleanly.
2. Copy the current save folder to a safe place as a “just in case.”
3. Restore a backup into a test folder or staging location.
4. Start an isolated test instance with an explicit restored --data-path, the intended --save name, and a separate configured port; confirm the startup log identifies the restored world.
5. Join and confirm:
   • World loads
   • Base exists
   • Inventory and progress look correct
6. Stop the isolated test instance and resume the original live launch configuration; keep test writes separate and do not copy them over the preserved live data.

Decide when to restore vs keep troubleshooting:

• Restore when:
  • Persistent world data is confirmed missing or damaged after excluding the wrong world/data path and client synchronization problems
  • Saved player progress is confirmed missing after checking the selected world, save logs, and whether recent changes were written
  • Persistent missing or corrupted world data remains after version checks and a clean restart
• Keep troubleshooting when:
  • Join fails for one player only
  • Firewall or port issues are obvious
  • Version mismatch is the likely cause

Restore a backup only after confirming save corruption or missing persistent world data, and preserve the current files before replacing them.

Restart Policy

Nitrox does not publish an official restart interval. Restart after updates, crashes, or persistent synchronization issues that remain after players reconnect and confirm matching versions.

Restart triggers:

• A Subnautica or Nitrox update has completed
• The server has crashed or stopped unexpectedly
• Synchronization problems remain after affected players reconnect
• Players continue reporting stuck or missing objects after version checks

Always do a clean stop when possible. It reduces save issues.

Update Policy (Do Not Break Game Night)

Updates break multiplayer when they are not coordinated.

Scheduled Update window:

• Pick one day and time when you update.
• Do not update minutes before a planned session.

Client alignment rule:

• Update server and clients as one unit.
• If one player cannot update, delay the update.

Rollback Plan:

• Keep the last known-good combo written down:
  • Subnautica build
  • Nitrox release
• If an update causes connection problems, confirm that the server and clients use compatible versions, review the release notes, and restore only a backed-up combination confirmed to work with the save.

A slow, disciplined update policy beats “latest everything” every time

Performance And Desync Control

You cannot “tune” Nitrox into perfection. You can reduce the triggers that cause desync and you can recover fast when it appears.

Common Factors To Check

• Packet Loss And Jitter
  • Packet loss, jitter, and unstable upload can disrupt real-time synchronization between clients and the server.
  • A wired connection can remove Wi-Fi as one possible source of packet loss and jitter.

Fix Flow That Works

Use the same flow every time. Do not improvise.

1. Ask the affected player to reconnect.
2. If the issue persists, confirm compatible versions and review logs and current Nitrox known issues before restarting.
3. If those checks do not explain the symptom, save and restart gracefully when appropriate; if the problem persists, document the logs and compare it with the release’s known limitations. Preserve current files and restore only for a confirmed persistent data-recovery need.

This flow keeps you calm and prevents “we tried random stuff for 2 hours.”

Subnautica Dedicated Server Linux (Advanced)

Nitrox 1.8.1 includes experimental Linux support. For a remote deployment, consider Linux dedicated servers if you can maintain the required runtime, permissions, and startup configuration. Windows remains the better-documented option, so validate game-path detection, dependencies, permissions, and server startup before relying on Linux for a persistent world.

Linux makes sense when you want always-on ops with automation. It also demands more troubleshooting discipline.

When Linux Makes Sense

• You want automatic server startup and scheduled backups without manual effort.
• You already manage Linux servers and you are comfortable reading logs.
• You want a server that behaves like a service, not like a desktop app you babysit.

Linux shines for repeatable ops. It is less forgiving when you are new.

What You Must Confirm Before You Commit

• Nitrox’s Linux release includes a console server that can run without a desktop game client.
• Verify the required .NET runtime, readable Subnautica files, writable data path, and UDP access rather than assuming a desktop environment is required.
• Troubleshooting overhead is real:
  • File permission
  • Service management
  • Log chasing

If your goal is “play with friends this weekend,” Windows is often the faster path. If your goal is “run this for months,” Linux can be worth it.

Linux Ops Basics

Run the server in a controlled directory structure.

Download the matching Linux x64 or Linux ARM64 archive from the Nitrox 1.8.1.0 release page, extract the complete archive, and install the matching patched .NET 9 runtime using Microsoft’s .NET installation instructions for Linux. With application files in /srv/nitrox/app, compatible game files in /srv/games/Subnautica, and a writable /srv/nitrox/data directory, launch:

cd /srv/nitrox/app

dotnet ./Nitrox.Server.Subnautica.dll \

--game-path "/srv/games/Subnautica" \

--data-path "/srv/nitrox/data" \

--save "TeamWorld"

Replace these example paths with your actual directories. Confirm successful startup and the selected world before exposing the UDP endpoint. This is a source-reviewed command template, not a live deployment test.

• Use a service manager approach so the server:
  • Starts on reboot
  • Stops cleanly
  • Restarts automatically if it crashes
• Store logs and rotate them so they do not grow forever.
• Schedule a confirmed save and graceful stop, or another tested consistent-snapshot procedure, before copying the complete persistent world data; retain off-server copies.

Subnautica Dedicated Server Docker (Advanced)

Nitrox does not provide a first-party Docker deployment in its standard documentation. Available Nitrox containers are community-maintained, so verify the image source, release tag, update history, game-file mounts, and persistent data paths before use.

Docker helps when you want repeatable deploys and clean rollbacks. Docker hurts when you forget persistence.

When Docker Helps

• You want the same setup every time.
• You want quick rebuilds after updates.
• You want rollback without scrambling.

Docker is a packaging tool. It does not remove the need for backups and version discipline.

Persistence Rules

World progress can be lost if its only copy remains in a container’s writable layer and that container is deleted or recreated.

• Use persistent Docker volumes for:
  • Saves
  • Config
  • Logs
• Keep backups outside the container.
• Use a restart policy that brings the server back after reboots.

What to avoid:

• Running everything inside the container filesystem with no volumes.
• Pulling “latest” versions without testing.
• Updating the container without coordinating client versions.

Troubleshooting Decision Tree (Fast Fixes First)

When something breaks, most people panic and try random fixes. Do not do that. Use a simple decision tree. You will solve problems faster and avoid damaging your saves.

Symptom To Fastest Fix To Deep Fix

Choosing a Host That Saves You Time

A Subnautica dedicated server should make it easier for your group to return to the world you are building together. With Nitrox, that starts with compatible versions, a reachable server, and tested backups.

Reliable hosting supports that setup, while the mod’s synchronization limits still need realistic expectations.

Self-hosting can suit occasional sessions. When your group needs access independent of your playing PC, remote hosting becomes worth considering.

RedSwitches offers dedicated hardware for users who want single-tenant resources and control over their server environment. Choose a location that suits your players, and confirm whether your selected management plan covers Nitrox updates, backups, and recovery.

Explore RedSwitches dedicated servers when you are ready to move your world to a separate host. Choose the infrastructure your group needs, verify the setup, and make the next session about where to dive next.