Garry's Mod server hosting: what to look for before you pay

Good Garry's Mod hosting is mostly about one CPU core. The server runs every addon's Lua and every prop's physics on a single main thread, so a fast core with a stated, enforced share of it matters more than any other line on the pricing page. After that come memory sized for your addon collection rather than your slot count, full file access so Lua can be edited and addons removed, a MySQL database on the same network if you run DarkRP or a shared admin mod, a location close to your players, and an honest description of what happens during an attack. "128-tick", "unlimited slots" and a long list of regions are mostly decoration.

This post is about judging an offer. Installing the server, the launch line and server.cfg are covered in Garry's Mod server setup; getting addons onto players' machines in Workshop addons and FastDL; DarkRP itself in the DarkRP server guide; and finding the addon that makes a server lag in Garry's Mod server lag and Lua errors. Here, those facts are turned into questions to ask before you pay.

What a Garry's Mod server asks of a host#

A Garry's Mod server is srcds running the garrysmod game directory (Steam app id 4020), with a gamemode and a pile of addons on top. The engine is old and light; almost everything that costs resources is content somebody else wrote. That shapes what a host has to provide:

• One fast core for the main thread, where Lua hooks, timers, entity think functions and physics all run in sequence.
• Memory that follows the addon list. Models, materials and Lua for every mounted addon are held by the server whether one player is connected or forty.
• Disk for the base install (a few gigabytes), the Workshop cache, which grows with your collection, and logs and data files that addons write.
• One reachable port: 27015 UDP carries both game traffic and the server browser query. RCON over TCP and SourceTV are extras.
• A database, for DarkRP on more than one server, for admin mods that share ranks between servers, and for the many logging, inventory and economy addons that expect MySQL.
• Your control over the files. Fixing a Garry's Mod server usually means editing a Lua file, removing an addon folder or reading a log. Anything between you and the file system slows every fix down.

Bandwidth during play is small. What players notice is the first join: Workshop content comes from Steam, but anything sent through FastDL comes from wherever you put it. That is a content question rather than a hosting one, and it is covered below.

CPU: single-thread speed and an honest share#

This is where Garry's Mod hosting succeeds or fails. The server has to finish each tick inside its budget - about 15 ms at 66 ticks, 30 ms at 33 - and everything on the main thread counts against it. If an addon spends 10 ms per tick in a Think hook, that is two thirds of a 66-tick budget gone, and no number of extra cores gets it back. Extra cores help with loading, networking and the operating system around the process; they do not make that thread faster.

So the questions are about one core:

1. How fast is a single core? A recent desktop-class processor or a high-clocked server chip makes a visible difference to tick time. An older many-core server processor at a low clock can look impressive on paper and still run Lua slowly. If a host names its CPU, look up single-thread performance rather than core count.
2. How much of it is yours? "2 vCPU" can mean two guaranteed cores, two threads shared with a crowd of neighbours, or a share that shrinks at busy hours. Ask how the limit is enforced. A modest hard limit you can see on a graph beats a generous figure with no guarantee - shared CPU and noisy neighbours explains why the unguaranteed kind fails exactly when your server is full.
3. Can you see it? A CPU graph against the plan's limit, plus the in-game stats command, tells you whether the server is short of CPU or wasting it.

The graph has one trap. A server pinned at 100% of one core on a 2 vCPU plan shows 50% overall and looks comfortable. Reading game server CPU usage shows how to spot a single saturated thread behind a calm total. In Garry's Mod the quicker check is stats in the server console: when the fps column falls below your tick rate, the main thread is behind.

On RE:NODE, CPU is a percentage of one core - 150 is 1.5 vCPU - enforced as a hard throttle to the share you bought, with one container per server. A server at its limit is slow, never suspended for it. Garry's Mod plans run from 0.75 vCPU on the smallest tier to 2.5 on the largest.

RAM by gamemode and addon count#

Memory is the headline number on every Garry's Mod plan, and the slot count is a poor guide to how much you need. The size of the collection is a better one. A realistic table:

A few things drive where in each range you land:

