Empyrion Galactic Survival Dedicated Server Setup Guide: 2026 Updates

To set one up, install the free dedicated server tool (Steam App ID 530870) on Windows 64-bit using SteamCMD. Copy dedicated.yaml to a custom file, configure the server and save selection, then launch with -dedicated pointing to that file. Allow TCP and UDP ports 30000–30003 through the firewall and, for home hosting, forward them on your router. Keep the optional Telnet port 30004 private, then test that a player can join from outside your network.

This guide takes you from platform choice and installation through configuration and your first connection. It also covers playfield resource use, EAH, Reforged Eden 2, updates, and backups so you can keep the world running.

What Changed in Empyrion During 2026?

Empyrion v1.17 was released on May 19, 2026. Its server-relevant changes included an expanded block ID range, EAH and API compatibility updates, the Warp Route Planner, and BPYAML blueprint support.

Version 1.18 was released on July 8, 2026. It introduced multithreaded NPC pathfinding, a container limit increase from 1023 to 9999, expanded BPYAML export data, EAH fixes, and separate multiplayer scenario files.

A subsequent v1.19.6 Build 5188 hotfix was released on September 24, 2026.

Empyrion Dedicated Server Quick Facts

Windows vs Linux vs Docker: Choosing the Right Platform Before You Install

An Empyrion: Galactic Survival dedicated server does not use the same deployment method on every platform. Your choice affects official support, maintenance, updates, and troubleshooting.

Native Windows Hosting

Windows 64-bit is the officially supported dedicated-server platform.

• Uses the official dedicated server binary
• Config files behave as expected
• Native Windows avoids the Wine compatibility and Linux permission layers that can introduce additional failure points
• Debug logs are easier to read and trust

Choose This If:You want the officially supported deployment path with fewer compatibility layers. It is the most practical starting point for first-time self-hosters.

Linux via Wine or Proton

Empyrion does not ship a native Linux server.

• Runs through a Windows compatibility layer such as Wine or Proton
• File paths and permissions cause common errors
• Wine or Proton updates can break working setups
• Debugging takes longer due to mixed logs and silent permission failures

Choose This If:You already manage Linux servers and accept extra maintenance work.

Dockerized Wine Setups

Docker wraps the Linux + Wine setup into containers.

• Easier redeployments
• Cleaner separation between servers
• Better control at the deployment and orchestration layer
• Harder debugging when something breaks

Choose This If:You run multiple servers or host for others and understand container workflows.

Docker Setup Notes

When using Docker, select a maintained community image and follow its exact documentation for image names, persistent paths, environment variables, user IDs, ports, and shutdown behavior. Do not use an unverified generic image or expose the Telnet port publicly.

Run the Empyrion server process as an unprivileged user and ensure proper ownership:

# Create dedicated user
sudo useradd -m -s /bin/bash empyrion
# Set proper ownership (do NOT use chmod 777)
sudo chown -R empyrion:empyrion /path/to/gamedir

Empyrion Dedicated Server System Requirements

Empyrion server capacity depends on active playfields, player activity, scenario complexity, CPU performance, memory capacity, and storage behavior. Player count alone is not a complete sizing metric.

RAM

Empyrion is RAM-heavy by design.

• Active playfields run in playfield server processes, which can host multiple playfields
• Playfields stay loaded while players remain active
• Memory use should be monitored across long sessions because behavior varies by game version, scenario, and active playfield count
• Mods and scenarios increase memory pressure

Planning approach: Plan memory around expected active playfields, player activity, scenario complexity, and operating-system overhead. Ten players spread across eight playfields may use more RAM than ten players in one playfield; measure the workload before choosing a capacity target.

Practical guidelines:

• Small private servers (2-4 players, few playfields): 16-24 GB total RAM
• Medium communities (6-15 players, moderate exploration): 32-48 GB total RAM
• Large or modded servers (15+ players, Reforged Eden 2): 64-96+ GB total RAM

These are conservative editorial starting estimates, not official Empyrion system requirements. Actual resource use depends on active playfields, scenario complexity, structures, AI activity, and server uptime.

Windows systems: Reserve additional memory for the operating system, EAH, security tools, and background services. Measure the host’s actual idle use instead of assuming a fixed overhead.

CPU

Empyrion runs multiple playfield server processes.

