How to choose a VPS for game servers

Which kind of gaming VPS do you mean?

A VPS for game servers is a good buy for one job: running a dedicated server that you and your friends connect to from your own machines. It is a poor buy for the other thing people mean by the phrase, which is playing the game on the VPS itself over a remote desktop. Those two jobs want opposite hardware. A dedicated server wants one fast CPU core and enough RAM to hold the world. Playing wants a GPU (graphics processing unit), and a standard VPS plan does not have one.

Everything below is about the first job. The second one is worth two minutes of your time, because a lot of people buy the wrong box for it.

Why you cannot play games on a VPS

A standard VPS gives you virtual CPU cores and no graphics card. Nothing is passed through from the physical host, so there is no hardware renderer for a game to use. You can see what you actually got:

sudo apt install -y pciutils
lspci | grep -iE "vga|3d"

The answer is a virtual display adapter, something like a Cirrus Logic or virtio GPU device. It exists so the provider's web console can show you a screen, and it has no 3D acceleration behind it. Install a desktop and a VNC server on top of that and glxinfo -B reports its renderer as llvmpipe, which is Mesa's software renderer running on the CPU. A modern 3D game drawn by the CPU runs at a few frames per second, so it is unplayable before anything even leaves the box. Windows instances hit the same wall from the other side. Many titles exit at launch complaining that they could not create a Direct3D device, because there is no display adapter to create it on.

The second problem is the trip back to you. Playing on a remote box means every frame is encoded to video, sent over the internet, and decoded on your screen. That adds encoding and decoding time on top of the game's own input lag, and RDP and VNC were designed for desktops rather than for 60 frames per second of motion. Cloud gaming services solve this with real GPU hardware and a purpose built streaming protocol. A plain VPS has neither. If you want to play, rent GPU time. If you want to host, keep reading.

What a dedicated game server actually needs

A game server is a simulation loop. It holds the world in memory and advances it a fixed number of times per second. Each connected player is then sent the part of that world they can see.

That shape decides the hardware. The loop is mostly one thread, so core speed matters more than core count. The world lives in memory, so RAM is usually the first ceiling you hit. The disk is quiet during play and busy at load and save. Your network path sets the ping, and no plan tier changes it.

Single core speed beats core count

Most game servers advance the world on one main thread. Minecraft's tick loop and the Source engine's server frame both work this way. That tick has a deadline. Minecraft Java runs at 20 ticks per second, which gives each tick 50 milliseconds of budget. When the work does not fit, the server prints exactly this:

[12:04:51] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2547ms or 50 ticks behind

That line means one thread ran out of time. Adding cores does not give that thread more time. A plan with 2 fast vCPUs will hold a tick rate that a plan with 8 slow vCPUs drops, because only one of those 8 is doing the work that matters.

Measure single thread speed before you commit to anything:

sudo apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=1 run

Read the events per second line. The number means nothing on its own and everything as a comparison, so run it on two candidate plans and put the results side by side. A full VPS benchmark run covers disk and network the same way.

Extra cores still earn their place. They run the second game server, the database, the nightly backup and the chunk pre-generator without stealing time from the tick thread. Server software has also learned to spread out, and Paper, a popular Minecraft server fork, moves some work off the main tick thread. So the shape to buy is a few fast cores, not many slow ones.

One number never appears on a plan page, and it decides whether the fast core you paid for is really yours:

vmstat 1 5

The st column is the percentage of time your virtual CPU was ready to run and the physical host handed the core to somebody else. A steady st above a few percent means the host is oversold. Players feel that as stutter while top on your box still shows idle CPU, because that idle time is not yours to spend.

How much RAM does a game server need?

[
  {
    "label": "Minecraft Java, vanilla",
    "players": 10,
    "ram_gb": 2
  },
  {
    "label": "Minecraft Java, large modpack",
    "players": 10,
    "ram_gb": 8
  },
  {
    "label": "Valheim",
    "players": 10,
    "ram_gb": 4
  },
  {
    "label": "Palworld",
    "players": 32,
    "ram_gb": 16
  }
]

