BeamMP Keymaster: creating and managing auth keys

The BeamMP Keymaster at keymaster.beammp.com is where server auth keys come from. You sign in with Discord, open Keys, press the green +, give the key a label, and copy the 36-character string into AuthKey under [General] in ServerConfig.toml. One key runs one server at a time, your account only gets a handful, and a BeamMP server with an empty AuthKey will not start at all - private or not. Most of the problems people have with BeamMP keys come down to three things: a key that was never pasted, a key pasted with a stray space or into the wrong line, and one key shared between two servers.

This guide covers the Keymaster itself and everything around the key. Installing the server, the rest of ServerConfig.toml, maps and mods are in the BeamMP server guide; scripting is in BeamMP Lua plugins and races.

What the auth key actually does#

A BeamMP server is not a standalone island. While it runs, it sends a heartbeat to the BeamMP backend over HTTPS - its name, map, player count, version and player list - and the key travels with every heartbeat as the server's identity. The backend answers with a status, and the server logs whether it was accepted. That is how a server gets into the in-game server list, and how the backend knows which account a server belongs to.

Three consequences follow from that design, and they are worth having in your head before you touch anything:

• The key belongs to an account, not to a machine or a host. It is created under your Discord login. A host cannot generate one for you; any provider will ask you to paste yours, because there is no other legitimate way to get one.
• The server needs outbound HTTPS. The heartbeat goes out on port 443. A server behind a firewall that blocks outbound traffic will start, but never authenticate, and never appear in the list.
• The key is a credential. Anyone who has it can run a server that the backend believes is yours. The BeamMP documentation says it plainly: treat it like a password and never show it to anyone.

Signing in to the Keymaster#

The Keymaster uses Discord for sign-in. BeamMP states the reason as spam prevention: tying keys to a Discord account makes it expensive to create thousands of junk servers. It is worth joining the BeamMP Discord server too - support, including the route for a compromised key, runs through it.

A few things that catch people out at this step:

• The Discord account is the owner. Keys created under one Discord account are not visible from another. If a club runs its servers, decide which account owns the keys before you create them, and make it one that will still exist in two years - not a member who might leave.
• Your Discord security is your key security. Somebody who gets into that Discord account can see and delete every key you own. Turn on two-factor authentication in Discord; the reasoning in two-factor on your panel account applies to any account that holds credentials for a server.
• The BeamMP forum account is a separate login. Donation perks are matched using the email on your forum account and the Discord account linked on Patreon, which matters for the key limits below.

Creating a key step by step#

1. Open keymaster.beammp.com and sign in with Discord.
2. Click Keys in the menu on the left.
3. Click the green + button in the top right.
4. Enter a Server Name. This is only the key's label inside the Keymaster - it is not the name players see. That comes from Name in ServerConfig.toml.
5. Click Create.
6. Copy the value in the Key field with the clipboard icon to its right.

Use the clipboard icon rather than selecting the text by hand. Hand-selection is how a trailing space or a missing last character ends up in the config, and both give you a server that starts but never authenticates.

Name the key after where it will live: cruise-de-prod, drift-test, league-season-3. When you have three keys and need to revoke the one that leaked, a label that tells you which server it belongs to saves you from guessing - and from taking the wrong server off the list on a race night.

The key itself is a UUID: 36 characters, five groups of hexadecimal separated by hyphens. That length is a useful sanity check, because the server checks it too.

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

How many keys you get#

Every account has a limited number of keys, and every key can run exactly one server at a time. The free allowance is small - hosting providers' guides consistently describe it as two keys per Discord account - and the exact number is shown in the Keymaster when you reach it, which is the place to check because the policy is BeamMP's to change.

Extra keys come from supporting the project. The official player FAQ states the rates:

Both routes also grant early-access perks. For the keys to arrive, your Patreon account must be linked to the same Discord account you use on the Keymaster, and the email on Patreon should match the one on your BeamMP forum account. BeamMP says syncing can take a few hours and sometimes up to 12; if nothing has arrived after that, their support is the next step, not a second donation.

Before paying for more keys, look at whether you need them:

• A test server does not need its own permanent key if it never runs at the same time as the live one. It does, however, need to stop before the live server starts, or one of them will be refused.
• Old keys for servers you shut down still count. Delete them. A dead key in your list is a slot you are not using and a credential that could still be abused.
• One key per running server is the rule, not one key per machine. Two BeamMP servers on one box need two keys.

Where the key goes#

The key lives in one line of ServerConfig.toml, under [General], in quotes because it is a TOML string:

[General]Port = 30814AuthKey = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"Private = falseName = "Sunday Night Cruise"

On first start the server writes a fresh ServerConfig.toml with a comment pointing at the Keymaster and an empty AuthKey, then stops. That is expected: fill the key in and start again. The file layout and every other key are in the server guide.

Environment variables instead of the file

Current 3.x server builds also read the key from the environment. If BEAMMP_AUTH_KEY is set and not empty, it overrides whatever is in the file; BEAMMP_PRIVATE does the same for Private, and is treated as true only when it is 1 or true.

$ export BEAMMP_AUTH_KEY="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"$ export BEAMMP_PRIVATE=false$ ./BeamMP-Server

This is the better pattern for containers and for anyone who keeps the config file in Git: the file can be committed and shared, and the secret stays out of it. Environment variables and secrets covers why that separation is worth the small extra effort. The one trap is precedence - if the variable is set, editing AuthKey in the file does nothing, which looks very much like the server ignoring you. Older server versions predate these variables, so check the release notes for the build you run before relying on them.

