VDS for game servers and databases: what to know
Game servers and databases share one trait: they react badly to hiccups. A short CPU stall means a lag spike for players or a slow query for users. That is why they are classic VDS workloads. Commands target Ubuntu and Debian and may vary elsewhere.
Game servers
- Many games lean on one fast core, so check the clock speed
- Pick a location near your players: India, Singapore, Germany, the US or Canada
- Keep the server in a screen or tmux session, or use systemd so it restarts
- Open only the game's ports with sudo ufw allow PORT/udp or tcp as the game requires
- Leave RAM free for the system rather than giving the game everything
Run it under a dedicated user such as gameuser, never root. For a quick persistent session, tmux new -s game starts one and tmux attach -t game returns to it.
Databases
- RAM matters because databases cache data in memory
- Fast storage and steady CPU keep queries predictable
- Bind to localhost with bind-address = 127.0.0.1 unless remote access is needed
- Do not open the database port to the whole internet
- Dump regularly with mysqldump or pg_dump
Watch the right numbers
- htop for CPU and memory
- iostat -x 5 from the sysstat package for disk activity
- df -h for space
- free -h for memory
Setup order
- Update the system
- Create a non-root user
- Enable the firewall
- Install the game or database
- Set it to start at boot with systemctl enable
- Make a backup before and after major changes
Protection
DDoS protection comes with all Tabi Cloud plans, which is especially useful for public game servers. Still keep software updated and use strong credentials.
Tips
- Test performance with real players before launch
- Schedule restarts in quiet hours
- Keep config files in version control or a backup
- Upgrade the plan when usage shows a steady rise, which you can do any time
Need advice on a particular game? Open a ticket on our Discord.