You changed a world setting in the panel, restarted the server, and nothing happened. Sim speed is the same, the asteroid density is the same, and the value you typed is sitting there in Service Settings looking perfectly correct – saved, spelled right, no complaints from anything. This is the single most common Space Engineers configuration ticket we get, and it almost never means the panel is broken. It means the setting you changed isn't the setting the server is reading.
Space Engineers keeps its configuration in two places, and which one wins depends on whether your world already exists. Get that straight and most of the confusion disappears. Get it wrong and you can spend an evening editing a file the server stopped caring about weeks ago. Which is, I'd guess, where a good number of the people reading this have just come from.
The two files, and which one the server actually reads
The first file is SpaceEngineers-Dedicated.cfg, which lives in the WORLD\ folder on your service. You can open it through Configuration Files in the panel sidebar. This is the dedicated server config, and it's the one the panel writes for you from whatever you've set in Service Settings.
The second is Sandbox_config.sbc, which sits inside the world itself, at WORLD\Saves\<yourworld>\. Unless you've renamed it, that world folder is called world, not the world name you see in the server browser, which is a separate value and frequently different.
Here's the part that matters. The dedicated server config seeds a world at the moment it's created. Once that world exists, the world's own Sandbox_config.sbc is what the server loads, and the dedicated config no longer has a say on session settings. So on any established server, editing the cfg and restarting achieves precisely nothing, and you're left assuming the setting is broken or that you've misunderstood the value format.
There's a second trap layered on top. Our config template rewrites SpaceEngineers-Dedicated.cfg automatically, so if you hand-add an element that the template doesn't know about, it gets wiped the next time the file regenerates. That's not a rule about Space Engineers – it's a rule about how the panel manages that particular file – and it catches people who've read a guide written for a self-hosted box, where the same edit would have stuck.
The short version I'd give anyone: new world, use Service Settings. Existing world, edit Sandbox_config.sbc.
What Service Settings genuinely covers
Worth knowing the boundary, because it's narrower than people assume. The settings our panel exposes and writes into the cfg are the ones from the old dedicated server basics: game mode, the multipliers for inventory, refinery, welder, grinder, assembler efficiency and hacking, environment hostility, auto-healing, copy-paste, weapons, thruster damage, cargo ships, spectator, permanent death, in-game scripts, respawn ship deletion, ownership reset, realistic sound, whether clients can save, autosave interval, spawn ship timer, destructible blocks, world size, asteroid amount, scenario, world name and folder, group ID, and view distance.
That's a decent list. It's also missing almost everything you'd actually want to reach for when a world starts struggling, which is the next section and most of the rest of this article.
The sync distance trap
This is the one I'd fix first on a busy server, and it's the one nearly every guide on the internet gets half right.
Grids and entities stream to players based on sync distance, not view distance. If your players are complaining that ships and stations pop into existence uncomfortably close, or that asteroids only appear when they're nearly on top of them, sync distance is the lever. View distance governs render distance and a few related things – useful, but not this – and it's the one people reach for purely because it's the one with a box in the panel.
<SyncDistance> defaults to 3000, and the game's own dedicated server interface accepts 1000 to 20000. It isn't in our config template, which means it isn't in Service Settings and never has been. Every Space Engineers server we provision ships with view distance set to 20000, already the practical top of its range and well above the game's own default of 15000.
Put those two facts together and you get the situation most people are actually in. The lever they can reach is already pushed as far as it goes. The lever they need isn't in the panel at all. So turning view distance up does nothing, because there's nothing left to turn, and the advice circulating on forums – raise view distance for asteroid streaming – reliably fails on a hosted server for reasons that have nothing to do with the advice being wrong in general.
There's one more detail from the settings reference that explains the rest, and it's easy to skim past: the documented defaults apply when a setting is missing from the world file. Because our template never writes sync distance at all, worlds created from it fall back to 3000 rather than to anything we picked deliberately. The effective configuration on a stock server, then, is 3000 sync against 20000 view – a fairly lopsided pair, and not one anybody chose.
To change it, stop the server, open WORLD\Saves\<yourworld>\Sandbox_config.sbc, and set <SyncDistance> to something between 3000 and 5000. That range suits most servers. Push it much higher and you're asking the main simulation thread – the one that runs out first on this game, always – to hold far more in play at once, which trades one complaint for a worse one. If you'd rather not edit XML on a world you care about, open a ticket and we'll set it for you.
PCU, grid size and block limits
None of these are in Service Settings either, and all of them live in Sandbox_config.sbc. They're the settings that stop one player's thousand-block capital ship from quietly becoming everybody's problem.
<BlockLimitsEnabled> is the master switch and it defaults to NONE, which disables the lot. Its other values are GLOBALLY, PER_FACTION and PER_PLAYER. While it's set to NONE the three limits below are ignored entirely – all of them, silently – so setting them first and then wondering why nothing is being enforced is a common order-of-operations mistake.
<BlockLimitsEnabled>PER_PLAYER</BlockLimitsEnabled>
<TotalPCU>600000</TotalPCU>
<MaxGridSize>50000</MaxGridSize>
<MaxBlocksPerPlayer>100000</MaxBlocksPerPlayer>
Those are the documented defaults. <TotalPCU> shows up as "World PCU" in the game's dedicated server interface and <MaxGridSize> as "Max Grid Blocks". Worth knowing, because guides switch between the XML names and the interface names without warning and you'll otherwise go looking for a setting that doesn't exist under that name. I wouldn't start by clamping these hard on an established world. Anything already built over the limit puts its owner in an awkward position the moment you restart. Turn the limits on, watch what your genuinely heaviest grids actually measure, then decide where the ceiling goes.
Autosave, floating objects and trash
<AutoSaveInMinutes> is one of the few performance-adjacent settings that is tokenised, so you can set it in Service Settings on a new world. It defaults to 5. On a large world you'll feel every save, and the instinct is to shorten the interval so each one has less to do. It doesn't work that way. Shortening it just gives you more spikes rather than smaller ones, so if saves are hurting, push it out to ten or fifteen instead.
Max floating objects is also in Service Settings, and this one deserves a proper look. The game's own dedicated server interface caps it at 100, with a documented default of the same. Our servers provision at 512. Loose items are tracked entities, so a server holding five times the game's own ceiling in dropped ore and stray components is doing real work for a benefit nobody has ever noticed, and bringing it down is about as close to a free win as this game offers if you're chasing sim speed.
Trash removal is messier, and I'd rather be straight about it than tidy. The setting Space Engineers uses for this now is <TrashRemovalEnabled> plus a set of thresholds, and those live in the world file rather than the dedicated config. The older RemoveTrash name that a lot of guides still reference doesn't appear in the current session settings reference at all. So if you've toggled trash removal somewhere and watched nothing change, check which of the two you were actually editing before assuming it's ignoring you. If you want the modern thresholds set properly on your world, open a ticket and we'll do it.
The 1.210 grid-storage option
Update 1.210 "Prosperity" added a dedicated server option that Keen's changelog lists as "Prevent Sending Grids to Distant Locations". It's aimed squarely at the grid-flinging behaviour that turns into admin cleanup work on economy and PvP servers.
Keen didn't publish a config key alongside that line, so I'm going to be careful here rather than confident. The world-side settings that correspond to the behaviour are the grid-storage family, and the one matching the description is <GridStorageMaxDistance> – "Max Retrieve Distance" in the interface, defaulting to 0. It sits in Sandbox_config.sbc along with everything else in this article, not in the dedicated config, so it isn't reachable from Service Settings either.
Torch admins get finer control over the same behaviour through three keys added in Torch PR #645:
GridStorageMinutesPerKm
GridStorageCombatCooldown
GridStorageMaxDistance
Leave those on defaults unless you already know grids are being launched across your map. Our 1.210 update walkthrough covers the update itself and what to back up before you run it.
Settings that look editable but aren't
This is the section I wish someone had written for me, because every item here has cost somebody an afternoon.
Max players is your slot count. The panel writes it straight from the slots on your service, so there's no separate field to find and editing the cfg by hand won't hold.
The production multipliers don't all behave the same. Assembler speed in particular is one I'd check rather than trust: if you've set it, restarted, and measured no change on an existing world, that's a known enough pattern that it's worth raising with us rather than re-typing the value. We can read what your server is actually running and set the world file directly.
Network type and online mode aren't yours to change either. Servers come up on Steam networking and public, and that's written for you.
The administrators block isn't tokenised. Admins are set by Steam ID in the cfg, and because that file regenerates, IDs added by hand can vanish. Add yours, restart, then go back and check the block still contains it. If it's come back empty that's expected behaviour rather than a mystery, and we can set it properly at our end, which is genuinely the easier route.
I'd treat this whole group as ask rather than fight. They're all one-line changes for us and none of them are worth an evening of yours.
Ports, briefly
Your game port and your query port are the same number. That's normal for this game and not a misconfiguration, so there's no point hunting for the separate query port you've seen mentioned elsewhere. Two more ports are allocated separately: one for Steam, which is what actually gets your server listed, and one for the remote API. Read your real numbers off Service Settings rather than assuming the 27016 default, because on a shared IP you'll have been handed something else out of a range.
Editing the world file without breaking it
Three rules, and the first is the one that bites.
Stop the server before you touch anything. Space Engineers holds its session settings in memory, rewrites the world on every autosave, and never re-reads that file mid-session, so a change made while it's running is either ignored outright or overwritten within five minutes. Stop, edit, start. In that order, every time.
Take a backup first. Cloud Backup in the panel sidebar takes about thirty seconds and Backup Manager keeps local copies, which is cheap insurance against a mistyped tag. A malformed Sandbox_config.sbc fails in the same ugly way a corrupt world does, which we've written up separately in Sector Could Not Be Loaded.
Don't leave spare files in the world folder. Space Engineers deletes anything it doesn't recognise in there when it saves, so your careful Sandbox_config.sbc.backup disappears the first time the world writes itself out, which is a nasty way to learn the rule. Keep copies somewhere else entirely, or pull them down over SFTP on port 8822.
For anything bigger than a settings tweak, where saves live and how to upload one covers moving a world in wholesale, and the dedicated server guide covers first-time setup.
If you've read this far and concluded that half the settings you actually want are sitting in a file you'd rather not hand-edit on a world you care about – that's a fair conclusion, and it's exactly why we don't mind doing it for you. Open a ticket with the service name and the values you want, and we'll set them with the server stopped and a backup taken. Details are on our Space Engineers server hosting page if you're weighing up a move.