V RISING · SERVER REQUIREMENTS · OCTOBER 2026

V Rising Server Requirements and RAM Guide

Stunlock publishes no RAM figure for the V Rising dedicated server, so plan sizes look confusing. Here is how to turn your player count, castle rules and settings into the right amount of RAM, CPU and slots, and how to spot when the server has outgrown its plan.

Best starting point

For a private clan server, 6 GB is the usual vanilla starting tier. If you plan to mod, or expect the world to grow quickly, start at 8 GB instead.

Biggest load driver

Player count matters, but castle count matters more. Every extra territory means more loaded world state, more servant state and more simulation work even when owners are offline.

CPU rule

V Rising benefits more from strong single-thread speed than from piling on extra cores. A higher slot count on the same weak CPU will not make raids smoother.

Upgrade triggers

Start planning the next tier when RAM sits above 85%, CPU is regularly above 80%, or peak population reaches 75% of your slot cap.

What the server is actually doing with RAM, CPU and disk

Stunlock gives you the server software and the settings, but not an official dedicated-server RAM target for 1.1.x on PC. That is why rental plans look inconsistent at first glance. What matters in practice is how much world state has to stay loaded, how much simulation happens each second, and how often the server writes saves to disk.

RAM is there to hold the live world: connected players, loaded castle territories, servant state, containers, crafting stations, AI state and everything else the world needs to remember without constantly reloading it. CPU time is spent advancing the simulation at the target ServerFps, which Stunlock’s example sets to 30. The busier the world is, the more work the server has to finish inside each of those update steps.

That is also why V Rising is usually more sensitive to single-thread CPU speed than to a big core count. The main world simulation has to keep up in sequence; if that main thread falls behind, combat and raids feel late even when other cores are sitting idle. Extra threads still help with background work and general system breathing room, but they do not replace a strong main thread. If you want the wider hosting context, our game server hardware guide explains why sandbox servers so often bottleneck on the main thread first.

Disk is a different job. V Rising autosaves to compressed .save.gz files, so AutoSaveInterval and AutoSaveCount mostly change write frequency and storage use, not live RAM demand. Short intervals and lots of retained saves put more pressure on disk and can create visible save spikes on slower storage. The dedicated server itself is Windows-only, so for self-hosting you should plan around Windows; if a host runs it on Linux, that is their compatibility layer rather than an official native build.

One thing works in your favour. Stunlock said in March 2026 that content development on V Rising has wrapped up, so what arrives now is balance and bug-fix patches. A big new system is unlikely to change these sizing rules overnight.

The castle maths: why offline bases decide your plan

The easiest mistake with V Rising hosting is to size for player count alone. A quiet server with few castles can hold more people than a build-heavy world with the same slot cap, because castles stay part of the loaded world even when the owners log off. That means floor limits, structures, inventories, servant activity and territory state keep adding to memory use and simulation work.

By default, CastleLimit is 2 and ClanSize is 4. That sounds harmless until you multiply it out. A full default-sized clan can therefore spread across up to 8 castle territories if you allow every member to use both hearts. Multiply that pattern across the whole server and the world gets heavy long before the slot count looks scary.

  • 10 players × 2 castles = 20 castle territories
  • 20 players with CastleLimit 3 = up to 60 castle territories
  • 40 players × 2 castles = 80 castle territories
  • 40 players at 1 castle each = 40 castle territories

That last comparison is the key rule. Halving CastleLimit from 2 to 1 roughly halves total castle load, which often matters more than trimming a few slots. It is not perfectly linear because one huge, servant-packed castle costs more than one modest outpost, but the direction is reliable: fewer territories means less world to keep loaded.

Servants add another layer. ServantLimit is set per castle heart level, so a community with lots of fully developed castles will be heavier than a PvP world where players build lean and lose bases regularly. If abandoned castles are cluttering the map, raising CastleDecayRateModifier above 1.0 helps clear unfuelled ruins sooner. The trade-off is obvious: neglected active-player castles also get less grace.

