Staging and production on one hosting account

Run a second, smaller server with the same software versions, a recent copy of the real data with the personal parts scrambled, and its own credentials that reach nothing real. Deploy there first, every time, and never edit it by hand to make a test pass. That is a staging environment, and on a panel it costs one extra small plan - from $4 a month on the app lines at the time of writing - which is less than one bad evening on the live one.

Testing an update on the live server is normal right up until the evening it is not. The value of staging is not that it finds bugs, because it mostly will not. The value is that it is the only place where an upgrade can fail with nobody watching, and that it forces you to write down what "deploying" actually consists of.

What a staging server is for, and what it is not#

Be precise about the job, because a vague staging server is one you stop using within a month.

It is a rehearsal of the deploy, not a rehearsal of the code. The code was tested on your laptop. What has never been tested is this specific sequence: this version of the runtime, these config files, this migration, against data shaped like the real thing, on a machine with this much memory. That sequence is what breaks, and it is exactly what a laptop cannot reproduce.

It is where version upgrades go first. A new game version, a new Java, a new plugin, a new database major version. Anything where the failure mode is "the world opens and is quietly changed" belongs on a copy before it touches the original.

It is not a development machine. If people are editing files directly on staging, it has stopped being a mirror of production and become a second production with worse uptime. Changes arrive by the same route they will arrive on production, or the test proved nothing.

It is not a performance test. One small server with three testers on it will not tell you how forty players behave. Say that out loud once so nobody expects it to.

Copy this, exactly#

The point of staging is sameness, so the list of things to copy is short and unforgiving:

• Every version number. Game or runtime version, and the exact build. "Paper 1.21.1" is not a version, paper-1.21.1-132 is. For an app, that means the same Node or Python minor version and an install from the lockfile rather than from the range in package.json. The difference between npm ci and npm install is precisely the difference between a staging server that mirrors production and one that mirrors a moment in time - npm ci vs npm install is the long version.
• Every mod, plugin or dependency, at the same version, in the same load order.
• The configuration files, minus anything containing a credential. Same tick settings, same view distance, same worker count, same memory flags where they are compatible with the smaller plan.
• A recent copy of the world or database, so the test runs against real data shapes: the 900-plugin-table database, the base with 40,000 blocks, the player with an inventory full of edge cases. Synthetic data tests nothing interesting.
• The startup command and its arguments, which on a panel means the Startup tab fields, and which is where half of all "works on staging" mysteries actually live.

The fastest way to get a truthful copy is a backup. Take one on production, download it, upload it to staging and unpack it in place. That has the pleasant side effect of exercising your restore path on a schedule - see testing a restore before you need it for why that matters more than having the backup at all.

Deliberately differ this#

Separate credentials, separate database, and no connection to anything that sends messages to real people. A staging server that can email your users, or write to your production database, is a production server with a misleading name. Concretely:

Two of these deserve more than a table row.

The database. The most common catastrophic mistake in this whole area is a staging deploy that still has production's connection string in an environment variable somebody forgot to override, and a migration that then runs against the live data. The defence is not care, it is arrangement: give staging its own database from the start, and make the production credentials unreachable from the staging server entirely. Different user, different password, and if the database is reachable over the network, restrict by address. Environment variables and secrets covers the mechanics of keeping two sets apart.

The personal data. A copy of production data is a copy of your users' data, sitting on a server with looser access. Scrub it as part of the import, not later:

UPDATE users SET  email = 'user' || id || '@example.invalid',  phone = NULL,  password_hash = '$2y$12$notarealhashnotarealhashnotarealhash1234567890ab';DELETE FROM sessions;DELETE FROM api_tokens;UPDATE payment_methods SET last4 = '0000', token = NULL;

Run that inside the same transaction as the restore if you can, so there is never a moment where a full copy exists unscrubbed. For a game server the equivalent is smaller but real: strip the staff list down to yourself, blank any Discord webhook URLs in plugin configs, and remove any stored payment or Tebex keys.

Sizing the second server#

Smaller is the point - it is why staging is affordable - but three kinds of "smaller" invalidate the test, and it is worth knowing which.

Safe to shrink: disk, as long as the data copy fits; the number of allocated ports; backup slots; and CPU, which will make things slower without changing behaviour.

Not safe to shrink: memory, when the thing you are testing is memory-related. A modpack that needs 6 GB will not start on 2 GB, and "it crashed on staging" then tells you nothing. Worker counts, if you reduce them, will hide every concurrency bug. And any hard limit you are near on production - a connection pool size, a heap ceiling - has to be the same number or the test is measuring a different system. Connection pools and limits is the usual place that bites.

A sensible default for an app is the same plan one tier down: same runtime, half the memory, and the same environment variables except the ones that must differ. For a game server, match the memory and cut the disk, because memory is what the test is usually about. RE:NODE's app, web and database lines all get the same panel regardless of tier - console, file manager, SFTP, backup slots, schedules, subusers - so the small staging plan is not a reduced version of the panel, just of the hardware.

Stopping the two from drifting#

Drift is the failure mode that kills staging environments. It happens the same way every time: something breaks on production at 23:00, somebody fixes it by editing a file directly, and nobody makes the same edit on staging. Three weeks later staging says a release is fine and production disagrees, everyone concludes staging is useless, and it gets cancelled.

Three habits keep it honest.

