Last Oasis Dedicated Server Setup Guide 2026

Launching a Last Oasis dedicated server is the easy part. The challenge begins when MyRealm marks an oasis Active, yet players see 0/0 slots, time out, or disconnect during travel.

To create a joinable server, install Steam App ID 920720, configure your realm and oases in MyRealm, and launch each active oasis as a separate process. Every process needs the realm’s CustomerKey, a valid ProviderKey, a unique identifier, a game port, and a reachable public IPv4 address. Multiple processes also need unique query ports. They may share one installation and ProviderKey, but their identifiers and ports cannot overlap.

This guide walks you through Windows and Linux installation, MyRealm configuration, launch commands, firewall rules, EAC, and multi-oasis deployment.

You will learn how to diagnose registration failures, 0/0 slots, version mismatches, unreachable servers, and failed oasis travel without relying on guesswork.

Last Oasis Dedicated Server 2026 Update

Last Oasis administrators should revalidate older setup instructions because Season 6 and subsequent 2026 updates changed the current client and server environment.

Season 6 launched on March 6, 2026, and Season 6 Chapter 2 went live on May 8, 2026, alongside a new public dedicated-server build.

The Last Oasis dedicated server tool is identified as App ID 920720. The main game App ID is 903950, so server admins should install App ID 920720 through SteamCMD.

The Last Oasis dedicated server tool has separate Windows and Linux Steam depots.

This guide uses Windows as the beginner path, while the Linux path assumes familiarity with dependencies, firewall rules, permissions, and process supervision.

Easy Anti-Cheat also matters in 2026. Update 44848 re-enabled Easy Anti-Cheat and added a client launch choice to enable or disable it.

If players cannot join, verify the client and server versions first, then inspect the exact error and confirm the EAC and mod configuration used by that server.

Last Oasis Dedicated Server Quick Facts

Self-Hosted vs Official Last Oasis Servers

This choice affects configuration control, operating responsibility, cost, and availability.

A self-hosted dedicated server allows players to join without the game host being present, provided the required server processes and backend services remain available.

You control the host, process uptime, network policy, access settings, and supported MyRealm configuration, but complete portable world backups and full backend control are not established by the published documentation.

Official servers remove setup effort but restrict configuration. You control your character and clan decisions, not server rules, wipes, or limits.

Comparison Overview

How Last Oasis Dedicated Servers Actually Work (MyRealm, Realms, and Oases)

Last Oasis does not run as one single world process. Your Last Oasis dedicated server is part of a structured system managed through MyRealm. Understanding this structure helps diagnose why an apparently Active setup may still fail during joining or oasis travel.

Start with the hierarchy.

A Realm is the top-level container. It defines ownership, rules, and which oases exist. You create and manage it inside MyRealm.

Inside a realm, you create one or more Oases. An oasis is a playable map instance. Each oasis runs as its own separate server process.

There are two operating models:

• Single Oasis Mode: One realm, one oasis, one server process
• Multiple Oasis Mode: One realm, multiple oases, multiple server processes

Small private setups often use Single Oasis Mode. Multi-oasis complexity only applies when you run more than one oasis.

Each oasis requires:

• A unique server instance
• Unique ports
• A valid ProviderKey, which may be reused or separated operationally

Understanding the Authentication Keys

Two keys control authentication:

• Customer Key: Identifies your entire realm. One per realm. Shared across all oases.
• Provider Key: Authorizes self-hosted server processes. One valid key may be reused, or separate keys may be created for independent revocation.

If the CustomerKey is wrong, the realm does not authenticate.

An invalid or revoked ProviderKey can prevent correct registration, but reusing a valid ProviderKey is supported and does not itself create a conflict.

Why This Architecture Causes Setup Failures

This design allows distributed, persistent worlds. It also increases failure points:

• Invalid or revoked ProviderKeys
• Overlapping ports between server instances
• Incorrect public IP advertisement
• Target oasis offline during player travel
• Wrong key assigned to the wrong server instance

When misconfigured, the server process still runs. MyRealm may even display it as active. Players only discover the issue when they cannot join or transition between oases.

A single-oasis realm can use one server process, while every additional active oasis requires another process.

You are coordinating authenticated server instances under one realm structure. Understand that mapping first. File installation can succeed independently, but registration, joining, and travel require the MyRealm, launch, and network layers to align.

Last Oasis Dedicated Server Requirements (Hardware, Network, Accounts, OS)

Before you deploy your Last Oasis dedicated server, validate hardware, networking, operating system, and account access. These are the first prerequisites to validate before installation and troubleshooting.

