Running a test game server beside production

A test server is a second, smaller copy of your game server - same game version, same mods, a recent copy of the world - with a different name, its own passwords and tokens, and no way for players to stumble into it. Every game update, mod update and risky config change goes there first; only when it starts, loads the world and survives an hour of you poking at it does the same change go to the real server. For a modded server it is the difference between finding a broken mod at your desk on Tuesday afternoon and finding it on Friday evening with forty people in Discord asking what happened. It costs one extra small plan, and it can sit stopped most of the month.

This post is the game-server version of the idea. The general principles of staging environments - mostly written for web apps - are in staging and production on one account. Here the concerns are game-specific: world copies, mod parity on clients, tokens that only one server may use at a time, and the shared databases that make a test server quietly change the real one.

What a test server catches, and what it does not#

Be clear about what you are buying, because a test server is excellent at some things and useless at others.

It reliably catches:

• Mods that break on a game update. The commonest reason a modded server goes down, and the easiest to catch: update the test server, start it, read the log.
• World conversion problems. Major game updates convert the save on first load. Doing that to a copy first tells you whether it works and how long it takes.
• Config mistakes. A typo in a YAML file, a missing bracket in an INI, a setting that does not do what the documentation implied.
• Plugin and mod conflicts. Two plugins fighting over the same event or command show up as soon as both load.
• Procedures. How long the update actually takes, which files need copying, what order things go in. You find out with nobody watching.

It does not catch:

• Load problems. Two testers do not reproduce forty players. A change that only lags under load will pass every test.
• Timing and luck. Crashes that need a particular combination of events - a raid during a save during a restart - are rare on a quiet server.
• Player behaviour. The exploit somebody finds in the first hour of a new mod.

A test server reduces surprises; it does not remove them. Keep a backup before every production change regardless, as game server backup strategy describes.

Sizing and cost#

A test server does not need to match production. It needs enough memory to load the same world and mods, and very little CPU, because nobody plays on it.

