Sons of the Forest server performance: RAM, CPU and lag

A Sons of the Forest dedicated server needs about 8 GB of memory and two fast cores for a small group, 10 GB for a settled group of four to six, and 12 GB with three cores for a full server of eight on a world that has been played for weeks. It is heavy because it keeps a large, detailed world resident and simulates every cannibal, animal and structure on one main thread, and on Linux it carries the extra weight of running a Windows binary under Wine. Two keys in dedicatedserver.cfg decide most of its CPU use - ActiveTargetFramerate and IdleTargetFramerate - and one, SaveInterval, decides when it stutters. The rest of the performance story is about time: a server that has been up for three days is slower than the same server fresh, and a scheduled restart fixes more lag than any setting.

This post is about sizing and keeping the server fast. The install, ports and every config key are in the Sons of the Forest dedicated server guide, and the mechanics of Wine itself are in Wine and Proton for Windows-only servers. Nothing here repeats them more than it has to.

Why the server is heavy#

People arrive at this game from The Forest, whose server ran comfortably in 3 GB, and are surprised to find the sequel wants more than twice that. Four things account for the difference.

• The world is big and loaded. The island is far larger and denser than the first game's, and the server holds the state of everything that has changed in it: felled trees, dropped items, killed enemies, opened containers, every log and stick of every structure. That state grows as the group explores and builds, and it does not shrink while the server runs.
• AI runs on the server. Cannibal groups, mutants, animals and companions are simulated by the server, not by the players' machines. More active players in more places means more AI awake at once, and the AI is the expensive part of every tick.
• Building is physics. Sons of the Forest's free-form building places individual logs and planks rather than prefabricated pieces, and the structural checks that decide whether something holds up are real work. A large base is thousands of objects, each one held in memory and synced to every client that joins.
• It is a Unity game built for a client. The dedicated server is the game with the renderer removed, not a purpose-built lean server. A lot of what a client keeps around stays in the server's memory too.

None of this is a defect. It is simply the cost of the game it is, and it means the low-memory tiers that suit Terraria or Valheim are the wrong starting point. The general version of this reasoning - working out what a game actually spends memory and CPU on - is in CPU vs RAM for game servers.

RAM and CPU by player count#

Endnight does not publish hardware requirements for the dedicated server, so the figures below are planning numbers from running it, not an official table. They are for the whole server process and, on Linux, include the Wine layer.

Some context for reading that table:

• Memory is driven by the world more than by the head count. Two players with an enormous base can use more than six players on a young world. Player count matters because more people spread out across the island wake more of it up at once, and each player who joins pulls more of the world into active use.
• 8 GB is the floor, not the comfortable middle. A fresh server will idle well below it, which misleads people into buying less. Watch it after a week of play, not after an hour.
• CPU is about one thread. The main simulation loop is single-threaded in practice, so one fast core is worth more than four slow ones. The extra cores carry saving, networking and the BlobSync transfer to joining players, which is why two is the realistic minimum even though the game "only" uses one. Reading game server CPU usage explains why a server can be at its limit while showing 40 percent.
• Disk speed matters at two moments: loading the world on start and writing it on every save. The install is in the 10-15 GB range and each save slot is tens of megabytes, so capacity is rarely the issue; latency is.

The eight-player cap is in the game, so there is no "16-player tier" to plan for. If you are wondering whether a bigger plan would help a server that already has headroom, it will not - see how many players fit on a server for the general argument.

The frame-rate targets: ActiveTargetFramerate and IdleTargetFramerate#

A server has no screen, but it still runs a game loop, and these two keys set how many times a second that loop tries to run. They are the closest thing Sons of the Forest has to a tick-rate setting, and they are the main lever on CPU use.

{  "IdleDayCycleSpeed": 0.0,  "IdleTargetFramerate": 5,  "ActiveTargetFramerate": 60,  "SaveInterval": 600}

Note the names. Guides and forum posts sometimes call this "TargetFps" or "TargetFramerate"; neither key exists in the file. The server reads ActiveTargetFramerate and IdleTargetFramerate, and a misspelled key in a JSON config is ignored rather than rejected, so a typo here looks exactly like a setting that does nothing.

What the idle target does

With nobody online the server drops to five loops a second. That is why an empty Sons of the Forest server costs almost nothing in CPU, and why a server that is running hot with nobody on is a sign of something else - a save in progress, a stuck process or, on Linux, Wine itself misbehaving. Leave IdleTargetFramerate at 5. There is no gain in raising it: with IdleDayCycleSpeed at 0.0 the world clock is frozen while empty anyway, and there is nothing for a faster idle loop to do.

