The best Space Engineers server configuration is not the one with every limit removed. It is a predictable contract: choose a hosting method that survives your schedule, make networking work before changing gameplay, set a player cap your CPU can simulate, and only enable experimental mechanics your group understands. For most private groups, start with a password or Steam Group visibility, autosave and backups, vanilla rules, the default 100,000 global PCU budget, and Steam networking if Workshop mods matter. Use EOS/cross-platform only when console access is more important than Workshop compatibility.
A dedicated server is headless software, so it can run on a Windows PC or rented host without a graphics card. The documented baseline is a 3.2 GHz CPU with three logical cores and 6 GB of RAM; the recommended target is 4.5 GHz, three logical cores and 10 GB of RAM, plus about 8 GB for the installation and additional space for saves, logs and mods.
What hardware does a Space Engineers dedicated server need?
The server process does not render the game world. A graphics card is therefore unnecessary, but CPU speed, memory, storage and network reliability still determine how smoothly the simulation runs.
| Requirement | Documented figure | What it covers |
|---|---|---|
| Minimum CPU | 3.2 GHz, three logical cores | Baseline dedicated-server operation |
| Recommended CPU | 4.5 GHz, three logical cores | More headroom for a busy world |
| Minimum RAM | 6 GB | Server process and a modest session |
| Recommended RAM | 10 GB | Additional simulation, players and content headroom |
| Installation storage | Approximately 8 GB | Dedicated-server files before saves, logs and downloaded mods |
Reserve storage beyond the installation figure. Save files, log history, backups and Workshop downloads grow over time, and a full disk can prevent saves or updates. A rented host removes most Windows, port-forwarding, backup and uptime work, while self-hosting gives you direct control over files and hardware.
Should I run the server as a foreground process or a Windows service?
Use a foreground process when one person can launch, monitor and restart the server manually. Use a Windows service when the machine should bring the world online after a reboot, run without an open desktop session, or host multiple world instances.
Foreground process
- Simplest setup for a small group.
- Convenient while you are actively configuring and watching logs.
- Requires a person to start it again after a reboot or crash unless you add your own automation.
Windows service
- Starts the world after Windows restarts and can run without an interactive desktop session.
- Suitable for several instances on one machine, with a unique port assigned to each instance.
- Creating and managing the service requires administrator rights.
A managed host is the practical alternative when nobody wants to maintain Windows, firewall rules, backups, updates and recovery. Check that the host supports the network mode, Workshop policy and restart controls your group needs before subscribing.
How should I set the server’s name, visibility and identity?
Give the server and the world different, recognizable names, then choose access controls before inviting anyone. A private group normally needs either a password or Steam Group visibility rather than an openly discoverable listing.
Access settings
- Public: use it when discovery by players outside your group is intentional.
- Private/password: best for a friends-only world when you will share the address and password directly.
- Steam Group: restricts visibility to members of a chosen Steam group.
Add a message of the day that states the connection rules, restart expectations, and any unusual gameplay policies. If you enable scripts, unsafe physics or other experimental options, put that information in the welcome message so new players are not surprised.
The server interface also exposes the listen IP, listen port, network type and maintenance actions. Keep a written record of the selected values, especially when more than one person administers the machine.
Why can’t my friends connect to the server?
Most connection failures occur before gameplay settings matter: the server is listening on the wrong interface, the router is not forwarding the port, or the host firewall is blocking it. Fix those layers in order.
- Confirm the listen address. Bind the server to the intended local interface. The documented default,
0.0.0.0, listens on all interfaces in common cases; a deliberate binding is preferable when the machine has several network adapters. - Choose and record the listen port. The setup guide commonly uses UDP port
27016, but the configured value is the one that matters. - Forward UDP on the router. Send incoming traffic on that port to the Windows machine running the server. Forward the same port selected in the server UI.
- Allow the port through Windows Firewall. Create an inbound rule for the server’s UDP port, and ensure the rule applies to the network profile the machine is using.
- Test with the actual network mode. Steam and EOS/cross-platform clients do not exercise exactly the same path. Test from a player connection outside the host’s local network before announcing the server.
- Separate instances cleanly. Every service instance needs its own port. Reusing one port can make one world unreachable or prevent a second process from starting.
Do not change PCU, scripts or block limits to solve a port-forwarding problem. Those settings affect simulation after a player connects; they cannot open a blocked network path.
Which world settings should a cooperative group use?
World Settings define the gameplay contract: who can join, how quickly resources are processed, how much construction the simulation permits, and which mechanics are considered safe. Start conservatively, then change one category at a time so you can identify the cause of a problem.
Recommended starting profile
- Use Private/password or Steam Group visibility for a friends-only session.
- Set a player cap that matches the host’s simulation budget, not the largest number the menu permits.
- Enable autosave and retain backups outside the active world directory.
- Begin with vanilla settings; add mods after the base world has run reliably.
- Record the active mod list and load order for every administrator.
- Choose the scenario template and asteroid amount before creating the world; these are creation-time choices rather than routine live-server toggles.
Progression multipliers
Assembler efficiency and refinery speed change the amount of time players spend gathering and processing materials. Higher multipliers shorten the production loop; lower values create a longer progression curve. Set them as a pair that fits your group’s available play time rather than raising one while leaving the other unexpectedly restrictive.
Player and save controls
Autosave is the first recovery measure, not a substitute for retained backups. A player maximum that is too high can produce poor simulation performance when everyone builds in the same world, while a cap that is too low can reject legitimate group sessions. Revisit the cap after large bases, scripted ships or substantial mod additions change the workload.
What does PCU do, and should I remove the limit?
PCU is a performance budget for the world. Each construct consumes PCU according to its blocks, so the budget limits how much construction the simulation must maintain. The documented default global PCU value is 100,000.
Administrators can lower multiplayer limits to protect performance. On an owned dedicated server, the relevant experimental settings can allow limits to be removed, but unrestricted construction trades predictable performance for freedom. Values outside the ranges offered by the normal interface are not tested or officially supported.
Block-limit modes
The SessionSettings reference exposes three scopes for block limits:
- NONE: no faction or global block-limit scope is applied by that setting.
- GLOBALLY: one world-wide limit is shared across players.
- PER_FACTION: factions receive their own limit.
Use the default budget first and watch simulation behavior as the world grows. Remove or greatly raise limits only when the group accepts the possibility of slower updates, heavier saves and less predictable performance. PCU and block limits are controls for capacity, not merely restrictions to bypass.
Which advanced settings should I enable?
Advanced options can change engineering behavior, damage rules and failure modes. Enable them deliberately, test them in a copy of the world, and document the result in the server message.
Programmable Block scripts
Scripts are disabled by default. Turn on Enable In-Game Scripts only when the group is prepared to administer script-heavy worlds and troubleshoot scripts that consume simulation time or conflict with mods.
Physics and engineering options
- Share Inertia Tensor: changes how connected grids distribute rotational behavior.
- Unsafe piston impulses and unsafe torques: permit more aggressive mechanical behavior, with greater risk of instability or damage.
- Sub-grid damage: changes whether attached sub-grids can damage one another.
- Unsupported stations: allows station configurations outside the normal supported rules.
- Adaptive simulation quality: lets the game adjust simulation quality as load changes.
- Permanent death: makes player death a lasting progression consequence rather than a routine respawn.
- Supergridding: permits grid arrangements that are outside ordinary building behavior and may create compatibility or stability issues.
None of these is a universal “best” choice. A cooperative survival group usually gets a more predictable first session by leaving them off, then enabling one feature after everyone understands its consequences.
Should I use Steam networking or EOS/cross-platform?
Choose Steam when your group relies on Steam Workshop mods. Choose EOS/cross-platform when admitting console players is worth giving up Steam Workshop mods; the documented cross-platform configuration cannot use those Workshop mods.
| Network choice | Best fit | Important trade-off |
|---|---|---|
| Steam | PC groups that depend on Steam identity and Workshop content | Does not provide the console reach of cross-platform mode |
| EOS/cross-platform | Groups that need PC and console participation | Steam Workshop mods cannot be used |
The dedicated-server software itself runs on Windows; it does not run on consoles. Consoles can participate only as clients through the supported cross-platform configuration. Test the chosen mode with the actual PC and console clients before distributing connection instructions.
How do I maintain, restart and recover the world?
Use the server UI’s maintenance actions instead of editing live files casually. The available controls include Save Config, Edit Config, Save and Start, Restart, Stop, automatic restart and automatic update.
Routine maintenance
- Announce a restart window in the message of the day or your group chat.
- Save the world and stop or restart it through the server controls.
- Keep backups outside the active world folder, including a copy made before major mod, settings or game updates.
- Review logs after updates and after adding or removing mods.
- Confirm that automatic restart and automatic update policies match the group’s schedule; an unattended update can change availability at an inconvenient time.
Command-line overrides
Command-line switches can override the server path, session, player maximum, IP address, port, plugin and EOS mode. Use them to make service definitions reproducible, but keep the chosen values documented so a second administrator can reproduce the launch.
Safe configuration editing
Back up the world before manual edits. The SessionSettings reference warns that unrecognized files can be deleted when the game saves, so do not place unrelated files in locations the server treats as part of the session. If a change causes a failure, stop the server, restore the last known-good backup, and reapply settings one at a time.
What is the best baseline configuration for a friends-only server?
For a group that wants a reliable cooperative world rather than a public stress test, use this starting point:
- Run the headless server on a Windows machine meeting the recommended 4.5 GHz, three-logical-core and 10 GB RAM target, with storage beyond the approximately 8 GB installation.
- Choose a foreground process for occasional sessions or a Windows service for a world that must return after reboots.
- Use a distinct server name and world name, then select Private/password or Steam Group visibility.
- Bind the intended listen IP, forward UDP on the configured port (27016 is the guide’s common example), and allow it through the firewall.
- Enable autosave, keep external backups, and set a player cap based on observed simulation capacity.
- Keep the default 100,000 global PCU budget and ordinary block limits until the group has evidence that a change is needed.
- Leave scripts and risky experimental mechanics off initially.
- Use Steam networking when Workshop mods are part of the plan; select EOS/cross-platform only when console access outweighs that restriction.
- Document the settings, mod list, restart schedule and connection rules in the message of the day.
Frequently Asked Questions
Can a rented host run a console-friendly Space Engineers world?
Only if the provider exposes EOS/cross-platform networking for the server edition you are renting. Confirm console access, port handling, automatic updates and the no-Workshop-mod restriction before committing to a host.
How can I tell whether my PCU budget is too high?
Watch for worsening simulation responsiveness as the world’s grids and scripts grow, rather than judging by PCU alone. Lower the global budget or player cap after making a backup if the group prefers consistent performance over unrestricted construction.
Can I change the asteroid amount after creating the world?
Asteroid amount is a creation-time choice in the world setup. Treat it as part of the initial scenario decision and make a backup before generating a replacement world if the group wants a different distribution.
What should administrators record when they add a mod?
Record the mod list, load order, date of the change and the server network mode. That information makes it possible to reproduce the session and identify whether a later connection or save problem began with the mod change.