Dedicated vs VPS vs Shared Game Server Hosting

There are roughly three ways to pay someone else to run your game server, and the marketing for all three uses the same words. Every provider promises low latency, high performance and protection against attacks. The specification pages list RAM and slots and a processor name, and none of that tells you whether the thing will hold thirty players on a modded map without stuttering.

This is an attempt to explain what you are actually buying in each case, which technical properties matter for game servers specifically, and how to recognise the point where the cheap option has stopped being the right one.

The three shapes

Shared game hosting

You buy a game server, not a computer. The provider runs the game process for you on hardware shared with many other customers, and hands you a web control panel with a start button, a config file editor and a file manager. You pick the game, it installs, you set a password and you are running.

Your process is one of many on that physical machine, usually contained by a resource limit that caps how much memory and CPU time you can consume. You do not have a shell. You cannot install system packages. You cannot see the other tenants and they cannot see you.

Pricing is normally per slot — per player capacity — sometimes per gigabyte of RAM.

This is the entry point, and for a lot of servers it is also the correct permanent answer.

VPS

You buy a virtual machine. Real CPU cores are shared between virtual machines by a hypervisor, and you get a defined allocation of memory, a slice of disk, and root access to an operating system that is entirely yours.

Nothing is installed for you. You install the game server, keep the OS patched, configure the firewall, set up backups, and fix it when it breaks at an inconvenient hour. In exchange you can run anything: several game servers side by side, a Discord bot, a web panel, a database, whatever you want on the same box.

Priced per specification, and generally by the month.

Dedicated server

You rent a whole physical machine in a data centre. Every core, all the RAM, the disks, the network port. No hypervisor between you and the metal, no other tenants competing for anything.

You handle everything above the hardware. The provider handles the hardware, the power and the network, and replaces a failed drive when one goes.

The most expensive of the three by a wide margin, and the least often necessary.

CPU: why one fast core beats eight slow ones

This is the single most misunderstood specification in game hosting, and it explains most disappointing upgrades.

Most game servers run their world simulation in a single loop on a single thread. Every tick, that one thread walks through entities, applies physics, runs whatever plugin code is registered, processes player input and produces the next state. Networking and file I/O may be handled by other threads, but the simulation — the part that determines whether your server feels smooth — is one thread doing one thing at a time.

The consequence is that adding cores does almost nothing for a single server instance. A machine with many modest cores can look impressive and perform worse than a machine with fewer, faster ones. What matters is how quickly one core can finish one tick, which comes down to clock speed and the per-clock efficiency of the processor generation.

Minecraft is the clearest case. Java edition's main tick loop is single-threaded, and the way you make a heavily-modded world stop stuttering is a faster core, not more of them. Some server forks parallelise parts of the work — that is much of the appeal of the alternative server software discussed in the Paper, Purpur and Fabric comparison — but the core simulation loop still dominates. Source-engine games behave similarly: a Counter-Strike 2 or Team Fortress 2 server needs one core that can keep up with its tickrate, not a wide processor.

Where extra cores do earn their keep: running several separate server instances on one machine, since each gets its own thread; and world generation or chunk loading in games that thread those operations.

The practical implication is uncomfortable. A modern desktop-class processor at high clock speed will often outperform a server-class processor with three times the core count, for this workload. Providers who advertise total core count are advertising the number that matters least. If a listing names the exact processor model, look up its single-thread performance. If it does not name the model, that omission tells you something too.

Then there is contention. On shared hosting and on a VPS, your allocation is a share of a physical core, and how honestly that share is enforced varies enormously between providers. Some pin virtual cores to physical ones. Some oversell aggressively, assuming most tenants sit idle, which works until they do not.

RAM: usually the thing that actually stops you

CPU determines how smooth your server feels. RAM determines whether it runs at all, and it is the constraint people hit first.