Changes flow one way. Anything that changes production must be able to be applied to staging first, by the same mechanism. On the app lines that mechanism is Git: RE:NODE's deploy is GitHub through a GitHub App with short-lived tokens, so private repositories work, with two switches - pull on every start, and deploy on push. Deploy on push restarts only a server that was already running, which is a useful property for staging: leave it stopped between tests and it picks up everything on next start. Deploy a Node app from GitHub walks through the setup.

Emergency fixes get replayed within a day. Not "when we get round to it". Write it on the incident note: the fix is not finished until it exists in the repository and on staging.

Diff them on a schedule. This is a ten-minute job that finds drift before it embarrasses you. For a game server, compare the plugin list and the config:

$ ls -1 plugins/*.jar | xargs -n1 basename | sort > prod-plugins.txt$ ls -1 plugins/*.jar | xargs -n1 basename | sort > staging-plugins.txt$ diff prod-plugins.txt staging-plugins.txt$ diff <(sort prod-server.properties) <(sort staging-server.properties)

For an app, the equivalent is comparing the lockfile, the runtime version and the list of environment variable names - names only, never values:

$ node --version && cat package-lock.json | head -5$ printenv | cut -d= -f1 | sort > env-names.txt

A difference in the set of variable names is the single best early warning there is. A variable that exists on production and not on staging means the next deploy will start a process that reads undefined and behaves in a way nobody has ever seen.

What staging will not catch#

Say this plainly so nobody builds false confidence on it.

Load. Three people clicking around is not forty players logging in at 19:00. Concurrency bugs, lock contention, connection pool exhaustion and memory growth under sustained traffic are all invisible on an idle staging server.

Data volume. A query that is instant against 400 MB can be a table scan against 40 GB. If the staging copy is a trimmed subset, every performance conclusion from it is wrong. Copy the whole thing, or accept that you are not testing performance.

Time. Slow memory leaks, log directories filling, certificate expiry, cron jobs that only fire on the first of the month. Staging is usually too young and too idle to show any of them.

Third-party behaviour. Sandbox APIs are not the real API. Rate limits, partial outages and payloads with fields the docs do not mention only happen in production.

The one-off. The plugin that reads a file that only exists on production, the DNS record that is different, the firewall rule someone added by hand. These are exactly the drift problem above, which is why the diff routine matters more than the testing does.

Given that list, the honest framing is: staging catches the deploy failing, the migration failing, the config being wrong and the version being incompatible. That is four of the five things that go wrong on a release evening. The fifth is load, and load is what backups and a rollback plan are for.

What a release actually looks like#

The routine below is the deliverable. It is worth writing yours down in the repository even if it is shorter than this one.

1. Merge the change. Staging deploys from the repository, automatically or on your next start.
2. Start staging and read the log from the top. The start-up banner tells you the versions that actually loaded. Compare it with production's.
3. Run the migration on staging first, and time it. A migration that takes 40 seconds on staging against a tenth of the data is a four-minute outage on production unless you write it to avoid locking - migrations without downtime covers the patterns.
4. Smoke test. Six things, the same six every time: log in, do the main action, check the thing the change touched, check one thing it definitely should not have touched, check the admin path, check the log for new warnings.
5. Take a production backup. Before anything, every time. This is the rollback.
6. Deploy the same build to production. Not a rebuild, not "the same commit built again" - the same artefact if you can, the same commit hash at minimum.
7. Watch the first five minutes. New warnings in the log, memory, and the graph. If it is bad, roll back now rather than diagnosing live.
8. Write down anything you did by hand, and replay it onto staging the same day.

For the part where the restart itself is visible to users, zero-downtime deploys on a small server covers closing the gap without a load balancer.

One access note: the people who test do not need billing rights or the ability to delete a server. RE:NODE has subusers, roles and teams with granular permissions - console only, files only, no billing - with time-boxed access and a per-server activity log, which is the right shape for a staging environment that several people poke at. Subusers and least privilege has the split.

FAQ#

Do I really need a staging server for a small community server?

For a vanilla server with five friends, no. The moment you have mods, plugins, a database, or anyone who would be upset by losing an evening, yes. The trigger is not player count, it is how much state would be expensive to lose and how many moving parts a version upgrade touches.

Can staging and production share a database if I am careful?

No. This is the one rule in the post with no exceptions. Shared databases mean a staging migration can destroy production data, and a staging bug can write nonsense that production then serves. Separate instances, separate credentials, and staging must not be able to reach production's at all.

How do I keep staging from being months out of date?

Refresh the data on a schedule rather than on demand - monthly is usually enough - and deploy every change to staging first even when you are confident. The data refresh is a download, an upload and a scrub script, which is a fifteen-minute job you can put in the calendar.

Should staging be the same size as production?

Match memory and any hard limits you are testing against, shrink the rest. Half the CPU makes staging slower, which is harmless. Half the memory changes behaviour, which is not, especially for a modded game server or a JVM where the heap size is the thing being tested.

Is it worth paying for a second server just to test?

Compare it with the cost of the alternative once. A small app or game plan is a few dollars a month, and longer terms are cheaper per month. One lost evening, one corrupted world, or one migration that ran against live data costs more than a year of the second server. There is no free tier here, so it is a real cost, just a small one.

Can I use the same staging server for several projects?

Yes, if they are not running at the same time and you are disciplined about cleaning between them. It is worse than one each, because the leftovers from the last project are exactly the kind of difference that makes a test lie, but it is far better than no staging at all.