V Rising Blood-Moon Load: 60-Player Node Sizing, Entity Counts and Tick Budget

V Rising looks lightweight next to Rust or ARK, and for a private 4-player co-op world it genuinely is. The problem is Blood Moon nights, castle sieges and a populated public server. Under those conditions the entity simulation cost roughly triples for a 20-minute window, and a node sized for the average case will hitch at exactly the moment everyone is online and watching.

The V Rising entity model

Three things drive server cost, in descending order:

• Castle pieces. A fully-upgraded endgame castle is 400-900 placed structures, each with a tick cost for integrity, servant pathing and storage resolution. A 60-slot server with 25 active castles is simulating 12,000-20,000 structures continuously. This is the dominant cost and it grows monotonically across a wipe.
• Servants and prisoner AI. Each castle can hold up to 9 servants. 25 castles = 225 active AI entities that path every tick. Servant missions resolve their loot tables on completion, which creates small but sharp CPU spikes.
• Player count. Genuinely cheap per player (~120-200 MB RSS, ~0.03 cores) compared to the castle simulation. Do not size V Rising on slot count alone.

Reference sizing for 60 slots

• RAM: 16 GB for a fresh wipe with light building; 32 GB is the realistic figure once castles mature. Budget roughly 900 MB per developed castle plus 350 MB per online player plus 2.5 GB baseline. That is 2.5 + (25 x 0.9) + (60 x 0.35) = ~46 GB at theoretical worst case, though in practice castles are not all fully loaded simultaneously because V Rising unloads castle interiors when no owner is present. 32 GB handles 60 slots comfortably; 48 GB removes the risk entirely.
• CPU: 6-8 physical cores at 4.0 GHz+ for 60 slots. Single-thread performance matters more than core count because the entity tick loop is not well parallelised. A 4-core 5.0 GHz part will beat an 8-core 3.0 GHz part at this workload.
• Storage: V Rising saves are small (20-60 MB) but the server rewrites the whole save file on each autosave. Any NVMe is fine; a SATA SSD is acceptable; HDD is not.
• Network: 100 Mbps is technically enough upstream for 60 players, but V Rising’s siege traffic bursts during castle raids. Provision 1 Gbps to avoid policer drops during a multi-clan fight.

Tuning the tick and the save

V Rising exposes a small settings surface. These are the ones that actually move the needle on a populated server.

# ServerHostSettings.json
"SaveInterval": 300,
"ListOnSteam": true,
"ListOnEOS": true,
"MaxConnectedUsers": 60,
"MaxConnectedAdmins": 4,
"GameSettingsPreset": "StandardPvP"

# ServerGameSettings.json (relevant subset)
"CastleDecayRateModifier": 0.5,
"CastleHeartDamageMode": "OnlyWhenOnline",
"ServantConvertRateModifier": 1.0,
"BloodMoonFrequency_Min": 10,
"BloodMoonFrequency_Max": 18

The two settings that matter most for hardware are CastleDecayRateModifier and ServantConvertRateModifier. Decay removes abandoned castles and is the single most effective way to keep entity counts bounded on a long-running server — a lower decay rate (0.3-0.5) prunes dead structures faster. In the opposite direction, a high servant convert rate fills more castles with more AI.

On the OS side, pin the server process to physical cores with taskset -c 2-9 and keep core 0-1 free for the kernel and Steam network threads. V Rising responds measurably to this because it otherwise lets the entity tick and the network receive path share a core.

Blood Moon: the 20-minute stress test

Blood Moon increases mob density in the world, which multiplies the wild-entity tick cost. Operators who size against a normal night and then measure during a Blood Moon see CPU utilisation jump from 45% to 75% on a 60-slot server. Keep BloodMoonFrequency_Min at 10 days or higher unless you deliberately want the load — nightly Blood Moons on a fully-built server will push past the tick budget and produce visible desync during castle raids.

Why castle decay is a hardware setting

It is tempting to treat decay as a gameplay/griefing question and leave it at defaults. On a hardware level it is the primary control on long-run entity count. A server at 60 slots with no decay enforcement accumulates abandoned castles indefinitely — a player quits, their castle heart decays, but the 700 structures do not vanish until the heart is destroyed. Measured on a three-month-old server, roughly 40% of placed structures belonged to players who had not logged in for 30 days. Enforcing CastleHeartDamageMode: OnlyWhenOnline together with a decay modifier of 0.5 removes those structures and drops steady-state RAM by 20-30%.

Time your decay sweeps to run during your lowest-population window so the resulting chunk unload and save write does not collide with a siege. The same schedule, incidentally, is a natural point to take a filesystem snapshot.

Storage detail that matters more than it looks

V Rising rewrites the entire world save file rather than appending, and it keeps short server-side journals per castle that are written on a different cadence. This produces a write pattern that is small in volume but high in file-open frequency. Consumer NVMe drives with DRAM-less controllers handle this noticeably worse than drives with an onboard DRAM cache, showing up as occasional 200-400 ms save stalls even though throughput is nowhere near saturation. If you have a choice, pick a drive with DRAM and rated 1 DWPD endurance over one with a larger raw capacity.

The practical mitigation is a restart before the Blood Moon window if your uptime is already past 72 hours. V Rising’s memory does not fully release on castle unload, and a multi-week server accumulates 15-25% RAM bloat that only shows up under the Blood Moon spike. Our dedicated server comparison table includes restarts-per-day allowances, which is worth checking because some managed plans cap them. If you are choosing between a smaller node with frequent restarts and a larger one with none, compare bare-metal specs side by side — for V Rising specifically, RAM headroom is the cheaper insurance.