// ARK

Setting up an ARK cluster: multiple maps, one tribe

Setting up an ARK cluster: multiple maps, one tribe

One ARK map is a world in itself, but after a few months your players know every cave and every drop location. A cluster solves that without anyone having to start over: multiple ARK servers with different maps, linked into one whole. Your tribe keeps its main base on The Island, farms on Ragnarok and ventures into the depths of Aberration with the same survivors and dinos. In this guide we set up such a cluster, configure the transfers and walk through the pitfalls, because there are some.

What exactly is a cluster?

A cluster is a group of ARK servers that share the same cluster ID. Within that group, players can upload their survivor, items and dinos on one server and download them again on another. Levels, engrams and tames travel along with the player; the bases themselves stay on the map where they were built, because each server simply keeps its own savegame. Technically this works through a shared cluster folder that holds all uploaded data. That also means all servers of your cluster have to run with the same host; two separate servers at different providers cannot be tied together. At MC-Node you set the cluster ID per server, and our support is happy to think along if you get stuck.

Why you want a cluster

  • More content without a wipe. Every map has its own biomes, creatures and engrams; think of the desert of Scorched Earth or the underground world of Aberration. Adding an extra map gives your community something new without anything being lost.
  • Spreading the load. Twenty players on one server is heavier than ten on each of two servers. A cluster spreads players, bases and tames across multiple machines, and ARK worlds in particular grow heavier month by month.
  • Room for flavours. Each server can run different rates or rules: a relaxed building map next to a challenging adventure map, within the same community and with the same characters.

How a transfer works in practice

Players travel via the obelisks, supply drops or a Tek Transmitter. There they upload their survivor, items and dinos to the cluster; on the destination server they do the reverse at an obelisk or transmitter. Large dinos do not need to be uploaded individually, by the way: in a cryopod a dino counts as an item, and that makes moving a lot less of a hassle.

Two things every player has to know. One: uploaded items and dinos are only kept in the cluster for about 24 hours. The upload is a hand-off, not a storage vault; whatever you leave hanging there, you lose. Two: not everything is allowed through. Some resources, such as element, are bound to their map by default. Put those two rules prominently in your Discord, because this is where most of the questions (and dramas) come from.

The settings that control transfers

Per server, a set of settings determines what may come in and go out. The most important ones:

PreventUploadSurvivors=False
PreventUploadItems=False
PreventUploadDinos=False
PreventDownloadSurvivors=False
PreventDownloadItems=False
PreventDownloadDinos=False
noTributeDownloads=false

Mind the double negative: False here means it is in fact allowed. With these flags you steer per map. If you want, say, a challenging map that players cannot walk into with endgame gear and top dinos, you close only the download of items and dinos there and still let survivors in. That way every map keeps its own character within the same cluster.

Test first, announce later

Do not take the cluster live with a big announcement before you have tested it yourself. Walk the whole route once with a throwaway item and a cheap dino: upload at an obelisk on map one, download on map two, and back again. If something is off, for example because the cluster ID is spelled slightly differently on one server or a Prevent flag is set wrong, you discover it now with a stone in your inventory instead of a player with his best dino. Once everything works, make a fresh backup of all servers and only then open the doors.

The pitfalls

  • Crashes during a transfer. If a server goes down exactly while someone is traveling with a full inventory, items or in the worst case a survivor can get corrupted or disappear. You cannot rule it out completely; you can limit the damage, with regular backups on all servers of the cluster and the advice to players to leave valuable gear at home when it does not absolutely need to come along.
  • A wipe on one map touches everyone. If you want to reset one map of the cluster, announce it well in advance, so players can move their dinos and belongings to another map. That is the beauty of a cluster right there: a wipe does not have to mean total loss.
  • Mods have to match. An item from a mod cannot be downloaded on a server that does not run that mod. The safest route is the same mod list across the whole cluster; if you deviate from that, be crystal clear to your players about what stays behind.

How many servers is realistic?

Bigger is not automatically better. Every extra map is an extra server that costs memory, needs updating and has to feel populated. ARK is no light lodger either: count on serious RAM per server, especially on maps with lots of bases and tames. For most communities, two maps is therefore the ideal starting point: enough variety, manageable administration. Only grow to three or four when your player base carries it, because four half-empty servers feel deader than two well-filled ones. Financially it does not have to be a hurdle: at MC-Node you rent an ARK server from € 3.00 per month, on our own hardware with NVMe storage and DDoS protection, and everything is cancellable monthly. A map that does not catch on, you simply cancel again. Check the possibilities in the ARK store.

Further reading

// TRY IT YOURSELF
Your Minecraft server online in 60 seconds
View packages →