What the active target does

With players on, the server aims for 60 loops a second. Each loop runs AI, physics and world updates and sends state to clients. When the CPU cannot keep up, the server simply runs fewer loops than the target, and players see it as enemies that move in steps, hits that land late and doors or structures that respond after a pause.

Lowering ActiveTargetFramerate is a legitimate trade on a CPU-limited server. At 30, the server does roughly half the simulation work per second, and on a plan that is pinned at its CPU limit the result is often smoother play rather than worse, because a steady 30 feels better than a 60 target that keeps collapsing to 20 during fights. The cost is coarser updates: enemy movement and physics are sampled less often, which some players notice in close combat. Endnight does not document exactly how each subsystem responds to the target, so treat it as something to test with your own group.

Some rules of thumb:

• Do not raise it above 60. Clients do not benefit, and the server spends CPU it rarely has to spare.
• Lower it in steps - 60, then 45, then 30 - and play a session at each. Change one thing at a time so you know which change helped.
• Lowering it does not save memory. The world is the same size at any frame rate. If memory is the problem, this key is not the fix.
• It can be set from the command line as -dedicatedserver.ActiveTargetFramerate "30", which is how many panels expose it without editing the file.

The general idea - what a tick or frame target means for a server, and why a stable rate beats a high one - is in what tick rate actually means.

Autosave and the save hitch#

Every SaveInterval seconds - 600 by default - the server serialises the world and writes it to the save slot. On a young world that takes a moment. On a mature world with a large base it is a noticeable hitch: a second or more where everything on the server stops, followed by a brief rubber-band as clients catch up.

That hitch is the most common "random lag" report on a Sons of the Forest server, and it has a tell: it is regular. If the stutter arrives every ten minutes, close to the same minute past the hour, it is the save. Confirm it by watching the console for the save line at the moment people complain.

What you can do about it:

• Accept it. A one-second pause every ten minutes is the price of not losing ten minutes of work on a crash. Most groups, told what it is, stop minding.
• Lengthen the interval to 900 or 1200 if the hitch really is disruptive. You halve how often it happens and double what an unclean stop can lose. That trade is worth making only alongside reliable backups and clean restarts.
• Do not shorten it to chase safety on a big world. 300 on a world with a five-thousand-piece base means a visible pause every five minutes.
• Fast disk shortens the pause but does not remove it; much of the time goes on gathering and serialising state, not on the write itself. What NVMe actually changes is honest about where it helps.

The broader trade-offs of save timers, for this game and others, are in game server autosave intervals.

The Windows-only binary and what Wine costs#

Endnight ships the dedicated server for Windows only. On Linux, which is where most game hosting runs, it is started under Wine (or occasionally Proton), usually with a virtual display such as Xvfb because the Unity runtime expects one. The setup is covered in Wine and Proton for Windows-only servers; what matters for sizing is the cost.

• Memory: a few hundred megabytes more than the same server would use on Windows, for the Wine server process, loaded Windows libraries and the virtual display. On a 12 GB plan that is noise; on an 8 GB plan it is part of why 8 GB is the floor.
• CPU: small in steady play, because the game's code runs natively and only system calls are translated. It shows up more in file-heavy moments - start-up, world load and saves - which are exactly the moments that already hitch.
• Log noise: Wine's own diagnostic output can be chatty. Setting WINEDEBUG=-all in the environment silences it and saves a little CPU and disk on a busy server.
• Version sensitivity: a game patch occasionally needs a newer Wine. If a server that ran smoothly starts stuttering or crashing straight after an update, and Windows hosts are not reporting the same, the Wine build is the first suspect.

On Windows itself none of this applies, but a Windows server costs more memory at idle than a Linux one plus Wine, so self-hosting on a Windows box is not the saving it looks like. Linux vs Windows game servers has the wider comparison.

Long sessions: why the server gets slower#

Sons of the Forest servers degrade with uptime. A server that runs smoothly on Monday evening can be noticeably laggier by Thursday with the same players doing the same things, and a restart brings it back. Several things contribute:

• World state accumulates. Dropped items, corpses, cut logs and debris add up through a session. Some are cleaned up, plenty are not, and every one is something the server tracks.
• Memory grows. Long-running Unity servers tend to climb in memory over days, partly from the state above and partly from the managed runtime holding on to memory it has used. Whether that counts as a leak or as normal growth depends on the build, and it changes between patches. Game server memory leaks explains how to tell the two apart.
• Garbage collection gets more expensive. A bigger heap means longer collection pauses, which show up as short, irregular stutters - unlike the save hitch, which is regular.
• AI and physics drift. Enemy groups and simulated objects that never quite settle keep costing CPU in areas nobody is in.

