What is a dedicated game server, and how does it work

A dedicated game server is the game's server code running on a machine of its own, with nobody playing on that machine. It holds the world, decides what is true, and sends each connected player their slice of it. Nothing depends on one person being online, nobody's frame rate is everybody's simulation, and the world is still there at four in the morning when somebody wants half an hour before work. That is the entire idea. Everything below is what it costs, what it needs, and what you actually have to do once it is running.

The practical shape of it: a headless program, somewhere between 512 MB and 16 GB of memory depending on the game, one or two CPU cores that are fast rather than numerous, a few gigabytes of disk, one or two open ports, and a configuration file. The hard parts are not the install. They are updates, saves, and the fact that a game server is a program that has to survive without anybody watching it.

Listen servers, peer-to-peer and dedicated servers#

Multiplayer games pick one of three arrangements, and which one a game uses decides almost everything about hosting it.

A listen server is what you get from Host and Play in Terraria, Open to LAN in Minecraft, the in-game world host in Valheim, or Create Server in a Source game. It is genuinely the same code as a dedicated server, bolted to a client that is also rendering the game. It is free and it takes ten seconds, and it has three problems that never go away: the host has zero latency while everybody else has whatever the host's upload allows, the world exists only while the host's game is open, and the host's machine is doing two jobs at once. On a busy evening the host alt-tabs to a browser and eight people feel it.

Peer-to-peer is rarer for persistent worlds and common in session games - fighting games, some co-op shooters, older RTS titles. One player is usually promoted to host anyway, which is why "host migration" exists and why it is usually unpleasant.

A dedicated server removes the player from the equation. The publisher ships a second program with no renderer and no audio: valheim_server.x86_64, srcds_linux, PalServer.sh, server.jar, 7DaysToDieServer.x86_64. It starts from the command line, prints to standard output, and is administered over a console or RCON rather than a menu. It is nearly always free, even when the game is not, and it is nearly always available on Linux, which is why hosting one costs a few dollars rather than the price of a Windows desktop.

What is actually running on the machine#

Strip the marketing away and a game server is a loop. It wakes up on a fixed interval, reads whatever input arrived from clients since last time, advances the simulation by one step, decides what each client is allowed to know, and sends it. Then it does it again. The interval is the tick rate: 20 per second for Minecraft, 30 or 64 or 128 for competitive shooters depending on the game and the config, 60 for many Unreal titles. What tick rate actually means covers why a higher number is not automatically better.

Two consequences matter for hosting. First, that loop is overwhelmingly single-threaded in most games, so one fast core beats four slow ones. Second, the loop has a budget: at 20 ticks per second, every tick has 50 milliseconds to finish. If it takes 70, the server is behind, and everybody sees it as rubber-banding, delayed hits, or blocks that reappear after you break them.

Here is what sits between a player's mouse and the file the world lives in, on a typical rented server:

The DNS name is optional and does nothing except spare people from typing four numbers. The container is what a panel-based host gives each customer: an isolated filesystem, a memory limit, a share of CPU. The game process is the only part the game developer wrote. The world on disk is the only part you cannot replace.

That last line is the reason this post keeps returning to saves and backups. A game server has no database transaction log. It holds the world in memory and writes it out periodically, which means every game server has a window - usually five to thirty minutes - in which a hard stop loses everything.

At home, on a VDS, or on a game panel#

Three ways to get a dedicated server running, and they are genuinely different jobs.

At home is free until it is not. The two things that stop people are upload bandwidth (a server sends far more than it receives, and most home connections are built the other way round) and carrier-grade NAT, where your router has no public address to forward a port to. Add the electricity, the noise, the fact that your home IP is now published to strangers, and the reality that the machine has to be on when you are not. Self-hosting a game server at home versus renting does that comparison honestly.

