ECO Dedicated Server Guide 2026: Setup, Ports & Linux
Your ECO world can keep running after the last player logs off. Keeping it reachable and protecting weeks of progress takes more than installing the server.

An ECO dedicated server runs your world independently of players’ game clients.While running and unpaused, it can continue processing the world even with nobody connected.
Start by installing the server on Windows or Linux, authenticating it, and configuring networking and player access. Then match your hardware to the workload and set up backups you have tested restoring.
This guide covers Windows and Linux setup, Docker considerations, hardware requirements, ports, and recovery. You’ll learn how to get players connected, troubleshoot common failures, and maintain the world as your community grows.
ECO 2026 Latest Updates
ECO 14.1.1 is the latest published stable release as of September 30, 2026. Released on September 6, it fixed an issue allowing bank-account data manipulation and a server startup crash associated with plugin load order.
Update 14 is a released production version, rather than a playtest-only release. Keep playtest files, worlds, ports, configurations, and mods separate from a stable production server. Create an external backup before testing a major-version migration.
Update 14.1 explicitly supports migration of Update 14 worlds. Check the relevant release notes and test a restored copy before migrating older worlds.
ECO Dedicated Server Quick Facts
| Item | Current Detail |
|---|---|
| Main game App ID | 382310 |
| Dedicated server App ID | 739590 |
| Server type | Free official Steam Tool |
| Latest stable version | ECO 14.1.1 |
| Stable release date | September 6, 2026 |
| Supported server OS | Windows and native Linux |
| Windows executable | EcoServer.exe |
| Linux executable | EcoServer |
| Main game port | UDP 3000 |
| Web interface port | TCP 3001 |
| Optional RCON port | TCP 3002 |
| Main network config | Configs/Network.eco |
| User and admin config | Configs/Users.eco |
| World and backup directory | Storage/ |
| Mods directory | Mods/ |
How an ECO Dedicated Server Actually Works (Beyond the Basics)
An ECO dedicated server keeps simulating the world while running and unpaused, even when no players are connected.
World Activity Continues Between Sessions
- Active crafting jobs and scheduled world processes can continue.
- Pollution and ecosystems respond to world conditions.
- Laws remain in effect.
Uptime Affects World Progression
Pausing or stopping the server halts normal simulation activity. After a restart, the world resumes from its most recently saved state.
The default meteor setting is 30 real-life days. Verify countdown behavior on your current build before relying on downtime to delay impact.
Resource Needs Can Change Over Time
- CPU: Simulation can consume CPU even with no players online; load depends on world activity and settings.
- Memory: Usage varies with world size, activity, databases, and mods. Monitor peak usage and usage after restarting.
- Storage: Saves and statistics can grow as activity accumulates. Monitor the complete
Storagedirectory.
Stopping the server releases process memory, but persistent world data remains.
What This Means for Hosting
Compare hosting options using sustained per-core performance, available RAM, storage latency, monitoring, and planned uptime.
ECO Dedicated Server Requirements
ECO’s official minimum requirements apply to the default 72×72 world. Larger worlds, public communities, extensive civic data, and mods may require additional resources, so monitor CPU, memory, and storage use after launch.
The following factors are useful when planning a production deployment.
CPU
ECO is strongly affected by its main simulation thread. Additional cores can support the operating system and secondary workloads, but sustained per-core performance remains important.
Prioritize:
- High sustained single-thread performance
- Modern consumer or workstation CPUs
- Fewer fast cores over many slow ones
Avoid Choosing Hardware Solely By:
- Processor category or core count without checking sustained per-core performance
- Older processors selected only because they provide many cores
- Oversubscribed plans with inconsistent single-thread performance
Do not choose a processor solely by total core count. Compare sustained single-core performance, clock behavior, processor architecture, and the exact CPU generation.
RAM
A mature world may require more memory than a new world, but the server process releases its allocated RAM when it stops.
Memory use can vary with:
- Player count
- World age
- Mods and plugins
A new public server may run comfortably above the official 4 GB minimum, depending on world size, player activity, and installed mods. Large or heavily modded worlds may require substantially more memory. Configure monitoring and alerts because sustained memory pressure may cause swapping, degraded performance, or an out-of-memory termination.
Storage and Backup I/O
ECO stores persistent world, statistics, configuration, and backup data whose size varies with activity and retention settings.
You need:
- Fast SSD or NVMe storage
- Enough space for multiple backup generations
- I/O headroom during backup windows
Network Requirements and Troubleshooting
ECO benefits from stable latency, low packet loss, and sufficient bandwidth for the expected player count and mod load.
Common network and reachability checks include:
- Blocked UDP ports
- Incorrect automatically detected or manually advertised addresses
- Hosting firewalls
Low throughput, packet loss, traffic shaping, or provider filtering can still affect server reachability and player experience.
Practical Sizing by Player Count
These are illustrative planning estimates, not verified player-capacity ratings or official ECO requirements. Validate them against the current ECO version, world size, mod load, measured concurrency, and monitored resource use:
- 5–10 players: 4 fast cores, 16 GB RAM
- 15–30 players: 6–8 fast cores, 24–32 GB RAM
- 40+ players or heavy mods: dedicated CPU, 32–64 GB RAM
Leave upgrade headroom and monitor RAM, storage, and CPU trends as world complexity and activity change.
ECO Dedicated Server Ports and Server Visibility (Why Servers Don’t Show Up)
If players cannot find or join the server, check UDP reachability, public-listing settings, NAT, browser filters, the advertised address, version compatibility, and server logs.
The Ports ECO Actually Uses
Each ECO port serves a different role. Open only the ports required for the features you use.
Game Connection Port: 3000/UDP
Handles player connections and world data. Blocked UDP 3000 can prevent direct gameplay connections and affect server reachability. This is the default port players use to join the world.
Web Interface Port: 3001/TCP
Powers the admin web panel and query system. A working web panel confirms TCP 3001 reachability, but it does not verify UDP gameplay traffic.
RCON Port: 3002/TCP
Provides optional remote console administration. RCON is disabled until a valid password is configured in Network.eco. Restrict this port to trusted source IPs whenever possible.
Offline Steam Server Port: 3003
Used for Steam game-server traffic when offline mode is enabled. It is not required for a standard online deployment.
Why the Web Panel Works but Players Cannot Join
The web panel uses TCP on port 3001. Player connections rely on UDP on port 3000. A firewall can allow TCP while silently blocking UDP.
In that state, the server looks healthy. The web UI at http://your-ip:3001 loads. Players may still be unable to find the server, join it, or both, depending on which network or listing path is failing.
This pattern indicates that TCP web traffic is reachable while UDP gameplay traffic still requires testing.
Common Reasons ECO Servers Do Not Appear
Common visibility and connection causes include:
UDP Port 3000 Blocked by Firewall or Hosting Provider
Windows Firewall, router NAT rules, and provider firewalls may block UDP independently from TCP. Allow UDP 3000 explicitly when direct gameplay connections are required.
Incorrect Advertised Server Address
Leave RemoteAddress empty when ECO detects the correct public address automatically. Set it only when automatic detection is wrong or you need to advertise a specific hostname or port.
PublicServer Disabled in Server Settings
With PublicServer = false, the server is unlisted rather than access-restricted. Enable PublicServer for public listing, and configure a password separately if access must be restricted.
Game Version Mismatch between Client and Server
Client and server versions must be compatible. A mismatched server may be filtered from normal browser results or reject the connection.
Testing Your Ports
Do not assume ports are open. Verify them.
- UDP 3000: Test by attempting direct connect from an external network
- TCP 3001: Access http://your-external-ip:3001 from outside your LAN
- UDP 3000 carries direct gameplay traffic. TCP 3001 serves web-interface and query traffic; expose that endpoint when external clients or tools require it.
If the web interface loads but an external direct connection fails, UDP 3000 or its NAT path is a likely cause and should be tested.
Server List vs Direct Connect
Server list visibility and direct connect use different paths.
Public Listing and Joinability Checks:
- UDP 3000 reachable
- PublicServer = true
- Correct externally advertised address, detected automatically or configured with RemoteAddress
- Server version compatible with clients
Direct Connect Requires:
- UDP 3000 reachable
- Correct IP:port shared with players
A successful connection over a confirmed direct UDP path demonstrates gameplay reachability; a relayed connection does not prove the server’s public UDP port is reachable.
Then check PublicServer, browser filters, the advertised address, version compatibility, and communication with the listing service.
ECO Dedicated Server Setup on Windows (Steam Tool + SteamCMD)
Windows can host ECO reliably when updates, restart behavior, service management, security, and backups are configured deliberately. The goal is to prevent uncontrolled interruptions during active simulation.
When Windows Is an Acceptable Choice
Windows is suitable for scenarios such as:
- Small or private ECO servers
- Short-lived worlds or seasonal play
- Test, staging, or mod development servers
- Schools or labs already standardized on Windows
- Admins who rely on a GUI for configuration and monitoring
With controlled maintenance windows and monitoring, Windows can support both small and long-running ECO worlds.
When Windows Becomes an Operational Risk
ECO benefits from predictable uptime. Unmanaged Windows updates or restart policies can interrupt the server unexpectedly.
Primary Failure Vectors
- Operating System UpdatesWindows may schedule update-related restarts unless maintenance and restart policies are configured.
- Deferred RebootsDeferred restarts may occur at an inconvenient time if maintenance windows are not configured.
- Long-Term Resource MonitoringA mature or heavily modded world may require more memory than a new default world.
Windows background services consume some resources, so monitor their impact alongside the ECO process.
Monitor CPU, memory, storage, logs, and restart frequency so performance problems can be identified before they affect players.
For persistent ECO servers, unmanaged updates, restarts, and background maintenance can disrupt gameplay continuity.
Installation Paths on Windows
Windows offers multiple official installation methods. SteamCMD is generally preferable when automation and controlled updates are required.
Steam Tools (Manual Management)
- Installed via Steam → Library → Tools
- Fast initial setup
- Update timing tied to Steam client behavior
This approach is convenient for manually managed servers, but update timing should be coordinated so clients and the server remain compatible.
SteamCMD (Recommended for Automation)
- Headless installation
- Explicit update control
- Reproducible deployments
SteamCMD is recommended when you need scripted installation, controlled updates, and reproducible deployments.
Recommended Command (Windows Command Prompt):
steamcmd +force_install_dir "D:\EcoServer" ^
+login anonymous ^
+app_update 739590 validate ^
+quit
Production-Oriented Setup Flow
A stable Windows deployment follows a strict sequence.
1. Dedicated Server Directory
Use a non-system path:
D:\EcoServer
Avoid:
- Program Files
- User profile directories
- System-protected paths
A separate server directory simplifies permissions and maintenance, but correct access rights and controlled updates are still required.
2. Controlled Installation
Install the server using SteamCMD or Steam Tools. Do not replace server files while the ECO process is running; stop, back up, update, and restart through a controlled workflow.
3. First Launch for Configuration Generation
For online hosting, obtain an account token from your play.eco account and launch the server from its installation directory with .\EcoServer.exe -userToken=YOUR_ECO_ACCOUNT_TOKEN.
Replace the placeholder with your token; anonymous SteamCMD login downloads the server but does not authenticate the running server.
Stop it cleanly with Ctrl+C. While the server is stopped, configure administrator access in Configs/Users.eco by adding the intended administrator’s SLG ID or SteamID64 to Admins.
Configure Password in Configs/Network.eco if access should be restricted. WhiteList entries bypass that password; they do not create whitelist-only admission.
Prefer a graceful shutdown and wait for saving to finish. Forced termination can lose unsaved progress or damage files and should be reserved for a process that cannot stop normally.
4. Network Configuration
Configure the following in Network.eco:
- Game port
- Web port
- PublicServer flag
- RemoteAddress only when automatic external-address detection is incorrect
Incorrect values prevent server registration and visibility.
5. Configure Unattended Windows Process Management
For unattended hosting, use a service wrapper, scheduled task, or process supervisor with startup, logging, and restart controls.
Configure the launcher to use the server’s installation directory and pass the required runtime authentication arguments; protect the token and restrict access to the launcher configuration.
Service Management Options
NSSM
- Free
- Lightweight
- Reliable restart handling
Basic setup:
nssm install EcoServer
Set:
- Path: D:\EcoServer\EcoServer.exe
- Startup directory: D:\EcoServer
- Startup type: Automatic
- Restart on failure: Enabled
FireDaemon Pro
- Commercial
- GUI-driven
- Advanced scheduling and monitoring
Windows Task Scheduler Considerations
- Can launch the server automatically at startup
- Requires an additional script or wrapper for controlled shutdown handling
- Provides less lifecycle visibility than a dedicated service manager
Windows Update Control
Unmanaged updates can interrupt an ECO server or create a temporary client-server version mismatch.
Configure update and restart policies to reduce unexpected reboots and schedule routine maintenance; these policies do not guarantee that every reboot will occur within a planned window.
Windows Server / Windows Pro
Group Policy Editor →
Computer Configuration →
Administrative Templates →
Windows Components →
Windows Update →
Manage end user experience → Configure Automatic Updates → (current policy templates; older templates may list the policy directly under Windows Update)
Enable the policy and select “3 - Auto download and notify for install” where supported by the target Windows version.
Windows Home
- Use Active Hours, pause controls, maintenance scheduling, and tested startup behavior. Windows Home provides fewer centralized update-management options than Windows Pro or Windows Server.
Combine Active Hours with planned maintenance, backup checks, and tested restart behavior.
Firewall Configuration
Open required ports explicitly.
PowerShell (Run as Administrator):
New-NetFirewallRule -DisplayName "ECO Game UDP" -Protocol UDP -LocalPort 3000 -Direction Inbound -Action Allow
New-NetFirewallRule -DisplayName "ECO Web TCP" -Protocol TCP -LocalPort 3001 -Direction Inbound -Action Allow
Recheck firewall rules after Windows updates.
Backup Strategy on Windows
Backups protect the simulation state, not just save files.
Critical Paths to Back Up
- Storage/
- Configs/
- Custom mods and overrides
Example Offline Backup Script
This script assumes that EcoServer is the actual Windows service name and that stopping it allows ECO to finish saving before the process exits. Verify that behavior before using the script. A successful service start confirms process startup; check the logs and a client connection to confirm the world is ready.
Save the following script as a .bat file and run it with administrator privileges. The script treats Robocopy exit codes of 8 or higher as copy failures.
@echo off
set ECO_DIR=D:\EcoServer
set BACKUP_DIR=E:\Backups\Eco
net stop EcoServer if errorlevel 1 exit /b 1
for /f %%i in ('powershell -NoProfile -Command "Get-Date -Format yyyyMMdd_HHmm"') do set TS=%%i
mkdir "%BACKUP_DIR%\%TS%"
if errorlevel 1 goto backup_failed
robocopy "%ECO_DIR%\Storage" "%BACKUP_DIR%\%TS%\Storage" /E /COPY:DAT /DCOPY:T /R:3 /W:10 /LOG+:"%BACKUP_DIR%\%TS%\backup.log"
if errorlevel 8 goto backup_failed
robocopy "%ECO_DIR%\Configs" "%BACKUP_DIR%\%TS%\Configs" /E /COPY:DAT /DCOPY:T /R:3 /W:10 /LOG+:"%BACKUP_DIR%\%TS%\backup.log"
if errorlevel 8 goto backup_failed
robocopy "%ECO_DIR%\Mods" "%BACKUP_DIR%\%TS%\Mods" /E /COPY:DAT /DCOPY:T /R:3 /W:10 /LOG+:"%BACKUP_DIR%\%TS%\backup.log"
if errorlevel 8 goto backup_failed
net start EcoServer
if errorlevel 1 exit /b 1
exit /b 0
:backup_failed
echo Backup failed. Do not use this backup directory for recovery. 1>&2
net start EcoServer
exit /b 1
Windows-Specific Requirements
Before running ECO:
- .NET Framework 4.6.2+
- Visual C++ Redistributables
Performance Tuning:
- Add a narrowly scoped Defender exclusion only after confirming measurable scanning overhead or a false positive
- Disable Windows Search indexing for the server directory
- Set power plan to High Performance
ECO Dedicated Server Setup on Linux
Let’s discuss how ECO actually runs on Linux, what you must install yourself, and how to operate it safely in production.
Why Linux Fits Headless ECO Server Deployments
Linux provides native ECO server execution and mature tools for headless process, log, firewall, and update management.
- Configurable update and reboot policies
- Control over unattended upgrades and maintenance timing
- Potentially lower operating-system overhead with a minimal installation
- Native process supervision through systemd
- Native remote management through SSH
Linux can provide predictable operation when unattended upgrades, reboot policies, services, and resource limits are configured correctly.
How ECO Installation on Linux Actually Works
The Linux server package includes an install.sh dependency script, but SteamCMD, permissions, firewall rules, and service management still require administrator configuration.
What You Must Install
- Dependencies installed through the server package’s install.sh script
- Required system libraries
- SteamCMD or direct server binaries
- ECO configuration files (generated on first run)
What ECO Provides
- Server binaries
- Default config templates
- Documentation
Linux deployments still require administrator control of users, permissions, networking, updates, services, logs, and backups.
Optional Third-Party Tool
- LinuxGSM provides installation, startup, update, backup, and monitoring commands; boot automation requires additional configuration.
- It is widely used but not official
- Useful if you want speed over control
Installing ECO Dedicated Server on Linux
The package examples below target Ubuntu 24.04 LTS on amd64. Debian, other Ubuntu releases, and other architectures may require different repositories or dependencies. Validate installation, authenticated startup, and shutdown on the exact ECO build before production use.
1. Create a Dedicated User and Install the Server
sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository -y multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y lib32gcc-s1 steamcmd
sudo useradd -r -m -U eco
sudo -u eco mkdir -p /home/eco/eco-server
sudo -H -u eco /usr/games/steamcmd +force_install_dir /home/eco/eco-server +login anonymous +app_update 739590 validate +quit
2. Install the ECO Linux Dependencies
cd /home/eco/eco-server
sudo chmod +x install.sh
sudo ./install.sh
3. First Run (Generate Config Files)
sudo chown -R eco:eco /home/eco/eco-server
cd /home/eco/eco-server
read -r -s -p "ECO account token: " ECO_USER_TOKEN
printf '\n'
sudo -H -u eco ./EcoServer "-userToken=$ECO_USER_TOKEN"
unset ECO_USER_TOKEN
Let the server start once, then stop it cleanly with Ctrl+C.
This creates configuration files inside the Configs directory.
Common Linux Issues (And How to Avoid Them)
Startup Errors
Check server logs for missing libraries, permission problems, incompatible mods, damaged saves, configuration errors, or an incomplete installation.
Common Checks:
- libgdiplus missing
- Incorrect file ownership or permissions
- Incompatible mods, saves, or configuration files
Recheck the bundled installation script and server logs after major ECO or operating-system upgrades because dependencies can change.
Permission Errors
Linux enforces ownership strictly.
Avoid these mistakes:
- Running the server as root
- Installing as one user and running as another
- Writing world data to protected paths
Service Management for Uptime (Systemd)
Linux does not need third-party tools to manage ECO.
Use systemd.
Before creating the credentials file, create its parent directory:
sudo install -d -m 700 /etc/eco
Create /etc/eco/eco.env, owned by root with permissions 0600, containing ECO_USER_TOKEN=YOUR_ECO_ACCOUNT_TOKEN with the placeholder replaced.
Keep the file out of public repositories and logs. The expanded token is passed in the process arguments, so restrict local access. The 300-second stop timeout below is an example; verify that the chosen ECO build finishes saving and exits before that deadline.
Create a Systemd Service
Create /etc/systemd/system/eco.service using the following systemd service configuration:
[Unit]
Description=ECO Dedicated Server
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=60
StartLimitBurst=3
[Service]
Type=simple
User=eco
Group=eco
WorkingDirectory=/home/eco/eco-server
Environment=HOME=/home/eco
EnvironmentFile=/etc/eco/eco.env
ExecStart=/home/eco/eco-server/EcoServer -userToken=${ECO_USER_TOKEN}
KillSignal=SIGTERM
TimeoutStopSec=300
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=eco-server
[Install]
WantedBy=multi-user.target
Enable and start:
sudo systemctl daemon-reload
sudo systemctl enable eco
sudo systemctl start eco
sudo systemctl status eco
View Logs:
sudo journalctl -u eco -f
Configure automatic startup, monitoring, controlled shutdowns, and recovery for unattended operation.
Update Control on Linux
Linux update timing is configurable, but unattended-upgrade services and provider maintenance policies must still be reviewed.
That matters for ECO.
Safe update workflow:
- Stop the server
- Back up Storage, Configs, custom mods and overrides, and the current server version needed for rollback
- Update via SteamCMD
- Restart cleanly
Update Command:
sudo -H -u eco /usr/games/steamcmd +force_install_dir /home/eco/eco-server +login anonymous +app_update 739590 validate +quit
You decide when the world pauses.
Firewall Configuration
Only expose required ports.
Before enabling UFW remotely, allow the actual SSH port from your administrator’s IP and check provider firewall rules. If SSH uses port 22, for example, run sudo ufw allow from YOUR.ADMIN.IP.ADDRESS to any port 22 proto tcp after replacing the address. Keep the existing session open and confirm a second SSH connection after enabling UFW.
UFW (Ubuntu / Debian)
sudo ufw allow 3000/udp
sudo ufw allow 3001/tcp
sudo ufw allow from YOUR.TRUSTED.IP.ADDRESS to any port 3002 proto tcp
sudo ufw enable
firewalld (RHEL / CentOS)
sudo firewall-cmd --permanent --add-port=3000/udp
sudo firewall-cmd --permanent --add-port=3001/tcp
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="YOUR.TRUSTED.IP.ADDRESS" port protocol="tcp" port="3002" accept'
sudo firewall-cmd --reload
Always verify after OS updates or cloud firewall changes.
Web Interface and RCON Security
ECO supports TCP RCON on port 3002.The web interface uses TCP 3001, while optional RCON administration uses TCP 3002 after a valid password is configured in Network.eco.
Protect it.
- Use a strong password
- Avoid public exposure if possible
- Restrict access to localhost when feasible
- Use SSH tunneling for remote admin access
Example:
ssh -N -L 127.0.0.1:3001:127.0.0.1:3001 -L 127.0.0.1:3002:127.0.0.1:3002 user@your-server
Compromised administrative access can expose credentials, alter the world, or require rollback and incident review.
ECO Dedicated Server with Docker: When It Makes Sense (and When It Doesn’t)
Docker looks attractive for ECO. Clean containers. Easy restarts. Fast deployment.Docker can simplify deployment and isolation, but world and configuration data must be stored in correctly mapped persistent volumes.
This section explains the persistence, backup, update, and monitoring controls a production container requires.
How ECO Behaves Inside Docker
ECO is not a stateless service.
- The world simulation continues while the server is running and unpaused
- Active crafting and scheduled simulation systems can continue
- Pollution, laws, and ecosystem systems continue while the simulation is active
Containers can be replaced or restarted quickly, but recovery still depends on persistent volumes, compatible files, and tested backups.
When Docker Makes Sense for ECO
Docker works well when repeatable deployments, isolation, controlled updates, and persistent volume management are priorities.
Multi-Server Environments
Docker fits well if you run:
- Multiple ECO servers on one host
- Separate worlds for different communities
- Identical configs across regions
Containers reduce config drift. Each server stays isolated.
Testing and Staging
Docker shines for:
- Mod testing
- Update validation
- Short-lived experimental worlds
You can test changes in a disposable container without affecting production when test and production volumes are strictly separated.
Disposable worlds are useful for staging; production containers can also be replaced safely when persistent data remains attached to the correct volumes.
When Docker Causes Problems
Docker deployments become unsafe when administrators treat persistent world and configuration data as disposable container data.
Poor Volume Persistence
Incorrect persistence configuration is a major preventable cause of container data loss.
Mistakes include:
- Not mounting /app/Storage correctly
- Using anonymous volumes without recording their IDs or reattaching the correct volumes when replacing containers
- Binding world data to temporary paths
A container restart should not reset history.If it does, the setup is wrong.
Misconfigured Backups
Docker does not back up data for you.
Common failures:
- Backup jobs interrupted by container restarts, or backup files stored only in the container’s writable layer
- Volumes not included in backup scope
- Uncoordinated raw-volume snapshots taken during active writes
Use ECO’s built-in backups for routine restore points. Stop the container or use a coordinated consistent snapshot before copying the raw live volume externally.
False Sense of Safety
Docker can restart containers automatically when a restart policy is configured. Docker’s default restart policy is no automatic restart; repeated failures still require monitoring and investigation.
- Repeated resource growth can be hidden by automatic restarts
- Recurring crashes may continue without alerts
- The same startup failure may repeat after every restart
A server that restarts forever is not stable.It is broken quietly.
Docker Best Practices for ECO
For persistent ECO deployments, apply the following safeguards.
Use Explicit Volumes
World data must persist in a named volume or bind mount rather than only in the container’s writable layer
- Bind mount /app/Storage
- Bind mount /app/Configs
- Verify paths before first launch
Verify that replacing the container preserves the world and configuration before opening the server to players.
For strangeloopgames/eco-game-server, populate the host Configs directory from an existing server or the matching server ZIP before mounting it at /app/Configs.
If custom mods need separate mounts, mount their specific subdirectories; an empty bind mount over /app/Mods can hide bundled game files.
Set Restart Policies Carefully
Avoid blind restarts.
- Choose on-failure, unless-stopped, or another restart policy that matches your maintenance workflow
- Add restart delays
- Watch crash frequency
Repeated ECO crashes should generate alerts and log review instead of unlimited unattended restart attempts.
Apply Resource Limits
Docker does not protect ECO from itself.
- Set memory reservations or limits only after measuring normal and peak usage
- Monitor swap usage
- Avoid CPU starvation
Without monitoring or sensible resource controls, one container can compete with other workloads on the host.
Docker vs Native Linux for ECO
Docker and native Linux are two deployment approaches with different operational tradeoffs. Availability of an SLG-published Docker image does not establish a support guarantee; check the image’s current documentation and support terms.
- Docker helps manage many servers
- Native Linux provides simpler host-level process and file management
- Docker reduces setup friction
- Native Linux avoids container-specific volume and image-management requirements
Choose native Linux when simpler host-level administration better matches your team’s skills.
Choose Docker when standardized deployment, isolation, cloning, and multi-instance management are priorities.
Choosing the Right Path
Use Docker when:
- You run many short-lived servers
- You need fast cloning and teardown
- You separate testing from production
Reconsider Docker when your team cannot reliably manage:
- Persistent volume mapping and validation
- Graceful shutdowns, updates, monitoring, and restart alerts
- Built-in backups, off-host copies, and periodic restore tests
ECO Dedicated Server Settings That Actually Matter
ECO exposes many configuration options, but only a small subset affects uptime, visibility, recovery, and long-term stability. Assess settings for both their gameplay effects and their impact on performance, access, and recovery.
Incorrect priorities can create visibility, recovery, or performance problems after the server launches.
Ignore Low-Impact Settings During Initial Deployment
Purely cosmetic settings are usually lower priorities during initial deployment. Gameplay and simulation settings can affect server workload, so assess their resource and stability impact individually.
Configure infrastructure-critical settings first, then adjust cosmetic and gameplay options.
Stability comes first. Customization comes after the world proves it can survive the load.
Network Visibility Determines Whether the Server Exists
A running process does not mean a reachable server. ECO public visibility depends on listing settings, reachable gameplay traffic, and a correct externally advertised address, which is normally detected automatically.
Misconfigured visibility can leave a locally running server unavailable to external players. Validate the deployment with real external connections, not only clean logs.
The Web Interface Is Control, Not Proof
The admin web interface confirms that TCP port 3001 responds. It does not confirm that UDP gameplay traffic works. Many failed servers load the web panel perfectly while rejecting players.
Use the web interface to manage the server and check web-service responsiveness, but combine that check with logs, save completion, and an actual gameplay connection.
Access Control Protects the Simulation
ECO worlds persist. Administrative access affects laws, progression, and simulation integrity. Weak credentials or exposed admin access compromise the entire world, not just player accounts.
Configure access control before public launch. If credentials or tokens are exposed, rotate them immediately and review logs and world changes.
Backup Frequency Defines Recovery Capability
ECO maintains persistent state. Backups reduce the impact of crashes, failed updates, incompatible mods, and operator mistakes. Choose a recovery-point objective that matches your community’s tolerance for lost progress.
Local backups provide fast rollback for some failures, while off-host copies protect against disk loss, host loss, and broader compromise. Recovery planning is part of server configuration, not an optional layer.
Performance Settings Do Not Create Capacity
Raising a player cap permits more connections but does not add hardware capacity. Actual resource use depends on connected players and workload; the effects of simulation-limit changes depend on the specific setting.
ECO does not scale linearly with configuration changes.
Stable servers accept conservative limits and allow growth only after observing real memory and tick behavior.
Know What Can Change During Runtime
Some Server UI changes can apply immediately when saved, while direct edits to .eco configuration files generally require a restart. World-defining parameters require additional caution.
Most WorldGenerator.eco changes require regenerating the world. Other simulation settings may remain editable after creation, but their gameplay impact should be tested on a backup first.
Avoid Bulk Configuration Changes
Multiple simultaneous changes remove failure visibility. When something breaks, you lose the cause.
Change one category, observe behavior, then proceed. This discipline makes faults easier to isolate, while tested backups provide a recovery path when changes damage a world.
Pattern of Stable ECO Servers
For long-running worlds, prioritize measured tuning, appropriate access control, regular backups, and limits suited to the available resources.
These choices align with ECO’s persistent simulation model, where errors compound instead of resetting.
Once these settings are stable, operating system behavior and hardware selection become the next limiting factors.
Backup, Recovery, and Long-Term Stability
Let’s discuss the backup, recovery and long term stability of ECO dedicated server.
Why ECO Requires Disciplined Backups
ECO maintains continuously changing world state and writes saves to storage at configured intervals. An interrupted save or unsafe file-level copy can risk world integrity, which is why graceful shutdowns and verified backups matter.
Stable servers assume failure will happen. Backups exist so recovery stays controlled.
What Must Be Backed Up
Backing up only the world file is not enough. A full recovery requires all state that influences simulation and access control.
You must back up:
- World DataStorage/ — Contains world saves, statistics, and automatic backup data.
- Configuration FilesConfigs/ — Contains network, user, backup, storage, world-generation, difficulty, performance, and other server settings.
- Mods and Mod ConfigurationCustom mods and overrides — Preserve their exact versions and verify compatibility before restoring them onto a different ECO build.
- Sensitive User and Access Data (Already Included in Configs/)Configs/Users.eco — Contains administrators, access lists, queue settings, and sensitive API credentials.
Missing any of these turns recovery into manual reconstruction.
How to Back Up Safely
The safest backup happens when the server is not writing data.
Preferred Method (Recommended):
- Stop the server cleanly.
- Copy required directories
- Restart the server.
ECO’s built-in automatic backups can run while the server is active. External raw-file copies should follow a clean shutdown and completed save, or use an application-coordinated snapshot procedure whose restore behavior has been tested.
For LVM, ZFS, or Btrfs snapshots, coordinate application saving and writes across all required data paths and test restoration. If that coordination cannot be verified, stop ECO cleanly before taking the snapshot.
Do not assume that an ordinary live file copy or rsync operation captures a transactionally consistent state.
Backup Frequency vs Storage Growth
Backup frequency is a balance between recovery precision and storage use.
A practical retention policy can include:
- ECO’s automatic backups at the default two-hour interval or another tested recovery-point objective
- Daily retention for recent history
- Weekly or monthly archival snapshots
Storage use depends on save growth, backup frequency, retention, compression, and file replacement. Longer intervals increase the amount of progress that may be lost between restore points.
Why Off-Server Backups Matter
Backups stored on the same disk or server provide limited rollback protection but do not cover complete disk, host, or site loss.
Hardware failure, disk corruption, ransomware, or operator error can wipe both the server and its backups at once. Store copies off the host. Use separate storage systems or remote locations.
If every backup shares the same failure domain as the live server, maintain an additional off-host or off-site copy.
Restoration Testing Verifies Backups
A backup that has never been restored is unverified.
Test restores periodically:
- Spin up a temporary server.
- Restore data.
- Start the simulation.
- Verify world integrity.
This confirms backups are usable and complete. It also reduces downtime during real incidents.
The Stability Pattern
Long-running ECO servers follow a predictable pattern:
- Controlled shutdowns
- Verified backups
- Periodic restore testing
- Disk usage monitoring for logs and backups
Documented shutdown, backup, monitoring, and restore procedures reduce recovery uncertainty during an incident.
When RedSwitches Makes Sense for ECO Servers
A reliable ECO server gives your community a world it can return to. That takes sustained CPU performance, enough RAM, reachable gameplay ports, controlled updates, and backups you can restore. The goal is to keep players connected and make their progress recoverable when something goes wrong.
RedSwitches becomes a practical option when monitoring shows that your current hosting struggles with the workload or you need greater control over the environment.
Its dedicated servers offer bare-metal resources, SSD and NVMe storage options, and full root access for managing your ECO installation, mods, updates, and backup workflows.
Explore RedSwitches dedicated servers to choose a configuration around your world’s measured needs, with headroom for the community you’re building next.
Frequently Asked Questions
Common questions about eco dedicated server guide 2026: setup, ports & linux.
What is an ECO dedicated server and how is it different from hosting through the game client?
What are the real hardware requirements for running an ECO dedicated server?
Why does my ECO dedicated server not appear in the server list?
Should I run an ECO dedicated server on Linux, Windows, or Docker?
Can I run an ECO dedicated server on a VPS, or do I need a dedicated server?
Hafsa Qadeer
Technical Writer
Hafsa Qadeer is a Technical Content Writer at RedSwitches and a journalist with a background in molecular biology and oncology. She brings research precision to technical writing and SEO strategy, turning complex topics in infrastructure, biotech, and AI into content that informs and engages.
Power Your Next Project With Bare Metal
10 min delivery, zero setup fees, and 24/7/365 human engineers across 20+ global locations.