On a hosted panel

On a panel-based host the key is usually a field rather than a line you type into the file, and the panel writes it into the config or the environment for you. On RE:NODE, BeamMP is one of the games that needs a credential of your own: the server is built as soon as payment clears and the install waits on the Setup tab until you paste the key there, which is also where you go to replace it later.

Private and public servers#

Private decides whether the server is advertised, not whether it needs a key. The server refuses to start with an empty AuthKey regardless of Private, so even a server for four friends needs a key from the Keymaster.

Two details matter more than they look:

• `Private = true` is not a password. It keeps the server out of the list. Anyone who knows the address and port can still connect. Real access control is a Lua check in onPlayerAuth; the plugins guide shows how, and whitelist vs password explains why an identifier list beats a shared secret anyway.
• Private mode silences the authentication messages. In current builds a private server still sends heartbeats, but it does not print the "Authenticated" line, the refusal reason or the warning about an unreachable backend. A private server with a bad key therefore looks perfectly healthy in the console. If you are testing a key, test it with Private = false first, read the result, and then make the server private.

Managing, rotating and revoking keys#

The Keys page is the whole management interface: your keys, their labels, the value of each, and the option to delete one. Deleting a key is how you revoke it. Once it is gone the backend no longer recognises it: a server started with it will be refused, and one already running under it should not be expected to stay listed. Treat a deleted key as dead everywhere at once.

Rotate a key when it has been exposed - pasted in a Discord channel, visible in a screenshot or stream, committed to a public repository, or held by an admin who has since left. The order matters, because you do not want the server unlisted for longer than a restart:

1. Create a new key in the Keymaster and give it a clear label.
2. Replace AuthKey in ServerConfig.toml (or the panel field, or BEAMMP_AUTH_KEY) with the new value.
3. Restart the server and confirm the "Authenticated" line in the console.
4. Delete the old key in the Keymaster.

You need one free slot for step 1. If every slot is in use, you have to delete the old key first and accept a short gap. If you believe a key has been abused rather than merely exposed - a server you do not recognise appearing under your name, for example - BeamMP asks you to open an Account Support ticket through their Discord as well as deleting the key.

Keep the key out of the places that leak: support tickets to third parties, screenshots of the config editor, shared config templates, and Git history. If somebody on your team needs to edit the server, give them file access without giving them the Discord account; subusers and least privilege is the general principle. And keep a backup of ServerConfig.toml that does not travel with the key in plain sight - backups that actually restore is about the rest of that habit.

Errors from a bad, missing or reused key#

Every key problem shows up in the server console within the first heartbeat, if you are looking. These are the messages current 3.x builds print, and what each one means:

Message wording shifts a little between releases, so search the console for AuthKey, Authenticated and REFUSED rather than for an exact sentence. Reading the console has the habits that make this quick.

The server stops straight after starting

The key is empty. Either the file was never saved, the key was pasted into a comment line, or you edited a different ServerConfig.toml from the one the server reads - easy to do when an old copy sits in a backup folder next to it. Open the file the server actually loads and check the line under [General].

The wrong-length warning

The value is not a 36-character UUID. The usual causes are a leading or trailing space, a missing final character from hand-selection, quotes pasted inside the quotes, or a Discord message ID copied by mistake. The server keeps running after this warning, so it is easy to scroll past; it will then be refused by the backend.

"Backend REFUSED the auth key"

The backend saw the key and rejected it. The reason after the colon comes from BeamMP, so read it before guessing. In practice it is one of three things: the key was deleted in the Keymaster, it was mistyped in a way that still has the right length, or it is already in use by another running server. The fix for the last one is a key per server - a test copy left running on a home PC is the classic culprit.

"Backend failed to respond to a heartbeat"

This is a network problem, not a key problem. The server could not reach the backend over HTTPS, so it never got an answer either way. Check that outbound traffic on port 443 is allowed, that DNS resolves on the machine, and whether BeamMP's backend is having a bad day. Direct connections still work while this is happening; only the list is affected.

Running, authenticated, but not in the list

Check Private first - it is the most common cause by a distance. Then give the list a minute or two to refresh. If you still cannot see it, connect directly by address and port: if that works, the key and the server are fine and the issue is listing or filtering in the client. If players cannot connect at all, that is a port problem on 30814 TCP and UDP, covered in game server ports explained, not anything the Keymaster can fix.

FAQ#

Is the BeamMP Keymaster free?

Yes. Every Discord account gets a small allowance of keys at no cost, which is enough for most people running one or two servers. More keys come with donations or a Discord boost, at the rates in the official FAQ.

Can two servers share one auth key?

No. A key can be used by one running server at a time, and the backend refuses the other. Two servers, including a test copy, need two keys - or the test copy has to be stopped while the real one runs.

Do I need an auth key for a private server?

Yes. The server will not start with an empty AuthKey, whatever Private is set to. Private mode only keeps it out of the public list, and it also hides authentication messages, so verify the key with the server public first.

What happens to my server if I delete its key?

The process does not crash and players already on it are not kicked, but the key is no longer valid with the backend: expect the server to lose its place in the list, and to be refused on its next start. Paste a new key and restart to bring it back properly.

Can I move a key to a different host?

Yes. The key belongs to your account, not to the machine, so moving a server is a matter of copying the key into the new config and shutting the old server down first. If both run at once, one is refused.

Can somebody else create the key for my server?

They can create one under their own Discord account, but then they own it and can delete it whenever they like. For a server you are responsible for, create the key yourself and paste it in yourself.