A VPS or VDS gives you root and a blank Debian or Ubuntu box. You install SteamCMD, write a systemd unit, configure a firewall, set up backups, and keep the OS patched. It is the right answer when you want several games on one machine, a game nobody offers, or software the game needs that a container will not have. It is the wrong answer if the phrase "write a systemd unit" is the reason you stopped reading. Note the vocabulary trap: a "dedicated server" in the sense of this post is a program, while dedicated machines in the sense of a hosting product are hardware. The two meanings collide constantly.

A game panel host runs each server in its own container with the game already installed, the ports already allocated, and a web console instead of SSH. You give up root and the ability to run whatever you like on the box. For one game and one group of friends, that trade is almost always correct. Choosing between a VDS and a game panel has the decision written out, and what a Pterodactyl panel actually is explains the machinery underneath most of them.

What a dedicated game server needs#

Memory is the number people ask about and the one that varies most between games. These are working figures for a group of about ten, on a vanilla install:

Four rules behind that table:

• Memory is claimed, not used. Java-based servers in particular will grow to fill whatever heap you give them and only then collect garbage. A Minecraft server sitting at 90% of a 4 GB heap is usually fine; the same server hitting the container limit and dying is not. Node memory limits explained covers the same trap on the app side.
• CPU is a clock speed question, not a core count question. Almost every game server has one hot thread. Buying four cores for a game that uses 1.2 of them buys you nothing. CPU versus RAM for game servers explains how to tell which one you have actually run out of.
• Disk is mostly the install. Source-engine games and large survival titles want 20-60 GB before a single save exists; Minecraft and Valheim want two or three. Speed matters at save time and at world generation, which is where what NVMe actually changes is visible and nowhere else.
• Bandwidth is small and latency is not. Most games send somewhere between 30 and 300 KB/s per player. Ten players will not trouble any modern uplink. What people call lag is nearly always latency, jitter or packet loss instead, and those three are different problems with different fixes.

Ports, addresses and how players find the server#

A server is an IP address and a port. Most games need a second port for queries - the small protocol that server browsers and monitoring tools use to ask "who are you, what map, how many players" without joining.

Two failure modes come out of that table constantly. The first is a TCP firewall rule for a UDP game, which produces a server that starts, logs happily and accepts nobody. The second is opening the game port but not the query port, which produces a server you can join by IP but that never appears in any browser. Game server ports explained goes through both.

Players find a server in one of four ways: typing the IP, the game's own master-server browser, a third-party listing site, or a join code handed out in Discord. The browser route usually needs the query port open and, for Steam games, often a game-server login token - Steam game server tokens covers when you need one. If you want a name rather than an address, that is an A record pointing at the server's IP, and for Minecraft an SRV record lets you hide a non-standard port entirely: connecting a domain to a game server and SRV records for Minecraft.

Installing one, and the files that configure it#

For Steam games, installation is SteamCMD and an app id, usually with anonymous login:

$ steamcmd +force_install_dir /home/container +login anonymous \    +app_update 896660 validate +quit

A handful of games refuse anonymous downloads and want a real Steam account, and a few want their own credential before the server will run at all. SteamCMD explained has the app ids and the beta-branch syntax. Minecraft is the exception to all of this: download a jar, run it once, accept the EULA in eula.txt, run it again (the full first run).

Configuration then lives in one of four shapes, depending on the game:

1. A key-value file the server reads at start: server.properties, PalWorldSettings.ini, serverconfig.xml, ServerConfig.toml.
2. A script of console commands executed at start: server.cfg in Source games, autoexec.cfg, FiveM's server.cfg.
3. Launch arguments only, with no file at all - Valheim is the well-known case, and people arriving from Minecraft spend twenty minutes looking for a config file that does not exist.
4. Environment variables, which is how container-based hosts usually surface the launch arguments so you can edit them in a form instead of a command line.

Nearly every game generates its config on the first run rather than shipping it, so the sequence is: start the server, let it fail or idle, stop it, edit the files it made, start it again. Editing a config while the server is running and then restarting normally throws your edits away, because most servers write their config back out on shutdown.

Keeping one alive#

Installing a server takes an afternoon. Running one is the job, and it is four habits.

