ARK: Survival Ascended Cluster Hardware Sizing for 2026: Per-Map CPU, RAM and Save Bloat Math

An ARK cluster is not a single server — it is a fleet. Most communities run three to eight maps (Island, Ragnarok, Extinction, Aberration, Genesis, plus mod maps) that transfer characters, dinos, and items between each other. Each map is a full Unreal Engine process with its own world simulation, save file, and mod stack. Sizing a cluster is therefore three problems layered together: per-map CPU/RAM, inter-map transfer load, and total resource allocation across the node or nodes. Here is the 2026 sizing model.

Per-Map Baseline: The Numbers That Rarely Change

ARK: Survival Ascended uses far more memory than the original. Measured baselines for a single map with no players connected:

Map size	Idle RAM	RAM at 30 players	CPU threads useful
Small (The Center)	6-8 GB	10-12 GB	3-4
Medium (Ragnarok, Extinction)	9-11 GB	14-18 GB	4-5
Large (Island, Genesis, Aberration)	11-14 GB	18-24 GB	5-6

ARK’s simulation is more multi-threaded than Rust or Minecraft: it uses worker threads for physics, AI, and dino pathfinding. This means modest core counts help, but the main game thread still dominates, so single-core clock remains the ceiling for entity-heavy maps. A 4.5 GHz+ part is the minimum for a smooth 50-player map.

CPU Pinning Across Maps

When you run four to six maps on one node, unpinned processes will fight over the same cores at peak time and produce correlated lag spikes. Pin each map to a dedicated core group so cross-map transfer bursts cannot starve the tick:

• A 16-core node comfortably hosts four medium maps (4 cores each) with 0 cores reserved for OS, transfer, and mod-sync.
• A 32-core node hosts six to eight maps with the same 4-core-per-map split.
• Reserve at least two cores exclusively for inter-map transfers and mod download hosting.

Use taskset or systemd CPUAffinity to bind each map’s process tree to its core group. Without pinning, a single busy map can consume 60% of node CPU during a large dino upload and starve every other map’s tick.

Save Bloat and the Disk Budget

ARK save files are the silent capacity killer. A populated map grows to 2-8 GB on disk, and the `.ark` save plus its backup generations must all live on fast storage. Encrypted dinos, tamed stat inflation, and mod-added structures balloon the file over months.

• Per map: budget 15 GB for live save + rolling backups.
• Six-map cluster: 90-120 GB of active save storage on NVMe.
• Compression: ARK supports save compression in config; enabling it trades a small CPU cost for a 30-50% reduction in save size and write time.

Save writes are atomic and can pause the world. Put saves on NVMe with low fsync latency and keep them on a volume separate from logs. For the broader storage-tiering approach that applies across games, see this guide to high-performance server storage planning.

Mod Load: The Multiplier Nobody Plans For

ARK mods are Unreal Engine packages and each one adds load. A map with 20 mods typically uses 30-50% more RAM and 20-30% more CPU than the same map vanilla. The classic mods that hurt most are those adding entities, dino variants, and structure sets, because every new entity type increases the per-tick simulation cost.

Rule of thumb: add 2 GB RAM and 0.5 CPU core per 10 active mods per map. A six-map cluster running 20 mods each needs roughly 12 GB of extra RAM and 3 extra cores simply for mod overhead — before any players connect.

The Full Cluster Sizing Table (2026)

Cluster	Node spec	RAM	NVMe	Uplink
2-3 maps, small community	8-core 4.8 GHz	32 GB	1 TB	1 Gbit
4-6 maps, 150 total players	16-core 4.6 GHz	64 GB	2 TB	10 Gbit
6-8 maps, 300 total players	32-core 4.5 GHz	128 GB	4 TB	10 Gbit

Cluster-Level Operational Rules

1. Stagger scheduled saves across maps so you never write two large saves at the same instant.
2. Host recurring population on the largest maps; use small maps for events and overflow.
3. Monitor per-map tick time, not node CPU. A cluster is healthy only if every map’s average tick is under budget.
4. Keep cluster transfer traffic on the internal interface, never looped through the public IP.

A cluster sized from these numbers runs the wipe-weekend dino uploads, the mod stacks, and the simultaneous map traffic without the correlated stutter that tells players your node is under-provisioned. Pick the node architecture for the number of maps first — the per-map tuning follows from there.

Designing the Cluster Topology Before Buying Hardware

Most operators buy a node first and then discover their map count does not fit. Work backwards instead. Decide the maps you need, assign each a slot target, add the mod overhead, and only then choose the machine.

A worked example: a community running Island, Ragnarok, Extinction, and Aberration with 30 slots each and 15 mods per map. Per map: 11 GB base + 6 GB for players + 3 GB mod overhead = ~20 GB. Four maps = 80 GB, plus OS and transfer services = 96 GB. Cores: 4 maps x 4 cores + 4 reserve = 20 cores. This is a 24-core, 96 GB node — not the 16-core, 32 GB machine many operators start with.

The lesson generalises: ARK clusters are RAM-hungry far more than CPU-hungry, because each map is an independent Unreal process with its own memory footprint that does not shrink when idle.

Event Capacity and Overflow Maps

Boss fights, server-wide wars, and seasonal events spike a single map’s population well past its normal load. Rather than sizing every map for the event peak, keep one or two small overflow maps that absorb temporary population. A small map costs 6-8 GB idle and 3-4 cores, and it converts a hardware emergency into a routing decision. When the main map fills, the proxy sends late joiners to overflow until a slot frees up.

Validating the Cluster Before It Goes Live

Before opening a cluster to the public, run three acceptance tests: fill every map to its target player count simultaneously, trigger a large cross-map transfer mid-peak, and force a save on all maps at once. If tick time stays in budget through all three, the cluster is sized correctly. If any test breaks the tick, the failing resource is the one to upgrade — and it is usually RAM, because idle maps hold their full footprint whether or not players are active. Capture the numbers from these tests so future upgrades are driven by data rather than by guesses.