CPU Matters More Than Core Count

As a hosting recommendation, prioritize strong per-core CPU performance and verify actual usage on the current server build.

• Higher per-core performance may reduce CPU bottlenecks under load
• Compare processors by per-core performance and sustained load behavior, not core count alone
• Multi-oasis deployments benefit from additional cores, but clock speed still matters

RAM Expectations

• Measure the server’s idle working set before inviting players
• Add RAM headroom according to active oasis count, player load, mods, and observed usage

Do not overprovision blindly. Size based on player count and number of active oases.

Storage Requirements

• Older official setup guidance recommends at least 25 GB free space for the install volume
• Keep at least 25 GB free for installation, validation, logs, and updates
• Use SSD storage and move to NVMe only when monitoring shows storage latency under load

Slow disks can increase load times, delay writes, and make busy multi-oasis deployments less responsive.

Operating System Support

Use an operating-system version that you have tested and can keep fully patched:

• A currently supported 64-bit Windows Server release
• A currently supported 64-bit Windows desktop release for testing or small private setups

Linux dedicated servers are supported by the Steam dedicated server tool through a separate Linux 64-bit depot. Windows is still simpler for first-time admins, while Linux requires more dependency, firewall, and service-management knowledge.

Network Requirements

Public IPv4 Is Required for Public Hosting

Your server must advertise a reachable public IPv4 address.

Without proper public routing:

• MyRealm may show the server as active
• Players cannot join
• Oasis travel fails

Port Requirements Per Oasis

Each oasis server instance should reserve:

• The game port you set with -port
• Any additional UDP port that the current server process is verified to bind
• One unique query port

Allow only the UDP ports that the current server process is verified to use. Add TCP rules only if a listener check or current first-party requirement confirms that TCP is needed.

CGNAT and Home Hosting

If your ISP uses CGNAT:

• You do not control the public IPv4
• Standard port forwarding will not expose your server

Public self-hosting becomes unreliable without workarounds.

Possible workarounds for private groups:

• A ZeroTier or Tailscale overlay tested with MyRealm advertisement, routes, and every participating client
• ISP-provided static IPv4 upgrade
• A hosting provider offering a routable public IPv4 address and configurable inbound UDP rules

For public servers, a proper public IPv4 remains the cleanest solution.

Account Requirements

You need more than just files.

Steam Access

Current setup guides commonly use a Steam account that owns Last Oasis, while older official guidance showed an anonymous SteamCMD login. If anonymous login fails, log in with a valid Steam account that owns the game.

MyRealm Access

You also need:

• Access to MyRealm
• One CustomerKey per realm
• At least one valid ProviderKey, with separate keys optional for revocation or auditing

Last Oasis Dedicated Server Setup

Use the following dependency order to reduce configuration errors and rework. If you skip a step, the server can show Active in MyRealm and still be unjoinable.

1) Prepare Infrastructure

• Choose an OS: Windows Server for the simplest setup, or Linux if you are comfortable with dependencies, firewall rules, and service management
• Verify hardware meets the specs you already defined in the Requirements section
• Confirm you have a public IPv4 for public access
• Decide Single Oasis Mode or Multiple Oasis Mode
• Document port allocation per oasis

2) Install Server Files (SteamCMD)

• Install SteamCMD
• Try an anonymous login first if your SteamCMD build allows it; if that fails, sign in with a Steam account that owns Last Oasis
• Download server files into a dedicated path
  • Example (Windows): C:\LastOasisServer\
  • Keep paths simple. Avoid special characters and deep folder nesting.

3) Configure MyRealm and Generate Keys

Inside MyRealm:

• Create your realm
• Pick Single Oasis or Multiple Oasis mode
• Create your oasis entries
• Generate and record keys
  • CustomerKey: one per realm
  • ProviderKey: one valid key may be reused, or separate keys may be generated operationally
• Create a simple mapping sheet: Oasis name → ProviderKey policy → identifier → game/query ports → launch file

MyRealm defines your realm configuration. Your server processes enforce it during play.

Self-hosting does not establish a complete portable world-save backup or migration workflow. Back up local launch files, configuration notes, and logs before updates, but treat MyRealm and Donkey Crew backend services as part of the realm architecture.

4) Assign Ports (Per Oasis) and Open Firewalls

Per simultaneous oasis process, reserve one configured game port and one unique query port, then verify whether the current build binds any additional UDP port:

• Configured game port and any additional UDP port verified through a current listener check
• Unique query port over UDP for each simultaneous server process

Example port-planning pattern:

• Oasis 1 → Game 5555, Query 27015
• Oasis 2 → Game 5557, Query 27016
• Oasis 3 → Game 5559, Query 27017

Published self-hosting guidance requires unique -port, -QueryPort, and -identifier values for simultaneous server processes. -QueryPort is optional when only one server process is running. Allow any additional port only when a listener check confirms that the current build uses it.

Open the required UDP ports in:

• OS firewall (Windows Firewall / ufw)
• Hosting firewall (if present)
• Router/NAT rules (if self-hosting)

Do not open TCP unless the current process is verified to listen on it.

5) Configure Launch Parameters (Joinability Step)

This is where most servers “run” but cannot be joined.

For each Oasis server instance, you must ensure it advertises your public IPv4.

• Set -OverrideConnectionAddress=YOUR_PUBLIC_IP for the documented public-hosting topology
• Confirm each instance uses the correct ProviderKey and its own ports
• Use a separate launch file for each oasis process; separate full installations are optional

If this is wrong, the server can register but advertise an internal IP. Players fail to connect.

6) Launch and Validate (Single Oasis vs Multi-Oasis)

Start one instance first. Validate before scaling.

Single Oasis Mode

• MyRealm shows the oasis as Active
• Server appears in-game as joinable
• You can connect and play reliably

Multiple Oasis Mode

• Repeat validation per oasis
• Then test travel between your oases
• If travel fails, the target oasis is usually offline, mis-keyed, mis-ported, or advertising the wrong IP.

Installing the Last Oasis Dedicated Server (SteamCMD Explained Clearly)

The Last Oasis Dedicated Server is distributed through Steam. SteamCMD is the recommended method for headless installation and updates, while the tool may also be installed through the Steam Tools library.

The Correct App ID

This is where many setups go wrong.

• Last Oasis Dedicated Server App ID: 920720
• The main game has a different App ID. If you download that instead, you will only get client files.

Always verify you are installing App ID 920720.

Why Use SteamCMD

SteamCMD handles:

• Authentication
• File delivery
• Server updates
• File validation

Anonymous login support is inconsistent across older and newer guidance. If anonymous login fails, log in with a valid Steam account that owns Last Oasis.

If authentication fails, SteamCMD displays an error and stops the download. Accounts using Steam Guard may require a one-time verification code during first login.

Basic Installation Flow (Windows)

Run this command from the SteamCMD directory:

steamcmd.exe +force_install_dir "C:\LastOasisServer" +login anonymous +app_update 920720 validate +quit

Most operators choose Windows for simplicity and compatibility.

High-level steps:

• Install SteamCMD
• Create a dedicated installation folder, for example: C:\LastOasisServer\
• Log in anonymously if supported, or use a Steam account that owns Last Oasis if anonymous login fails
• Install App ID 920720 into that folder
• Use the validate option to confirm file integrity

Keep at least 25 GB free for the installation, validation files, logs, and update workspace.

How to Confirm Installation Is Correct

After download:

• The current dedicated server depot is smaller than 20–30 GB, but you should still allocate at least 25 GB free space
• MistServer.exe should be present (Windows)
• The expected MistServer.exe launcher and Mist directory tree should be present on Windows

If these are missing, you downloaded the wrong App ID or the install did not complete.

Running Multiple Oases: Directory Structure

For easier troubleshooting, give each oasis process its own launch file, identifier, and ports; use separate full installations only when operational isolation is required.

Example:

C:\LastOasisServer
├── MistServer.exe
├── Start_Oasis1.bat
├── Start_Oasis2.bat
└── Start_Oasis3.bat

Multiple oasis processes can share one validated installation when each process uses a unique identifier and non-overlapping ports. Separate installations improve isolation but increase disk use, update work, and version-drift risk.

Installation on Linux

Linux is supported, but requires more system awareness.

Common Approaches:

• Native SteamCMD on a currently supported 64-bit Linux distribution
• An unofficial Docker deployment whose provenance, maintenance status, and current-build compatibility you have verified

Linux Deployments Require:

• Any 32-bit compatibility libraries required by SteamCMD and the separate dependencies required by the 64-bit server binary
• Manual firewall configuration (iptables or ufw)
• Proper file permissions
• Service management (systemd for auto-start)

For native Linux, enter Mist/Binaries/Linux, create steam_appid.txt containing 903950, and launch ./MistServer-Linux-Shipping Mist with the required keys, identifier, ports, and advertised-address parameters. Recheck the binary name after major server updates.

Updating the Server

Whenever the game updates, your server must update too.

To update:

• Run SteamCMD again with App ID 920720
• Use the validate option to repair or patch files

