VDS or a game panel: which one do you actually need

The short version: if you want one to five game servers and you do not enjoy Linux administration, buy the managed plan. If you need software nobody sells as a product, or you are packing eight small services onto one box, buy the VDS. The interesting cases sit between those two, and they are usually decided by temperament rather than by numbers. This post is an attempt to decide them with numbers instead - what each one actually gives you, what the operating system costs you in memory before you run anything, and what the sysadmin job attached to root access takes in hours per month.

People ask for a VDS because they want control. What they get is control plus a second unpaid job: the firewall, the updates, the backups, the certificate that expires on a Sunday, and the restart at three in the morning that nobody else is going to do. Sometimes that trade is obviously right. Often it is bought by somebody who wanted to run a Minecraft server and ends up reading sshd_config documentation instead.

What you are actually renting#

A managed game or app plan is a container on a shared machine. On a Pterodactyl-based host that means one Docker container per server, with memory, disk and CPU capped by the kernel's control groups, and a web panel as the only interface. You get a console, a file manager, SFTP, scheduled tasks and backups. You do not get a shell on the host, you do not get root, and you cannot install a package that is not part of the image your server runs from.

A VDS is a virtual machine. It has its own kernel, its own distribution, its own users, and you are root. Everything above the hypervisor is yours, which includes every mistake.

The dividing line is not power. A container on good hardware will run a Minecraft server exactly as fast as the same allocation on a VM sitting beside it. The dividing line is responsibility, and responsibility has a price in hours that never appears next to the monthly figure. If the terminology is what is bothering you, VPS, VDS or dedicated server separates the three properly, and what a Pterodactyl panel gives you covers the managed side in detail.

The overhead nobody prices in#

This is the part that decides most real comparisons, and it is almost never in the table on a pricing page. A VDS runs a whole operating system before it runs anything you care about.

Measure it yourself on a fresh box with free -m after a reboot, but the usual shape is:

So an 8 GB VDS is not 8 GB of game server. It is roughly 7.5 GB if you run services directly, and closer to 6 GB if you install a panel on it so that your friends can restart things without an SSH key. Compare that against buying the same memory as managed plans, where the overhead lives on the host and you are billed for what your process gets.

The arithmetic cuts both ways and it depends entirely on the shape of your workload:

• One big thing. A single 10 GB Minecraft server is cheaper and less work as a managed plan. You pay for exactly the memory the JVM gets, the install is done, and you have not spent a weekend on it.
• Many small things. Five Discord bots, two small game servers, a Postgres instance and a staging copy of your website is where a VDS pulls ahead, because memory pools. A bot that idles at 90 MB borrows from the bot that spikes to 400 MB. Buy those as eight separate plans and each one carries its own ceiling, paid for whether it is used or not.
• Bursty and unpredictable. A VDS lets you overcommit and find out. A panel plan will stop the container at the limit and restart it clean, which is safer and less forgiving.

The single most useful question is: how many separate things am I running, and how spiky are they? Below about four, the panel almost always wins on total cost once you value your time above zero. Above about six, the VDS starts to win on money even before you count the pooling.

Which one is obviously right#

There are cases where this is not a judgement call.

Take the managed plan when:

• You want between one and five servers and no opinions about the distribution.
• You want the install, the start command, the Java version and the updates handled.
• You want to hand somebody console access without handing them the machine. Roles, teams and time-boxed grants exist for exactly this, and subusers and least privilege walks through setting them up.
• You would rather restore a backup with a button than remember how you set up the cron job that was supposed to be making them.
• Your reaction to the phrase "check the DOCKER-USER chain" is to close the tab.

Take the VDS when:

• You need software that is not sold as a hosting product: a Matrix homeserver, a mail relay, a custom binary, a specific kernel module, an obscure distribution.
• You are running enough services that pooling memory is worth real money.
• You want your own Docker or Compose stack, with volumes and networks you define. Docker on a VDS and Compose for small stacks are the starting points.
• You already administer Linux daily and the panel would be in your way.
• You need one machine with a single address running several game servers on ports you choose, which is its own topic in several game servers on one VDS.