The fix is unglamorous: restart the server on a schedule. Once a day at a time nobody plays is right for most groups; a very active eight-player server may want two. A restart reloads the world from the last save, discards the accumulated junk and resets memory to its baseline.

A good restart sequence:

1. Warn players, if your group plays at odd hours. There is no server-side broadcast command, so this happens in Discord.
2. Let the server stop cleanly so it saves on the way out. Do not kill it.
3. Take a backup of the save once it has stopped, or immediately before the restart.
4. Start it and confirm the world loaded from the expected slot.

On RE:NODE the Schedules tab runs that as ordered tasks on a cron expression - a backup, then a restart power action - with backups stored off the machine they protect. The reasoning behind picking the time and frequency is in restart schedules that help.

Reading the graphs: memory or CPU#

Before you buy a larger plan or start changing settings, work out which resource is actually short. The symptoms differ.

A memory graph that climbs steadily over days and drops at each restart is normal. One that climbs to the limit within hours of a restart means the world has outgrown the plan. A CPU graph pinned at its limit only during play is a server that needs a faster or bigger share, or a lower frame target; one that is high with nobody online is a problem with the process, not the sizing.

On RE:NODE the console shows memory, CPU and disk graphs against the plan's limits, which is the comparison you want. CPU is a hard throttle to the share you bought: a server at 100 percent runs slower, and is never suspended for it. Memory works differently - at the limit the container is stopped and restarted clean rather than left to swap - which on this game means losing whatever happened since the last save. If that is happening, it is the strongest signal there is to move up a tier, and changing plan does not rebuild the server or touch the world. Reading a server load graph goes through the shapes in more detail, and when to upgrade your plan covers the decision itself.

Troubleshooting slow servers#

The server is laggy but the CPU graph is nowhere near the limit. Look at a single core rather than the total. The main loop can be saturating one thread while the overall percentage looks relaxed. If it is, lowering ActiveTargetFramerate helps more than adding cores.

Everyone rubber-bands at the same moment, every ten minutes. That is the autosave on a big world. Check the console for the save line at the moment it happens.

One player lags and nobody else does. That is their connection or their machine, not the server. A server problem affects everyone in the same place at the same time. Latency, jitter and packet loss helps them work out which.

Joining takes several minutes and the server stutters while someone joins. The joining player is pulling the world state over the BlobSync port. On a mature world that is a large transfer and costs the server work while it happens. It is normal, and it is worse the bigger the base.

Memory hits the limit and the server restarts with a rollback. The world needs more memory than the plan has, or the server has been up too long. Add a daily restart first; if it still reaches the limit within a day, move up a tier. Why your game server keeps restarting covers the other causes of unplanned restarts.

Changing the frame target made no difference. Check the spelling of the key and that the file is valid JSON. A mistyped key is silently ignored, and a broken file makes the server start with defaults. Run with -verboseLogging to see what was read.

The server got slower straight after a game update. Either the update itself is heavier, which happens and is not something you can configure away, or on Linux the Wine build has fallen behind. Compare notes with other server owners before changing anything on your side.

FAQ#

Is 8 GB enough for a Sons of the Forest server?

For two to four players on a world that is not enormous, yes. It is the floor rather than a comfortable margin, and a long-lived world with a large base will outgrow it. Watch memory after a week of play, not on the first evening.

Does lowering ActiveTargetFramerate hurt gameplay?

A little, in exchange for stability. At 30 enemy movement and physics update less often, which some players notice in close combat. On a server that cannot hold 60 anyway, a steady 30 usually feels better than an unstable 60. Try it for a session before deciding.

Why is my empty server using almost no CPU?

Because of IdleTargetFramerate. With nobody connected the server runs at five loops a second and, with IdleDayCycleSpeed at zero, the world clock is frozen. That is intended, and there is no reason to change it.

Does running under Wine make the server slower?

Only slightly. The game's code runs natively; Wine adds a few hundred megabytes of memory and some overhead on file-heavy work such as saves. Lag on a Wine-hosted server is almost always the game's own load, not the translation layer.

How often should I restart a Sons of the Forest server?

Once a day at a quiet hour suits most groups. A busy eight-player server may benefit from twice a day. Always let it stop cleanly so it saves, and take a backup alongside the restart.

Will more CPU cores make the server faster?

Beyond two or three, rarely. The simulation leans on one main thread, so the speed of that core matters more than the number of them. Extra cores help with saving and with players joining, not with the main loop.