Linux Server Administration: Game Server Basics

Running a game server smoothly starts with a solid foundation in Linux server administration. Whether you host a Metin2 PvP server, a Minecraft world, or a custom C++ server application, the same core tasks apply: logging in, separating users, auto-starting services and securing the network all rely on the same handful of tools. This guide walks through the first steps after you rent a VPS, with real, working commands in a sensible order.

Connecting over SSH

You usually reach Linux servers without a graphical interface, through SSH. Your provider gives you an IP address and a temporary password. The first connection looks like this:

ssh root@SERVER_IP

Using an SSH key instead of a password is both safer and more convenient. You generate a key pair on your own machine and copy the public key to the server:

ssh-keygen -t ed25519 -C "game-server"
ssh-copy-id root@SERVER_IP

Providers use port 22 by default. If yours assigned a custom port, specify it with the -p flag: ssh -p 2222 root@SERVER_IP. Once key-based login works, disabling password login is an important security step.

Updating the system and core packages

The first job is to update the package list and installed software. On the Debian/Ubuntu family:

apt update && apt upgrade -y

On RHEL derivatives such as AlmaLinux/Rocky the equivalent is dnf upgrade -y. A few essential tools for managing a game server:

• htop — live view of CPU, RAM and processes
• tmux or screen — sessions that survive a dropped SSH connection
• git — manage server files with version control
• ufw — a readable firewall front end

apt install -y htop tmux git ufw

Creating a separate user

Running everything as root is a big risk; a single wrong command can affect the whole system. Run the game server under its own restricted user. Let's create a new user and grant administrative (sudo) rights:

adduser game
usermod -aG sudo game

On RHEL derivatives the group is wheel instead of sudo. You can now log in as this user and prefix commands with sudo when needed. The game server files should live in this user's home directory, for example under /home/game/server. To fix file ownership:

chown -R game:game /home/game/server

Managing services with systemd

If you start your game server by hand with ./start.sh, the application stops when the SSH session closes or the server reboots. The proper solution is a systemd service: it runs in the background, restarts automatically if it crashes, and starts on boot. Create the file /etc/systemd/system/game.service:

[Unit]
Description=Game Server
After=network.target

[Service]
Type=simple
User=game
WorkingDirectory=/home/game/server
ExecStart=/home/game/server/start.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

After writing the file, register and start the service:

systemctl daemon-reload
systemctl enable --now game

Use systemctl status game to check its state and journalctl -u game -f to follow live logs. Thanks to the Restart=on-failure line, if the server shuts down unexpectedly systemd brings it back within five seconds.

Firewall and port management

Game servers accept connections on specific ports. Closing everything else dramatically shrinks the attack surface. With ufw, allow SSH first (so you don't lock yourself out), then open the game port:

ufw allow 22/tcp
ufw allow 30000/tcp
ufw enable

For games that use UDP, remember to specify the protocol: ufw allow 30000/udp. You can list your rules with ufw status numbered. Installing Fail2ban on top of this automatically blocks brute-force attempts against SSH and keeps your logs clean.

Monitoring, backups and disk checks

Administration continues after the server is up. Turn a few commands into a regular habit:

• df -h — disk usage; log files can quietly fill the disk
• free -h — free memory and swap
• htop — which process is eating CPU under load

Regular backups of the database and world/character files are essential. A simple MySQL backup looks like this:

mysqldump -u root -p game_db > /home/game/backup/game_db_$(date +%F).sql

By attaching this command to a cron job, you can take an automatic backup every night. Storing the backup off the server, in a separate location, will save you in a disaster scenario.

Frequently Asked Questions

Which Linux distribution should I choose for a game server?

Ubuntu Server LTS is the most practical choice thanks to broad community support and current packages. Debian is leaner and very stable, while AlmaLinux/Rocky suit those who want RHEL compatibility. If you're just starting, begin with Ubuntu LTS; most commands in this article run directly.

How many players can a server hold?

That depends on the type of game, the number of CPU cores it uses and the RAM available. A single-threaded game loop will hit a CPU bottleneck with many players. Watch the load with htop to identify the bottleneck, and move to a more powerful VPS if needed.

My SSH connection keeps dropping — what should I do?

Start the running process inside tmux; even if the connection drops, the process continues and you reconnect with tmux attach. In the long run, running the game server as a systemd service is the most robust solution.

Stuck on server setup? We can work together on your game server's Linux configuration, security and automation — get in touch with me.