A vanilla server for a few friends needs very little. Add mods and the picture changes completely. Every loaded chunk, every entity, every plugin's data structures, every cached asset lives in memory, and modded packs can multiply the requirement several times over compared to vanilla. Rust and 7 Days to Die hold large persistent worlds in memory, and the requirement grows as the world is explored, so a server that was comfortable in its first week may not be in its third.

Running out of memory does not produce a polite warning. On a Java server you get garbage collection pauses that lengthen until the server freezes for seconds at a time, then a crash. On a Linux VPS the kernel's out-of-memory killer picks a process and terminates it, and the process it picks is usually the largest one, which is your game server. Either way players see a hang and a disconnect.

Two things about advertised RAM figures.

The number normally includes overhead. On a VPS the operating system, the SSH daemon and any monitoring agent all consume memory before your server starts. On shared hosting, whether the panel's own overhead counts against your allocation depends on the provider.

The number is a ceiling, not a reservation, on many shared plans. If the physical machine is oversubscribed and every tenant reaches for their maximum simultaneously, someone is not getting it.

Buy headroom. Memory is the cheapest thing to over-provision and the most disruptive to run out of.

Disk

Solid-state storage is effectively the baseline now, and NVMe is faster still. Whether the difference is visible depends on the game.

Where disk speed matters: world generation, chunk loading in open-world games where players roam into unexplored territory, save operations on large worlds, and server startup. A large world saving to a mechanical drive can produce a visible stall every time it autosaves.

Where it matters less: a small map-based server that loads once and then runs from memory. A competitive Counter-Strike: Source server changing maps every twenty minutes cares more about the map file loading quickly than about sustained throughput.

Check capacity as well as type. Modded worlds, backups and logs grow steadily, and some plans are tight enough that a month of automated backups fills the allocation. Ask whether backups count against your quota, because on cheaper plans they usually do.

Network and bandwidth

Three separate properties get conflated here.

Latency is how long a packet takes to reach your server and come back. It is dominated by physical distance and by routing quality, and no amount of hardware fixes it. A server in one continent will feel worse to players in another, full stop. If your community is regionally concentrated, host near it. If it is spread across several regions, you are choosing who gets the good experience, and that is a community decision more than a technical one.

Bandwidth is throughput. Game traffic is small packets sent frequently rather than bulk transfer, so a busy server typically consumes less bandwidth than people expect. Where it adds up is content delivery — FiveM servers pushing large custom asset packs to every connecting player, or a Minecraft server distributing a resource pack. That can dominate your usage entirely.

Port speed and traffic allowance are what actually appear on invoices. Some plans are unmetered on a given port speed, some allow a monthly volume then throttle or charge. Read which. A server that streams assets to every new player can burn through a metered allowance faster than you would guess from watching player counts.

The slots model, and what it hides

Shared game hosts almost always price per slot. Twenty slots costs a certain amount, forty costs more. It is a clean model to shop with, and it is a poor model for predicting performance.

Slots are a player limit, not a resource guarantee. Two servers with identical slot counts can behave completely differently, because what consumes resources is not the count of connected players. It is entities, plugins, mods, world size, tickrate and view distance. A twenty-slot vanilla server and a twenty-slot heavily modded server place utterly different demands on the same hardware, and the second one will struggle on a plan sized for the first.

The number also encourages buying the wrong thing. People buy generous slot counts hoping to grow into them, then discover the server stutters at half capacity because the underlying resources were sized for the advertised slots on a light workload. Meanwhile most servers never approach their limit — the piece on choosing a slot count makes the case that a smaller number that is often near-full reads better to a newcomer browsing server listings than a large number showing a handful of players.

What to look for instead: the RAM allocation, whether CPU is limited and how, and whether the provider states any policy about oversubscription. If a plan describes itself only in slots and gives no resource figures, you cannot compare it to anything, which is often the point. The 2026 cost breakdown covers what these plans tend to cost against what they deliver.

Noisy neighbours

On any shared infrastructure — shared game hosting and VPS alike — you are on a machine with other customers. When one of them starts consuming heavily, you can feel it.