What should not decide it: the belief that a VDS is faster. CPU on a managed plan is a hard throttle to the share you bought, so a server sitting at 100% is slow rather than broken, and it is never suspended for it. A VDS with two vCPU is throttled at two vCPU in the same way. The difference is that on a VDS nothing stops one of your own services from eating the whole allocation and starving the others, which is a problem you have now bought the right to solve. Shared CPU and noisy neighbours covers what a share actually guarantees.

The first hour on a VDS, in commands#

If you take the VDS, this is the minimum before you install anything. None of it is optional, and all of it is on you. There is a longer version in the first hour on a new VDS.

1. Update everything and reboot if the kernel changed.
2. Make a normal user with sudo, and stop using root interactively.
3. Put an SSH key on it and turn passwords off.
4. Close every port you are not deliberately using.
5. Turn on automatic security updates so that the box does not rot.

$ apt update && apt full-upgrade -y$ adduser deploy && usermod -aG sudo deploy$ ssh-keygen -t ed25519 -C "laptop"          # run this on your machine$ ssh-copy-id deploy@203.0.113.10

Then harden the daemon. Put the changes in a drop-in file rather than editing the main config, so that a package upgrade does not silently revert them:

PermitRootLogin noPasswordAuthentication noKbdInteractiveAuthentication no

Test the new settings in a second terminal before you close the first one. sshd -t checks the syntax; a locked-out VDS needs a console session from the provider to fix. SSH keys and hardening has the rest, including agents and jump hosts.

The firewall is next. Default deny, then open exactly what you need:

$ ufw default deny incoming$ ufw default allow outgoing$ ufw allow 22/tcp$ ufw allow 25565/tcp        # Minecraft$ ufw allow 2456:2457/udp    # Valheim game and query$ ufw enable$ ufw status numbered

Finish with unattended upgrades and a ban daemon:

$ apt install unattended-upgrades fail2ban$ dpkg-reconfigure -plow unattended-upgrades$ systemctl enable --now fail2ban$ fail2ban-client status sshd

That is about forty minutes the first time and fifteen once you have done it twice. It is also the cheap part.

Keeping it alive is the actual job#

Nothing on a VDS restarts itself unless you arrange it. The tool is systemd, and the unit file is where most of the real differences between "it runs" and "it survives" live:

[Unit]Description=Valheim dedicated serverAfter=network-online.target[Service]User=valheimWorkingDirectory=/home/valheim/serverExecStart=/home/valheim/server/valheim_server.x86_64 -nographics -batchmode \  -name "Longship Crew" -port 2456 -world "Midgard" -password "herring-barrel-42"Restart=on-failureRestartSec=10KillSignal=SIGINTTimeoutStopSec=90[Install]WantedBy=multi-user.target

KillSignal=SIGINT is the line that matters and the one people leave out. Many game servers save on a clean interrupt and lose everything since the last autosave on a SIGKILL, so a default unit file that sends SIGTERM and gives up after 90 seconds can quietly cost you an evening of progress every time the box reboots. Systemd services for your apps goes through the rest of the directives.

Backups are the other thing that does not happen by itself. A snapshot taken by the provider protects against the disk dying; it does not protect against you deleting a world at midnight. Something like restic, pointed at storage on a different machine, costs ten minutes to set up:

$ restic -r sftp:backup@198.51.100.5:/srv/restic init$ restic -r sftp:backup@198.51.100.5:/srv/restic backup /home/valheim/server/worlds_local$ restic -r sftp:backup@198.51.100.5:/srv/restic forget \    --keep-daily 7 --keep-weekly 4 --prune

Put that in a systemd timer or a cron entry, then restore one, to somewhere harmless, before you need to. A backup nobody has restored is a hypothesis, and testing a restore before you need it is the shortest post on this site worth reading twice.

On a managed plan, that entire section is a Backups tab with slots included on every plan, on demand or on a schedule, restored with a button and stored off the machine they protect. The panel side also has a Schedules tab with cron expressions and ordered tasks, so a nightly backup plus a weekly restart is about two minutes of clicking rather than two unit files.

Running a panel on your own VDS#

The common ambition is to have both: root access and a nice interface for the people who share the server. This is possible and a lot of people do it, but be clear about what you are signing up for.