• High clock speed improves performance inside each playfield
• More CPU cores allow more playfields to run in parallel
• Core count matters even on small servers if players spread out

Correct Framing:

• Clock speed affects per-playfield simulation
• Core count affects how many playfields stay smooth
• Modern CPU architecture matters more than raw GHz numbers

Avoid old guidance that focuses on single-core only.

Storage: SSD Strongly Recommended

Empyrion saves often and writes large files.

• An HDD can increase save and loading latency, particularly on large worlds or hosts with competing disk activity
• An SSD is the practical minimum for a responsive production server
• NVMe provides additional I/O headroom for large saves, frequent backups, and multiple server instances

NVMe matters most when worlds grow or restarts are frequent.

Network (Stability Over Raw Speed)

Empyrion sends constant state updates.

• Stable upload prevents rubber-banding
• Low latency improves combat sync
• Packet loss causes desync and disconnects

A clean, stable connection beats high advertised bandwidth.

Recommended Specs by Server Size

Installing the Empyrion Dedicated Server: Steam UI vs. SteamCMD

On Windows, you can install the Empyrion Galactic Survival dedicated server through Steam’s Tools library or SteamCMD. The main difference is how you manage paths, updates, and automation.

Steam UI Installation

This installs the server through Steam’s Tools library.

• Uses the Steam client
• No game ownership required
• Installs to the default Steam library path
• Manual updates through Steam

Use This If:

• You host on a personal machine
• You want the fastest possible setup
• You do not need automation

Common Steam UI Problem: Server Not Showing

Many users do not see the dedicated server in Tools.

Fixes:

• Restart Steam
• Restart the Steam client as admin
• Use the direct install link: steam://install/530870

This can be caused by Steam Library filters, client state, or installation visibility rather than the dedicated-server executable itself.

SteamCMD Installation

SteamCMD installs the server without a graphical client.

• Works on headless systems
• No Steam account required
• Uses anonymous login
• Allows custom install paths
• Supports scripted updates and restarts

Basic Install Logic:

steamcmd +force_install_dir "C:\EmpyrionServer" +login anonymous +app_update 530870 validate +quit

Copy dedicated.yaml to a custom file such as MyServer.yaml, then configure that copy. To launch it, edit a copy of the supplied startup script to use EmpyrionLauncher.exe -startDedi -dedicated MyServer.yaml.

Use this if:

• You run Linux or Docker
• You use a hosting provider
• You want automation and clean updates

This is the standard approach for long-running servers.

Important Clarifications

• You can have multiple installs using different methods
• Use one update method consistently for each installation
• Mixing update methods can create path confusion and unexpected file-management behavior

Steam UI installs can run in the background.SteamCMD is well suited to headless systems and scripted maintenance because it does not require the full Steam client interface.

Local Hosting Note

If you run the client and server on the same machine:

• Start the Steam client first
• Then launch the dedicated server

This avoids a known Steam conflict.

Why SteamCMD Is Preferred Long-Term

SteamCMD gives you control.

• Scripted updates
• Scheduled restarts
• Clean validation
• Predictable behavior

Steam UI is suitable for simple local use. SteamCMD is usually more convenient for automated production hosting.

Core Configuration Files Explained: Where Settings Actually Apply

Many configuration problems occur because administrators edit a scenario template instead of the file used by the active save.The Empyrion Galactic Survival dedicated server separates server startup settings from save-level gameplay settings.

If you do not understand this split, the settings will look ignored.

dedicated.yaml: Server-Level Configuration

This file controls how the server process runs.

You use it for:

• Server name and description
• Max players
• Public visibility
• Telnet and admin access
• Scenario selection

Most dedicated.yaml changes should be made while the server is stopped and then verified after a restart.

This file primarily controls server-level settings, startup behavior, save selection, and scenario selection. Many gameplay rules are stored separately in the active save’s gameoptions.yaml.

gameoptions.yaml: World-Level Rules

This file controls how the game world behaves.

You will commonly encounter gameoptions.yaml in two relevant locations:

1. Scenario template (new games only) Content/Scenarios/[scenario]/gameoptions.yaml
2. Active save (existing worlds) Saves/Games/[savename]/gameoptions.yaml

You edit different locations depending on whether the world already exists.

Editing the Correct gameoptions.yaml