Running outdated server files causes version mismatch errors when players connect.

MyRealm Setup: Creating a Realm That Actually Works

MyRealm is your configuration hub. It defines your realm, your oases, and the keys your server processes must use to register and become joinable. If MyRealm is wrong, the server can start locally and still show 0/0 slots or fail to join.

Below is the mental model and the practical setup flow.

1) Create Your Realm (One-Time Setup)

When you create a realm in MyRealm, you choose the operating model:

• Single Oasis Mode: one realm → one oasis → one server process
• Multiple Oasis Mode: one realm → multiple oases → one server process per oasis

Start with Single Oasis Mode if you want fewer moving parts. Move to Multiple Oasis Mode only when you truly need travel between oases.

Visibility and Access

• Private visibility usually reduces public discoverability, but exact access behavior depends on the current MyRealm options.
• Public is meant to appear in server browsing and be joinable by anyone who can reach the server network-wise.

(Visibility affects how people find you. It does not fix connectivity. Ports and advertised IP still decide joinability.)

2) Create Your Oases (Your Playable Maps)

Inside the realm, you create one or more oases. Think of each oasis as a separate playable map instance.

Oasis-level settings may include:

• Player cap for that oasis (per-oasis, not global)
• Gameplay rules, rates, limits, or decay-style settings if available in the current MyRealm UI

If you use Multiple Oasis Mode, you are committing to multiple server processes. Each oasis must have its own process running to be playable.

3) Generate and Assign Keys

Keys are not optional. They are the identity system.

Customer Key (one per realm)

• Identifies the realm itself
• Shared across every server process in that realm
• If this is wrong, nothing registers correctly

Provider Key (one valid key may be shared or separated)

• Authorizes self-hosted server processes to register under the realm
• You may reuse one valid ProviderKey or generate separate keys for independent revocation and auditing
• Reusing a valid ProviderKey is supported; an invalid or revoked ProviderKey can prevent clean registration

What to Do in MyRealm (UI-level guidance)

• Create the realm → locate the realm’s key section → generate/record the CustomerKey
• Generate at least one ProviderKey; reuse it across server processes or create separate keys for independent revocation and auditing
• Keep these in a mapping sheet before you launch anything
• Store CustomerKey and ProviderKey values securely, never publish them or commit them to version control, and revoke any exposed ProviderKey in MyRealm

4) Maintain a Correct Mapping Sheet

Use one consistent naming scheme and document everything.

Realm

• Realm Name: ExampleRealm
• CustomerKey: XXXXX

Per Oasis

• Oasis Name: Oasis1
• ProviderKey: YYYYY
• Identifier: Oasis1
• Game Port: 5555 (allow the verified UDP listener)
• Query Port: 27015 (allow UDP and keep it unique across simultaneous processes)
• Launch File: C:\LastOasisServer\Start_Oasis1.bat
• Public IP advertised: X.X.X.X

Repeat for Oasis2 and Oasis3 with unique identifiers and ports, using either a shared or separate valid ProviderKey.

This prevents “active but unjoinable” setups caused by mismatched keys, wrong identifiers, and port overlap.

5) Know What Affects Gameplay vs Joinability

Gameplay Settings (Affect How the Server Plays)

• Rates and limits (gathering/crafting-style multipliers, caps)
• Decay-style settings
• Rules that change balance and pacing

These can be misconfigured while the server remains technically joinable.

Connectivity Settings (Affect Whether People Can Join and Travel)

• CustomerKey and ProviderKey correctness
• Public IP advertisement (OverrideConnectionAddress)
• Verified UDP ports for game and query traffic, with TCP added only when a current listener confirms it is required
• Identifier uniqueness per server process
• Oasis online status (for multi-oasis travel)

These decide whether the server shows up and accepts connections.

6) What Requires a Restart (Be Precise)

A realm is not something you restart. You restart server processes.

Any change to launch parameters requires a restart, including:

• -OverrideConnectionAddress
• -identifier
• ports
• enabling cheats / flags
• backend override parameters

Documented MyRealm Additional Settings require the affected server process to restart. Use this safe rule for launch changes:

• If it touches keys, ports, identifiers, or advertised IP → restart that specific oasis server process.

7) What Key Mismatch Looks Like (Fast Diagnosis)

If your keys do not match MyRealm:

• The server process starts locally
• MyRealm may show the oasis as offline or unstable
• In-game, it may show an incorrect capacity state or fail to join; confirm the cause in the server log
• Players see “cannot connect” even when the machine is reachable