Updates. Client and server versions have to match in almost every game, so the day a patch lands your server is unreachable until it updates. That is fine for vanilla and a problem for modded, where the mods will not be ready yet. A modded server should never auto-update on patch day - keep a copy of the working mod folder and read what to do when a mod update breaks before you need it rather than after.

Backups. The world is one directory, sometimes one file, and it is written on a timer. A backup on the same disk as the world protects you from a bad save and from nothing else. Take a real copy, on a schedule, somewhere else, and restore one occasionally to prove it is not empty. Backups that actually restore and testing a restore before you need it are the two posts to read in that order.

Restarts. Long-lived game servers accumulate: entities, loaded chunks, plugin leaks, memory fragmentation. A scheduled restart at an hour nobody plays resets all of it and costs nothing, provided a backup runs before it and the players get a warning. Restart schedules that help and cron expressions explained cover the timing.

Attention. Somebody has to notice when it breaks. A memory graph, a console you can read, and an alert when the process goes down are the minimum - monitoring that tells you something and reading a server load graph.

On RE:NODE each server is one container on hardware in Germany with a memory and CPU limit of its own, and the install is done before you first see the console. Backup slots and the Schedules tab are on every plan, so the nightly backup and the restart above are two forms rather than two scripts. If a server hits its memory limit it is stopped and restarted clean instead of being left to swap, and a watcher checks every couple of minutes for a server that has gone down or is restarting in a loop - three restarts in an hour raises a warning and opens a ticket automatically.

What goes wrong, and what it usually means#

The server starts but nobody can connect. Port or protocol. Check that the rule is UDP if the game is UDP, check that the port in the config matches the port that is actually open, and test by joining from outside your own network.

It runs and is joinable by IP but never appears in the browser. Query port closed, the public flag off, or a missing Steam token. Server lists are also slow - ten minutes is normal before a new entry shows.

"Incompatible version" after an update. Client and server are on different builds. Update the server; if it is modded, wait for the mods first.

It stutters at eight players while the CPU graph shows 35%. That graph is an average across cores and the game uses one. The single hot thread is saturated even though the total looks idle.

Memory climbs all day and then it restarts by itself. Either a leak or normal growth that has finally reached the limit. Growth is expected as more of the world gets explored; a weekly restart flattens it. If the restart is automatic and repeating, why your game server keeps restarting walks through the log lines that tell you which of the two it was.

Everything was fine until one player joined. In games with client-owned simulation - Valheim's zones are the clearest example - one player on a poor connection can make the area around them unplayable for everyone else. That is not a server fault and no amount of extra RAM fixes it.

FAQ#

Is a dedicated server the same thing as dedicated hosting?

No, and the overlap causes real confusion. A dedicated game server is a piece of software: the game running without a player attached. Dedicated hosting is a whole physical machine rented to one customer. You can run a dedicated game server on a shared container costing a few dollars a month, and most people do.

Do I need a dedicated server for two or three friends?

Not technically - a listen server works. You will want one anyway the first time somebody wants to play while the host is asleep, or the host's machine stutters during a raid. The smallest plans for lighter games start at 1-2 GB, which is enough for a small group in most titles.

Does the server need a graphics card?

No. Dedicated server builds are headless: no renderer, no audio, no window. That is why they run on Linux machines with no GPU at all, and why they need far less hardware than the client does.

How many players can one server hold?

It depends on the game far more than on the hardware. Valheim caps at ten by design; Minecraft's limit is practical rather than hard and depends on view distance and plugins; some shooters are tuned for 64. How many players fit on a server works through the arithmetic.

Can I run two games on one server?

On a VDS, yes, with separate ports and separate users. On a panel host, no - one container runs one game, and a second game means a second server. That is a deliberate isolation boundary rather than an upsell: a crash in one cannot take the other with it.

What happens to my world if I stop paying?

It is deleted, along with its backups, which is true of essentially every host. Download a copy of the world folder before you cancel anything. It is the one file that cannot be rebuilt.