Garry's Mod Server Requirements Calculator

Garry's Mod dedicated server requirements explained

The Garry's Mod dedicated server is a free download from Steam (SteamCMD app ID 4020; the base game is app 4000). It runs on both Windows and Linux via SRCDS (srcds.exe / srcds_run). A free Game Server Login Token (GSLT) set with sv_setsteamaccount is mandatory — without it your server's listing ranking is penalized and it is effectively hidden from the public browser.

CPU — the one spec that really matters

Source-engine gameplay logic is effectively single-threaded. The entire per-tick simulation — physics, Lua, networking, entity think functions — runs on one core. As a result:

• Single-core clock speed is the limiter. A fast 3.4 GHz core beats a slower many-core chip for one busy server. Target 3.0 GHz+ for modded servers; 3.4 GHz+ for DarkRP or high player counts.
• Core count helps only indirectly — for running the OS, multiple separate server instances, or client-side multicore rendering. It does not speed up a single server's tick.
• A 2-2.4 GHz core is fine for a small vanilla server; community reports say a 2.4 GHz dual core is marginal for 40+ player DarkRP.

RAM — driven by addons, not players

This is where expectations and reality diverge most. Vanilla and light gamemodes use surprisingly little memory:

• Sandbox / TTT / Prop Hunt / Murder: often under 1 GB even when full. Busy stock servers commonly peak around 500-800 MB. 2 GB is comfortable.
• Curated modded (under ~50 addons): 4 GB is a safe target for up to ~24 players.
• DarkRP / heavily modded: 8-16 GB. RAM scales with the size and quality of your addon set — hundreds of addons and multi-gigabyte content packs are the cause, not the player count. Even large 100-slot builds rarely need more than 32 GB.

Poorly optimized addons can leak or bloat memory over hours, which is why scheduled restarts matter (see optimization).

Storage

The base server install plus a few maps fits in roughly 5-6 GB. SSD/NVMe is strongly recommended — not for capacity but for fast map and addon load times, which directly affect level changes and player join times. Storage grows when you add maps and addons (a big DarkRP install can be 10-20 GB+), not from player activity, so there's effectively no per-player disk cost.

Network and bandwidth

GMod's tick and rate settings govern ongoing bandwidth. At a 33 tickrate with typical sv_maxrate values (30000-100000), budget roughly 5-10 GB of egress per active player per month. Physics-heavy gamemodes and higher tickrates push that up. The larger consideration is content delivery: if new players download your addons directly from the game server, a big addon pack multiplies bandwidth per join — route downloads through an HTTP FastDL server or the Steam Workshop instead. A low-latency location near your playerbase and DDoS protection matter more than raw throughput for most communities.

Vanilla vs. modded summary

As a planning rule, a heavily modded DarkRP server needs roughly 2-3x the RAM and a noticeably faster single core than a comparable vanilla server. Size for your actual gamemode, and remember that when a full server lags, the cause is almost always the single-core CPU tick budget — not a shortage of RAM.

Optimizing a Garry's Mod server

Because gameplay is single-threaded, optimization is mostly about reducing per-tick work and tuning the network rates. The highest-impact changes:

Set a sensible tickrate

Launch with -tickrate based on player count and gamemode. Never run below a ~30 tick on light gamemodes; heavy servers trade smoothness for stability. A practical guide:

• Light gamemodes (Sandbox/TTT/Murder): 66 is fine on a fast core.
• 16-32 players: 33 (the common default).
• 32-48 players: 22.
• 48+ / max-slot DarkRP: 16 is common practice for large servers.

Rate and network cvars (server.cfg)

• sv_minrate 20000 and sv_maxrate 100000 (or 0 for unlimited) for smoother play on good connections.
• sv_minupdaterate 33 / sv_maxupdaterate 66 and matching sv_mincmdrate / sv_maxcmdrate to suit your tickrate.
• fps_max 600 to cap server FPS sensibly (0 = uncapped).
• net_maxfilesize 64 to allow larger transfers when not using FastDL.

Launch parameters

Use -disableluarefresh to stop constant Lua autorefresh recompilation in production, and -high plus -malloc=system for priority and memory allocation. Always run with -tickrate set explicitly rather than relying on defaults. Use net_graph 4 in-game to watch the server tick: if the sv value flashes red, the CPU tick budget is being exceeded and you should lower tickrate or trim addons.

Tame addons and entities

• Keep the addon count lean — aim for under ~50 on smaller servers. Each heavy addon can add 100-500 MB and per-tick CPU cost.
• Audit for badly written addons; one inefficient Think hook can tank a whole server.
• Run automatic prop/entity cleanup every 15-30 minutes to stop physics objects from accumulating and burning tick time.

Scheduled restarts

Restart every 12-24 hours. This clears Lua/map memory creep and entity buildup that gradually degrade performance on long-running DarkRP and sandbox servers.

Offload downloads

Serve addons and maps via HTTP FastDL or the Workshop rather than the game server. This dramatically cuts game-server bandwidth and speeds up player joins, especially on large modded installs.

What to look for in a Garry's Mod host

Because GMod lives or dies by single-thread performance, the most important question to ask any host is about CPU clock speed, not core count. Look for modern processors with high per-core frequency (3.0 GHz+, ideally 3.4 GHz+ for DarkRP). A plan advertising \"many cores\" tells you little about how smoothly one busy server will run.

Other factors that genuinely matter for this game:

• RAM headroom you can scale. Vanilla needs little, but if you might grow into DarkRP, choose a plan where you can move from 4 GB to 8-16 GB without migrating.
• NVMe/SSD storage. This drives map-load and addon-mount speed, directly affecting level changes and join times.
• DDoS protection. Public GMod servers are common targets; filtered networking is close to essential for community servers.
• Low-latency location. Pick a datacenter near your playerbase — ping affects hit registration and feel more than bandwidth does.
• Easy addon/Workshop management and FastDL support. The ability to attach a Workshop collection or HTTP download host saves enormous bandwidth and player-join pain.
• Full FTP/SFTP and console access. You'll need to edit server.cfg, manage addons, and read logs; avoid locked-down panels that hide these.
• Automated backups for your config, addons and DarkRP data.
• GSLT support — confirm you can set sv_setsteamaccount, which is required for public listing.

Whether you self-host on a dedicated box or rent a managed slot, prioritize a fast single core, fast disk, protected networking and the freedom to configure files directly. Those four things determine the player experience far more than headline RAM or core numbers.

CPU note: Source-engine gameplay logic (server tick) is effectively single-threaded, so high single-core clock speed (3.0 GHz+) matters far more than core count. Extra cores only help run the OS, multiple separate server instances, or client-side multicore rendering (gmod_mcore_test) — they do NOT speed up one busy server. Choose CPUs with strong per-core performance.

Numbers are conservative real-world figures, not theoretical minimums. Vanilla and light gamemodes barely touch RAM (community reports of full Prop Hunt/Sandbox servers under ~800 MB), so RAM-per-player is small; the listed per-player figure mostly covers modded scripting and player entities. The decisive resource for any populated GMod server is single-core CPU performance. The modded multiplier (~3x) reflects how DarkRP and large addon packs balloon memory and CPU vs. stock. Storage is small (install + a few maps, roughly 5-6 GB); growth comes from adding addons/maps, not from player saves, so per-player disk is effectively 0. A free GSLT token (sv_setsteamaccount) is mandatory or the server is penalized in the listing and effectively hidden.