A common reason settings appear ineffective is that the wrong gameoptions.yaml copy was edited.

When editing an existing world, confirm that you are changing Saves/Games/[savename]/gameoptions.yaml rather than the original scenario template.

Correct workflow:

1. Stop the server
2. Edit Saves/Games/[savename]/gameoptions.yaml
3. Start the server

When Changes Take Effect

Not all settings behave the same.

Restart only

• Server visibility settings
• Player count limits
• Telnet configuration

Restart

• Most gameplay options
• PvP and resource rules
• Difficulty multipliers

New save required

• Scenario changes
• Game mode changes
• Certain playfield rules

Existing playfields may keep old values even after restarts.

YAML Formatting Rules

YAML errors can appear in the server logs; check them if configuration changes fail or the server will not start.

Common Mistakes:

• Using tabs instead of spaces
• Using inconsistent indentation or placing a value under the wrong YAML key
• Editing the wrong file location
• Saving as .txt instead of .yaml
• Wrong ValidFor: section (SP vs MP)

These errors can cause values to be ignored, trigger parser errors, or prevent the expected configuration from loading. Check the startup logs after every change.

Safe Change Guidelines

Golden rule: Never edit files while the server runs.

A Configuration Rule That Prevents Common Mistakes

• dedicated.yaml starts the world
• gameoptions.yaml defines how it plays
• The active save determines which save-level configuration is loaded

Understand that distinction, and configuration changes become easier to verify.

Empyrion Dedicated Server Ports, Firewall Rules, and Network Visibility

If your server starts but never appears publicly, incomplete port, NAT, firewall, or visibility settings are common causes.

The Empyrion Galactic Survival server relies on multiple ports, both protocols, and multiple executables.

Required Port Range (Default)

Empyrion does not use a single port.

If your base port is 30000, you must open:

For the default configuration, make ports 30000–30003 available for both TCP and UDP.

For admin access: Port 30004 (TCP) should only be accessible from trusted networks (LAN, VPN, or localhost).

TCP and UDP Are Both Required

Empyrion uses both protocols.

The official setup guidance recommends allowing both TCP and UDP for the configured game port and the following three ports.

Incorrect TCP or UDP rules can cause discovery, connection, or playfield-transition problems. Test the complete required gameplay range instead of diagnosing the server from one symptom alone.

Windows Firewall

On Windows, Empyrion runs two separate executables:

• EmpyrionDedicated.exe (main server process)
• EmpyrionPlayfieldServer.exe (hosts active playfields; one process can host multiple playfields)

A playfield server process can host multiple playfields. Large servers may spawn many.

Windows Firewall must allow both executables for TCP and UDP inbound traffic on the firewall profile active on the server network.

Allowing only one executable causes:

• Invisible servers
• Random disconnects
• Playfield loading failures

Telnet Port

Telnet uses TCP port 30004 by default.

Best practice:

• Do not forward Telnet publicly
• Bind to localhost or a private network
• Use a strong password

Home Router Guidance

For home hosting:

• Forward each port individually if ranges fail
• Match internal and external ports
• Ask the ISP for a public IPv4 address, use an appropriate tunnel or VPN solution, or host the server on infrastructure with a publicly routable address
• Some consumer routers may require individual port-forwarding rules instead of a range

Cloud Servers

On VPS or bare metal:

• Open ports in the provider firewall
• Open ports in the OS firewall
• Confirm UDP is allowed

Cloud and hosting-provider firewalls may require separate UDP rules in addition to the operating-system firewall.

Why Servers Run but Don’t Appear

A server process can run normally even when NAT or firewall rules prevent external reachability.

Common Causes:

• UDP blocked
• Only one executable allowed
• Firewall allows inbound but blocks outbound
• Wrong port range forwarded
• Port checker tools reporting false negatives

A running server is not a reachable server.

Same-Machine Hosting Note

If you host and play on the same PC:

• Start the client first
• Connect using 127.0.0.1 from the server machine or the host’s private LAN address, such as 192.168.x.x, from another local device
• Avoid alternate port ranges when testing locally

How to Manage an Empyrion Dedicated Server (EAH-Based Workflow)

Empyrion Admin Helper (EAH) can assist with player administration, monitoring, commands, backups, and scheduled maintenance. Its access requirements depend on whether you use the Full or Lite deployment model.