The symptoms are distinctive. Your server lags in bursts that do not correspond to anything you did. Player count is normal, your own metrics look fine, then tick times spike for twenty minutes and recover on their own. Nothing in your logs explains it, because the cause is not in your logs. It is another tenant.

Different providers manage this differently. Hard CPU limits per container prevent one tenant from starving another, at the cost of capping your own bursts. Pinned cores on a VPS give predictable performance. Aggressive overselling with no limits gives everyone great performance right up until the machine fills, and then gives everyone poor performance.

You cannot audit this from the outside. What you can do is run your server through a busy evening and watch the tick timing, then ask for a refund inside whatever window the provider offers if the pattern looks like contention. Uninstrumented complaints go nowhere; a graph of tick times against a flat player count is a conversation.

A dedicated server removes this variable entirely. That is the main thing you are buying, more than raw speed.

Root access and why mods force the issue

Shared game hosting gives you a panel. The panel gives you what the provider decided to expose: config files, a console, file upload, sometimes a plugin installer for a curated list.

That covers a plain Minecraft server or a standard Left 4 Dead 2 instance comfortably. It starts to bind when you need any of the following:

A specific runtime version. Some modpacks require a particular Java version, and if the panel offers only one, you are stuck.

System packages. Mods with native dependencies need libraries installed on the host. You cannot install those without root.

Custom startup parameters. Garbage collection tuning is a real lever for large Garry's Mod or Minecraft servers, and some panels lock the startup command.

Extra processes. A database, a Discord bridge, a web map renderer, a stats backend. Shared hosting runs the game and nothing else.

Direct file system access. Migrating a large world in over SFTP is slow and error-prone compared with a shell and a copy command.

Non-standard ports. Some panels assign a port and do not let you open others, which matters when a mod expects its own listener.

When you hit two or three of these, the panel has become the problem rather than the convenience, and a VPS with root is the answer. That is the usual migration path: not because the shared server was too slow, but because it was too closed.

The cost is real. Root access means you own security updates, firewall configuration, backups and recovery. If nobody in your group is comfortable with a Linux command line, a VPS is a source of outages rather than freedom.

DDoS protection

All three tiers advertise it. They mean different things.

Volumetric attacks — floods large enough to saturate a network link — can only be handled upstream, by filtering capacity at the network edge before traffic reaches your machine. This is a property of the provider's network, not of your plan, and it is why a home connection cannot be protected at all.

The differences appear in the details. What attack volume can they absorb before the mitigation itself fails? Is filtering always on, or triggered after detection — and how long is the gap? Do they filter game protocols intelligently, or blackhole your IP when an attack starts, which stops the attack by taking you offline, achieving the attacker's goal on their behalf? Is protection included or an add-on?

Shared hosts typically provide network-level protection by default, because an attack on one customer affects everyone on that machine and they have every reason to filter it. VPS providers vary hugely. Dedicated providers usually offer it as a tier with options.

Application-layer attacks are a separate problem that no network filter solves — malformed packets that crash the server process, connection floods that exhaust slots, query amplification. Those are handled by patched software, rate limiting and sensible configuration, and they remain your job on every tier. The practical guide to attacks on small servers covers what is realistic to defend against yourself.

One thing worth knowing: being attacked is not a sign you have done anything wrong. Banned players retaliate. It is common and it is mostly automated.

Which one is actually right

Shared game hosting is correct when you are running one server for one game, using standard software or a supported modpack, with a player count in the small-to-moderate range and no need for anything outside the panel. It is also correct when nobody in your group wants to administer Linux, and when the ability to hand a co-owner panel access without handing them root matters. Starting here is sensible even if you expect to grow — the migration later is a world file and a config directory, not a rebuild.

A VPS is correct when you need root, when you want several services on one machine, when you have outgrown a panel's constraints, or when you want predictable resources at a price well below dedicated hardware. Running a Counter-Strike 1.6 server alongside a Day of Defeat one and a stats site, on the same box, is exactly the VPS case. The requirement is someone willing to maintain it.

