How to set up an ARK: Survival Ascended cluster server

A complete guide to ARK: SA clustering: matching cluster IDs, one shared cluster directory, per-instance ports, mod parity, and the expiry timers that delete uploads while you sleep.

Clustering ARK: Survival Ascended servers is conceptually simple and operationally fiddly. The concept: several server instances, each on a different map, all pointed at one shared folder, all carrying the same cluster ID. The fiddly part is that there are about six ways to get it almost right, and almost right presents in game as "the other map is not in the list", with no error message anywhere to explain why.

This guide covers the machinery, whoever is running it.

What is actually shared

Only transfer data. When a player uses an obelisk, a supply drop or a Tek transmitter to upload a survivor, a dino or items, that data is written into the cluster directory as a profile. The destination map reads it out on arrival.

What is not shared: the world. Each instance keeps its own save with its own bases, its own tames and its own map state. Clustering does not merge worlds, does not sync bases, and will not let two maps see each other's structures. If someone in your group is expecting one continuous world, correct them now rather than after the third rebuild.

What each map costs you in hardware

Every instance is a full server. The resources multiply with the number of maps.

CPU is the part people underestimate. ARK's physics tick is largely single-threaded per instance, so five maps want five cores that are not fighting each other, plus headroom for saves. High clock speed beats high core count for ARK, but running five instances on a four-core box means every autosave becomes everyone's problem. On Linux you are also running the Windows binary through Proton, so add a few GB of overhead per instance and disk space for each instance's compatibility prefix.

Ports: the mistake that costs people an evening

Each instance needs its own game port, query port and RCON port, and no two instances may overlap on any of them.

Leave a gap on the game ports rather than using consecutive numbers, because some ASA builds reach for the port above the one you asked for.

Now the important bit, and the reason a lot of second maps appear dead on arrival. ASA ignores the port when you pass it as a URL option. Writing ?Port=7787 into the query string looks reasonable, is accepted without complaint, and does nothing at all: the process binds 7777 anyway. Your first map works, your second map either fails to bind or answers on a port nobody is connecting to, and the players get a join timeout with no clue why.

Pass the ports as dash flags instead:

-port=7787 -QueryPort=27016

Both the game port and the query port must be reachable from outside, on UDP. The query port is what the server browser and stat sites read; if it is blocked, your server exists but cannot be found. RCON is TCP and should stay on your LAN or behind a tunnel rather than being published to the internet, because it is a remote console with an admin password in front of it.

The launch command

Here is a two-map cluster, annotated. Windows first:

ArkAscendedServer.exe TheIsland_WP?listen?SessionName=Cluster%20Island?RCONEnabled=True?RCONPort=27020?TributeItemExpirationSeconds=2592000?TributeDinoExpirationSeconds=2592000?TributeCharacterExpirationSeconds=2592000 -server -log -port=7777 -QueryPort=27015 -NoTransferFromFiltering -WinLiveMaxPlayers=30 -clusterid=northlight01 -ClusterDirOverride="C:\ARK\clusterdata" -automanagedmods -mods=930324,893657

And the second instance, differing only in map, ports and session name:

ArkAscendedServer.exe ScorchedEarth_WP?listen?SessionName=Cluster%20Scorched?RCONEnabled=True?RCONPort=27021?TributeItemExpirationSeconds=2592000?TributeDinoExpirationSeconds=2592000?TributeCharacterExpirationSeconds=2592000 -server -log -port=7787 -QueryPort=27016 -NoTransferFromFiltering -WinLiveMaxPlayers=30 -clusterid=northlight01 -ClusterDirOverride="C:\ARK\clusterdata" -automanagedmods -mods=930324,893657

On Linux you are launching the same Windows binary through Proton, and the shape is identical:

proton run ./ArkAscendedServer.exe \
  "TheIsland_WP?listen?SessionName=Cluster Island?RCONEnabled=True?RCONPort=27020?TributeItemExpirationSeconds=2592000" \
  -server -log \
  -port=7777 -QueryPort=27015 \
  -NoTransferFromFiltering \
  -WinLiveMaxPlayers=30 \
  -clusterid=northlight01 \
  -ClusterDirOverride=/srv/ark/clusterdata \
  -automanagedmods -mods=930324,893657

What each of the cluster-relevant pieces does:

• -clusterid= ties the instances together. Any string, as long as it is identical everywhere.
• -ClusterDirOverride= is the shared folder. Absolute path, quoted if it contains spaces.
• -NoTransferFromFiltering drops the origin filtering on downloads, so a survivor can collect their upload on any map in the cluster rather than only the one it came from. Nearly every working cluster runs with this on.
• -WinLiveMaxPlayers= sets the slot count. ASA ignores the older MaxPlayers option.
• -automanagedmods -mods= hands mod downloading to the server. The mod list must match on every instance, on which see below.

Note what is not on the command line: passwords. Unreal writes the full command line into logs that you may well end up sharing with a player who is debugging a crash, so put ServerAdminPassword and ServerPassword in the [ServerSettings] block of GameUserSettings.ini instead of pasting them into argv.

The shared cluster directory

One absolute path, writable by every instance, and it should live outside any individual server's install tree. Putting the cluster folder inside map A's directory works until you reinstall or verify map A, at which point everybody's uploads become a story you tell.

/srv/ark/
  clusterdata/          <- ClusterDirOverride points here
  island/               <- instance 1 install
  scorched/             <- instance 2 install

On Windows, quote the path if it has spaces, and check that the account running the service can write there rather than assuming it can because your user can.

