Before you start
You need Linux administration skills and must check each game’s conditions. Inventory every instance, its version, dependencies, persistent files and listening ports. This Gaming VPS does not preinstall games, Docker or a multi-server control panel.
Add resource requirements, not player counts
For each game, record observed memory use, CPU peaks and actual storage. Include the operating system, databases and monitoring. More vCPUs do not remove an expensive simulation loop or blocking script. A Rust world and a small community tool do not deserve the same allowance just because each counts as one instance. Begin with the publisher’s requirements and measure representative activity.
Allocate ports to services
Every listener needs an address, protocol and port combination that works alongside other services. Separate gameplay, query, RCON and administration endpoints. Rust documentation distinguishes UDP and TCP ports; txAdmin has its own configurable port. Never copy a network example without checking existing listeners and your access rules. A second public IP is not required merely because a second process exists.
Separate data and permissions
Use suitable service accounts and directories instead of mixing all worlds in one folder. Root access administers the VM; games can run as less privileged users. Avoid sharing secrets between instances. Optional containers still need resource limits, persistent volumes and maintenance. They are not magical isolation or a preinstalled feature, and do not create extra CPU, RAM or disk space.
Monitor the shared limits
All instances use the resources of the same VPS. Updates, compression and concurrent restarts can create peaks even when average use looks low. Observe memory, CPU and file growth during representative activity. Network speed is also shared across that VPS’s IP addresses. Adding an address does not automatically multiply bandwidth or improve game performance. Monitor before deciding what to expand.
Prepare consistent backups
Keep worlds, configuration and associated databases at a matching state. Some applications must pause writes or provide a consistent export. A world copy without its SQL database may not be usable. Keep a copy outside the VM, protect credentials and test restoration in isolation before relying on that backup for a real incident. A snapshot is not automatically an independent off-server backup.
Know when to split the project
Separate VPSs may simplify operations when applications must restart independently or have incompatible requirements. If combined needs exceed published plans, discuss the project without assuming custom capacity exists. The selector compares catalogue resources and reserves nothing. Game hosting with a panel remains an alternative when Linux administration is not your objective. Check actual availability before planning a migration date.
For your situation
| Situation | Next check |
|---|---|
| Two worlds and a database | Separate files and ports, add resource requirements and prepare matching world/database backups. |
| Several simultaneous restarts | Stagger work where necessary and measure peaks; averages are not sufficient. |
| No configuration matches | Reduce instances or discuss splitting them with support, without assuming available stock. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.