Before you start
Keep the delivery credentials from your client area and verify console access before sensitive changes. Identify game files, databases, dependencies and a separate backup destination. Tools discussed here are not promised as preinstalled with the VPS.
Protect access before sharing it
SSH uses the delivered port, defaulting to 22 on the relevant offers. Use unique secrets and protect private keys. Do not share the root account with every community member. Ubuntu’s OpenSSH documentation covers keys and configuration. Apply a method suitable for your distribution rather than copying an unverified configuration file. Check a second connection before ending the session that lets you recover access.
Separate administration and game processes
Root administers the VM. A game process can use a limited service account with separate directories and secrets. Give collaborators only the access their tasks require. Protect RCON, SQL and panel credentials as carefully as the system password. Different ports are not authentication, and public interfaces still need access control. Installing another panel creates another application to secure and maintain.
Plan updates at each layer
Track Linux, runtimes and game software separately. A new FXServer artifact or mod update may require changes. Back up first, read requirements and test on a copy where possible. Do not assume every extension immediately supports a new game version. Tell the community when downtime is needed. Keep a record of what changed so rollback is based on a known state rather than guesswork.
Define what a backup contains
A useful copy includes worlds, configuration, persistent data, custom extensions and associated databases. An SQL export must match the state of the files. Use documented game facilities or a period without writes where necessary. Copying files during database changes is not automatically recoverable. Record software versions and dependencies needed for a restart, while keeping access secrets encrypted or separately protected.
Keep an independent copy and test it
A backup stored only on the VM disk shares that VM’s risks. Plan a separate destination, limited permissions and retention suited to the rate of change. Test restoration in isolation: extracting an archive alone is insufficient. Check that the world loads, the database matches and administration works. Avoid accidentally publishing a second live copy while testing; recoverability is the goal, not an unplanned duplicate server.
Put network protection in context
Peeryx acts upstream on network attacks within the actual service scope. Advertised global capacity is not reserved VPS throughput or a guarantee against every attack. It does not repair a vulnerable plugin or leaked password. Combine network protection with access control, updates, monitoring and backups. Consider hosting with a game panel if administering Linux is not work you want to take on.
For your situation
| Situation | Next check |
|---|---|
| A collaborator needs server access | Provide task-appropriate limited access instead of sharing root and every secret. |
| A world update is planned | Back up files and databases at a matching state, then verify rollback. |
| Your only backup is inside the VM | Prepare an independent copy and a restore test before you need them. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.