What is EAH?

Empyrion Admin Helper, or EAH, is included with the dedicated server package, and current versions are delivered through official Empyrion server updates.

The following workflow explains the main EAH deployment and access considerations.

Step 1: Check Whether Your EAH Setup Requires Telnet

EAH Lite and remote-management configurations commonly use Telnet for server commands. Enable Telnet only when the selected EAH configuration requires it, and restrict the interface to a trusted private network.

For a Telnet-based EAH setup, configure:

• Telnet enabled
• A defined Telnet port (commonly 30004)
• A strong Telnet password

If Telnet is enabled, restrict access to localhost, a trusted LAN, or a VPN using firewall rules. Do not forward its port to the public internet.

Step 2: Verify Telnet Access If Your EAH Setup Uses It

Once Telnet is enabled, the next requirement is network access. Even a correct configuration will fail if Telnet traffic is blocked by:

• OS firewalls
• Hosting provider firewalls
• Router rules

Most setups use port 30004, but the exact port matters less than consistency. If EAH cannot connect, the server will appear offline inside the tool even while it runs normally.

Step 3: Install EAH and Choose the Right Version

EAH is used alongside the Empyrion dedicated server. Use the copy included with the server package, as current EAH versions are delivered through official Empyrion server updates.

Two versions are commonly used.

• EAH Lite is intended for remote administration and may use Telnet for commands plus FTP for file access, depending on the hosting environment.
• EAH Full normally runs on the same Windows machine as the dedicated server and provides deeper local process and file integration.

EAH Full and EAH Lite use different deployment models, so follow the documentation for the version and hosting arrangement you use.

Step 4: Configure EAH Connection Details

Once installed, EAH needs to know how to reach the server.

Remote EAH Lite setups may use Telnet for commands and FTP for file access. Local EAH Full deployments use a different integration model.

Depending on the EAH version and hosting arrangement, admins may need:

• Server IP or hostname
• Telnet port and password
• FTP host, port, credentials
• Server directory path (host-specific)

The available commands and file operations depend on the selected EAH version, its permissions, and the interfaces supplied by the hosting provider.

Step 5: Establish a Management Routine

Once EAH connects successfully, management becomes repeatable.

Daily, admins use EAH to:

• Check server status and player activity
• Run admin commands through a controlled interface
• Trigger saves before planned actions

Over time, most servers adopt a schedule.

Regular tasks often include:

• Player data refresh
• Log review
• Planned restarts when monitoring or maintenance policy shows they are needed

This is where EAH helps most. Instead of reacting to crashes, admins operate on a predictable rhythm that matches how Empyrion behaves under load.

Step 6: Choose the Right Remote Management Model

In practice, EAH is used in three ways.

• Local management runs EAH on the same machine as the server. This offers full access and minimal complexity.
• Remote Telnet-only access allows command control but limits file operations. It works for monitoring and quick actions but does not scale well.
• Remote Telnet with FTP can provide command and file access for EAH Lite when the hosting provider supports both interfaces. For rented servers, use the management interfaces supplied by the provider and expose only the minimum access required.

Updating, Validating, and Patching Without Breaking Your World

Let’s discuss how to update the Empyrion Galactic Survival dedicated server safely, including scenarios like Reforged Eden 2.

Safe Update Workflow

Follow this order. Do not skip steps.

• Stop the server cleanly
• Shut down EAH or any server manager
• Back up:
  • Saves/
  • dedicated.yaml
  • Any custom startup scripts
  • Your active custom YAML (such as MyServer.yaml) and custom scenario files
• Update the dedicated server
• Update scenarios and mods
• Start the server
• Check logs before players join

Skipping backups is how worlds get lost.

SteamCMD Update Commands

For standard updates:

steamcmd +force_install_dir "C:\YourServerPath" +login anonymous +app_update 530870 validate +quit

For experimental branch:

steamcmd +force_install_dir "C:\YourServerPath" +login anonymous +app_update 530870 -beta experimental validate +quit

Validation checks file integrity. It does not repair saves.

When Validation Helps and When It Doesn’t

Use validation when:

• The server fails to start
• Files are missing
• An update stopped mid-download

Run validation once, then inspect the server logs. Repeat it only if SteamCMD reports an incomplete update or validation operation.