This is the part worth visualising, because the same player count can produce very different world weight.

Castle territories the server may keep loaded
Players × CastleLimit. Offline castles stay in the world.
10 players × 2 castles
20
40 players × 1 castle
40
20 players × 3 castles
60
40 players × 2 castles
80
A 20-player world with CastleLimit 3 can hold more territory than a 40-player world with one castle each.

Practical RAM tiers for renting a V Rising server

Use these as practical allowances from hosts’ guidance, not official minimums. The numbers make sense only when you read them alongside castle load, build style and mods.

RAM to plan for, by player count
Practical allowances from hosts’ guidance, GB of RAM
1–8 players, small vanilla PvE
4 GB (tight)
2–10 players, small clan
6 GB
Up to about 20 players, or any modded world
8 GB
20–30 players, busy community
10–12 GB
30–40 players, build-heavy with raid nights
12 GB+, often 14 GB+
Each step up the list adds castles as well as players. Buy one tier higher if your CastleLimit is 3 or more.
Setup Players Castle load RAM to plan for What to watch
Very small vanilla PvE 1-8 Light building, few servants, few offline bases 4 GB can work, but headroom is tight Watch for memory growth after a few days, and for one large building phase pushing it over
Small clan or friends server 2-10 Default castle rules, ordinary vanilla progression 6 GB Good fit for most small groups unless everyone builds separately
Growing vanilla world or any modded world Up to about 20 Moderate castle spread, more AI activity, BepInEx mods 8 GB Watch restart-to-restart memory creep and raid-night CPU peaks
Busy mid-size community 20-30 Many active territories, servants and regular combat 10-12 GB Both RAM and main-thread CPU start to matter at the same time
Large active community 30-40 Build-heavy, busy raid windows, lots of loaded castles 12 GB+ and often 14 GB+ Buy extra headroom if CastleLimit is 3 or higher, or if building is the point of the server
Strict-rule large PvP server 40 One castle per player, low clutter, abandoned bases cleared fast 12 GB can be enough in hosts’ guidance Only true if the rule set is enforced and the world stays lean

The practical reading is simple. 6 GB is the sensible vanilla floor for a real clan server, 8 GB is the safe floor for mods or a server growing towards about 20 players, and 10-12 GB is where many public communities stop worrying about ordinary growth. 4 GB is not useless, but it is a budget edge case, not a comfortable default.

Slots, RAM and CPU are three different limits

Hosts usually sell V Rising plans in one of two ways: by slots or by RAM. Slot-billed plans make the admission cap obvious, while RAM-billed plans make the hardware allowance obvious. Neither tells the whole story on its own.

MaxConnectedUsers is often shown with the example value 40, and Stunlock says the technical maximum supported is 128. That is a connection limit, not a promise that the world will feel good at that number. A 40-slot world full of sprawling castles can be heavier than a stricter 60-slot world with one castle per player and quick decay. Size for peak concurrent players, not for the total headcount in your Discord.

The other common mistake is paying for more slots on the same CPU and expecting raids to improve. Slots only let more people join. If raid lag is caused by the main simulation thread running out of time, adding slots without improving CPU performance changes nothing except how many people can suffer it at once.

Ask what CPU allocation is included. A London plan in our comparison lists 10 GB of RAM, 2 CPU threads and 10 GB of NVMe storage, which is the level of detail you want before you pay. For V Rising, fast per-thread performance matters more than a long thread list.

If you want a simple buying rule, use slots to match expected concurrency, RAM to match world growth, and CPU quality to judge raid smoothness. If one of those is weak, the other two do not cancel it out.

Settings that change the bill more than people expect

V Rising splits server settings between ServerHostSettings.json for hosting details and ServerGameSettings.json for gameplay rules. Defaults live in VRisingServer_Data/StreamingAssets/Settings/, while your overrides go in the Settings folder under the persistent data path. The settings below are the ones that most often change what you need to rent.