Those are the starting allocations that the game and modpack documentation publish, as of August 2026. They are guidance, not numbers measured on one box. Vanilla Minecraft Java is comfortable with 2 GB of heap for around 10 players. The same player count on a large modpack wants 8 GB, because the mods add entities and generated structures that all live in that heap. Valheim's own listed minimum is 2 GB, while operators with a small world report the process settling nearer 3 GB, so 4 GB is the sane place to start. Palworld is the outlier at 16 GB for its 32 player maximum, which is what Pocketpair recommends.

RAM does not scale with connections. It scales with loaded world. Each player keeps the region around them loaded, so two players standing together cost far less than two players exploring opposite corners of the map. That is why "RAM per player" is only a rough guide while "RAM per active area" is the real driver, and why a small group that likes exploring can outgrow a plan sized for twice their number.

Java servers need two extra rules. Set the minimum and maximum heap to the same value so the JVM never pauses to resize it:

java -Xms4G -Xmx4G -jar server.jar nogui

Then leave headroom. The JVM uses memory outside the heap you gave it, for thread stacks and native buffers, and the kernel needs page cache to read world files quickly. On a 6 GB box a 4 GB heap is sensible and a 6 GB heap is not.

The two memory failures look completely different, so learn both strings. A heap that is too small throws inside Java, and the server usually keeps limping:

java.lang.OutOfMemoryError: Java heap space

A heap larger than the box gets the whole process killed from outside. The console says only Killed, and the evidence sits in the kernel log:

sudo dmesg -T | grep -i "out of memory"

Adding swap stops the kill without fixing anything. A tick loop that has to read its world back from swap misses every deadline, so your players get a frozen server instead of a crashed one.

One version note, current as of August 2026: Minecraft Java 1.20.5 and later require Java 21. An older runtime starts and then fails with an unsupported class file version error, which reads like a compiler message and confuses everyone the first time they meet it.

sudo apt install -y openjdk-21-jre-headless
java -version

Does disk speed matter for a game server?

Less than people expect during play, and a great deal at two specific moments. The world is read into memory at startup and written back on autosave, so disk speed shows up as a slow boot and as a pause when the save runs. In between, most reads are served from RAM.

Two things make the disk matter more than that summary suggests. Exploration loads new chunks or zones from disk while players are moving, and that read happens inside the tick budget. Autosave on a large world writes a lot at once, and on a slow volume the write blocks the loop long enough to print the "Can't keep up" warning above. Both are latency problems rather than throughput problems, which is why the gap between NVMe and SATA SSD on a VPS matters here more than the headline megabytes per second suggest. What you care about is how long one small operation takes.

Size the volume for growth. A world grows every time somebody walks somewhere new, and your backups multiply whatever it weighs. Run du -sh world once a week for a month and you will know your real growth rate.

Tick rate, ping, and the difference between them

Tick rate is how many times per second the server recalculates the world. Minecraft Java runs at 20. Source engine servers commonly run at 64. Higher is not something you can buy in Minecraft, because the rate is part of the game's design, so the goal is holding 20 rather than exceeding it.

Ping is the round trip between one player and the server. These two produce different complaints, so separate them before you spend money. When the server misses ticks, everybody rubber-bands at the same moment and the server log says so in plain text. When one player has a long network path, only that player lags and the rest of the group is fine. A bigger CPU will never fix the second case.

Latency is about location, not about plan tier

Light in fibre travels about 200 kilometres per millisecond. A round trip covers the distance twice, so the floor is roughly 1 ms for every 100 km between player and server. No provider beats that, and no plan upgrade changes it.

[
  {
    "label": "Toronto to New York",
    "distance_km": 550,
    "rtt_floor_ms": 5.5
  },
  {
    "label": "Dallas to Chicago",
    "distance_km": 1290,
    "rtt_floor_ms": 12.9
  },
  {
    "label": "Dallas to Los Angeles",
    "distance_km": 1990,
    "rtt_floor_ms": 19.9
  },
  {
    "label": "New York to London",
    "distance_km": 5570,
    "rtt_floor_ms": 55.7
  },
  {
    "label": "Los Angeles to Sydney",
    "distance_km": 12070,
    "rtt_floor_ms": 120.7
  }
]

