Setting Up an OVH VPS for a Game Server

A game server needs more than code. It also needs a reliable machine, secure access, and a firewall. In this first step of building the Bloodstrike backend, we prepare an OVH VPS before exposing the game to the Internet.

Starting with a fresh VPS

Imagine renting a new computer in a data center. It has an operating system and a public IP address, but it is not ready to host a public game yet.

We started with an OVH VPS running Ubuntu 26.04 LTS. We connected to it over SSH using the ubuntu user.

SSH lets us control the server from a terminal without needing a graphical desktop.

ssh ubuntu@YOUR_SERVER_IP

Replace YOUR_SERVER_IP with the public IP address of your VPS.

Before changing anything, it is useful to check the system resources.

free -h
df -h

The first command shows available memory. The second shows disk space.

Our VPS had roughly 4 GB of RAM and 38 GB of disk space, which was enough to begin preparing the game server.

Updating Ubuntu

A fresh server may already have updates waiting to be installed.

We updated the package lists and installed available upgrades.

sudo apt update
sudo apt upgrade -y

The sudo command runs an operation with administrative privileges. The -y option automatically confirms package installation prompts.

Keeping the operating system updated helps reduce exposure to known vulnerabilities.

Configuring the firewall

A public server can receive connection attempts from anywhere on the Internet. A firewall helps control which services can be reached.

We used UFW, the uncomplicated firewall included with Ubuntu.

First, we allowed SSH so that we would not accidentally lock ourselves out.

sudo ufw allow OpenSSH

We also allowed HTTP and HTTPS for the web proxy that we would configure later.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Then we enabled the firewall.

sudo ufw enable
sudo ufw status verbose

The important part was the default policy:

Default: deny (incoming), allow (outgoing)

Incoming connections are denied unless a rule allows them.

We did not open port 8080 to the public Internet. Later, the game server would listen only on the local loopback interface.

This is an important security principle: only expose the services that actually need public access.

Adding protection against SSH attacks

Public servers often receive automated SSH login attempts. These attempts do not necessarily mean that someone is specifically targeting your project.

We installed Fail2ban to help block repeated failed login attempts.

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

We checked that the SSH protection was active.

sudo fail2ban-client status sshd

The output showed that the SSH jail was running and had already banned several IP addresses.

Fail2ban does not replace strong authentication, but it provides another layer of protection.

Enabling automatic security updates

A server needs maintenance even when nobody is actively working on it.

We checked the automatic update service.

sudo systemctl is-active unattended-upgrades

The expected result was:

active

We also confirmed that the automatic update settings were enabled.

Automatic security updates help keep the operating system protected. However, they do not replace regular maintenance or application updates.

What about SSH keys?

For this initial setup, we kept password-based SSH access because we were working from a computer that was not our own.

We deliberately postponed switching to SSH key-only authentication until we could configure a trusted personal computer.

This matters because disabling password authentication before verifying key access can lock you out of your server.

Before making that change, you should create and test a key, open a second SSH session using it, and only then consider disabling password login.

Summary

We prepared the VPS with system updates, a restrictive firewall, Fail2ban, and automatic security updates.

The server was still not ready for public game traffic. We had secured the foundation, but we still needed to deploy the application and put a secure HTTPS proxy in front of it.

In the next lesson, we will deploy the Node.js game server and make it run automatically as a system service.