Space Engineers is one of those games where hosting your own server changes what the game is. On someone's listen server you're all tied to whether that person is online, and their machine is simulating every grid, every rotor, every conveyor line. Move it to a dedicated box and the world keeps running whether anyone is logged in or not. Your half-built refinery keeps refining. Drills keep drilling.
I've set these up for groups of three mates and for public servers running Torch with a plugin list as long as your arm, and the same handful of things catch people out every time. Here's what setting one up actually looks like, including the bit that gets nearly everyone on their first boot.
What you're actually running
Space Engineers ships a separate dedicated server tool on Steam, app ID 298740, distinct from the game itself at 244850. It's a free download and you don't need a second copy of the game to run it. It's Windows-only, which suits us fine – our whole fleet is Windows anyway, so there's no awkward compatibility layer sitting in the middle of things.
The thing people underestimate is how much Space Engineers leans on a single fast core. Keen have parallelised plenty over the years, physics has been multithreaded since 1.181 and the 1.196 server work pulled a lot of load off the main thread, but the main simulation thread is still the one that runs out first. Sixteen slow cores is still one slow core.
RAM tracks the world, not the player list. Ten people pottering about in a starter base barely register. Two players who have built a thousand-block capital ship and left a hundred drones parked in orbit will cost you a lot, because grids and physics are where the money goes. I'd rather someone ran a modest server and kept their world tidy than a huge one they let sprawl.
Running it yourself
Worth knowing what the DIY route involves, because for some groups it's genuinely the right answer.
The server tool is free and anonymous, so there's no login to sort out:
steamcmd +force_install_dir C:\SEDS +login anonymous +app_update 298740 validate +quit
That drops the launcher at C:\SEDS\DedicatedServer64\SpaceEngineersDedicated.exe. There's a 32-bit DedicatedServer\ folder in there too – ignore it. The config doesn't live next to the executable, which surprises people: it ends up in %APPDATA%\SpaceEngineersDedicated\<InstanceName>\.
Then the fine print nobody mentions. Your home upload becomes load-bearing infrastructure, and so does your electricity. You'll need to forward the game port and the Steam port, and if your ISP has you behind CGNAT you're finished before you start – a lot of UK fibre is. You're on SteamCMD duty every time Keen ship an update, which is more often than you'd think. And the specifically Space Engineers one: if that machine is also playing Space Engineers, the client and the server are now fighting over the one core that matters.
If that sounds like a fun weekend, genuinely go for it. I still run things off a box in the corner for personal projects. It's when other people are relying on it being up at 9pm on a Tuesday that the maths changes.
What to look for in a host
If you'd rather not, the things worth asking about are fairly specific to this game:
- Single-thread performance, not core count. This is the one that decides whether your world runs well. Ask what CPU generation you're landing on, not how many cores you get.
- Backups you didn't have to remember to take. Space Engineers worlds die in one particular way, covered below, and the only real answer is a rollback point.
- A proper update button. You'll be pressing it every time Keen ship, so it shouldn't involve a support ticket.
- File access that survives a big world. A web file manager is fine until your save isn't, and then you want SFTP. Ours is on port 8822.
- Torch tolerance. Not every host will let you run a community wrapper. Worth establishing before you pay for anything.
- Support that knows the game, rather than a ticket queue that replies "please restart your server" whatever you ask it.
Ours are on the Space Engineers server hosting page, and the rest of this applies whichever way you go.
Getting it running
Order a server and you'll get login details for the LOW.MS Control Panel by email a few minutes later. Everything below happens in there.
Here's the step that catches people. A Space Engineers dedicated server has to be told which world to run. Point it at nothing and it either sits there loading nothing, or – worse – quietly generates a fresh random world that isn't the one you uploaded, which is how people end up staring at an empty sandbox wondering where their base went.
So before the first proper start, decide which world it's running. Two routes:
- Pick a scenario through the server config and let it generate one. Quickest way to get something on its feet.
- Or build a world in single-player on your own machine and upload it. Our guide on where Space Engineers saves live and how to upload one walks through that, including the folder layout.
If you're uploading, the world goes in the server's Saves\ folder and <LoadWorld> has to point at it with a full drive-letter path. Not a relative one. That single detail is behind a decent share of "my world won't load" tickets – ours included, I've typed the fix out more times than I'd like – and it's easy to get wrong precisely because relative paths look like they ought to work.
One thing to know before you go editing anything: a running server holds its config in memory and never re-reads the file, and it writes its own copy back out again. So edits made mid-session either do nothing or get clobbered. Stop, edit, start. In that order, every time.
Once a world is set, hit Start and watch Log Viewer while it comes up. The first boot is always slower than the ones after it.
Ports and how people connect
Space Engineers uses one UDP port for game traffic, 27016 by default, and it queries on that same number – that's the bit that puts you in the server browser. There's a second port for Steam itself, 8766 by default, and that one is what actually gets your server listed. On a shared IP you'll be allocated both from a range, so check Service Settings for your real numbers rather than assuming the defaults.
Servers not showing up in the public list is a common complaint, and when it happens it's usually the Steam port rather than the game port, or just the sheer size of the list. Either way the reliable route is having people add your IP:PORT to favourites directly, or sending them a steam://connect/IP:PORT link. Every group ends up doing this eventually – it's the first thing I'd drop in the group chat – so you may as well skip the "I can't find it" round of messages entirely.
Making yourself an admin
There's no in-game promote command. Admins are set by Steam ID in the server config, and the nesting matters more than people expect – getting it wrong is the single most common reason admin rights don't apply. It's a list, one ID per tag:
<Administrators>
<unsignedLong>76561198000000000</unsignedLong>
</Administrators>
Open Configuration Files in the panel sidebar to edit it. Get your ID from your profile URL, or from any of the lookup sites if you've set a custom URL – it's the long numeric one, not your display name.
Restart afterwards, then go back and check the block still has your ID in it. Config files can get regenerated, and if yours comes back empty, open a ticket and we'll set it properly at our end rather than have you fight it. Admins get the spectator and creative tools in game, which is how you'll do most real moderation: clearing abandoned grids, digging someone's ship out of a planet, that sort of thing.
Settings worth changing before anyone joins
Worth understanding where settings actually live, because this trips people up constantly. The dedicated server config seeds a world when it's created. After that, the world's own Sandbox_config.sbc is what the server reads. So on an existing world, editing the dedicated config and restarting does nothing at all, and you're left assuming the setting is broken.
Sync distance is the one I'd point at first, and it's the one most often confused with view distance. They aren't the same lever. Grids and entities stream to players based on sync distance, so if people are complaining that things pop into existence uncomfortably close, sync is what you want. It's <SyncDistance> in Sandbox_config.sbc, it defaults to 3000, and the game clamps it between 1000 and 20000. Somewhere in the 3000 to 5000 range suits most servers. Push it much higher and you're asking that main simulation thread to hold far more in play at once. Open a ticket if you'd rather we changed it for you.
Auto-save interval is <AutoSaveInMinutes>, five by default. If you're running a big world you'll feel each save. Shortening the interval doesn't make the spike smaller, it just gives you more of them – so if saves are hurting, push it out to ten or fifteen rather than pulling it in.
Whichever file you're in, edit it with the server stopped. The world file gets rewritten on every autosave, so a mid-session edit there is definitively gone.
Mods and Torch
Space Engineers mods come from the Steam Workshop, and you add them by putting the Workshop IDs into the world configuration. They download on the next start, so expect one slow boot after adding a batch.
Mods are also the single most common reason a working server stops working. When an update lands, Keen's build is fine. The mods written against last week's definitions might not be, and if your world stops loading the morning after a patch, I'd bet on a mod over the update every single time. Disable the lot. Confirm it boots on vanilla, then add them back in batches until it breaks again.
Torch is the community server wrapper, and if you're running anything with a real playerbase it's worth having. Proper admin interface, plugins for grid cleanup and concealment, and a lot more visibility into what your world is actually doing.
One thing to get right: download it from torchapi.com. Its GitHub releases page still lists 1.3.1 from December 2023 as the newest, which makes the whole project look dead. It isn't. GitHub just stopped being where the builds go – the current build from torchapi.com is 1.3.1.347, put out on 27 July 2026. Those two version strings look nearly identical, which is exactly why people compare them, conclude they're already current, and run a two-and-a-half-year-old Torch for a month wondering why nothing works.
And whichever way you go, drive the server from the panel. Don't remote in and launch the executable or Torch by hand while the panel also thinks it owns the service – and if you manage that during an update, you get to find out what a half-written install looks like.
Backups, and why you want them
Space Engineers worlds die in a specific and memorable way. The server starts, sits for a few seconds, then drops straight back to stopped, and the log has this in it:
Error during loading session: Sector could not be loaded
That's a corrupt save, and no amount of restarting fixes it. We wrote up how to recover from that one because it comes through often enough to deserve its own article.
The short version: restore a backup. Cloud Backup and Cloud Restore sit in the panel sidebar, and Backup Manager keeps local copies. Take a manual one before any update, before adding a big batch of mods, and before letting anyone loose with creative tools. Those are the three moments worlds actually get lost.
Speaking of updates, 1.210 "Prosperity" landed on 27 July 2026, and if your server is still on the old build your players get bounced with a version mismatch until you update it. That one has its own walkthrough.
And if you'd rather skip all of it, open a ticket telling us what you want and we'll get a world running for you. Genuinely, ask. Ten minutes of us pointing a config at the right save beats an evening of you wondering why an empty server won't load anything – and the sooner that's sorted, the sooner the refinery gets back to refining.