Rotating the secrets a game server accumulates

A game server accumulates credentials the way a desk accumulates paper. An API key here, a database password there, an RCON secret, a webhook URL, a licence key, and none of them is ever changed, because nothing forces the issue and everything works.

Then somebody leaves the staff team, or a config file ends up in a public repository, and the question becomes which of those still matter and who has them.

What a typical server actually holds

More than people expect:

• The database password, usually in plain text in a config the whole staff team can read
• RCON, frequently shared verbally and never changed
• The hosting panel login, often one account used by several people
• API keys for Steam, for a payments provider, for a licence service
• Discord bot tokens and webhook URLs
• SSH keys, including ones belonging to people who left

The backup destination belongs on that list too, and it is the one worth a separate thought: a credential that can delete your archives is a different category of key from one that can read a player count, which is why a write-only backup key is worth the ten minutes it takes to issue.

Six categories, each with a different blast radius, and most servers cannot list them from memory.

The inventory is the whole job

Before rotating anything, write down what exists. Where it lives, what it grants, and who has seen it.

That document is uncomfortable to produce and is most of the value. Nearly everyone discovers at least one credential that a former staff member still holds and one they cannot remember creating.

Keep it somewhere that is not the server. A list of where the keys are, stored next to the keys, is not an improvement.

Rotate on departure, not on a schedule

Calendar rotation is the standard advice and it is weaker than it sounds for a small server: rotating a password every ninety days protects against nothing in particular and gets skipped by month four.

What genuinely matters is rotating on the events that change who should have access:

Somebody leaves the staff team. Every shared credential they held, that day. This is the case rotation exists for, and it is the one most often not done because it feels like an accusation.

A credential is exposed. A config pushed to a repository, a screenshot with a token in it, a paste in a public channel. Rotate immediately and assume it was read.

Ownership of the server changes. Everything, without exception, which is also the moment the inventory above turns a handover into something that can actually be completed rather than an ongoing dependency on the previous owner.

What makes rotation hard, and the fix

Most credentials are hard to rotate because nobody knows what breaks when they change. The database password is in the framework config, and also in a backup script, and also in a monitoring check that somebody set up two years ago.

The fix is not better documentation of where each one is copied. It is to stop copying: one file holding the secrets, read by everything that needs them, excluded from version control. Then rotation is a single edit.

Getting there is an afternoon of work on an existing server and ten minutes on a new one, which is why it is worth doing early — the same asymmetry as everything else about security basics.

The ones that cannot be rotated

Some cannot. A licence key tied to an identity, a payment method, a domain registration. These are not secrets to rotate but assets to control, and the relevant question is not who knows them but who can change them.

For those, the protection is that more than one trusted person has legitimate access, because the alternative is a server that ends when one person becomes unreachable, which is the single most common way a community actually dies.

The ones people forget exist

The list everybody thinks of is the RCON password and the database user. The ones that go unrotated for years are less visible and frequently more dangerous.

The webhook URL. A Discord webhook is a credential in the shape of a link: anybody holding it can post as your server, forever, with no authentication step. They end up in config files, in screenshots, and in repositories, and revoking one means deleting the webhook rather than changing a password.

The API key for the panel. Frequently issued once during setup, scoped to everything, and never looked at again. It outlives staff departures silently.

The key on the backup destination. This one is worth checking specifically, because the whole point of an off-site backup is that it survives a compromise of the server, and a write-capable key stored in plain text on that server defeats the arrangement entirely.

Anything a departed admin knew. Not a credential in itself, but the reason rotation has a schedule. A password that three former staff members remember is not a secret, whatever it looks like in the config.

The thirty-minute version

List what exists. Move the secrets into one file that is not in version control. Rotate anything a departed staff member held. Note who holds what, somewhere off the server.

None of that prevents a determined attacker. What it prevents is the ordinary case (a credential from three years ago, held by somebody who has not been involved since, still working), which is how most small servers are actually compromised, and it is far more common than anything in the dramatic threat models people worry about instead.