First game server checklist, start to finish

Your first game server comes down to ten jobs, in order: choose the game version and a plan sized for your group, secure the panel account with two-factor, set the server name and a join password or whitelist, make yourself admin, start it and join by IP to prove the connection works, take a backup and restore it once, add a nightly backup and a restart schedule, install mods only after the vanilla server works, invite a few friends before everyone, and write down what you did. None of it is hard. Doing it in this order means every problem appears when there are few moving parts to blame, and the world you build in week one is still there in month six.

Before you order: three decisions#

Which game, which version, which mods. Decide whether the group plays vanilla or modded, and if modded, which modpack or mods. That changes everything after it: a modded Minecraft server on Fabric or NeoForge needs different software and much more memory than a vanilla one, and a Valheim group with ten mods needs every player to install the same ten. If you are not sure yet, start vanilla. Adding mods to a working server is easy; debugging mods on a server that has never worked is not. Paper, Fabric or vanilla covers the Minecraft version of this choice.

How many players, really. Not the number in the group chat - the number online at the same time on a busy evening. That is what you size for. Most friend groups peak at half their membership.

Where the players are. Latency is distance. A server in Germany is a short hop for most of Europe and a long one from Australia. Pick a location near the bulk of your players, and test it before paying for a year. Choosing where your server lives and how to choose game server hosting go deeper on both.

Sizing: what plan to start with#

Memory is the resource that decides most plans, because running out of it stops the server outright. CPU decides whether the server stays smooth.

These are starting points; game server requirements by game has more games and the reasoning, and how many players fit on a server explains why player count is a weaker guide than what the players do. The safe approach is to start on the plan that fits your peak, watch the memory graph for two weeks, and move up if it lives near the ceiling. Starting large "to be safe" usually means paying for memory that sits empty. When to upgrade your plan covers reading the signs.

The first ten minutes: secure the account#

Before touching the game, lock down the thing that controls it.

1. Turn on two-factor authentication on the panel account. Someone with your panel password can delete your server and its backups. Two-factor on your panel account explains the setup and why the recovery codes matter as much as the app.
2. Store the recovery codes somewhere that is not the same phone as the authenticator.
3. Do not share your login. If a friend helps run the server, give them their own access as a subuser with only the permissions they need. Subusers and least privilege has a sensible set.
4. Note the server's address - IP and port - from the panel, and keep it handy.

First start: name, password, admin#

Now configure the basics. Where these live depends on the game - a config file like Minecraft's server.properties, launch settings on the panel's Startup tab, or an ini file - but every game has the same few:

• Server name - what appears in the browser. Keep the password out of it; some games refuse to start if it contains the password.
• Join password or whitelist - for a private server, at least one. A whitelist of specific accounts is better than a password once your group grows past a handful. Whitelist vs password covers both, game by game.
• Max players - match it to your real peak, with a little room.
• Admin - add your own account as admin. That might be an op command (Minecraft), a line in an admin list file (Valheim's adminlist.txt), or an admin password in a config (Palworld's AdminPassword). Use your account ID, not your display name, where the game allows.
• Difficulty and game rules - agree them with the group before the first session. Changing them later is possible in most games, but people get attached to the rules they started with.

For a Minecraft server, the first pass at server.properties might look like this:

motd=Thursday Night Crewdifficulty=normalmax-players=10white-list=trueenforce-whitelist=trueonline-mode=trueview-distance=8

Start the server and watch the console until it says it is ready - Done in Minecraft, a line saying the session or world is loaded in most others. If it stops before that, read the last lines; the reason is nearly always there. How to read a server console helps when it is not obvious.

Prove the connection before you invite anyone#

Join the server yourself, by IP and port, before telling anyone the address. This one step separates "the server works" from "the server is running", which are not the same thing.

1. In the game, use direct connect or add server, and enter the address exactly as the panel shows it, port included: 203.0.113.10:25565.
2. If it connects, walk around, place something, and log out and back in to check it was saved.
3. If it does not, check you used the game port (not a query or RCON port), that the game version on your client matches the server, and that the password is right. Why players cannot connect to your server goes through the rest in order.

Then check the server list, if your game has one. Listing can take several minutes, and some games list only if a setting is on. Joining by IP working while the list does not is a listing problem, not a server problem. Game server ports explained covers the query ports behind most lists.

Backups: take one, then restore it#

This is the step people skip, and the one that matters most in six months.

1. Take a manual backup now, while the world is small.
2. Restore it - on purpose, now, while nothing is at stake. Build something, restore the backup, and check the build is gone. You have just proven that your backups work and that you know how to use them.
3. Schedule a daily backup at an hour when nobody plays.
4. Take a manual backup before every change - a game update, a new mod, a config experiment.