• Addon count and type. Prop packs, vehicle packs and map content cost memory once, at load. Lua-heavy addons - inventories, HUDs with server-side logic, NPC systems - cost memory and CPU continuously.
• Gamemode. Round-based modes like TTT reset the map regularly, which clears entities and keeps memory flat. DarkRP and sandbox servers accumulate entities, props and data until the next restart, so the figure that matters is the one just before the nightly restart, not after startup. The TTT server guide covers what that gamemode needs in detail.
• Maps. A large RP map with dense props uses noticeably more than gm_flatgrass. Some TTT and RP maps also need Counter-Strike: Source content mounted, which adds to disk and memory.

What this means when comparing offers: buy for the end of the day, and check what happens at the limit. Some hosts let a server swap to disk, which turns a memory shortage into an evening of stutter. Others stop the process. On RE:NODE a server that reaches its memory limit is stopped and restarted clean instead of swapping, so a memory problem shows up as an unexplained restart at a similar time each day rather than as slow lag. Either way, you should know which behaviour you are buying.

The 32-bit ceiling

One Garry's Mod quirk makes large plans less useful than they look. The standard branch runs a 32-bit server process, which can address roughly 3-4 GB however much memory the plan has. A server with a huge collection can crash with allocation errors while the panel shows gigabytes free. The x86-64 beta branch removes that ceiling, at the cost of needing 64-bit builds of every binary module in garrysmod/lua/bin/.

So before paying for an 8 GB plan to run a 32-bit server, ask yourself whether the server can use it. A host worth choosing lets you pick the branch, and anyone selling Garry's Mod plans above 4 GB should be able to tell you which branch their install uses.

Workshop collections, FastDL and disk#

Garry's Mod has two content systems, and a host affects them differently.

The server side - what the server loads - is usually a Workshop collection mounted at startup:

+host_workshop_collection 123456789 -authkey <steam_web_api_key>

The server downloads and caches the collection at boot. That needs outbound access to Steam, disk for the cache, and a launch line you can actually edit. A host that only lets you choose from a fixed list of addons, or rewrites your launch parameters, makes this harder than it needs to be. The cache also makes startup slower the bigger the collection gets, which matters when a crash or a restart has players waiting.

The client side - what players download - is Steam's job for anything added with resource.AddWorkshop, and FastDL's job for loose files set up with resource.AddFile. FastDL is an ordinary web server holding compressed copies of your files, with sv_downloadurl pointing at it:

sv_downloadurl "https://fastdl.example.net/garrysmod/"sv_allowdownload 0

FastDL does not need to run on the game server, and usually should not. A small web host serves static files far better than srcds does, and keeps the download traffic away from the game process. When comparing offers, check whether the game plan comes with a web server or whether you need a separate one - and if you are moving mostly to Workshop content, you may not need FastDL at all. Workshop addons and FastDL has the full setup, including the .bz2 compression and the folder layout that trips people up.

On RE:NODE, game plans do not include a web server, but a small plan from web hosting serves FastDL with a domain and a certificate issued and renewed automatically through its proxy slot. Disk on the Garry's Mod plans runs from 10 GB to 40 GB on NVMe, which comfortably holds a large collection and its cache.

MySQL for DarkRP, admin mods and logs#

A single Garry's Mod server can run happily on SQLite. DarkRP stores money and owned doors in garrysmod/sv.db by default, ULX keeps its groups and bans in data files, and many addons write to the same local sv.db. For one server that is fine, and a database included in a plan is not a reason to pick it.

You want MySQL when:

• You run more than one server and want shared money, ranks or bans between them.
• An addon expects it. Plenty of logging, inventory, economy and admin addons offer MySQL storage, and some of the larger ones are built around it. SAM can store its data in MySQL; ULX needs a separate addon for that.
• You want to query or fix data while the server runs, from phpMyAdmin or a client, rather than stopping the server to open sv.db.