Setting Default/example Effect on load Sensible small clan choice Sensible 40-player PvP choice
ServerFps 30 Higher update targets cost more main-thread CPU every second. Lower targets reduce CPU pressure but also reduce update frequency and can make combat feel less crisp. Keep the example 30 unless the machine is genuinely struggling Keep 30 if at all possible; solve castle load or CPU quality before sacrificing combat feel
LowerFPSWhenEmpty / LowerFPSWhenEmptyValue Examples 15, 10, 5 Reduces idle CPU use only when nobody is logged in. It does not help peak fights, but it is free savings during quiet hours. Enable it Enable it
CastleLimit Default 2 The biggest direct lever on RAM and CPU because it controls how many territories the server may need to keep loaded. Keep 1 or 2 Keep it strict; avoid 3+ unless you are already buying a larger tier
ClanSize Default 4 Indirect effect. Larger clans can consolidate into fewer castles, while smaller clans often fragment into more separate territories. Default 4 is usually fine Keep near default unless your ruleset has a clear reason to change it
CastleDecayRateModifier Default 1.0 Higher values remove abandoned unfuelled castles sooner, reducing long-term world clutter. The cost is less forgiveness for neglected active bases. Leave at 1.0 unless abandoned bases pile up Raise above 1.0 if dead castles are filling the map
AutoSaveInterval / AutoSaveCount Examples 120 / 20 Primarily disk and storage load, not RAM. Shorter intervals mean more writes; higher counts mean more retained .save.gz files. Use the example values unless you need a different backup rhythm Keep a sensible interval and count; do not mistake save spikes for a RAM fix

Two short examples, using only documented keys and example values:

{
  "Name": "Clan server",
  "Port": 27015,
  "QueryPort": 27016,
  "MaxConnectedUsers": 40,
  "MaxConnectedAdmins": 4,
  "ServerFps": 30,
  "LowerFPSWhenEmpty": true,
  "LowerFPSWhenEmptyValue": 15,
  "AutoSaveInterval": 120,
  "AutoSaveCount": 20
}
{
  "ClanSize": 4,
  "CastleLimit": 2,
  "CastleDecayRateModifier": 1.0,
  "InactivityKillEnabled": true
}

How do you tell a setting change actually helped? Watch the resource that setting targets. CastleLimit and decay changes should reduce world clutter and lower memory growth over restart cycles. LowerFPSWhenEmpty should lower idle CPU only. ServerFps changes show up as reduced CPU pressure, but the trade-off is player-facing responsiveness, so it is usually the last lever to pull rather than the first.

Mods push you up a tier, and PC and PS5 servers are separate

V Rising has no Steam Workshop support for servers. Mods are usually done through BepInEx, commonly distributed through Thunderstore, which means a modded server is not just “vanilla plus extras”. It is more code running inside the same world loop, often with more state to hold and more hooks firing during events and saves.

That is why hosts’ guidance tends to put modded servers at 8 GB+ from the start. Even if the player count is still small, mod frameworks reduce your headroom and make version mismatches more painful. In practical terms, treat a modded server as one tier higher than the same server would need in vanilla.

Patch discipline matters more with mods as well. Back up saves before patching, and remember that some hosts only apply updates on restart. V Rising can run for days, but Stunlock recommends a daily restart anyway, which also helps with memory creep.

Finally, PC and PS5 are separate server branches and do not crossplay. If your community spans both platforms, that is not a settings problem; it is a separate server decision.

Self-hosting on the same PC you play on

If you are thinking about self-hosting a game server from your gaming PC, remember that the V Rising client itself lists 12 GB RAM for both minimum and recommended play. The dedicated server then needs its own share on top of that: 6 GB for a small vanilla world, 8 GB for mods or around 20 players, and more again once castles spread. On one machine, those demands stack rather than overlap.

CPU contention is the other catch. Your local client and the server both want fast cores at the same time, and the server’s main world thread does not stop being important because the player is local. That is why self-hosting can feel fine while building alone and then fall apart once combat, AI and multiple castles are active together.