When this happens, do not touch gameplay sliders. Check authentication (`CustomerKey` and `ProviderKey`), process identity (`identifier`), reachability (address, ports, and firewalls), and build compatibility separately.

8) Propagation Timing (What to Expect)

Some MyRealm changes appear quickly in the dashboard, but player-visible behavior depends on the server process pulling and enforcing the latest state. If you change anything connectivity-related, restart the affected server process so it re-registers cleanly.

Server Launch Configuration: How to Launch a Joinable Last Oasis Server

A Last Oasis server can appear to run while still being unreachable or unjoinable. That happens when the launch command is incomplete, the server advertises the wrong IP, or the required UDP ports are blocked.

This section gives you an execution-ready launch setup.

1) What You Need Before Launch

For each oasis server process you plan to run, you must already have:

• CustomerKey (One per realm, shared across all oases)
• ProviderKey (A valid key that may be shared or separated)
• Identifier (Unique per oasis, matches your naming plan)
• Game Port (Allow the verified UDP listener)
• Query Port (Keep it unique for simultaneous processes and allow UDP)
• Public IPv4 to advertise via -OverrideConnectionAddress

2) Folder Layout (Multi-Oasis)

Multiple oasis processes can share one validated installation. Give each process a separate launch file, identifier, game port, and query port.

C:\LastOasisServer\

├── MistServer.exe

├── Mist\

├── Start_Oasis1.bat

├── Start_Oasis2.bat

└── Start_Oasis3.bat

Keep at least 25 GB free for the installation and update workspace. Separate complete installations are optional and require additional storage and update management.

3) Port Scheme

For each simultaneous oasis process, configure:

• One unique game port through -port
• One unique query port through -QueryPort
• Any additional UDP listener verified on the current server build

The gaps between example game ports are organizational. Open only the ports the current process is verified to use.

4) Complete Launch Command

MistServer.exe -log -force_steamclient_link -messaging -NoLiveServer ^
-backendapiurloverride="backend.last-oasis.com" ^
-identifier=Oasis1 -port=5555 ^
-CustomerKey=YOUR_CUSTOMER_KEY ^
-ProviderKey=YOUR_PROVIDER_KEY ^
-slots=40 -QueryPort=27015 ^
-OverrideConnectionAddress=YOUR_PUBLIC_IP

What each critical parameter does

• -log exposes live diagnostic output and is strongly recommended during setup
• -force_steamclient_link appears in the published self-hosting launch template
• -messaging appears in the published self-hosting launch template; retain it unless current-build testing establishes otherwise
• -backendapiurloverride="backend.last-oasis.com" appears in the published self-hosting template; retain it unless current first-party guidance changes
• -identifier=Oasis1 unique instance name (must be unique per oasis)
• -port=5555 sets the configured game port; allow its verified UDP listener
• -QueryPort=27015 sets the query port; keep it unique across simultaneous processes and allow UDP
• -CustomerKey=... realm identity (same for all oases in the realm)
• -ProviderKey=... supplies a valid self-host credential that may be reused or separated
• -slots=40 sets capacity for this server process; published guidance recommends no more than 100
• -OverrideConnectionAddress=... forces the server to advertise your public IPv4

Optional flags should be used only when verified in your current build or MyRealm setup:

• Add -EnableCheats only when administrative cheat access is intentionally required
• -NoLiveServer appears in the published self-hosting template; retain it unless current-build testing confirms it is unnecessary
• Set server name, password, and visibility in MyRealm if those options are available.

5) Batch File Example (Start_Oasis1.bat)

Create C:\LastOasisServer\Start_Oasis1.bat:

@echo off

cd /d "C:\LastOasisServer"

MistServer.exe -log -force_steamclient_link -messaging -NoLiveServer ^
-backendapiurloverride="backend.last-oasis.com" ^
-identifier=Oasis1 -port=5555 ^
-CustomerKey=YOUR_CUSTOMER_KEY ^
-ProviderKey=YOUR_PROVIDER_KEY ^
-slots=40 -QueryPort=27015 ^
-OverrideConnectionAddress=YOUR_PUBLIC_IP

pause

Repeat for Oasis2/Oasis3 with:

• Different -identifier
• A valid -ProviderKey, which may be shared or different
• Different ports

6) How to Find Your Public IP

Use a browser site like:

• whatismyipaddress.com

Or from terminal:

Windows PowerShell:

(Invoke-WebRequest -UseBasicParsing ifconfig.me).Content

Linux:

curl ifconfig.me

If your IP changes often, use DDNS to track the current IP, but update -OverrideConnectionAddress with the current reachable public IPv4 unless you have confirmed hostnames work.

7) Firewall Rules

