How to Reduce Lag on a The Isle Server (Evrima)

Work out what kind of lag it is before you touch settings

The first mistake most owners make is treating every complaint as the same fault. Rubberbanding, stutter, desync, timeouts and teleporting dinosaurs can all come from different places. If only one or two people are affected while everyone else is moving normally, your server is probably not the issue. If everyone feels the same hitch at the same time, it usually is.

Look for patterns: only at peak population, only after many hours of uptime, or all the time no matter how quiet the server is. That tells you whether to tune the simulation, restart more often, lower the player cap, or stop wasting time and move the server closer to the group.

One more distinction matters: if the server and clients are on different versions or branches, players are blocked from joining. That is not lag. Evrima and Legacy are separate branches, and after updates the server must match the current Evrima version before anyone can get in.

What an Evrima server is actually spending CPU and RAM on

Evrima is the current The Isle branch, built on Unreal Engine 5.6, and it is much heavier on a server than Legacy. The current map is Gateway, and the extra systems and map detail mean the server has more to simulate all the time.

The heavy work is not just “player count”. The server is simulating each connected player, handling movement and networking, spawning AI groups around players, checking whether more AI should spawn, running migrations and patrol zones, and keeping persistent corpses in the world. If players are spread all over the map instead of clustered, the AI work can multiply because the server is supporting separate pockets of activity around many different locations.

The key hardware point is that Evrima’s simulation sits mostly on one main core. That means one saturated core can cap the whole server even if your host panel shows spare capacity on other cores. This is why a plan with more slow cores does not automatically solve stutter. On the memory side, AI density and persistent entities matter because they keep more things alive in the world for the server to track.

That is also why severe server lag can affect things beyond movement. If the simulation is struggling, growth calculations can slow as well, because the server is late processing its normal work.

Where to change Evrima server settings safely

Most gameplay and server keys live in Game.ini, under [/Script/TheIsle.TIGameSession]. On Linux hosts the usual path is TheIsle/Saved/Config/LinuxServer/Game.ini. On Windows hosts it is the matching WindowsServer folder. Stop the server before editing, then start it again after saving changes.

Be careful here: a bad entry or the wrong section header can crash the server or be silently ignored. After updates, keys can be renamed or removed, and an update can reset Game.ini, so keep your own copy before every update. If a server becomes unstable straight after an update or crash, corrupted save data is also possible, so restore from a recent backup instead of chasing performance settings that did not cause the problem.

For live changes, Evrima uses its own custom RCON protocol. Standard Source RCON tools such as mcrcon do not work. You need an Evrima-compatible RCON client, with bRconEnabled=true and an RconPassword set.

[/Script/TheIsle.TIGameSession]
AIDensity=1
AISpawnInterval=40
bEnableMigration=true
MaxMigrationTime=5400
bEnableMassMigration=true
MassMigrationTime=43200
bEnablePatrolZones=true

[/Script/TheIsle.TIGameSession]
AIDensity=0.5
AISpawnInterval=60
bEnableMassMigration=false

That lighter-load example is not a universal answer. It is a sensible starting point when complaints are happening at peak times and you want to reduce work without stripping the server back to nothing.

Fix first: lower AIDensity

If everyone is feeling server-side lag, AIDensity is the first setting to change. Host documentation calls it the single biggest lever for AI performance impact, which fits how Evrima actually works: AI groups are spawned around players, so higher density means more AI groups for the server to create, update and path around the map.

Why it works

Lowering AIDensity cuts the amount of AI the server tries to support. That reduces simulation work on the main thread and usually trims RAM pressure as well, because fewer active AI groups means fewer entities to keep in memory. It is especially useful when players are scattered, because the server is then building AI activity around multiple hotspots instead of one.

What to try

The default is 1. The usual scale runs: 0.25 is very sparse, 0.5 is light and suits constrained servers, 1.5 is denser and 2 is heavy, with the highest CPU and RAM use. On servers with 50+ players, keeping it at 1 or lower is the sensible side of the line. A good first live test is aidensity 0.5 through RCON during the period when players normally complain.

The trade-off

Players will notice less target density. Food sources feel less frequent, the world can seem quieter, and some areas may feel emptier. Also, 0.5 is not “half the CPU”, because actual load still depends on where players are, what AI is active, pathfinding and how many corpses remain in the world.