The official dedicated server is free through Steam Tools or SteamCMD as App ID 1829350, and for self-hosting you should plan on Windows because the official server binary is VRisingServer.exe. Open or forward the UDP game port and QueryPort if you want the server to appear in the list; Stunlock’s examples use UDP 27015 for the game and UDP 27016 for QueryPort. Direct connect only needs the game port, while RCON is a separate TCP service, off by default, and needs a password.

For a clan world, self-hosting only makes sense if the machine can stay on all the time, save reliably, and restart daily at a quiet hour. If you plan to run more than one V Rising world on the same machine, give each one its own -persistentDataPath and its own pair of ports.

Reading the signs before the server outgrows its plan

When V Rising starts feeling bad, the fix is easier if you identify the bottleneck first. Look for the pattern rather than reacting to a single complaint.

Is it RAM, CPU, disk or network?
Players report lag or the server falls over
Is memory near the plan limit at peak, or climbing day after day?
Yes
RAMRestart daily, trim castle sprawl, then move up one tier.
No
Is CPU regularly above 80% during raids?
Yes
CPUCut castle load first, then pick a plan with faster single-thread CPU.
No
Do the spikes line up with autosaves?
Yes
DiskReview AutoSaveInterval and AutoSaveCount, and prefer faster storage.
No
Is the server on a home connection?
Yes
NetworkUpload speed can feel like server lag. Test at a quiet hour.
No
Check the ports and the host’s status page before paying for more
Stop at the first yes. More slots fixes none of these.
Symptom Likely cause First fix How to tell it helped
Memory use keeps climbing over days, then drops after a restart Uptime creep plus lots of offline castles staying loaded Set a daily restart, review CastleLimit, and clear abandoned castles faster with a higher decay modifier if needed Post-restart memory is lower, and the climb between restarts is slower
Rubber-banding or delayed combat during raids while RAM still looks fine Main-thread CPU saturation at the current ServerFps Reduce castle load first, keep ServerFps sensible, then move to a plan with stronger single-thread CPU if needed CPU peaks settle down and raid windows feel more consistent
Server does not appear in the list, but direct connect can work QueryPort is wrong, closed or not forwarded Check the configured QueryPort and make sure the UDP port is open The server appears in the list without changing gameplay settings
Lag spikes line up with autosaves every couple of minutes Disk write stalls on slower storage Review autosave interval and save count, and prefer faster storage if the host offers it Spikes stop matching the save schedule so closely
Crash or forced restart at peak population RAM ceiling reached Move up one RAM tier, especially on modded servers or worlds with high castle counts Peak usage stays below the cap with visible headroom

Use these thresholds as upgrade triggers rather than waiting for a failure: RAM consistently above 85%, CPU regularly above 80%, or peak population at 75% of slots. On a home connection, network upload can also mimic server lag, but on managed hosting the first checks are usually RAM, main-thread CPU and storage behaviour.

What V Rising server plans cost right now

In our V Rising server hosting comparison, these are the plan shapes and prices that map most clearly to the sizing advice above. Use them to compare billing models as much as raw price.

Plan shape How it is billed Price Best fit
4 GB RAM-billed from £8.99/30 days ($11.96) Only for very small vanilla worlds; headroom is tight
8 GB RAM-billed £6.01/month ($7.99) Modded starts or growing vanilla worlds
12 GB RAM-billed £9.77/month ($12.99) A sensible target for many public communities
10 slots, 10 GB, 2 CPU threads, London Slot-billed £8.50/month ($11.31) A clan server with RAM to spare for castles
10 slots with up to 10 GB Slot-billed £10.85/month ($14.43) Billed in pounds; fine if concurrency stays low
20 slots Slot-billed £15.95/month ($21.21) Mid-size community pricing benchmark
40 slots Slot-billed £25.35/month ($33.72) Only worth it if your true peak needs it
60 slots with 16 GB DDR5 Slot and hardware bundle £12.45/month ($16.56) Lots of headroom for a growing community