Garry's Mod reaches MySQL through a binary module - usually mysqloo - placed in garrysmod/lua/bin/. The module must match the server's platform and branch: gmsv_mysqloo_linux.dll for the 32-bit Linux server, gmsv_mysqloo_linux64.dll for x86-64. The .dll extension on Linux is correct and confuses everybody. A host that does not let you upload files to lua/bin, or runs a different branch from the one you expect, breaks this quietly: DarkRP falls back to SQLite and money appears to reset.

Three questions for any offer:

1. Is a database included, or priced separately? That changes the comparison between two plans that look similar.
2. Where does it run? Addons make many small queries. A database on the same network answers in under a millisecond; a free remote one on another continent adds tens of milliseconds to every query, which turns into hitches when the main thread waits on it.
3. Is it backed up, and can you get it out? A database you cannot dump is a database you cannot move.

Every RE:NODE Garry's Mod plan includes one database slot, created from the panel with a generated host, user and password, and an "Open in phpMyAdmin" button that signs you in with a one-use token. If you want the database on its own resources, MySQL 8.4 LTS is also sold separately under database hosting. The admin side - groups, permissions and choosing between them - is in ULX and SAM admin.

Tick rate and what "high tick" offers mean#

Tick rate is set with -tickrate on the launch line. Garry's Mod servers usually run at 33 or 66. Raising it roughly doubles the per-tick CPU cost and makes no difference to a server that is already falling behind.

That makes "128-tick Garry's Mod hosting" an odd thing to advertise. Any host can let you type -tickrate 128; the question is whether one core can finish a tick in under 8 ms with your addons loaded, and for a DarkRP server it almost certainly cannot. A plan sold on tick rate is selling a launch parameter. What you want is the freedom to set the rate yourself and a CPU fast enough to hold it. What tick rate actually means has the longer argument.

Location, latency and DDoS#

Pick the location for where your players are. Source interpolates other players' movement, so moderate latency is hidden well, but past roughly 100 ms gunfights in TTT start to feel unfair and props in sandbox lag behind the player carrying them. Most Garry's Mod communities are regional; put the server in the middle of where the regulars live, and ask a few of them to ping a host's test address in the evening before you pay. Latency, jitter and packet loss explains what to look at besides the average.

RE:NODE runs in one location, Germany, on hardware we run. That suits players in Europe and nearby, and it is the wrong choice for a community in North America or Asia.

Attacks are the other half of the network question. Source servers have long been targets for query floods and reflection attacks, and DarkRP communities attract grudges. What filtering upstream of a server does well is drop volumetric floods, reflection traffic and malformed packets. What it does poorly is tell an attack shaped like real clients from real clients. When reading a host's claim, look for what is filtered in plain words, what happens when filtering is not enough (some hosts null-route the address during a large attack, which takes the server offline), and no promise of zero downtime. A host that promises no downtime under any attack is selling you a sentence, not a service. DDoS attacks on game servers explained goes through the categories.

On RE:NODE the wording is exactly this: upstream filtering that drops obvious volumetric floods, plus reflection and malformed traffic. Attacks that look like real players are not filtered.

Some protection is yours. Keep rcon_password long or unset, and do not open TCP 27015 unless you need RCON - RCON safely explains why. Many "attacks" on small servers turn out to be a backdoored addon or an exploitable net message, which no network filter can catch.

Panel features that actually matter#

Most hosting panels look alike in screenshots. These are the features you will use every week:

• An unfiltered console with history. Lua errors announce themselves there, with the file path of the addon that threw them. A console that hides or truncates output hides your problems.
• Full file access, including SFTP. Removing an addon is deleting a folder; fixing one is editing a Lua file. Uploading a map pack through a browser form is miserable; through SFTP it is routine. SFTP and the file manager has the details.
• An editable launch line. Collection ID, gamemode, map, tick rate, max players and branch all live there. A panel that generates it from a short form and drops anything it does not recognise is a problem.
• Scheduled restarts. Sandbox and DarkRP servers benefit from a nightly restart. A schedule that can send a warning message, wait and then restart is worth more than any "auto-restart on crash" checkbox - restart schedules that help covers the timing.
• Backups off the machine, restorable by you, covering garrysmod/data, sv.db and your config. A backup stored next to what it protects does not protect against losing the server.
• Subusers. Garry's Mod servers are run by staff teams. A developer needs files; a moderator may only need the console. Handing out the account password is how servers get lost.

