One of our sizing changes made a game more expensive to start hosting. It was the most useful change in the batch.
Enshrouded used to sit on a generic ladder that began at 4 GB of memory. The game publishes a flat 16 GB requirement, applying equally to a four-player session and a sixteen-player one. So the cheapest Enshrouded build we offered could not reliably start the game it was sold for. Raising that entry rung to 16 GB made it cost more. It also made it work, which is the only version of that trade worth taking.
That is the shape of what a real sizing audit turns up. Most of it saves people money. Some of it does not, and the parts that do not are usually the parts that matter.
The problem with one ladder for every game
A generic ladder is the easy way to build a configurator. Pick memory tiers, attach storage and cores in fixed proportion, apply to everything. It is fast to build and it is wrong in a specific, expensive way: it assumes every game spends resources the same way, and games do not even agree on which resource matters.
Three examples from our own catalog, all previously on the same ladder.
Factorio was carrying six cores and 150 GB of storage at the top rung. Headless Factorio is about a gigabyte of memory, comfortable at four, and its saves are measured in megabytes. The simulation runs on one thread, so five of those six cores did nothing. It now tops out at 8 GB, two cores and 30 GB, and it runs exactly as well.
Garry’s Mod was the opposite mistake. Memory is close to free there even at high player counts, but Workshop content is what fills the disk, and an addon-heavy server genuinely reaches tens of gigabytes. Its ladder needed memory moved down and storage moved up.
BeamMP was the worst of the set. The server is a state relay: the physics runs on the players’ own machines, and the official requirement for the server process is measured in megabytes. It was being sold 150 GB and 250 GB rungs. What a BeamMP server actually needs is upload bandwidth, which no slider on any configurator sells.
None of those are exotic games. They were simply never looked at individually.
What we actually did
The method was unglamorous and mostly consisted of reading.
Start with what the developer publishes. Facepunch publish a 12 GB floor for Rust. The Windrose developer guide publishes a tier table that is unusually specific: 8 GB at two players rising to 16 at the top, 35 GB of SSD at every tier, two cores at every tier. Enshrouded publishes its flat 16 GB. Where a developer states a number, that number wins, and our job is to make sure no rung sits below it.
Then check the fleet. A published requirement tells you what the game asks for. Our own servers tell you what it uses. Backup sizes are the honest measure of how much disk a game really writes, and they are frequently far below what the game’s install size suggests, because the install is static and the save is not.
Then find the cap. This is the step most easily skipped, and it produced the clearest single error we found. Windrose caps a server at eight players, straight from the developer’s own documentation. We were offering a 24 GB rung for it. That rung was sizing for a roster the game will not allow anyone to have. Palworld caps at 32. Enshrouded caps at 16. Selling above a cap is not generosity, it is a bill for nothing.
Then decide which axis the game scales on. Enshrouded scales on cores with memory pinned flat. Factorio scales on entity count, which correlates with neither players nor time. Project Zomboid scales almost linearly with players, because its Java heap runs about 6 GB before anyone joins plus roughly half a gigabyte each, which is how a 32-player server arrives at 22 GB.
Player counts are a sizing aid, not a product
There is a decision underneath all of this that is worth stating plainly, because it changes what the numbers are for.
We do not bill player slots and we do not cap them. There is no seat count on an invoice and no upgrade to buy when a tenth person wants to join. The player-count control in the configurator exists to suggest a build, and that is all it does.
That sounds like a small distinction and it is not. If slots were a product, the incentive would be to make the slot number the headline and let the hardware follow it. Because slots are free, the player count control has exactly one job: land you on hardware that will hold up. It can suggest a smaller build without costing us a seat sale, which is why it does, in most of the catalog, quite aggressively.
The exception is a cap the game itself imposes. Enshrouded stops at 16 and Windrose at 8 because those are limits in the games, and no build changes them. We would rather the control stop there than take money for a roster the engine will refuse.
What came out of it
Most rungs came down. Factorio, BeamMP, Necesse and Terraria are all games where a correct build is a small one, and they were all being offered builds several times larger than anything they can use. Necesse is the extreme case: a 2D game with worlds measured in megabytes, previously offered 150 GB of storage.
Some rungs moved sideways. Garry’s Mod traded memory for disk. Arma Reforger holds 40 GB of storage at every player count, which looks like an error until you know that a Reforger server’s disk is dominated by its mod cache, and the engine mounts the full dependency set from disk rather than only what the current config names. A mod folder that looks unused usually is not.
Two rungs went up. Enshrouded, for the reason at the top of this post. And Palworld, where the 8 GB starter rung was removed rather than repriced: the official recommendation is 16 GB, and 8 GB is documented by the developers as an out-of-memory risk. Suggesting a build that is documented to fail is worse than suggesting an expensive one.
The part that does not stay fixed
Windrose is in early access. Its requirements have already moved once, and they will move again. The same is true of any game still being built, which is a growing share of what people want to host.
So this is not a task that completes. The figures track current developer guidance and current fleet behaviour, and both change. What we can commit to is the method: read what the developer publishes, check it against what our servers actually do, find the cap, and work out which axis the game scales on. Re-run that at each major patch.
The alternative is a ladder that was right once, applied to a game that has changed twice since, which is the thing we just spent this work undoing.
If you want the resulting numbers rather than the reasoning, they are all in how much RAM a game server needs, game by game. If you want to skip the reading, the configurator has the same curves behind its player-count control and quotes the price live before you pay.