How to Run a Large Vintage Story Server (High Player Count)

How to Run a Large Vintage Story Server (High Player Count)

Checked on 14 October 2026 against the default configuration of the Vintage Story 1.22.7 server and the Mod DB.

Through late 2025 and into 2026 the Vintage Story community discovered something Minecraft players have known for years: the game makes a great backdrop for massive "civilization" servers. Community "civilization" servers, where many players build settlements and kingdoms in one shared world, are a popular format on the official forums, and they find the breaking points in entities, chunk handling, networking and mods. If you want to host more than a few friends, the defaults will not carry you. This guide covers the server settings that actually move the needle on a high-population world, plus the operational habits that keep one running.

Step 1: Raise the player and queue limits

Every setting below lives in serverconfig.json in your server's data directory, or can be set live from the console. The defaults assume a small server, so they are the first thing to change.

• MaxClients (default 16): the maximum number of concurrent players. Raise it to your target population. Higher values demand more RAM and CPU, so do not set 300 unless your hardware and config are ready for it.
• MaxClientsInQueue (default 0): how many players may wait in line when the server is full. On a popular server, a queue of 10-20 keeps people from being hard-rejected during peak hours.

You can apply these without editing files by using the console: /serverconfig maxclients 100. Restart afterward if the change does not take effect immediately.

Step 2: Control view distance, the biggest lever

Chunk view distance is the single setting most responsible for high-population lag. Every player loads a square of chunks around themselves, and the server has to simulate all of them. Forty players each pulling a wide radius can load thousands of chunks at once.

• MaxChunkRadius (default 12): the highest view distance any player may request. On a server above ~30 players, drop this to 6-8. Players will not notice much on foot, and you reclaim a large amount of RAM and CPU.

If your server feels fine inside a town but stutters whenever people scatter to explore, view distance and terrain generation pressure are almost always the cause. Lowering MaxChunkRadius is the fastest fix. For the deeper mechanics behind chunk-driven stutter, see our chunk loading lag fix.

Step 3: Tame entities and mob spawning

Entities, animals, drifters, and dropped items all cost tick budget. A crowded server with large pastures and busy bases can drown in entities long before it runs out of RAM.

• SpawnCapPlayerScaling (default 0.5): scales each creature's spawn cap up as more players join: the base cap is multiplied by 1 + (players − 1) × this value × the creature's own scaling factor. With the default 0.5 and 100 players online, that is about 50 times the single-player cap for a creature that scales fully. Lower it to 0.25 or below to keep mob counts sane at scale.
• Cap animal breeding socially or with rules. Player-run ranches with hundreds of animals are a common cause of creeping TPS loss that no config alone will solve.

Vintage Story targets roughly 30 ticks per second. The interval is governed by TickTime (default 33.333 ms). When that value starts climbing in practice, the server is falling behind and players feel rubber-banding. Treat rising tick time, not RAM usage, as your real lag alarm.

Step 4: Pick hardware that matches the workload

Because simulation leans on one thread, a 4.5 GHz+ single-thread CPU (a recent Ryzen 9 or Core i9) will outperform a slower chip with twice the cores. A busy server commonly sits at 100-150% CPU as the world thread saturates and helpers pick up slack, which is normal, not a fault.

Use SSD or NVMe storage. Chunk generation and saving on a large world are storage-heavy, and a spinning disk will stall the world thread during autosaves. For the full hardware decision framework, see our buyer's checklist for choosing a host.

Step 5: Install server-side optimization mods

The community has built server-only mods specifically for high-population servers. The most prominent is Tungsten, a server-side performance mod that reduces garbage-collection pauses by reusing internal lists (entities, blocks, drops, event data) and optimizing chunk load and unload paths. It ships dozens of micro-optimizations, claims memory savings on the order of 15 MB per minute, and changes no gameplay. Its reported gains grow with player count, which is exactly where you need them.

On the Mod DB, Tungsten (by Zaldaryon) is listed as server side only, release 1.3.7 for 1.22.5 and 1.22.6, so players download nothing for it. Its author also makes OptiTime, the client-side counterpart each player can install for frame rates. Entity Resync Fix, which targets ghost players, frozen mobs and floating drops in 1.22, runs on both sides, and the game offers it to players when they join. To learn how to load any of them onto a dedicated server, follow our mod installation guide.

Step 6: Operational habits for big servers

• Whitelist or open intentionally. A public no-whitelist server attracts griefing at scale. Vintage Story has a granular land-claim and privilege system; lean on it. See the admin commands reference for roles, claims, and moderation.
• Stagger autosaves. Large saves cause a brief hitch. The server autosaves every 300 seconds by default; /serverconfig autosaveintervall changes it (30 to 3600 seconds). Keep it reasonable and warn players before manual saves during events.
• Know the built-in safety stops. The server warns at 90% of DieAboveMemoryUsageMb and shuts itself down above it (50,000 MB by default), and it refuses to run when free disk space drops below DieBelowDiskSpaceMb (400 MB by default), to protect the save from corruption. On a big world, make sure neither limit is closer than you think.
• Watch tick time, not CPU percent. A server can read low total CPU while one thread is pinned. Trust the tick-time and TPS readout.
• Test mod load before an event. Mods behave differently under real crowds. Pre-test your full mod list with as many people as you can gather.
• Tune everything in serverconfig.json, version it, and keep a backup. When a setting change tanks performance, you want to roll back fast.

For the complete reference of every setting touched here, including world generation and access control, see our full server configuration guide.

The honest reality of 100+ players

Events with hundreds of players are impressive, but they are not casual undertakings: they need top-tier hardware and weeks of stress-testing before launch. For a typical clan or community, the sweet spot is a well-tuned 20-50 player world on a high-clock dedicated machine. That is achievable for almost anyone willing to set MaxChunkRadius sensibly, cap entities, and run an optimization mod.

Want the high-clock CPU, NVMe storage, and one-click mod installs without renting a workstation? Rent a Vintage Story server from Supercraft and scale your player slots as your community grows.