On RE:NODE, every plan gets the same panel: a live console with history, a file manager with an in-browser editor, SFTP with per-server credentials, a Schedules tab that runs console commands, backups and power actions in order, backup slots stored off the machine, and subusers with console-only or files-only access. Mods and addons are installed by you, through the file manager, SFTP or the Workshop - there is no list of allowed addons, and no one-click addon installer either.

Red flags in Garry's Mod hosting offers#

Some offers are just expensive. Others tell you how the host operates.

• "Unlimited slots." Garry's Mod caps -maxplayers at 128, and the real limit is the main thread long before that. "Unlimited" means nobody checked.
• "Free premium addons" or "full DarkRP pack included." Paid Garry's Mod addons are sold per buyer, usually through Garry's Mod marketplaces with licence checks. A free bundle of them is almost always leaked, and leaked addons are a well-known route for backdoors that hand someone else RCON-level control of your server. What to do when your server is hacked is the page you do not want to need.
• A vCPU figure with no explanation. "Up to 4 cores" with nothing about enforcement usually means whatever is left over.
• Large plans with no word on the branch. 8 GB on a 32-bit server is 4 GB you cannot use.
• No way to upload binary modules or edit the launch line. You lose MySQL, the 64-bit branch and half the useful addons.
• No database, or one on another continent. A cost you discover after a week of hitches.
• No backups, or backups on the same disk. See backups that actually restore.
• Zero-downtime DDoS promises and 100% SLAs. Nobody delivers them, which makes you wonder what else on the page is decoration.

None of these prove a host dishonest. Several are signs of a product built for a different customer. But a community runs on its first host for months, and moving later means a weekend of copying data folders and re-pointing players.

A checklist before you pay#

In the order worth checking:

1. Location close to most of your players, confirmed with a ping from a few of them.
2. CPU: a stated share of a fast core, enforced and visible on a graph.
3. Memory for your addon collection at the end of the day, with a known behaviour at the limit and a known branch.
4. Launch line and files fully editable, SFTP available, lua/bin writable.
5. Database on the same network if you need one, included or priced into the comparison.
6. FastDL planned: Workshop-only, or a small web host beside the game server.
7. Backups off the machine, restorable by you.
8. An honest DDoS description and a support route you have tested.

For the parts that apply to every game, see how to choose game server hosting and game server CPU requirements.

FAQ#

How much RAM does a Garry's Mod server need?

1-2 GB for a sandbox or TTT server with a modest collection, 3-4 GB once you pass about a hundred addons, and 4-6 GB for a busy DarkRP server. Measure just before the nightly restart, not after startup, and remember the default 32-bit server cannot use much more than about 4 GB.

Is a DarkRP server more demanding than TTT?

Usually, yes. TTT resets the map every round, which keeps entity counts and memory in check. DarkRP accumulates props, printers and player data all session, and its addons tend to be Lua-heavy, so it needs both more memory and a faster main thread for the same player count.

Do I need MySQL for a Garry's Mod server?

Not for a single server. SQLite in sv.db handles DarkRP and most addons well. MySQL becomes worth it when several servers share money, ranks or bans, or when an addon you want is built around it.

Will a higher tick rate make my server smoother?

Only if the CPU can hold it. A server that already falls below its tick rate in stats gets worse at a higher one. Fix the expensive addons first, then raise the rate if there is headroom.

Can I host FastDL on the same server?

You can, but a small separate web server does it better and keeps download traffic off the game process. Many servers now use Workshop content alone and need no FastDL at all.

Can I move my Garry's Mod server to another host later?

Yes. Copy garrysmod/addons, garrysmod/data, garrysmod/cfg, sv.db and any binary modules, dump and import the MySQL database if you use one, check the branch matches, and point players at the new address. Moving a server without losing players covers the rest.