You added six Workshop mods last night, restarted, and either the server won't come up at all or it came up perfectly and not one of the mods is actually in the world. Both land in our ticket queue most weeks, and they're the same problem wearing different clothes – Space Engineers has two separate ideas of what "installing a mod" means, and the panel only does one of them for you.
Torch sits on top of all this as the community wrapper most serious servers end up running, and it has its own traps, starting with where you download it from. So here's the whole picture: how mods actually attach to a world, what Torch is really doing, and the particular way a Space Engineers save dies when you get it wrong.
Downloading a mod is not the same as enabling it
This is the bit that catches everyone, so I'll be blunt about it.
Open Mod Manager in the LOW.MS Control Panel and you get a Steam Workshop browser for Space Engineers. Search, tick, install, and the files come down onto your service. Collections work too, so you can pull a whole curated list in one go. That step is real and it does what it says.
What it doesn't do is tell your world to load any of them.
A Space Engineers world carries its own mod list, inside Sandbox_config.sbc, in the world folder at WORLD\Saves\<yourworld>\. That list is what the game reads when the session comes up. The dedicated server config has a <Mods> block too, and Service Settings even shows a Mod ID field. Neither is wired to anything – there's no token behind that field, so the panel never writes it into the cfg, and the block ships empty and stays empty. While writing this I checked every Space Engineers service on the fleet: that field is blank on all of them, including one with 37 Workshop files sitting on disk, which is precisely the shape of "I installed the mods and nothing happened".
There's a second reason the dedicated config is the wrong place to look even when it isn't empty. It seeds a world at creation and then stops mattering, because once the world exists the world's own file wins. So on any server that's been up longer than about five minutes, Sandbox_config.sbc is the only mod list with a vote – the same two-files trap we cover properly in the server configuration guide.
In practice: Mod Manager to fetch the files, then the world's mod list to switch them on. If editing XML isn't your idea of an evening, send us a ticket with the Workshop IDs and we'll wire them in – that's a two-minute job at our end and I'd much rather do it than have you lose a world to a mistyped <ModItem> block.
Adding them without a bad boot
A few habits that have saved me more evenings than any single setting:
- Stop the server first. Space Engineers rewrites the world on every autosave, so anything you change while it's live either gets clobbered or lands half-applied. The panel's Workshop install stops the service for you, which tells you something about how safe the alternative is.
- Take a Cloud Backup before a batch, not after. The moment you want a rollback point is the moment before you touched anything.
- Add mods in small batches rather than thirty at once, because when something breaks you want a short list of suspects instead of an archaeology project.
- Expect one slow start. The first boot after adding mods pulls content and rebuilds definitions, and people panic and hit Stop halfway through – which is its own route to a bad save. Watch Log Viewer and let it finish.
Then the ordering problem nobody thinks about until it bites. If a mod adds blocks and your players build with them, that mod is now load-bearing. Taking it out later doesn't cleanly remove the blocks, it removes the definitions those blocks need to exist. That isn't a bug, it's just how a save works, and it's why "we'll try it and drop it if we don't like it" is a far bigger commitment on a survival server than it sounds.
When Keen ship an update
1.210 "Prosperity" landed on 27 July 2026, with a 1.210.012 hotfix three days behind it, and the pattern after any of these is the same. Keen's build is fine. Your mods were written against last month's definitions and some of them aren't.
So if your world stops loading the morning after a patch, I'd put money on a mod over the update every single time. Strip the list back to nothing, confirm the server boots vanilla, then add them back in batches until it falls over again. Tedious, yes – it's also twenty minutes and it always finds the culprit. The update side of it has its own 1.210 walkthrough.
The other half of this is Workshop rot. Mods get abandoned, hidden or pulled by their authors, and a mod that's vanished from the Workshop is worse than a broken one – your world still asks for something that can't be fetched any more. Worth running an eye over the list every few months.
What Torch actually does
Torch is a community wrapper around the dedicated server. It isn't a mod and it doesn't change the game for the people playing on it – it replaces the plumbing: real admin tooling, an entity manager for poking at grids without joining, a chat and command layer, and a plugin system, which is where all the actual server administration lives.
On our servers it's opt-in. You install Torch (Latest) from Mod Manager, and that swaps the service's command line over so it launches through Torch instead of the stock dedicated server. Nothing else to do. It runs headless, since there's no desktop for a window to appear on, and it's configured to bring the server back up on its own if the simulation stalls – which is worth knowing, because if your server has started restarting itself for no obvious reason, that's usually Torch's watchdog catching a hung tick rather than a crash.
Torch's own config isn't exposed in Configuration Files and the panel manages it, so whitelisting and the Torch-level settings are a ticket rather than a text editor. Not ideal, I know. It's the honest state of it.
Then the download rule, and this one matters. Get Torch from torchapi.com. Its GitHub releases page still has 1.3.1 from December 2023 sitting at the top, which makes the project look thoroughly dead, and it isn't – GitHub just stopped being where the builds land. The current build is 1.3.1.347. Those two strings are close enough that people compare them, conclude they're already current, and then spend a fortnight on a two-and-a-half-year-old Torch wondering why half the plugin ecosystem refuses to load. Installing through Mod Manager gets you the current build, which is the main argument for doing it that way.
The plugins worth bothering with
Mod Manager carries a curated set under the Torch API group, all of which want Torch installed first.
Essentials is the one I'd install before any of the others. Ranks and permissions, custom commands, timed messages, the scheduled housekeeping that stops a public server silting up – most of what people picture Torch doing is really Essentials doing it.
Concealment parks grids nobody is near so the sim stops simulating them. On a busy world with a lot of ships left lying about, it's the biggest single performance lever you've got.
Quantum Hangar lets players store ships out of the world and pull them back later. Quality of life on the face of it, and quietly a way to keep grid count down.
ALE Shipfixer repairs grids that have got themselves into a broken state – the specific and infuriating class of problem where a ship is technically still there but refuses to behave.
Profiler and SE PerformanceFix are for when things are already slow and you'd like to know which grid is responsible rather than guessing at it.
Outside that group there's Multigrid Projector, which makes projectors handle subgrids properly and is close to essential if your players build with rotors and pistons, and SEWorldGenPlugin for procedural star systems – that one's a world-generation decision rather than something you bolt on afterwards.
One caveat. Several of these entries are pinned to particular builds, some of them a good few years old now. They still work. But if you need a newer release of a specific plugin, ask us rather than assuming the catalogue version is the latest one going.
How a sector actually dies
All of that is prologue to the failure mode that costs people worlds. The server starts, sits for a few seconds, drops back to stopped, and the log says:
Error during loading session: Sector could not be loaded
A save is really two halves, the settings and the sector, and this is the sector refusing to read. Mods are one of the three usual causes, alongside an interrupted autosave and a version gap – so a mod-heavy server that got stopped mid-save during an update is more or less the perfect storm for it. The full recovery walkthrough lives here: Sector could not be loaded, and how to recover your world.
Two things that'll save you an evening. Restoring a backup is nearly always the answer, and Cloud Restore is sitting right there in the sidebar. And if you're binning the world and starting fresh, move the broken save out of WORLD\Saves\ entirely rather than renaming it in place, because the server will cheerfully pick up whatever world is in that folder no matter what you've called it, and then die on it all over again.
If you're still weighing this up, the Space Engineers hosting page is over here and the full setup guide covers the first-boot side of it. And if you've got a mod list you want running and no appetite for XML at eleven at night, open a ticket with the Workshop IDs and let us do it. That's genuinely what we're here for.