Do not expect validation to fix:

• Corrupted saves
• Broken scenarios
• Config mistakes

Validation checks Steam-managed installation files and reacquires missing or mismatched files. It does not repair saves, scenarios, or configuration logic.

Scenario Updates

Scenarios update independently from the base game.

Important facts:

• Reforged Eden 1 is obsolete and no longer supported
• Reforged Eden 2 is the newer Workshop scenario and is labeled beta
• Steam can update the subscribed Workshop copy of a scenario
• A scenario copied into Content/Scenarios must be synchronized manually or through your own automation

How to Update Scenarios on a Dedicated Server

For Workshop-based scenarios:

• Let Steam update the scenario
• Copy from:Steam/steamapps/workshop/content/383120/[scenario_id]
• Paste into:Content/Scenarios/
• Rename the copied folder to a stable scenario name that matches the CustomScenario value in dedicated.yaml

If the CustomScenario value does not match the local scenario folder name, the scenario will not load correctly.

Scenario Compatibility Rules

Always read scenario change notes.

Possible Outcomes:

• Works with existing saves
• Requires pda readdata command
• Requires a new save

Major scenario updates may introduce compatibility requirements or receive follow-up fixes, so review the release notes before updating a production save.

PDA Updates After Scenario Changes

Some scenario updates require this command:

pda readdata

Run it in-game as admin after updating.Run this command only when the scenario author’s update instructions require the PDA data to be reloaded.

Cache and Bundle Cleanup

Some updates require manual cleanup.

Perform cache or bundle cleanup only when the scenario author or release notes explicitly require it.

Scenario authors usually mention this in patch notes.

Hosting vs Self-Hosting Updates

Update behavior depends on where you host.

Self-Hosting

• Full control
• Manual backups required
• Validation optional

Hosting Providers

• May auto-update
• May overwrite configs
• May not back up saves

Always confirm update policies before major patches.

Version Mismatch Issues

If players cannot connect after an update:

• Check server version
• Check client version
• Experimental and stable clients cannot mix

A client and server version mismatch is a common post-update cause of connection failure.

YAML and Script Protection

Updates can reset files.

Protect yourself:

• Back up the active server YAML, including any custom file named in the startup script
• Rename custom .cmd or startup files
• Restore configs after updates if needed

Keep custom configurations and startup files backed up because stock files can be replaced during updates.

Linux, Docker, and Wine: Practical Deployment Considerations

Let’s explore what actually runs when you host Empyrion on Linux, and where things break when one layer slips.

How Empyrion Runs on Linux

Never Run the Server as Root

Running the game process as an unprivileged user is strongly recommended.

Running Wine or Empyrion as root creates unnecessary security risk and can produce unsafe ownership or permission inconsistencies.

Best Practice:

# Create a dedicated user

sudo useradd -m -s /bin/bash empyrion

# Prefer rootless Docker or follow the selected image’s documented user configuration

# Set proper ownership

sudo chown -R empyrion:empyrion /path/to/server

Linux Permission and Ownership Problems

Permission errors can appear as failed saves, missing logs, or startup problems rather than one consistent symptom.

Symptoms include:

• Saves stop updating
• Logs stop writing
• Worlds load but do not persist

How to Fix It

Set the correct ownership after creating or copying the server files:

sudo chown -R empyrion:empyrion ./gamedir

Case-Sensitive Paths Still Matter

Linux treats paths strictly.

This causes:

• Scenarios loading on Windows but not Linux
• Config files ignored
• Workshop content skipped

Rules:

• Match folder names exactly
• Avoid mixed casing
• Do not rename scenario folders casually

Wine Updates Can Break Stable Servers

Wine changes behavior across versions.

What admins report:

• Server runs fine
• Wine updates
• Server hangs or crashes

How to Control This

If using Docker, use specific image tags instead of :latest:

Use a maintained community image and pin an immutable tag documented by its registry. Do not use an unverified generic image name or rely on :latest for production.

Playfields Multiply Resource Use

Active playfields consume resources through playfield server processes, which can host multiple playfields.

On Linux:

• Wine processes scale quickly
• Memory and CPU use can increase as more playfield processes become active. Measure the behavior on the selected game version, scenario, and compatibility layer.

Plan RAM for peak playfield count, not idle state.