On RE:NODE the smallest game plans start from $3 a month for the lightest games and more for heavy ones (each game's page under game servers has current prices), every plan has the same panel, and nothing is gated by tier, so a small test server has the same console, files, schedules and backups as the big one. A server you only start when testing still costs its monthly price - there is no per-hour billing - so the saving comes from choosing a small tier, not from keeping it stopped.

The alternative, for a light change, is no second server at all: take a locked backup, try the change on production during a quiet hour, and restore if it fails. That is a legitimate approach for a small group. It stops being one when the server is busy, when the change touches dozens of mods, or when a failed update takes more than a few minutes to undo.

Setting it up: copy production, then change it on purpose#

The fastest way to make a faithful copy is from a backup of the real server:

1. Take a backup of production, ideally after a save command so the world is consistent.
2. Download it from the panel.
3. On the new server, upload the archive through the file manager and unpack it in place, or upload the folders over SFTP. SFTP and the file manager covers both.
4. Set the startup variables to match production: game version or branch, memory flags, mod list parameters.
5. Before the first start, make the changes in the next section. A test server that starts with production's identity can announce itself in the public server list, take over production's token, or write into production's database.

Then start it, confirm it loads the copied world (the log names the world it loaded), and stop it again.

What must be different#

This is the part that matters most, because a careless copy causes real damage.

Some of these deserve more detail.

Listing. Valheim has -public 0; Source games take sv_password; Minecraft can stay out of server lists by not being advertised and by setting enable-status=false in server.properties, which stops it answering list pings; most Steam games hide from the browser when passworded or set to private in their own config. A password is the minimum everywhere.

Steam tokens. Counter-Strike 2, Garry's Mod, Team Fortress 2 and others use a game server login token (GSLT). A token can be in use by one server at a time, so a test server started with production's token can knock the real server offline or fail to register itself. Create a second token for the test server; Steam game server tokens covers how.

Databases. This is the dangerous one. Minecraft plugins such as LuckPerms, CoreProtect and economy plugins can be configured for a shared database; FiveM frameworks keep everything in one through oxmysql; Garry's Mod DarkRP can use an external database. A test server copied with the same connection settings is connected to the real data. Promote a test player to admin and you have promoted them on production. Give the test server its own database - on RE:NODE each game plan includes a database slot, created in the panel with its own host, user and password - and restore a copy of production's data into it. Database backups and restores covers the dump and restore.

Discord. A copied DiscordSRV config or webhook URL posts the test server's chat, deaths and console into your community's real channels. Point it at a private test channel or disable it.

Keeping clients in step#

A test server for a game where clients also need mods - most Minecraft modpacks, Valheim with gameplay mods, RimWorld multiplayer - is only useful if the people testing have a client with exactly the test server's mod set. That means two client profiles on the tester's machine:

• Minecraft: separate instances in Prism Launcher, the CurseForge app or the Modrinth app, one per server.
• Valheim: separate profiles in a mod manager such as r2modman or Gale.
• Steam Workshop games: harder, because Workshop subscriptions are per account. Testing a Workshop mod update usually means testing with the updated mods and accepting that production follows soon after.

Without separate profiles, a tester who updates their client for the test server cannot join production until it is updated too, which is exactly the coupling you were trying to avoid.

The update-day procedure#

With a test server in place, a game or mod update looks like this:

1. Refresh the test server from production if it is more than a week stale. Testing against last month's world misses this month's problems.
2. Apply the update to the test server only: the game update, then the mod updates that match it. For Steam games that means running the update on the test server while production stays on the old build, or switching the test server to the developer's beta branch ahead of release where one exists. SteamCMD explained covers -beta.
3. Start it and read the log from top to bottom: every mod loaded, no exceptions, the world loaded under its real name.
4. Join and test what changed: the mod that updated, the area most likely to break, a save and a restart.
5. Write down exactly what you changed: file names, versions, config keys. This is the list you will apply to production.
6. Take a locked backup of production.
7. Apply the list to production during a quiet hour, start it, and read the log the same way.

The update day as a whole - patch notes, mod authors, announcements - is covered in the game server update day checklist.

Stopping the two from drifting apart#

A test server is only useful while it matches production. It drifts in predictable ways: someone hot-fixes production directly during an outage, someone tries a mod on test and never removes it, the game updates on one and not the other.

Three habits prevent it:

• One change list. Every change goes into a single dated log - in a text file in the server's root, a pinned Discord message, a git repository of configs. If it was not in the list, it did not happen.
• Refresh rather than repair. When test has drifted, do not fix it file by file. Download a fresh backup of production and rebuild the test server from it, then re-apply the identity changes from the table above.
• Keep a version manifest. A file listing the game build, the mod loader version and each mod's version, kept on both servers. Comparing two manifests takes a minute; comparing two mod folders by eye takes an hour.

game        Valheim <build> (public branch)loader      BepInExPack_Valheim <version>mods        Jotunn <version>            PlantEverything <version>updated     2026-10-04 by Mira - PlantEverything <old> -> <new>

Fill in the real build and version numbers from the startup log and each mod's page.

Who gets access to the test server#

A test server is the right place to be generous with access. A developer who would never get file access on production can have full access to test - files, SFTP, console, schedules - because the worst outcome is rebuilding it from a backup. On RE:NODE that is a separate grant on a separate server: give a team full permissions on the test server and console-only, or nothing, on production. Subusers and least privilege covers designing the roles.

The one thing a test server must never have is production's secrets. If someone with test access can read a config containing the production RCON password, the production database password or the live Discord bot token, the separation is decorative.

FAQ#

Do I really need a test server for a small group?

For a vanilla server or a handful of server-side plugins, usually not. A locked backup before each change and a quiet hour to try it is enough. A test server pays for itself once the mod list is long, the world is precious, or more than a handful of people depend on the server being up.

Can the test server use the same Steam token as production?

No. A game server login token can be used by one server at a time, so the two would knock each other offline. Create a second token for the test server.

Can I run the test server on the same plan as production?

Not on a game panel, where each plan is one server with its own limits. On a VDS you can run both, as two folders, two ports and ideally two users, at the cost of them sharing the machine's memory and CPU.

How often should I refresh the test copy?

Before each significant test, if the copy is more than a week or two old. A test run against a stale world misses problems in whatever players built since.

Should I copy the tested world back to production?

No. Copy the changed files - mods, configs - and leave production's world alone. The test world is older and contains your test edits; copying it back rolls players back.