Those are floors computed from great circle distance. Real fibre does not run straight, and every router on the path adds a little, so a good real world result sits somewhere near double the floor. A player in Toronto reaching a server in New York, 550 km away, has a floor of 5.5 ms and will usually see something in the teens. The Los Angeles to Sydney leg has a floor of 120.7 ms, and no amount of money moves it.

So put the server near the people who play on it. If your group is split across an ocean, somebody is getting the long path, and the fair answer is usually the region holding most of the players.

Measure the path instead of guessing at it:

sudo apt install -y mtr-tiny
mtr -rwzc 100 203.0.113.10

Read the last line first. That line is the server, and its loss and latency are the only ones that decide how the game feels. Loss shown on a middle hop with a clean final hop is almost always ICMP rate limiting on that router, because routers deprioritise replies to probe packets while forwarding real traffic normally. Have each player run it toward the server, since every one of them takes a different path.

Open only the ports the game needs

A game server needs one or two ports open and nothing else. The common defaults:

• Minecraft Java Edition: TCP 25565
• Minecraft Bedrock Edition: UDP 19132
• Valheim: UDP 2456 and UDP 2457
• Palworld: UDP 8211
• Source engine games such as Counter-Strike 2: UDP 27015

Check the game's own documentation, because several titles use an extra query port. Valheim is the clearest example: 2456 carries the game traffic and 2457 answers the Steam server query that makes your server show up in the browser list. Opening those numbers on TCP achieves nothing, because Valheim speaks UDP only.

Allow SSH before you enable the firewall, or you lock yourself out of your own server:

sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw enable
sudo ufw status verbose

Many providers also run a network firewall in their control panel, separate from the one on the box. A port that is open in ufw and closed there still refuses connections, and the symptom is identical from the outside, so check both places before you start editing config files.

Checking a TCP port from another machine is easy:

sudo apt install -y netcat-openbsd
nc -vz 203.0.113.10 25565

UDP cannot be tested that way. A closed UDP port is normally silent, so a probe that gets no reply has told you nothing at all. Confirm from the server side instead, and look for the game process bound to the port you expect:

sudo ss -lunp | grep 2456

Never expose RCON, the remote console protocol, to the internet. It is a single password sent over a plaintext connection, on port 25575 by default. Bind it to 127.0.0.1 and reach it through an SSH tunnel. Run the game server as its own unprivileged user as well, so a bug in a mod cannot reach the rest of the machine. The first ten minutes on a new VPS covers the user account and SSH hardening that this section assumes you have already done.

Run the server under systemd so it restarts

A server started by hand in an SSH session dies when the session closes, and it stays dead after a reboot. systemd fixes both. Write /etc/systemd/system/minecraft.service:

[Unit]
Description=Minecraft Java server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xms4G -Xmx4G -jar server.jar nogui
Restart=on-failure
RestartSec=15
TimeoutStopSec=180

[Install]
WantedBy=multi-user.target

Restart=on-failure brings the server back after a crash and leaves it down after a clean shutdown, which is what you want. Restart=always fights you every time you stop the server deliberately. TimeoutStopSec=180 matters more than it looks. systemctl stop sends SIGTERM, the vanilla Minecraft server catches that signal and saves the world before exiting, and when the timeout expires systemd sends SIGKILL instead. A large world can take longer than the default 90 seconds to write, and whatever has not reached disk when SIGKILL lands is gone.

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
sudo journalctl -u minecraft -f

A healthy start ends with a line like Done (12.345s)! For help, type "help". If the unit flips between activating and failed, journalctl -u minecraft -n 50 holds the reason, and it is usually a wrong path in WorkingDirectory or a heap bigger than the box.

systemd gives you no interactive console, so plan for that up front. Use RCON on localhost for commands, or run the server inside a tmux session, the same habit that keeps a long running Claude Code session alive on a VPS between logins.

Games distributed through Steam need SteamCMD before any of this. The Ubuntu package is a 32 bit binary, which is why the architecture line is there. Skip that line and apt reports that it has no installation candidate:

sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd

Some game servers grow their memory use the longer they run, and a scheduled restart at a quiet hour is the accepted workaround rather than a fix. A systemd timer calling systemctl restart is easier to reason about than a cron entry, because systemctl list-timers shows you exactly when it will next fire.

Back up the world on a schedule

Everything on a game server is replaceable except the world directory and the player data. Reinstalling the game takes minutes. Rebuilding what your group built takes months.

A safe backup is one taken while nothing is writing. Stopping the server for a minute is the simplest way to guarantee that:

sudo systemctl stop minecraft
sudo tar czf /var/backups/mc-$(date +%F).tgz -C /opt/minecraft world world_nether world_the_end
sudo systemctl start minecraft

If a nightly pause is unacceptable, flush the world first instead. In the Minecraft console, save-off stops autosave, save-all flush writes everything still pending, and save-on turns autosave back on once the copy has finished. Copying a world while the server is mid write can capture a region file that is only half written, and you will not discover that until the day you need the restore.

Keep at least one copy off the machine. A backup on the same disk does not survive the disk, and a provider snapshot is a convenience rather than a backup, because it lives in the same account you might lose. Scheduled restic backups to off site storage handle retention and deduplication, so a month of nightly world copies does not fill your volume.

Then restore one. A backup you have never restored is a guess. Extract last night's archive into a spare directory, point a test server at it, and confirm that the world loads and the buildings are where you left them.

Check the box before you commit to it

Buy one month rather than a year, and test with real players for one evening. Run the single thread sysbench figure, then have every player run mtr toward the server. The full VPS benchmark procedure walks through those tools and shows what a bad result looks like, and what a VPS actually costs per month helps you check that you are paying for the resource that limits your server rather than the one printed largest on the plan page.

Two posts pick up where this one stops. Building a Minecraft server on a VPS is the step by step version of everything above, on the game most people start with. The wider list of things a VPS can run is worth reading if you would rather the box did something useful between game nights.

FAQ

Can I play games on a VPS instead of buying a gaming PC?

No. A standard VPS has no GPU, only a virtual display adapter for the provider's console, so once a desktop is installed glxinfo -B reports the software renderer llvmpipe and a 3D game runs at a few frames per second. Even with a GPU attached, remote play adds video encoding and decoding to every frame's round trip, and RDP and VNC were never built for that. A VPS is for hosting the dedicated server your group connects to. Rent GPU time or use a cloud gaming service if what you want is to play.

How many CPU cores does a game server need?

Two fast cores beat eight slow ones for most games, because the world simulation runs on one main thread and extra cores cannot help that thread meet its 50 ms deadline. Compare candidate plans with sysbench cpu --cpu-max-prime=20000 --threads=1 run and read the events per second figure. Extra cores are worth paying for when you also run a second server or a database on the same box, since those workloads can then run without stealing time from the tick thread.

How much RAM does a Minecraft server need?

Around 2 GB of heap for a vanilla world with roughly 10 players, and 8 GB for a large modpack at the same player count. Set -Xms and -Xmx to the same value, and leave 1 GB to 2 GB of the machine free for the operating system, because the JVM uses memory outside the heap and the kernel needs page cache. A heap larger than the box gets the process killed by the kernel, which appears in dmesg as an out of memory line rather than as a Java error.

Why do my players lag when the server has spare CPU and RAM?

Two causes fit that description. Check the server log for Can't keep up! Is the server overloaded?, which means the single main thread missed its 50 ms tick budget while the other cores sat idle. If that line is absent, the problem is the network path, so have each player run mtr -rwzc 100 203.0.113.10 against your server address and read the last line. Also check the st column in vmstat 1: steal time above a few percent means the host is oversold, so the idle CPU you see is not actually available to you.

Which ports do I need to open for a game server?

Only the game's own port, plus SSH. Minecraft Java uses TCP 25565, Minecraft Bedrock uses UDP 19132, Valheim uses UDP 2456 and 2457, and Palworld uses UDP 8211. Add the SSH rule before you run ufw enable, or you lose access to the box. Remember that many providers run a second firewall in their control panel, and the port has to be open in both. Never open RCON on port 25575 to the internet, because it is one password sent in plaintext.