Docker: Helpful or Harmful

Docker does not remove complexity.It moves it.

Docker Helps When:

• You want repeatable deployments
• You run multiple servers
• You redeploy often

Some community images can run SteamCMD during container startup or simplify installation scripts. Verify the selected image’s exact update policy before deployment.

Docker Hurts When:

• You debug live issues
• You misconfigure volumes
• You assume the container forwards shutdown signals safely without verifying the image’s behavior

Docker Volume Mapping Is Mandatory

If the image’s save and configuration paths are not stored in persistent volumes, data can be lost when the container is replaced.

Use the exact image name, persistent paths, environment variables, and shutdown procedure documented by the maintained community image you select. Confirm that save, scenario, and configuration data persists outside the container.

If Docker created the folder as root, fix ownership immediately:

sudo chown -R [documented-container-uid]:[documented-container-gid] /host/path/gamedir

Correct Shutdown Inside Docker

Do not assume that stopping a container triggers an in-game save and clean shutdown.

Correct Order:

• Connect via Telnet (port 30004)

Run: saveandexit 0

or saveandexit 5

• Wait for shutdown confirmation
• Let the container stop

Initiate a clean in-game shutdown before restarting or replacing the container unless the selected image explicitly documents safe termination-signal handling.

Required Docker Port Mapping

With Docker bridge networking, publish the required ports using the mappings below. With host networking, Docker ignores these mappings; use the host firewall to allow gameplay traffic and restrict Telnet to trusted sources.

Example:

-p 30000-30003:30000-30003/udp

-p 30000-30003:30000-30003/tcp

-p 127.0.0.1:30004:30004/tcp

Missing TCP or UDP gameplay mappings can cause server discovery, connections, or playfield transitions to fail.

Easy Anti-Cheat and Wine

Set EACActive: false in dedicated.yaml:

ServerConfig:

EACActive: false

Linux vs Windows: Honest Tradeoff

Linux strengths:

• Lower OS overhead
• Supports automation and container orchestration

Linux costs:

• Wine dependency
• More layers to debug
• Higher setup effort

Windows strengths:

• Native execution
• Fewer failure points
• Faster troubleshooting

Who Should Use Linux or Docker

Use Linux or Docker if:

• You already manage Linux systems
• You understand Wine limits
• You accept operational overhead

Avoid them if:

• This is your first server
• You want minimal upkeep
• You need fast fixes

Backup Strategy and Operational Hardening for Long-Running Servers

Long-running Empyrion servers require monitoring, consistent backups, controlled updates, and verified shutdown procedures.

What You Must Back Up (And Why It Matters)

Not all server data has equal value.Back up what keeps the world alive.

Always Back Up:

• Saves/This is the world state. Lose it and everything resets.
• dedicated.yamlOne overwrite can expose admin access or break server visibility. Also back up the custom YAML named in your startup script, such as MyServer.yaml.
• Content/Scenarios/ (custom scenarios only)Scenario updates can change structure without warning.

Optional, but Smart:

• Logs/Useful for tracing slow corruption or memory issues.
• Custom startup scriptsUpdates overwrite defaults more often than people expect.

If you back up only binaries, you back up nothing that matters.

Backup Frequency and Timing (What Actually Works)

A backup taken while files are changing can be inconsistent unless the backup method coordinates with the running application.

Follow These Rules:

• For ordinary file-copy backups, shut down the server cleanly and wait for writes to finish; use live backups only when the method coordinates with the running application
• Avoid peak player hours
• Avoid copying mutable save data during heavy playfield activity unless the backup system provides application-consistent snapshots

Safe Workflow:

1. For an offline backup, initiate a clean save and shutdown through an approved administration method

(saveandexit 0 or saveandexit 5)

1. Wait for disk writes to finish
2. Copy backups
3. Restart only if planned

For Active Servers:

• Daily rolling backups
• Weekly off-machine copy
• Monthly cold archive

Disk is cheap. Worlds are not.

Restart Schedules and Memory Cleanup

Monitor memory use across long sessions, especially with custom scenarios and many simultaneous playfields.

If monitoring shows sustained resource growth or unresponsive playfields, schedule a clean maintenance restart and investigate the underlying logs and workload.

Always Restart Cleanly:

• Save first
• Let playfields shut down
• Then stop the server