Conversion used: £1 = $1.33

Monthly price by plan size in our comparison
Regular prices, GBP
8 GB
£6.01 ($7.99)
10 slots, 10 GB, London
£8.50 ($11.31)
12 GB
£9.77 ($12.99)
10 slots, up to 10 GB
£10.85 ($14.43)
60 slots, 16 GB DDR5
£12.45 ($16.56)
20 slots
£15.95 ($21.21)
40 slots
£25.35 ($33.72)
Price does not follow RAM: the 60-slot 16 GB plan costs less than a 20-slot plan.

Tune it or upgrade?

Situation Tune first Upgrade when
Small vanilla clan server, no mods, light raids Use 6 GB, enable lower FPS when empty, keep daily restarts Move to 8 GB if castles spread out or memory starts living near the ceiling
Server feels heavy because the map is cluttered with dead bases Lower CastleLimit or raise decay above 1.0 so abandoned castles clear sooner Upgrade only if the world stays heavy after rules are enforced
Raid lag with RAM still healthy Do not buy more slots; check CPU behaviour and keep ServerFps sensible Move to a plan with stronger single-thread CPU if peaks remain above 80%
Modded world starting to fill up Start at 8 GB rather than trying to squeeze mods into a 6 GB mindset Move to 10-12 GB once player activity and castle count both rise
Peak population already near the cap Confirm that the slot cap, not CPU or RAM, is the real limit Add slots when peak use reaches 75% and the hardware still has room to spare
Busy 30-40 player community with raids and lots of servants Keep castle rules strict and clear abandoned territory promptly Plan for 12 GB+ and often 14 GB+ before complaints become crashes

The order matters. Fix castle sprawl before blaming slots, and fix CPU bottlenecks before paying for extra admission capacity. If your ruleset is already lean and the usage thresholds keep being crossed, that is when the upgrade becomes the cheaper option than constant firefighting.

Pick the server by castle load first, slot count second

If your world is a private vanilla clan, 6 GB is usually enough and 8 GB gives easier breathing room. If it is modded, build-heavy, or heading towards a real community peak, buy the next tier before raid night forces the decision.

Compare the best V Rising server hosts

V Rising server FAQ

How much RAM does a V Rising server need?

There is no official RAM figure from Stunlock for the dedicated server. In practical host guidance, 6 GB is a good vanilla starting tier for small groups, 8 GB is safer for modded servers or worlds growing towards about 20 players, 10-12 GB suits many 20-30 player servers, and busy 30-40 player communities often want 12 GB+ or 14 GB+.

Is 4GB enough for a V Rising server?

It can be enough for a very small vanilla PvE server, especially in the 1-8 player range, but headroom is tight. Once players build multiple castles, leave offline bases loaded for days, or add mods, 4 GB becomes the tier most likely to hit the wall first.

How many players can a V Rising server hold?

MaxConnectedUsers is often set with the example value 40, and Stunlock says the technical maximum supported is 128. Real capacity depends less on the headline slot figure than on castle count, servants, raid activity and how strict your rules are on abandoned bases.

Does V Rising need a fast CPU or more cores?

A fast CPU thread matters more than a large core count. V Rising’s world simulation has to keep up at the target ServerFps, so raid smoothness usually depends on how well the main thread holds that pace rather than on how many spare cores exist elsewhere.

Can I run a V Rising server on the same PC I play on?

Yes, but only if the machine has enough spare RAM and CPU after the game client takes its share. The client itself wants 12 GB RAM, and the server needs additional memory on top, so same-PC hosting works best for small private worlds rather than busy community servers.

More V Rising server guides

Compare hosts for your castle world, or read up on server hardware.

V Rising patches and host control panels do change, even if the core sizing rules stay the same. If a panel labels a setting differently from the base files, follow your host’s current panel and back up before major updates or rules changes.