ARK Server Tuning in 2026: ASE vs ASA Config Flags, RAM Allocation and Startup Order

ARK has two live server generations, and their tuning surfaces have diverged enough that advice written for one will silently degrade the other. Survival Evolved is the older, mod-heavier, configurability-rich title. Survival Ascended moved to Unreal Engine 5, changed the performance profile substantially, and narrowed some of the legacy tuning knobs while making others matter more. Running one set of startup parameters across both is how servers end up with map loads that time out and RAM that balloons after a few hours.

This is a working guide to the parameters that actually change behaviour, ordered the way they matter during startup. If you are still choosing hardware tiers for a cluster, the dedicated server specs and pricing table here is the place to match RAM and core count to the map list you intend to run.

Where the two generations actually differ

The most consequential split is memory behaviour during map load. Survival Ascended loads significantly more asset data up front and holds a larger resident set per map, which means a machine that comfortably hosted four Evolved maps will not necessarily host four Ascended maps. Plan RAM per map, not RAM per cluster, and leave explicit headroom for the operating system and the save-flush spikes that appear during autosave.

The second split is startup time. Ascended maps take materially longer to initialise, and a cluster that starts all maps simultaneously will thrash disk and CPU contention against itself. Sequential startup is slower wall-clock but far more reliable, and it keeps peak memory from stacking across maps that are initialising at the same time.

Config flags that still matter on Evolved

On Evolved, the usual levers are the ones that control how aggressively the server trims unused structures and how much of the world it keeps resident. Structure and dino decay settings affect save size over time, which in turn governs both disk footprint and the duration of autosave stalls. Aggressive decay is not just a gameplay choice — it is a storage and latency choice.

Mod loading is the other big one. Each mod adds load-time work and resident memory, and the order of the mod list affects whether cross-mod references resolve. Pin the mod list to explicit versions and record the load-time cost of each addition, so a mod update that doubles load time is something you can attribute rather than merely observe.

What moved or narrowed on Ascended

Some legacy INI-level tuning that allowed deep control over rendering and replication load no longer has the same effect, because the engine’s own scalability systems take precedence. Chasing old flags here is mostly wasted effort. What does still respond is anything governing tick budget and actor replication distance, since those sit above the renderer.

Ascended also benefits more from core count than Evolved did. The engine parallelises asset streaming and some simulation work more aggressively, so a node with fewer, faster cores that was ideal for Evolved can be the wrong shape for a busy Ascended map. Six to eight physical cores per map is a reasonable starting point for a populated server, verified against actual tick time rather than assumed.

RAM allocation: the number people get wrong

ARK’s resident memory grows with world age, player count, and structure density. A fresh map and a two-year-old map on the same server are different workloads. Allocate against the aged case, and monitor resident set and available memory rather than trusting the initial post-load figure.

Leave at least a couple of gigabytes of system headroom per node beyond the sum of your per-map allocations. Autosave creates a transient spike, and on a node with zero headroom that spike turns into swap, which turns into a tick spike, which turns into players disconnecting in combat. Our dedicated hosting tiers list RAM alongside the CPU and storage each plan ships with so you can size against the aged case instead of the fresh-load case.

Startup order and why it is a tuning parameter

Start order is not cosmetic. Load the database or cluster service first, then the maps with the highest resident memory, and stagger launches so two heavy maps never initialise simultaneously. On large clusters this alone can eliminate the pattern where the third map in a set consistently fails to come up on a cold boot.

Give each map a generous startup timeout rather than a tight one. A timeout that fires during a slow-but-healthy load causes a restart loop, and a restart loop on a cluster makes everything worse because each attempt competes with the previous one’s cleanup.

Verifying the result rather than trusting it

After any config change, measure tick time percentiles at a representative player count and watch resident memory across several autosave cycles. The useful signal is not the average tick time on an empty server — it is the tail during a save with players online.

Keep a short change log with the parameter, the observed effect, and the date. ARK tuning knowledge decays fast; within a few months nobody remembers whether a flag helped or whether it was a superstition added during a bad weekend.

The short version

Size RAM per map for the aged case, run sequential startup with staggered heavy maps, pin mod versions, and treat core count as more important on Ascended than it was on Evolved. Verify everything against tick-time tails and resident memory under load, and keep a change log. Everything else is detail that only matters once those four things are right.