Game hosting or a VPS for a Minecraft server: which to choose

In short: a first server, one game mode, no Linux experience — go with game hosting. A network of several servers, your own services alongside (a database, a website, a bot), and a wish to control every setting — a VPS or a dedicated server. Below: how they differ, how to compare plans, and what hosts tend not to mention.

Game hosting vs VPS vs dedicated server#

Game hosting: up and running in minutes#

A game host gives you a ready panel: pick the server software and version, upload plugins in the browser or over SFTP, restart with a button. Java, the port and auto-start are already set up. Pterodactyl is an example of such a panel: free, open source under the MIT licence, with every server running in its own Docker container under CPU, memory and IO limits.

The catch: you share the machine with other servers and don't control the system. You can't add your own firewall or run a service next to the server, and the plan sets the CPU and memory limits. For a single plugin server that's usually enough — setting one up from scratch is covered in the complete guide.

VPS and dedicated servers: full control#

A VPS gives you a clean OS and SSH access. Everything else is your job:

• install the right Java and create a separate user for the server instead of running it as root;
• firewall everything except the game port and SSH; in a proxy network only the proxy faces the internet, the game servers stay closed (see Velocity or BungeeCord);
• run the server so it doesn't die with your SSH session: in tmux, screen or as a systemd service;
• keep the OS updated and back up to another machine.

In return you can do anything: several servers and a proxy on one machine, a database for plugins, a website and a bot alongside. You can even install Pterodactyl yourself and manage servers from the browser. A dedicated server gives the same freedom with the whole machine to yourself: no neighbours eating CPU at peak hours.

What matters in a plan#

CPU

The number one factor. Most of the server's work is the tick loop, which runs on one thread, so single-core speed matters more than core count. Paper's docs recommend a CPU with high single-threaded performance and at least 4 threads for the server: the rest handle chunk loading, networking and background tasks.

Ask for the CPU model. “2 vCPU” on a VPS is a share of physical cores, and it can fall short when the neighbours are busy.

Memory

Look at guaranteed memory, not “up to N GB”. Java needs a bit more than -Xmx, and the OS needs its own: Paper's docs say to set -Xmx 1000–1500 MB below what the plan gives, or ask the host to cover that overhead. How much you need: how much RAM a Minecraft server needs.

Disk

The server constantly reads and writes chunks, and a backup copies the whole world. Get an SSD, ideally NVMe: a slow disk drags down chunk loading and saves. Check the size too — worlds grow, and backups need room.

Network and DDoS protection

DDoS protection has to filter game traffic to the server port, not just websites. A plugin on the server can't stop a flood of junk traffic — it has to be cut off before it reaches the server, on the host's side. Defending against bots and attacks: bots and DDoS.

Ask about outbound connections too: many plugins talk to the internet. DGuard, for example, reaches the DGuard site over HTTPS for the license, updates and the cloud check of aim and TriggerBot rules. Without a connection, protection keeps running for up to 72 hours on the saved license, except the cloud rules — so find out before you pay whether a host blocks outbound traffic.

Location

Ping depends on the distance between the player and the data center. Pick a location close to most of your players: a server on another continent adds noticeable delay to every fight.

Backups and support

Find out whether the host makes backups, how often and where it keeps them: a copy on the same disk won't survive that disk failing. And message support before you pay — the answer tells you how they'll help when the server goes down.

Traps to watch for#

• Oversold CPUs. More servers are packed onto a machine than it can carry: mornings are smooth, the evening peak tanks your TPS. Test the server in the evening.
• “Unlimited slots”. Slots are just max-players in server.properties. CPU and memory decide how many players the server can take, not a number on the plan.
• Core by ID. In some panels, the CPU setting isn't a core count but a core ID: “4” means “core number 4”, and the server lives on a single core. Paper's docs warn about exactly this.
• Memory “up to”. If a plan promises “up to 8 GB”, ask how much is guaranteed.
• A scary memory meter. The panel shows the Java process's memory, which takes everything it's given and doesn't hand it back. Per Paper's docs, that's expected and not a leak.
• Restrictions. Some hosts won't open a second port (for a proxy, a web map, voice chat) or let you upload your own .jar. Ask before you pay.

How to test a server after buying#

Put load on the server and look at the numbers. Paper bundles the spark profiler since 1.21: /spark health shows TPS, CPU, memory and disk, /spark tps shows TPS and CPU, and /spark profiler start --timeout 600 returns a report link after 10 minutes showing what eats the tick. A steady 20 TPS at the evening peak is a good sign.

Plugins spend tick time too. DGuard's checks run in network threads, not the server's main thread: on a live server that's 0.03 % of one core on the main thread — 0.38 ms of a 10.9 ms tick with 121 players. /dguard perf shows your own number, and if something else is eating the tick, track it down with why a server lags.

FAQ#