How to tell if it helped

Do not judge it on an empty server. Compare the same busy time window on different days. If rubberbanding is reduced, peak CPU pressure is lower and RAM grows more slowly, you have found a real lever. If complaints remain unchanged, move to the next settings rather than bouncing AIDensity up and down all day.

Then reduce spawn checks, trim species and simplify migrations

Once AIDensity is sensible, reduce the work the server does to maintain that AI. The next adjustments are smaller than density itself, but together they can smooth out peak-hour hitching.

Raise AISpawnInterval

AISpawnInterval controls how often, in seconds, the server checks whether to spawn more AI. The default is 40. Raising it to something like 60 to 90 means fewer spawn checks, which reduces recurring main-thread work. This helps most on servers that are repeatedly checking many player areas.

The trade-off is straightforward: AI refills more slowly, so empty patches stay empty for longer. If you raise the interval and players stop reporting stutter but start saying the map feels under-populated for long stretches, you have pushed it too far for that community.

Use DisallowedAIClasses for species your community does not need

If there are AI species your ruleset or events do not rely on, block them instead of disabling all AI. Use one DisallowedAIClasses= line per species in Game.ini, or the live disableaiclasses <list> RCON command. The available AI classes are Compsognathus, Pterodactylus, Boar, Deer, Goat and Seaturtle.

Why this works: you are narrowing what the server may spawn and maintain, which simplifies the AI mix without removing the whole food web. The trade-off is less variety and fewer specific AI encounters. If your server identity depends on a fuller ecosystem, use this lightly.

Disable mass migration if you do not need it

Migration settings also cost work because the server has to manage migration state over time, and carnivore patrol zones add their own activity. The defaults are bEnableMigration=true, bEnableMassMigration=true and bEnablePatrolZones=true, with MassMigrationTime=43200. If your server does not rely on mass migration as part of its normal play pattern, disabling it is a reasonable performance step.

The trade-off is less map-wide guidance and less of that moving-world feel. If performance improves at busy times and players do not miss the feature, keep it off. If your server culture is built around migration routes, accept the cost and look harder at AI density, uptime and player cap instead.

For very stripped-back PvP or event servers, bSpawnAI=false is the blunt option. It removes AI entirely, which is a major cut to server work, but it obviously changes the server far more than any of the steps above.

Clear persistent clutter: corpses, restarts and player cap

AI is not the only thing that drags Evrima down over time. Corpses persist, and every persistent thing in the world is something the server still has to remember, update and send to players when relevant. This is one of the most overlooked causes of The Isle server lag because the map can look normal while the process is quietly filling up with old entities.

Wipe corpses live, then shorten how long they last

The emergency fix is the RCON command wipecorpses. That immediately removes all corpses and is useful when performance has clearly deteriorated after a busy period. The longer-term setting is CorpseDecayMultiplier, which controls how fast corpses decompose. Faster decomposition means less long-lived clutter for the server to keep track of. Run wipecorpses after big fights or events rather than waiting for the next restart.

The trade-off is less scavenging time and fewer lingering signs of previous fights. If players value long-lasting carcasses, expect complaints. If your RAM graph keeps climbing after battles and then drops sharply after a wipe or restart, corpse persistence is part of the problem.

Schedule restarts every 6 to 12 hours

Hosts recommend scheduled restarts every 6 to 12 hours, with busy servers usually closer to every 6. The reason is simple: the process’s memory use grows the longer it runs, and AI and other entities accumulate. A restart clears that state and gives the server a clean baseline again.

The trade-off is a brief interruption and one reconnect. That is far better than letting the server limp into late-session desync and timeouts. If players say the server is smooth just after a restart and noticeably worse much later, your restart cadence is too loose or your hardware is already undersized.

Lower MaxPlayerCount to find your server’s real ceiling

If tuning AI and corpses helps but peak hours still fall apart, lower MaxPlayerCount for a few busy sessions. That directly cuts player simulation load and also limits how many separate areas can be spawning AI around the map. If performance stabilises immediately with a lower cap, you have found the server’s real ceiling.

Use the queue instead of letting the process thrash. bQueueEnabled=true enables it, and the default QueuePort is 10000. The trade-off is fewer active slots, but it is better than letting a larger population create a worse experience for everyone already connected.