A backup nobody has restored is a hypothesis. Backups that actually restore explains the ways backups fail silently, and testing a restore before you need it the routine that catches them.

Also learn the difference between stopping and killing your server. A normal stop lets the game save the world first; a kill does not, and anything since the last autosave is lost. Use stop or restart, and use kill only when stop has hung.

Schedules: restarts and the boring automation#

Most game servers run better with a regular restart: memory is released, small leaks are cleared, and updates (where you have automatic updates on) are applied. Pick a quiet hour and add a schedule. A typical set:

04:00 daily    console command: say Restarting in 5 minutes04:04 daily    backup04:05 daily    power action: restart

That warns players, takes a backup while the world is fresh, then restarts cleanly. In cron syntax, which most panels use, "04:05 daily" is 5 4 * * *. Cron expressions explained covers the syntax, restart schedules that help how often to restart, and scheduled tasks worth having the rest of the list. Check which time zone the panel uses before you trust "04:00".

Mods and plugins: one at a time, after it works#

Only once the vanilla server has run cleanly for a session or two:

1. Take a backup.
2. Install the mod loader or plugin framework the game needs (Paper or Fabric for Minecraft, BepInEx for Valheim, and so on). Start the server and confirm it still works with no mods.
3. Add mods one or two at a time, restarting and checking after each. If something breaks, you know which one did it.
4. Note which mods need installing on players' clients too, and tell the group exactly which versions.
5. Get mods only from their official pages. Free copies of paid plugins are the most common way a backdoor reaches a server. Malicious plugins and mods explains.

When a game update arrives, a modded server should not update until its mods have. The update day checklist covers the order, and keeping a modded server clean the long-term habits.

Inviting players and the first week#

Invite a few first. Two or three people for the first evening catch the problems - a missing mod on a client, a permission that blocks building, a password typed wrong in the invite - before twenty people hit them at once.

Share the details in one place. Address, password or how to get whitelisted, game version, any mods with links, and the rules. A pinned Discord message works well. Game server Discord setup covers more.

Watch the graphs. For the first week, look at memory and CPU during your busiest evening. Memory near the limit means upgrade or trim; one core flat at its limit means the CPU is the bottleneck. Reading a server load graph shows what to look for.

Write down what you did. Which version, which mods, what settings you changed and why, where the backups are. Future you, or the friend who takes over, will need it.

Mistakes almost everyone makes once#

A short list, so you can make them on purpose or not at all.

• Uploading a world over a running server. The server keeps the old world in memory and overwrites your upload at its next save. Stop first, upload, then start.
• Editing a config while the server runs. Many games read their config only at start and write it back on shutdown, so your change is silently replaced. Stop, edit, start.
• Giving out admin to be friendly. A friend with admin can do anything you can in-game, including ending the world by accident. Give admin to the people who will moderate, not to everyone who asks.
• Running offline or cracked mode to let someone in. It turns off account checks, so anyone can join as anyone - including as you. Fix the real problem (an expired account, a version mismatch) instead.
• Treating the game's own backup folder as a backup. Several games keep automatic copies beside the world, on the same disk. They help with a corrupt save, not with a deleted server or a mistake made in the file manager. Real backups live somewhere else.
• Letting the disk fill. Logs, old backups and crash dumps accumulate. When the disk is full, saves fail - sometimes leaving a half-written world. Glance at disk usage once a month. Game server disk space full lists what to delete.

FAQ#

How much RAM does my first game server need?

It depends on the game: 2-3 GB is enough for vanilla Minecraft, Valheim or Terraria with a small group, while Palworld or a Minecraft modpack need 8 GB or more. Start with the plan that fits your busiest evening and upgrade if the memory graph stays near the limit.

Do I need to know Linux to run a game server?

Not on a hosted panel. Starting, stopping, editing config files, uploading saves and taking backups are all done in a web interface. Linux knowledge helps if you rent a bare VDS and install everything yourself.

Should I install mods straight away?

No. Get the vanilla server running and joined first, then add mods one or two at a time with a backup before each. When something breaks, you will know exactly what caused it.

Why can I not connect to my own server?

Usually a wrong port (using the query port instead of the game port), a version mismatch between your game and the server, or the server not having finished starting. Check the console for the ready line and copy the address exactly from the panel.

How often should I back up?

Daily as a minimum, plus a manual backup before any update or mod change. More importantly, restore one backup early on to prove the process works.