How to set up an ARK server: one process per map and cluster logic

This guide builds a working ARK server from scratch: choosing the operating system, installing through SteamCMD, the configuration files, opening ports, and the cluster setup that links several maps together. There is one sentence you need when planning ARK: every map is a separate server process. The whole resource calculation follows from it.

Before you start: what you need

• A lot of RAM. ARK is one of the most memory-hungry game servers there is. A single map sits in the 16 GB range up to 20 players, and 32 GB is the realistic figure for an active community server. The reason is simple: the server holds every dinosaur, every structure and every inventory in memory.
• Comfortable storage. Save files grow noticeably as play progresses. Size storage against the first week and you will run out within a few months.
• A firm decision on mods. Changing the mod list after the server is live permanently deletes, for some mods, the structures and tames created with them. The mod decision belongs before installation.

To pick RAM and cores against your map count and see the monthly total: server configurator

1. Operating system

Choose Ubuntu 22.04 LTS and run the server as a separate, unprivileged user.

The number of file descriptors the ARK process opens can exceed the operating system's default limit. Raise that limit before installing; otherwise the server falls over with inexplicable connection errors as the player count grows. This is one of the ARK-specific settings that costs people the most time.

SteamCMD will not start without 32-bit libraries; install the distribution's compatibility packages as step one.

2. Installing with SteamCMD

Server files are downloaded with an anonymous Steam session:

./steamcmd.sh +force_install_dir /home/ark/server +login anonymous \
  +app_update APPID validate +quit

Replace APPID with the dedicated server application ID of the ARK version you are installing. Take care here: ARK exists in more than one version, and each has its own server package and its own resource profile. Tell your players up front which one you are running, because clients do not cross between them.

The download takes a long time and occupies a lot of space. Use the validate parameter both on first install and after every update.

3. Configuration files

Start the server once and stop it; the configuration files are only generated on first boot. Under Saved/Config in the install directory you will find two files: GameUserSettings.ini, which holds the server name, passwords, player cap and basic rates, and Game.ini, which carries the more detailed game rules.

The launch command's format is peculiar to ARK: it begins with the map name, settings follow as key=value pairs separated by question marks on the same line, and the flags that start with a dash come after that block. The common mistake is putting a space between the map name and the first setting; the server then never sees the settings and starts with defaults.

Decide the rates (taming speed, experience, harvesting) before the server opens. Changing rates after players have progressed leaves a gap between earlier and later players that never closes.

4. Ports

Open all four. If the query port is closed the server runs but never appears in the list. Do not expose the RCON port to everyone; where possible allow only your own IP address.

If you are building a cluster, each map uses its own port set. Move the second map to the next free port range and write down which map sits on which port; in a three-map setup this is impossible to keep in your head.

5. Clusters: running several maps

A cluster is the setup where players can carry their characters and creatures between maps. What it does technically is this: each map is a separate server process, and they all share a common clusterdir directory. Transferred data lives in that directory.

The resource calculation follows: roughly 16 GB of RAM and three to four vCPUs per map. A three-map cluster needs three times the RAM of a single map — sizing a cluster's RAM against one map is the most expensive mistake here. A 64 GB / 16 vCPU plan runs three to four maps.

That makes ARK one of the rare games where a many-core processor genuinely helps: the processes spread across cores. For larger clusters it is worth considering a dedicated server instead of a virtual one; where the two options diverge is compared, with prices, here: VDS or dedicated server: which one fits?

If you run a single map the picture inverts: per-core performance decides rather than core count, and a virtual server is more than enough. How the cost per slot works out: game server slot planning

The most common first-boot mistakes

1. Sizing cluster RAM against one map. Each map is its own process; three maps mean three times the memory.
2. Not raising the file descriptor limit. The server falls over with seemingly causeless errors as the player count grows.
3. Leaving the query port closed. The server runs and is absent from the list.
4. Looking for configuration files before starting the server. They are generated on first boot.
5. Changing the mod list after launch. A removed mod can delete the structures and creatures built with it.
6. Updating without a backup. ARK updates can break save compatibility, so back up the save directory first.
7. Sizing storage against the first week. Save sizes multiply over months.

On DDoS

ARK carries game and query traffic over UDP, and because a UDP source address can be forged, floods cannot be blocked at the application layer. The query port is also a surface exposed to reflection attacks. We have covered the subject separately: what is DDoS protection?

On Datafex servers, layered Fexwall DDoS protection is included free on every plan.

Next step

We have put the recommended plans for single maps and clusters, the processor options and the ARK-specific questions on one page: ARK server plans.