Menu
 

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

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

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. Player-run events have pushed a single world to 300 concurrent players, and public stress tests on 1.22 have aimed for 500 at once to 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.

The hard limit

Vintage Story is a C# server that is only lightly multi-threaded. Most simulation rides one busy world thread, so single-thread CPU clock speed matters far more than core count.

What scales badly

Loaded chunks, tracked entities, and per-player network sync all grow with player count. Twenty players spread across the map load far more world than twenty players in one town.

The realistic ceiling

Self-hosting on a home PC tops out around 10-20 players. Past that you need a dedicated machine with a high-clock CPU, fast storage, and careful config.

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 the mob cap up as more players join, using roughly (this value x player count x base cap). On a 100-player world this can multiply hostile and passive spawns dramatically. 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.

Target populationRAMCPU single-threadMaxChunkRadius
10-20 players12-16 GB4.0 GHz+10-12
20-50 players20-32 GB4.5 GHz+8
50-100 players32-48 GB4.5 GHz+ top tier6-8
100-300+ players64 GB+fastest available, plus optimization mods6

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.

Tungsten is built to coexist with other optimization mods such as Synergy and OptiTime, and with desync fixes like Entity Resync Fix. Because these mods are server-side only, they do not force a download on every joining player. 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. Keep the autosave interval reasonable and warn players before manual saves during events.
  • 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. The 500-player public stress tests exist because 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

Civilization events that hit 300 players are impressive, but they are not casual undertakings. Organizers report spending serious money on top-tier hardware, running custom server software, and stress-testing for weeks 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.

Tired of fighting this issue every patch?

Run a managed Vintage Story server with us. We handle the patches, mod-version pinning, save backups, and DDoS protection. Set up in 3 minutes, 5 datacenter regions, no contract.

See Vintage Story hosting plans →
Top