Garry's Mod Sandbox on a Dedicated Server
Sandbox is what a Garry's Mod dedicated server runs when you do not tell it otherwise. Install the server, open garrysmod/gamemodes/, and you will find exactly three folders: base, sandbox and terrortown. The launcher ships with DEFAULT_GAME="garrysmod" and DEFAULT_MAP="gm_construct", and sandbox is the gamemode it loads. There is nothing to subscribe to, download or pick from a menu. If your server is online and you have never touched the gamemode convar, you are already hosting sandbox. Facepunch describes it plainly on the Sandbox gamemode page: the default mode, a spawn menu on Q or F1, and tools for building.
That makes sandbox the easiest gamemode to start and the hardest to keep smooth, because the thing players came to do, spawning physics props, is work your server pays for.
Last verified: September 17, 2026. Addon behaviour and prop budgets vary enormously between servers. Test the numbers below against your own build load rather than copying them from anywhere, including here.
Props are a server cost, not a client one
Every crate, barrel, ragdoll and welded contraption a player spawns is a physics object simulated on the server. The client draws it. The server decides where it is. That split is the single most important fact about hosting sandbox, and almost every performance complaint on a sandbox server traces back to it.
One player who spawns a thousand props and then knocks the pile over is not slowing down their own machine. They are stretching the server tick for everyone connected, including the people standing quietly across the map who have spawned nothing at all. You cannot solve that with a faster client, more bandwidth or a bigger slot count. It is CPU, single threaded, and it is yours.
Cost is also not linear in prop count. A hundred props lying still are cheap. A hundred props welded, roped and axised into one contraption are solved together as a system, and a contraption that is colliding with itself or fighting a constraint is expensive every single tick until someone removes it. This is why a server can sit at a comfortable load all evening and then fall over the moment somebody finishes a build.
gmod_physiterations controls how many iterations the physics solver runs. Raising it makes constrained builds hold together and sag less, and multiplies the CPU the solver spends per tick on the thread everyone is waiting for. Lowering it buys back headroom at the cost of jittery contraptions. There is no value that is correct for every server, and anyone handing you one without knowing your player count and build style is guessing. Move it a single step at a time, on a populated server, and watch what happens to your tick before you move it again.
The limits and cleanup you actually control
Sandbox enforces per-player spawn limits through server convars following the sbox_max<limitName> pattern, so the prop ceiling lives in sbox_maxprops and every other spawnable category has its own equivalent. When a player crosses one, the GM:PlayerCheckLimit hook fires and the spawn is refused. Two properties of these limits catch operators out repeatedly:
- They are per player, not per server. A limit of 150 props on a 32 slot server authorises 4,800 props. Size the number against your slot count and your CPU, not against what one sensible builder would use.
- They do not apply in singleplayer. Facepunch documents that the limit hook is never called in singleplayer, so whatever you tested alone on a listen server told you nothing about the dedicated one.
Cleanup is the other half of the job. The Utilities tab of the spawn menu carries the clean-up buttons, gmod_cleanup removes a player's own spawned entities, and gmod_admin_cleanup lets an admin clear the server. On a build server that runs for days, a scheduled admin cleanup between sessions is the difference between starting every evening fresh and degrading quietly all week.
Persistence deliberately works the other way. Setting sbox_persist to a non-empty identifier turns on saved props: an entity marked persistent through the context menu is written out when the server shuts down and restored when it starts, and by default it cannot be grabbed with the physgun or edited with tools. Left at its default empty value the feature is off and nothing survives a restart. If your server is measurably heavier after every reboot, this is the first thing to check.
Per-rank limits, timed cleanups and the authority to remove somebody who is lagging the server on purpose are not in the base game. They come from an admin mod. See admin commands and admin mods for what each layer gives you.
Settings that matter for a sandbox server
| Setting | Typical value | Why it matters here |
|---|---|---|
gamemode | sandbox | The default, but set it explicitly so no addon or stray config moves you without you noticing. gamemode_reload exists for development; a real gamemode change wants a restart. |
map / host_map | gm_construct | Sandbox maps use the gm_ prefix. Only two ship with the game, so everything else is content you have to deliver. |
maxplayers | Lower than you think | Every slot multiplies your prop ceiling. Slots are cheap; the physics they authorise are not. |
sv_alltalk | Usually on | Sandbox is a social building mode and cross-team voice is the point of it. This is the opposite of a TTT server, where alltalk ruins the round. |
sv_cheats | Off | Turning it on hands cheat-protected commands to every connected player, not just to you. |
hostname | Something searchable | The name in the server browser. Say "build" or "sandbox" in it if you want builders to find you. |
sv_password | Set for private builds | The cleanest way to keep a long-running creative server free of prop spam is to keep strangers out of it. |
host_workshop_collection | Your collection ID | Installs and updates the server's addons on boot and marks matching content for client download. The supported way to ship tool and prop packs. |
sv_voiceenable, rcon_password, sv_lan, sv_pure, sv_downloadurl, sv_allowdownload and sv_loadingurl belong in the same file. Startup flags and server.cfg covers where each one goes and which are command line only.
Maps and addons
Sandbox maps carry the gm_ prefix by convention, and only gm_construct and gm_flatgrass ship with the game. Everything else is community content, which means getting the file onto the server is only half the work: every joining client needs the same file or it will sit on the loading screen forever. Installing and delivering maps covers both halves, and missing textures and ERROR models covers the aftermath, where a purple and black checkerboard means a missing material and a red ERROR sign means a missing model.
Sandbox is also the gamemode people load addons into most heavily, and the count is a real cost, not a cosmetic one. Garry's Mod loads every directory under garrysmod/addons/, so each tool pack, prop pack and construction kit is Lua your server executes at boot and content your clients must fetch before they can play. Two hundred addons is a slower start, a larger memory footprint and a much longer first join. Read content packs and mounting for the delivery side, Workshop collections and addons for the collection itself, and Workshop addon safety before you install anything with server-side Lua in it.
The September 2026 update is relevant here too. It brought 64 bit binaries on Windows, which raises the memory ceiling a heavily modded sandbox server used to hit, added content sub categories to the spawnmenu and a rebuilt player model selector, made the Dropship NPC damageable and added Hacked Manhacks to the spawn list.
Problems you will actually hit
| Symptom | Cause | What to do |
|---|---|---|
| Fine for an hour, then rubber banding | Props accumulating across a session | Run gmod_admin_cleanup, then lower the per-player limits so it takes longer to get there |
| One contraption tanks the whole server | Constraint system fighting itself | Remove it. Constrained props are solved together, so the fix is deletion, not a convar |
| Props still there after a restart | sbox_persist is set to an identifier | Clear it if you did not intend saved builds, or prune the persistent set |
| Everyone crashes at once | Usually an addon, occasionally a specific entity | Boot with -noaddons -noworkshop, add the stack back in stages, note the first failure |
| Red ERROR signs on spawned props | The prop's model addon is on the server but not the client | Put it in the Workshop collection or serve it over FastDL |
| Empty server still burning CPU | Lua still thinking through hibernation | sv_hibernate_think governs whether think logic runs while the server hibernates; an addon may also be holding it awake |
| NPC-heavy builds crawl | AI and pathing are server work too | Cap NPC and NextBot spawns the same way you cap props |
Sizing a sandbox server
Slot count is a poor guide for sandbox and a decent one for most other gamemodes, which is why the usual advice misleads people here. Ten builders on a heavily modded construct server will beat twenty people wandering a roleplay map. Size on the two resources that actually run out.
- RAM tracks your content footprint. It is set by the addon count, the size of the map and whatever mounted content you pulled in, and it is largely fixed once the server has booted. A big Workshop collection is a real number you can measure before opening to players.
- CPU tracks physics. It is set by how many props are live and how they are constrained, it varies minute to minute, and it is what people feel when they say the server is lagging. Single thread performance matters more than core count.
The practical approach is to set conservative limits, watch a full busy session, and raise them only when the tick stays clean. Performance and lag covers the measurement side, and server requirements has the hardware baseline.
Related Garry's Mod guides
- Dedicated-server setup, installing the server and getting sandbox running
- Gamemodes, what ships and how to run something other than sandbox
- Startup flags and server.cfg, where every convar on this page belongs
- Maps, the
gm_rotation and delivering it to players - Workshop collections and addons, the tool and prop packs sandbox lives on
- Workshop addon safety, vetting server-side Lua before you install it
- Admin mods and admin commands, per-rank limits and cleanup authority
- Performance and lag, measuring the tick before you change anything
- Prop Hunt and DarkRP, the two gamemodes sandbox builders most often graduate to
Want the CPU headroom that sandbox physics actually need, without sizing hardware by trial and error? Launch managed Garry's Mod hosting and spend your evening building instead of watching a tick graph.