Forced termination can interrupt writes and increase the risk of inconsistent save data.

Admin Access and Telnet Hardening

Telnet can provide powerful in-game administrative control and should be protected as a sensitive management interface.

Hard Rules:

• Never expose Telnet to the public internet
• Restrict access to localhost or trusted private networks using firewall rules
• Use strong admin passwords

If Telnet Leaks:

• Players can spawn items
• Worlds can be wiped

If you do not need remote admin access, disable Telnet entirely.

Preventative Ops, Not Disaster Recovery

Good operators do not wait for failure.

You Schedule:

• Backups before problems
• Restarts before crashes
• Updates during low activity
• Validation only when needed

This Helps:

• Reduce backup gaps
• Control maintenance windows
• Limit avoidable unplanned downtime

Backups, monitoring, controlled updates, and clean shutdowns reduce several common operational risks.

Common Empyrion Dedicated Server Problems

Here are common Empyrion dedicated server problems, possible causes, and practical fixes.

Running Empyrion at Scale: Multiple Servers, Regions, and Performance

Running Empyrion at scale is not only about making one server bigger. It also requires multiple instances to remain isolated, predictable, and free from directory or port conflicts.

Multi-Instance Setups (How Empyrion Actually Scales)

Empyrion does not support clustering or shared worlds.

Each server instance is isolated.

That means:

• One instance = one universe
• No shared saves, playfields, or state
• Scaling happens by running multiple instances, not linking them

Common multi-instance layouts:

• PvE and PvP on separate servers
• Vanilla on one instance, Reforged Eden 2 on another
• Production server plus a test server

Each instance must have:

• Its own install directory
• Its own dedicated.yaml
• Its own save folder
• Its own port range

Sharing writable directories, saves, or ports between instances can create conflicts.

Port Separation and Resource Planning

Gameplay ports cannot overlap on the same IP address and protocol.

Each Empyrion server uses:

• One four-port gameplay range
• A separate private Telnet port if administration access is enabled

Example layout:

• Server 1 gameplay → 30000–30003
• Server 2 gameplay → 30010–30013
• Server 3 gameplay → 30020–30023

Resource planning rules that matter:

• RAM use depends on active playfields, player activity, and scenario load
• CPU demand depends on the total active playfields, players, scenarios, and background processes across all instances
• Disk I/O spikes during saves, restarts, and updates

Measure host-level CPU, memory, and disk headroom before adding another instance because playfield demand can change quickly.

Geographic Placement and Player Experience

Latency, packet loss, jitter, and available bandwidth all affect multiplayer responsiveness.

Distance impacts:

• Ship movement smoothness
• Combat timing
• Playfield transitions

Best Practice:

• Host servers close to where most players live
• Split regions if your player base is clearly divided

One central server works only if latency stays reasonable for everyone.

When Edge or CDN Distribution Helps (and When It Doesn’t)

A conventional web CDN is suitable for downloadable scenario assets, not direct Empyrion gameplay traffic. Use only networking services that explicitly support the game’s protocols.

Edge distribution only helps with:

• Scenario file downloads
• SharedData cache delivery

Use edge locations for content distribution, not gameplay.

The Real Limit to Scaling

Player count is only one capacity factor.

Capacity and stability problems can also result from:

• Port collisions
• RAM starvation
• Unplanned restarts
• Too many servers sharing one machine without isolation

Scaling works when you:

• Isolate instances completely
• Allocate ports deliberately
• Budget RAM conservatively
• Use monitoring-based maintenance windows

Scaling fails when you “just add another server.”

How RedSwitches Supports Empyrion Dedicated Servers

A reliable Empyrion world takes more than a successful launch. Active playfields need resource headroom, players need the full gameplay port range, and every update needs a recoverable save.

As your community grows, monitoring those demands matters more than choosing hardware by player count alone.

RedSwitches offers single-tenant dedicated servers with Windows Server options, configurable CPU, RAM, and SSD or NVMe storage, plus administrator and IPMI access.

That gives you control over firewall rules, separate server instances, and the maintenance routine your world requires. You still choose the game settings, manage scenarios, and protect your saves.

If your current machine is reaching its limits, explore RedSwitches’ Windows dedicated servers and choose a configuration based on your active playfields, storage needs, and where your players connect.