Windows Firewall

Run these netsh advfirewall commands from an elevated Command Prompt:

netsh advfirewall firewall add rule name="Last Oasis 5555 UDP" dir=in action=allow protocol=UDP localport=5555

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

These rules cover the configured example game and query ports. Add another UDP rule only if a listener check confirms that the current build binds an additional port.

8) Check Ports Aren’t Already in Use

Windows:

netstat -ano | findstr :5555

Linux:

sudo ss -lunp | grep ':5555'

If a port is in use, change -port / -QueryPort and update firewall rules.

9) Logs: Where to Look When Something Breaks

Logs are commonly generated under the Unreal project directory, such as Mist\Saved\Logs, but confirm the current location after first launch by searching the installation for the newest .log file.

Use logs when:

• The server crashes on start
• Keys are rejected
• Ports fail to bind
• The server shows Active, but players cannot join

10) Validation: What “Working” Looks Like

After launch:

• MyRealm shows the oasis as Active
• In-game, the server shows normal slots (not 0/0)
• You can join from an external network
• In Multiple Oasis Mode, travel works to every running oasis

If it shows 0/0 slots or fails to join, check in this order:

1. -CustomerKey and -ProviderKey match MyRealm
2. -identifier is unique
3. -OverrideConnectionAddress equals your public IPv4
4. The configured game and query ports are open over UDP, and any additional listener shown by the current process is also allowed
5. Router / hosting firewall is not blocking UDP

11) Stopping and Restarting Safely

For planned restarts:

• Warn players (they will disconnect immediately)
• Use the current build’s verified graceful-stop method and confirm that the log finishes writing before terminating the process
• Restart using the same .bat file

Any change to launch parameters requires a restart:

• ports, identifier, slots, OverrideConnectionAddress, backend override, cheat flags

For production uptime:

• Windows: run via NSSM as a service (auto-start after reboot)
• Linux: run via systemd or Docker restart policies

Ports, Firewalls, and Networking

If your Last Oasis server shows Active but players see 0/0 slots or cannot connect, the problem is usually networking, keys, EAC mode, or public IP advertisement.

1) Documented Ports and Current Listener Verification

Each oasis server process should reserve:

• One configured game port through -port
• One query port through -QueryPort, kept unique across simultaneous processes
• Any additional UDP port shown by a current listener check

Example for Oasis1:

• Game Port: 5555 over UDP
• Query Port: 27015 over UDP

If UDP is blocked, the server may appear online but fail joins, handshakes, or travel.

If the Query Port is blocked, server visibility and discovery can break.

2) Standard Port Planning (Organized but Optional)

Example Convention:

The skipped game-port numbers leave room for any additional listener discovered during testing. Only configured or verified ports should be opened.

3) Every Firewall Layer Must Allow Traffic

Opening a port in one place is not enough.

Traffic must pass through:

1. OS firewall (Windows Firewall / ufw)
2. Hosting provider firewall (if VPS or dedicated server)
3. Router NAT rules (if self-hosted)

Miss one layer and traffic dies before reaching MistServer.exe.

4) NAT: Why Home Servers Fail

When hosting at home:

• Your PC uses a private IP address (192.168.x.x)
• Your router holds the public IP

Players connect to the public IP.

Your router must forward:

• Configured game port and any additional verified listener → internal machine
• Query Port → internal machine

Without port forwarding:

• MyRealm shows Active
• No external traffic reaches your server
• In-game display often shows 0/0

5) CGNAT: The Hard Stop

If your ISP uses CGNAT:

• You do not have a true public IPv4 address
• Port forwarding will not expose your server
• Public hosting becomes impossible without workarounds

How to Check:

• Compare your router WAN IP to whatismyipaddress.com
• If they differ, you are likely behind CGNAT

Solutions:

• Request a static public IPv4 from ISP
• Use a proper hosting provider
• Use overlay networks (ZeroTier / Tailscale) for private-only servers

CGNAT is a common reason home-hosted public servers remain unreachable.

6) OverrideConnectionAddress: Why Servers Advertise the Wrong IP

MistServer may auto-detect a local IP.

That may work inside your LAN.

It fails for external players if the server advertises a private address.

You must explicitly set:

-OverrideConnectionAddress=YOUR_PUBLIC_IP

If this value is:

• Missing
• Incorrect
• Outdated after IP change

Players connect to the wrong address.

Symptom:

• Server visible
• Join attempt times out instantly

7) How to Verify Ports Are Actually Open

Do not trust assumptions.

Check Locally:

Windows:

netstat -ano | findstr :5555

Linux:

sudo netstat -tulpn | grep 5555

Check Externally:

• Use external player testing or a reliable UDP-aware port test
• Test from a different network (mobile hotspot)
• Ask a friend to attempt a connection

If Ports Appear Closed:

• Confirm firewall rules allow the required UDP traffic and add TCP only if the server process is verified to listen on it
• Confirm router forwards the correct internal IP
• Confirm the server process is running
• Confirm no other service is using the same port

8) Hosting Provider Networking

If using a VPS or dedicated server:

• Create a temporary least-privilege UDP rule for the verified ports and remove or restrict it after testing
• Confirm no security group blocks UDP
• Confirm no DDoS protection is misconfigured
• Ensure the server has a real public IPv4 address assigned

Cloud and hosting firewalls may block UDP by default.

9) Multi-Oasis Networking Reality

If running multiple oases, each simultaneous server process must have:

• A unique configured game port
• A unique query port
• A unique identifier
• A valid ProviderKey, shared or separated according to your credential policy

Travel between oases fails if the destination oasis:

• Is offline
• Has closed ports
• Advertises wrong IP

An unavailable or unreachable oasis breaks travel to that destination.

Multi-Oasis (Multiple Server) Setup: Scaling a Realm Safely

Running multiple oases is not “one bigger server.” It is multiple independent server processes working under one realm. If you do not treat them as separate systems, scaling will break.

How Multiple Server Processes Actually Work

In Multiple Oasis Mode:

• One Realm
• Multiple Oases
• One server process per oasis

Each Process:

• Runs its own server process (MistServer.exe on Windows)
• Binds to its own game and query ports
• Uses a valid ProviderKey, which may be shared or separate
• Shares the same CustomerKey
• Registers separately with MyRealm

When a player travels between oases, the client disconnects from Oasis A and reconnects to Oasis B.

That Means:

Travel = network handoff between two live server processes.

If Oasis B is not healthy, the player disconnects.

Why Ports and Identifiers Must Never Overlap

Each simultaneous oasis process must have:

• A unique Game Port
• A unique Query Port
• A unique Identifier
• A valid ProviderKey, shared or separated according to your credential policy

If you reuse:

• Ports → binding errors or silent conflicts
• Identifier → registration instability
• Invalid or revoked ProviderKey → registration or authentication failure

Even if one oasis works, others may fail unpredictably.

Overlap is the fastest way to create unstable scaling.

Common Multi-Oasis Failures

Case 1: One Oasis Works, Others Do Not

Symptoms:

• Oasis1 joinable
• Oasis2 shows Active but cannot join

Common Causes:

• Ports not opened for Oasis2
• Wrong ProviderKey assigned
• Duplicate identifier
• Missing OverrideConnectionAddress
• Firewall missing UDP rules

Always validate each oasis individually before testing travel.

Case 2: Players Disconnect When Switching Oases

Travel failures happen when:

• Destination Oasis is offline
• Ports blocked on the destination
• Destination advertises the wrong public IP
• Server process crashes under load

Travel is not a teleport inside one server. It is a live reconnect to another server instance. If that instance is misconfigured, the connection drops.

Performance Reality: Each Oasis Consumes Resources

Each server process consumes:

• CPU
• RAM
• Disk I/O
• Network bandwidth

Each additional oasis process adds baseline CPU and RAM overhead, while disk and network demand depend on active players and activity.

Do not scale without planning:

• Monitor CPU usage per process
• Ensure enough RAM headroom
• Use NVMe if running multiple high-population oases

Sustained CPU saturation can increase latency and timeout risk; correlate resource telemetry with server and client logs.

Scaling Safely

Before adding another oasis:

• Confirm the current oasis is stable under load
• Document current port usage
• Reserve the next available game port and query port
• Reuse a valid ProviderKey or generate a separate key if independent revocation is useful
• Assign a unique identifier
• Copy the existing launch file and keep using the validated installation unless you intentionally require a separate full copy
• Update launch parameters carefully

Do not copy a launch file without changing its identifier and ports; change the ProviderKey only if you intentionally use separate credentials.

Controlled Expansion Strategy

Best Practice:

1. Launch Oasis1
2. Validate connectivity
3. Add Oasis2
4. Validate connectivity
5. Test travel between both
6. Monitor logs

Once stable, you can start all instances simultaneously.

During initial deployment, start one at a time to isolate errors.

Signs You Scaled Too Fast

• Frequent travel disconnects
• Sudden server crashes
• High CPU spikes during map transitions
• Players reporting timeouts or disconnects during travel, or rubberbanding within an oasis