Pterodactyl is two pieces. The panel is a Laravel application that needs a web server, PHP with the extensions it lists, a MySQL-compatible database, Redis and Composer. Wings is a Go daemon that needs Docker and talks to the panel over its own port, with SFTP served separately. Upstream defaults put the Wings API on 8080 and its SFTP listener on 2022, with the panel itself on 80 and 443.

That is at least five services to keep patched, plus certificates for the panel hostname, plus the Docker images for every game you run. On a 16 GB VDS that is fine. On the 8 GB tier it is a meaningful slice of your memory spent on infrastructure rather than on players, and every one of those components is a thing that can break at an inconvenient hour.

A reasonable rule: install a panel on your own machine when you are hosting for other people and the panel is part of the product. Do not install one so that three friends can press Restart. Give them a subuser account on a managed plan instead and keep your weekend.

Security is where the difference is real#

On a managed plan the security model is already built, and it is the same on every plan: two-factor with authenticator codes and single-use recovery codes, granular roles so somebody can have console but not billing, per-server activity logs, SFTP credentials issued per server rather than per account, and API keys that can be restricted by address. Platform backups run nightly, are copied to separate hardware, verified and pruned. If a container gets into trouble it is stopped and restarted clean.

On a VDS every one of those is a thing you build or go without. Worth being blunt about what actually goes wrong on small self-managed boxes, in rough order of frequency:

• A password-authenticated SSH account with a weak password, found by a scanner within hours of the address going live.
• A database or admin interface bound to 0.0.0.0 and published through Docker past the firewall.
• An application dependency with a known hole, on a box where nothing has been updated since the day it was ordered.
• Credentials committed to a public repository, then used from somewhere else entirely.

Almost none of it is a kernel exploit. Check what is listening with ss -tulpen on the day you finish setting up and again once a month, and keep the answer short. Firewall rules that matter is the practical version of that habit.

The cost in hours, not just dollars#

Price the hours at whatever your hour is worth and then compare. These are typical, not worst cases, and they assume nothing goes badly wrong.

That last row is worth expanding, because it is the one that separates the two properly. On a managed plan a watcher polls every couple of minutes for a server that went offline or whose uptime went backwards, and restarts you asked for are not counted against you. Three unexpected restarts in an hour puts a warning on the server page and opens a ticket automatically. On a VDS the equivalent is a Restart=on-failure line and whatever monitoring you built, and the first you hear about a crash loop is usually a message from a player. Monitoring that tells you something is worth reading before you build that yourself.

Money, using the current ladders as a sanity check: the VDS line starts at 8 GB, 128 GB of disk and two vCPU on an Intel i9-9900K, and steps up to 16 GB with four vCPU and 24 GB with six. A single managed Minecraft plan with 4 GB and 1.5 vCPU is a fraction of that. Two or three separate managed servers land in the same range as the entry VDS with less total memory but none of the work. Six or seven separate small services do not, and that is the crossover.

FAQ#

Is a VDS faster than a managed game server?

Not inherently. Both are a share of the same kind of hardware with a hard CPU cap, and a Minecraft server given 1.5 vCPU behaves the same either way. A VDS can feel faster because you can tune the whole machine, and slower because you are also responsible for the tuning.

Can I run a game hosting panel on my VDS?

Yes. Pterodactyl's panel and Wings will install on any recent Debian or Ubuntu with Docker. Budget around 1 GB of memory and several services worth of patching for the privilege, and only do it if a panel is part of what you are offering other people.

Do I get root or SSH on a managed plan?

No. You get SFTP with credentials issued per server, an in-browser file manager with a syntax-highlighting editor, and an unfiltered console with command history. That covers configuration, uploads and log reading, which is most of what people actually want root for.

How much Linux do I need to know before taking a VDS?

Enough to be comfortable with the package manager, systemctl, journalctl, the firewall and file permissions without looking each one up. If that list reads as homework rather than as a Tuesday, the panel is the right answer for now.

What happens when a VDS runs out of memory?

The kernel's OOM killer picks a process and terminates it, usually the largest one, which is usually the thing you cared about. Managed containers are stopped at the limit and restarted clean instead of being left to swap. Swap and the OOM killer explains how to read the evidence afterwards.

Can I move from one to the other later?

Yes, and the data usually moves cleanly because a world or an application is just files. Copy them off with SFTP, copy them back on the other side, change the address your players use. Moving a server without losing players covers doing it without a day of confusion.