aidensity 0.5
wipecorpses
save

Those are handy live commands for a busy evening. RCON commands are case-sensitive and can change between updates, so always check after a game patch before relying on old admin notes.

How to tell whether tuning really helped

Do not measure performance on a quiet server and assume it will hold at peak. Compare the same busy period on comparable days. If your panel offers CPU and RAM graphs, use them alongside player reports rather than trusting either one on its own.

• CPU: watch for peak-time spikes that line up with rubberbanding. Remember that Evrima is limited mostly by one main core, so a panel showing spare total CPU does not prove the server has headroom.
• RAM: use the 80% rule. If memory usage regularly sits above 80% even after sensible tuning, the server needs more memory.
• Uptime pattern: if the server is good after restart and bad later, you are looking at accumulation and memory growth, not just raw player count.
• Player reports: ask whether stutter happens everywhere or only during migrations, crowded hotspots or the late part of the day.

Change one lever, then compare at the same peak hour. If you cut AIDensity, raise AISpawnInterval and lower the cap all at once, you may fix the lag but learn nothing about which change actually bought you the most headroom.

When tuning stops helping and an upgrade is justified

At some point you run out of settings to trim without changing the server into something your community no longer wants. That is the point to upgrade, not the first complaint. For the wider hardware picture, see our guide to what CPU, RAM and storage do in a game server.

The important rule for Evrima is that clock speed beats a long list of slow cores, because the simulation is mostly sitting on one core. More cores can still help the machine overall, but they do not remove a single-thread bottleneck. Memory matters once AI density, player spread and persistent entities keep pushing usage up, and location matters because no setting can compensate for simple distance.

UNetConnection::Tick: Connection TIMED OUT (Elapsed 20.01, Threshold 20.00)

If many players start dropping with that timeout at around the same point, think server overload or crash first, not just bad home internet. Out-of-memory is a common cause of crashes and random disconnects, which is why that 80% RAM rule is worth taking seriously.

If you are past the tuning stage and weighing a move, our The Isle server hosting comparison shows which hosts give you London locations, full Game.ini access and scheduled restarts.

What to check before renting or moving an Evrima server

For Evrima, the control panel matters almost as much as the hardware. If a host makes it awkward to edit Game.ini, run RCON or schedule restarts, you lose the main tools used to keep a busy server stable. Before renting or migrating, check these points instead of assuming every plan exposes the same controls.

That last point is less about performance and more about avoiding false troubleshooting. Port or branch mistakes create join and visibility problems that can look like “the server is broken”, but they are not the same thing as server lag.

The Isle server FAQ

Why does my The Isle server rubberband?

If everyone is rubberbanding together, the server is usually overloaded rather than one client being at fault. In Evrima, the common triggers are too much AI activity, players spread across the map creating separate AI hotspots, long uptime with growing memory use, or too many persistent corpses. If only one or two players see the issue while everyone else is fine, it is more likely their connection or PC.

What AIDensity should I use?

The default is 1, but that is not always the right choice for a busy Evrima server. 0.5 is a sensible starting point when you need a lighter load, and host guidance says staying at 1 or lower is wise on servers with 50+ players. Use the busiest part of your day to judge it, because quieter periods hide the real effect.

How often should I restart a The Isle server?

A good working range is every 6 to 12 hours, with busy servers tending towards every 6. The reason is that memory use grows over time and AI plus other entities accumulate, so a restart clears the process before late-session lag becomes the norm. If the server always feels best just after restarting, tighten the schedule.

How much RAM does a The Isle server need to stop lagging?

There is no single safe figure that fits every Evrima server, because RAM demand depends heavily on AI density, player activity and how much persistent clutter the server is holding onto. The practical rule is to watch memory usage and act if it regularly sits above 80% after tuning. If you are still over that line after lowering AI load and managing corpses, more memory is justified.

Does server location affect lag in The Isle?

Yes. Constant high ping is mostly a distance problem, not a config problem, so no tweak in Game.ini will remove the delay added by a far-away server. For UK-heavy communities, a London or nearby EU location is the sensible baseline.

More The Isle server help

The host comparison and our explainer on what server hardware actually does.