On this page
An ARK dedicated server is one long-running process that holds an entire map, every structure on it, and every tamed creature in memory at once. That single fact decides almost everything else about running one, including the plan you need to buy.
This page covers ARK: Survival Evolved, the server most communities still run. ARK: Survival Ascended is a different product with its own server download and its own requirements, so check which one your players are on before you plan around anything here.
ARK is exceptionally memory hungry
Most game servers grow slowly with player count. ARK grows with the world. Every foundation, every storage box, every dinosaur anyone has ever tamed and left standing is a live object in the process for as long as it runs. A freshly generated map costs the least memory it will ever cost. After 6 months on a popular server, the same map costs a multiple of that, and it does not shrink until you restart.
Be clear-eyed about what that means: a small VPS will not run ARK. On a machine with 1 GB or 2 GB of RAM the server will start, appear to be working, spend several minutes loading, and then die during world load or shortly after the first few players join. That is not a tuning problem and there is no configuration that fixes it. ARK needs several gigabytes for a bare map before anyone connects, and a busy modded map needs considerably more.
Measuring what yours actually uses
Do not size from a number in a guide, including this one. Measure your own server, because the answer depends on your map, your mods, your player count, and how long the save has been running.
Whole machine, including everything else on it:
free -hThe server process on its own. RSS is resident memory in kilobytes, and
ETIME is how long the process has been up, which matters because the number
only means something after the server has been running for a while:
ps -o pid,rss,etime,args -C ShooterGameServerTake that reading at your busiest hour, then take it again a week later. The gap between the two is your real growth rate, and it is what you should be sizing against.
CPU and disk
ARK's game loop is largely single-threaded. One fast core does more for tick rate than four slow ones, and adding cores does not make a single map run better. Cores start to matter when you run several maps on one machine, because each map is a separate process and they can then run side by side.
Disk matters in two ways. The install is tens of gigabytes before you add a
single mod, so check what you have with df -h before you start downloading.
And ARK stalls the game loop while it writes a save, so slow storage turns
every autosave into a visible freeze for everyone online.
The ports ARK uses
ARK needs two UDP ports open, and they do completely different jobs.
| Port | Protocol | What it carries |
|---|---|---|
| 7777 | UDP | The game itself. Every player connection, movement, chat, and action. Set by ?Port= in the launch string. |
| 27015 | UDP | The Steam query protocol. Set by ?QueryPort= in the launch string. |
UDP 7777 is the game. If it is closed, nobody plays. There is nothing subtle about this failure.
UDP 27015 is how the outside world asks the server what it is. The in-game server browser, Steam's server list, and every third-party server list send a small query to this port and read back the server name, the map, the player count, and the ping. If it is closed, the server runs perfectly and a player who connects by direct IP gets in without trouble, but the server never appears in any list and shows as unresponsive to anyone browsing. This is the cause of almost every "my server works but nobody can find it" report.
ARK also has an optional RCON console, off by default, which listens on TCP
rather than UDP and is enabled through RCONEnabled and RCONPort in
GameUserSettings.ini. RCON carries your admin password in a protocol with no
encryption, so do not put that port on the public internet. Reach it over an SSH
tunnel from your own machine instead.
When you know which ports you need, add a rule for each under Port rules, or start from the matching entry in Game presets and add anything it does not cover.
Clusters, and why people run several maps
A cluster is a group of ARK servers, each running a different map, tied together so a player can take their character, their tames, and their items from one map to another through an obelisk or a transmitter.
People run them because a single map runs dry. Different maps carry different resources, creatures, and bosses, and a community that has finished one map will either move on or leave. A cluster keeps the same characters and the same progress across all of them, which is a very different proposition from asking players to start again on a new server.
The part that surprises people is the cost. A cluster shares saves, not
resources. Each map is a separate ShooterGameServer process with its own
world in its own memory, its own save directory, and its own pair of ports.
Three maps is three of everything: three times the RAM, three times the disk,
three sets of port rules. There is no pooling and no discount.
What actually ties them together is two things passed on the command line: a
shared cluster id, and a shared directory that all of them can write to, set
with -clusterid= and -ClusterDirOverride=. Transferred characters and
creatures are written into that directory by the map they left and read out by
the map they arrive on, so every server in the cluster must run as the same
Linux user and have write access to the same path. That is the main reason to
run all of them under one dedicated account.
Give every map its own game port and query port, and leave a gap between the game ports rather than using consecutive numbers, because of the game port plus one behaviour described above. A common arrangement is 7777 with 27015 for the first map, 7779 with 27017 for the second, 7781 with 27019 for the third.
Mods and the Steam Workshop
ARK mods come from the Steam Workshop and the server downloads them itself. Mod
ids are listed in ActiveMods under [ServerSettings] in
GameUserSettings.ini, and passing -automanagedmods on the command line lets
the server fetch and update them on its own. Confirm both against your own
config after the first run, since the file the server writes is the reference
for the build you have.
The startup cost is the part to plan for.
- Every mod is downloaded and then unpacked before the map loads. Workshop content arrives compressed and has to be extracted before the server can use it. On a large mod list this is the longest part of a start, and it happens again in full every time one of those mods publishes an update. A start that took 4 minutes can take 20 after a big mod updates.
- Mods load into the same process. They raise the memory floor before a single player joins, and a large content mod or a custom map can raise it a lot.
- Your server and your players have to agree on versions. When a mod author publishes an update, clients pick it up through Steam and your server picks it up on its next restart. Between those two moments, players cannot join. This is why servers with long mod lists end up on a scheduled restart rather than restarting when it happens to be convenient.
Keep the list short for reasons that have nothing to do with performance. Every mod is a dependency on someone else's release schedule, and one abandoned mod can hold a server back for months.
Related
SteamCMD, the launch string, the slow first boot, and systemd.
Port rulesOpening UDP 7777 and UDP 27015 at the network edge.
Game presetsStarting from a prepared set of rules instead of building them by hand.
BackupsWhat the panel keeps, and why you want your own copy of the save directory.