A dedicated server is correct when you are running a network of servers rather than a server, when contention has become a recurring problem you can demonstrate, when your workload genuinely needs the full memory of a physical machine, or when compliance or control requirements rule out shared infrastructure. Large FiveM roleplay communities with heavy scripting and big asset packs reach this point legitimately. Most communities do not, and buying a dedicated machine to fix a problem that is really a single-thread bottleneck just gives you an expensive machine with the same bottleneck.

Signs you have outgrown what you have

On shared hosting: you are editing files by uploading them because there is no shell, and it has become the slow part of every change. You want software the panel does not support. Performance is inconsistent in a pattern you cannot tie to your own activity. You are running a second server on a second plan and paying twice for resources one machine could hold. You need a process that is not the game.

On a VPS: memory is the constraint and the next tier up costs about what a small dedicated machine does. Contention shows up in your metrics regularly. You are running enough instances that you are managing a fleet. Your backups no longer fit.

On any tier: the server lags at a player count well below its limit. That one usually is not a hosting problem at all. It is plugin overhead, entity accumulation, a runaway world border or an inefficient mod, and the fix is profiling rather than purchasing. Diagnosing lag on a FiveM server walks through the method, and most of it transfers to other games.

Questions people ask before buying

Is a VPS always faster than shared hosting? No. A well-run shared host on modern hardware can outperform a cheap oversold VPS. What a VPS reliably gives you is control, not speed. If your problem is a locked-down panel, a VPS solves it. If your problem is slow ticks, the answer is faster single-thread performance wherever you find it.

How much RAM do I actually need? It depends on the game, the mods and the world size, and anyone quoting a universal number is guessing. Start from the software's own stated requirement, add the requirement of your mod set, then add meaningful headroom because running out is far more disruptive than overpaying slightly. Watch usage over a busy week and adjust.

Does more CPU cores mean more players? Only indirectly. Additional cores help when you run multiple server instances, since each gets its own thread. For one instance, the tick loop uses one core and the rest sit idle. More players on one server means you need that core to be faster, not to have company.

Can I move between tiers later? Yes, and it is easier than people expect. World data, configs and plugins usually transfer directly. Plan for a maintenance window, take a full backup first, and test the new instance before pointing anyone at it. Announce the address change clearly and update your entry on any server list you appear on, because a stale address is the fastest way to lose the regulars you spent months gathering.

Do I need managed hosting? If nobody in your group is comfortable maintaining a Linux system, yes, and there is no embarrassment in that. Managed means someone else patches the OS and answers at three in the morning. It costs more and constrains what you can install. That trade is straightforwardly good for many people.

What about hosting at home instead? Viable for a private server for friends, and a genuinely good way to learn. Domestic upload bandwidth, unprotected home IP addresses and the possibility that your ISP puts you behind carrier NAT are the limits, and a home-hosted server that is reachable but never appears on lists is usually a query port problem rather than a hosting one — why nobody joins your server covers that failure. Running a Minecraft server free covers the no-cost routes and what they cost you in other ways.

Does hosting choice affect whether people find my server? Not directly, though it affects whether they stay. A server that lags or goes down loses players regardless of how well it is advertised, and stability is what turns a first visit into a regular. Discovery is a separate subject from hardware, and your entry on a server list does more for it than your specification sheet ever will.

Choosing without overthinking it

Work out what you are actually running: which game, which mods, roughly how many people, and whether you need anything besides the game process. That determines your memory requirement and whether a panel will be enough.

Then be honest about who maintains it. Root access is worth nothing if nobody wants to use it, and a VPS that nobody patches is worse than shared hosting that somebody else patches for you.

Start smaller than you think you need, measure for a few weeks, and move when the measurements say to. The cost of starting too small is one migration. The cost of starting too large is paying every month for capacity that sits idle, on hardware that may not have been the bottleneck anyway.