On Linux, ownership is the usual trap. The directory must be writable by whatever account the server process runs as. If each instance runs under its own user, give them a shared group and set the group write bit, or you get the delightful failure mode where uploads succeed on one map and silently vanish on another.

Across two machines, the cluster directory has to be a real shared filesystem: NFS, SMB, or something like JuiceFS if you are doing this at scale. That comes with consequences worth planning for. Profile writes happen at the moment a player uploads, so latency on that mount is latency a player feels. A mount that drops out mid-write can leave a truncated profile, which ARK reads as "no such upload". And if you are tempted by two synchronised folders instead of one shared mount, resist: eventual consistency plus a player who travels quickly is how you end up with duplicated dinos, or none.

Transfer settings, and the timers that delete things

Three URL options control how long an upload survives in the cluster store before ARK removes it:

• TributeItemExpirationSeconds
• TributeDinoExpirationSeconds
• TributeCharacterExpirationSeconds

The value is in seconds, so 2592000 is 30 days and 604800 is a week. Set all three explicitly. The engine defaults are short enough that "I uploaded my rex and went on holiday" is a complete description of how a breeding line dies, and there is no warning in game and nothing in the logs afterwards to tell the player what happened.

Six more options gate what can move, each taking True or False:

Leave all six off for a normal cluster. Allow survivors while blocking dinos and items if you want visiting without importing. Set the same values on every instance: setting PreventDownloadDinos on one map only produces a cluster where travel works in one direction, which players will report as "it is broken sometimes".

Mod parity and build parity

This is the rule that catches everyone eventually. Every instance in the cluster runs the same mod IDs at the same versions, on the same game build. Travelling between maps requires the two servers and the client to agree on what the objects being moved actually are. Break that agreement and the failures are inventive: transfers refused, arrivals missing items, dinos that download as the wrong species, characters that land unrecognised.

Two practical rules follow.

Never update one map on its own. Not even to test something. A cluster where one map is a build ahead is a cluster where travel is off until you finish the job.

Update in lockstep, in this order:

1. Warn players, ideally with a few minutes of notice via RCON broadcast.
2. Run SaveWorld through RCON on every map, and wait for each to confirm.
3. Stop every instance.
4. Update every instance (SteamCMD app 2430930) and let mods refresh.
5. Start the instances one at a time and wait for each to be accepting connections before starting the next, rather than launching five at once and letting them fight over disk.
6. Test one transfer yourself before announcing you are back.

Backing up a cluster

Two things to back up, and people remember only the first.

• Each map's save tree. The Saved folder for each instance.
• The cluster directory. Everything in transit lives here and it is invisible in every map's save file.

Quiesce before copying. Send SaveWorld via RCON, wait for the confirmation, then take the copy. Copying a live save gets you a file that looks fine and restores into a world with holes in it.

One more thing to plan for: restore the pair together. A world save from Tuesday alongside a cluster directory from Friday means uploads that were already collected are still sitting in the store, so the same dino now exists twice, which your players will absolutely notice and absolutely will not report.

When travel does not work

Work through these in order. It is nearly always the first three.

1. Compare the cluster IDs character by character. Not "they look the same". Trailing whitespace and a capital letter in one start script are the classic causes, and they present as two clusters that each contain one lonely server.
2. Check the cluster directory is the same path for both instances, and writable by both. On Linux, check as the service account rather than as yourself. Look for profile files appearing in the folder after an upload; if the folder stays empty, you have found your problem.
3. Restart every instance after any cluster change. These are launch parameters. They are read at start-up and nowhere else, so a config change with no restart changes nothing.
4. Check the PreventDownload and PreventUpload options on both ends, including any values sitting in GameUserSettings.ini that you forgot were there and are quietly overriding your intent.
5. Confirm -NoTransferFromFiltering is present on every instance if downloads appear on the origin map but not elsewhere.
6. Verify build and mod parity. Same game build, same mod IDs, same mod versions.
7. Check the query port is reachable for the destination map. A map that cannot be queried can behave as though it is not there when the transfer UI goes looking for it.
8. Check the expiry timers if the upload happened a while ago. If the timer has passed, the data is gone and no amount of restarting brings it back.

Two symptoms with specific causes. A character stuck on arrival, unable to spawn, usually means the destination map could not read the profile: check permissions and free disk on the shared mount. And a survivor who arrives as a fresh level one has generally been handed a profile the destination map could not match, which is mod or build drift almost every time.

Pre-flight checklist

Before you tell anyone the cluster is ready:

1. Every instance has a unique game, query and RCON port.
2. Ports are passed as -port= and -QueryPort= dash flags, not URL options.
3. Game and query ports are open on UDP, RCON is not public.
4. -clusterid= is byte-identical on every instance.
5. -ClusterDirOverride= points at one shared absolute path, outside any server's install tree.
6. That directory is writable by every server process.
7. All three Tribute*ExpirationSeconds values are set deliberately.
8. The PreventUpload and PreventDownload options match across instances.
9. Mod IDs, mod versions and the game build match across instances.
10. Backups cover every map's saves and the cluster directory.
11. You have personally uploaded something on one map and collected it on another. This is the only test that counts.

Where to go next

• ARK: Survival Ascended cluster hosting on Hostd if you would rather this was already done for you.
• ARK: SA server troubleshooting for crashes, Proton wobbles and mod mismatch kicks.
• ARK: SA maps and CurseForge mods for the map identifiers and mod load order.

Last updated 2026-07-30. Notice a mistake? Tell us.