Linux and Docker Support

Last Oasis has a current Linux server depot, while Docker remains an unofficial community packaging option.

Linux is supported, but Docker compatibility depends on the maintenance, provenance, and current-build support of the selected image.

If your priority is fast deployment with minimal friction, Windows remains the simplest path. If your priority is automation, isolation, and infrastructure control, Linux or Docker can make sense, but only if you understand what you are managing.

Linux Support

There is no beginner-friendly one-click Linux installer in the same style as many managed hosting panels. Most Linux deployments rely on:

• SteamCMD for file delivery
• Required 32-bit compatibility libraries
• Manual firewall configuration
• Proper process supervision (systemd)

Use a currently supported 64-bit Linux distribution and document the exact packages verified on that release. On older distributions, missing runtime libraries can prevent the server from starting.

Linux can run stable in production. It simply demands system-level awareness.

Common Linux Pitfalls

Missing Dependencies

SteamCMD may require 32-bit compatibility libraries, while the current Last Oasis Linux server depot is 64-bit and has separate runtime dependencies.

If they are missing, the server may crash on launch or fail silently.

Firewall Configuration

Verify that the process is listening and that every active host or provider firewall allows the required inbound UDP traffic.

You must explicitly allow the required UDP traffic for game and query ports using tools such as UFW or iptables. Add TCP rules only if a listener check confirms that the server process uses TCP.

File Permissions

Running everything as root is unsafe. Running as a non-root user requires correct ownership and execution permissions on the server directory. Incorrect permissions lead to startup failures or log write errors.

Service Management

Configure systemd with an explicit restart policy, or use an equivalent supervisor, if the process must recover after crashes or reboots. A production Linux deployment requires proper service management.

Docker: What It Actually Solves

Docker wraps the server and its dependencies inside a container. This improves:

• Environment consistency
• Isolation between multiple oases
• Deployment repeatability
• Controlled restart behavior

Community-maintained Docker projects exist. These are not official Donkey Crew builds.

You must understand Docker port publishing and networking modes to avoid connectivity failures.

Use Docker only when you have reviewed a maintained community image, verified its current-build compatibility, and can correctly map every required UDP port. For a first deployment, native Windows or Linux installation is easier to validate.

Networking Reality on Linux and Docker

Regardless of platform:

• Open the required UDP traffic for the game port
• Open the required UDP traffic for the query port
• Set -OverrideConnectionAddress to your public IPv4
• Ensure the container or host advertises the correct IP

Docker does not bypass firewall rules. It adds another configuration point that must be correct.

EAC and Private Server Access

Update 44848 re-enabled Easy Anti-Cheat and added an enable/disable client launch choice. Clients launched without EAC cannot join official servers, while clients launched with EAC cannot join modded private servers. Do not assume every join failure is EAC-related; also confirm the server branch, mod state, versions, and exact error.

Check EAC when:

• Players can join some servers but not yours
• A modded private server rejects players
• The server appears online but join attempts fail
• A client update changes launch behavior

For troubleshooting, verify the game version, server version, EAC mode, and mod state before changing ports or keys again.

Common Last Oasis Dedicated Server Problems

Last Oasis server symptoms can have several overlapping causes. Use logs and controlled tests to check credentials, ports, address advertisement, process health, versions, access settings, EAC or mod state, and resource load.

Use this section as a diagnostic playbook. Start with the symptom, identify the likely cause, then apply the fix.

Quick Troubleshooting Matrix

Last Oasis Dedicated Server Hosting on RedSwitches

A reliable Last Oasis dedicated server depends on more than installing App ID 920720 and launching MistServer. MyRealm credentials, unique identifiers, non-overlapping UDP ports, a reachable public IPv4 address, and the correct OverrideConnectionAddress must all work together.

Start with one oasis, confirm that external players can connect, review the logs, and only then add more server processes.

As your realm expands, stable CPU performance, sufficient memory, consistent uptime, and dependable networking become increasingly important.

Home hosting may suit a small private group, but CGNAT, changing IP addresses, hardware limitations, and local outages can make public or multi-oasis realms difficult to maintain.

For public communities, gaming dedicated servers support persistent multiplayer workloads, while DDoS-protected dedicated servers can help mitigate volumetric attacks against public-facing infrastructure.

RedSwitches dedicated servers provide bare-metal resources, public IPv4 connectivity, and global hosting locations for administrators who want greater control over persistent Last Oasis deployments.

The infrastructure supports the workload, while careful configuration keeps every oasis reachable.

Build one stable oasis first, verify every connection layer, and scale your realm only when the foundation is ready.