Game server whitelist applications

A whitelist application is a short form a player fills in before they are allowed to join, plus a person who reads it and adds them to the server's whitelist. It is worth running when your problem is people who join, cause trouble or leave within a day; it is not worth running when your problem is nobody joining at all. A good form asks five to eight questions that reveal effort and fit - their in-game name, how they found you, what they want to do on the server, a question only someone who read the rules can answer - and nothing personal you do not need. Vetting is a quick identity check, a look for obvious red flags, and a decision within a day or two. Then one console command adds them, and the same command removes them.

Rules and moderation are covered in server rules, moderation and staff, and the Minecraft whitelist mechanics in depth in Minecraft whitelist and permissions. This post is about the application itself.

When an application is worth the friction#

Every step between "I found this server" and "I am playing" loses people. An application loses a lot of them, on purpose. The question is whether the ones it loses are the ones you wanted to lose.

An application does three things beyond keeping strangers out. It makes the player read your rules, because the form asks about them. It creates a record linking an in-game account to a Discord account, which makes bans stick and ban evasion visible. And it sets expectations: someone who wrote a paragraph about what they want to build has made a small investment in staying.

The cost is that your top of funnel shrinks. A whitelisted server grows slower and keeps more of the people it gets. If players join and stay already, you do not need one. If most of your moderation time goes on people who joined an hour ago, you do.

Questions that actually filter#

Each question should either verify something, reveal fit, or show effort. Cut anything that does none of those.

The rules question is the most useful line on the form. Pick a rule that is specific to your server and not guessable - "what is the minimum distance between bases" rather than "is griefing allowed" - so the answer proves they opened the rules page. For roleplay servers, a short character backstory serves the same purpose and also shows whether they can write in character; starting a roleplay server covers RP-specific questions.

Keep it under ten questions and under ten minutes. A form that takes half an hour filters for free time, not for quality.

What not to ask

Do not ask for anything you do not need to decide or to whitelist them. In particular:

• Real name, address, school, photos. You have no use for them and you would be holding personal data you must then protect.
• Exact date of birth. If you need an age threshold - for an adults-only community, or because Discord's minimum age applies - ask "are you 18 or older?" or the threshold you need, not the date.
• Passwords or account access, ever, for any reason.
• Social media profiles, unless the server is genuinely built around content creation.

If your community is in the EU, or the server is, data-protection rules apply to what you collect, even as a hobby. Game server privacy and player data covers the basics; the short version is collect less, delete it when you are done, and do not share it.

Where the form lives#

For most communities, a Discord-based flow wins: the applicant joins the Discord, clicks a button or opens a ticket, answers, and a staff member approves with a click that also grants a "Whitelisted" role. That role then becomes useful in other places - access to member channels, and on some games the whitelist itself. FiveM's txAdmin can whitelist by Discord role directly, so approval in Discord is the whitelist; Discord permissions and whitelist on FiveM covers it. Discord setup for a game server covers roles and bot permissions.

A spreadsheet-based form is fine for a small server and has one advantage: the record survives if the Discord goes wrong. Either way, keep a simple log of who was approved, when, and by whom.

Vetting: what to check, quickly#

Most applications take a minute to judge. The checks, in order:

1. The account exists. For Minecraft, look up the name to confirm it is a real account and note its UUID - names can change, UUIDs do not. For Steam games, ask for a profile link and note the 17-digit SteamID64.
2. The answers are real. Copy-pasted, one-word or obviously generated answers are a no. Short is fine; empty is not.
3. The rules question is right.
4. No known history. If the game has public ban trackers or your community shares a ban list with others, check it. BattleMetrics shows ban history for many Steam survival games where servers publish it; global ban systems for communities covers shared lists.
5. Discord account age and behaviour. A Discord account created yesterday is not a disqualification, but combined with a weak application it is a reason to ask a follow-up question.

Red flags that justify a no or a follow-up: answers that mention wanting to "test" the server or its plugins, a referral from someone you banned, insistence on being added immediately, and applications that ask for staff or special access before playing.

For serious servers, a short voice interview after a good written application catches things a form cannot. Ten minutes, two staff members, a few questions about the backstory or plans. It also shows the applicant that real people run the server, which is part of why whitelisted communities retain better.

A trial period - a role for the first two weeks with limited permissions, such as no access to valuable areas or claims beyond a small size - is a good alternative to a heavy application. It lets behaviour do the vetting.

Adding approved players, game by game#

The mechanics vary a lot between games. Some have a true account whitelist; some only have a password.

# Minecraft (server.properties: white-list=true, enforce-whitelist=true)whitelist add PlayerNamewhitelist remove PlayerNamewhitelist listfwhitelist add PlayerName    # Floodgate, for Bedrock players via Geyser# Valheim: permittedlist.txt in the save folder, one ID per line76561198012345678# Project Zomboid (servertest.ini: Open=false)/adduser "PlayerName" "theirpassword"# Factorio/whitelist add PlayerName/whitelist enable# Don't Starve Together: whitelist.txt in the cluster folderKU_AbCdEf12

Notes on each:

• Minecraft whitelists by UUID internally, so renaming does not remove someone. enforce-whitelist=true kicks players who are removed while online; without it they stay until they next disconnect. Bedrock players joining through Geyser need Floodgate's own command. Minecraft whitelist and permissions covers the edge cases.
• Valheim becomes allow-list-only as soon as permittedlist.txt contains any ID. On a crossplay server, IDs carry a platform prefix such as Steam_; the Valheim server guide explains which form to use.
• Project Zomboid with Open=false only admits accounts an admin has created; each player gets a username and password. Project Zomboid whitelist and accounts covers the account flow.
• Factorio keeps the list in server-whitelist.json; the commands edit it while the server runs.
• Don't Starve Together whitelist entries are Klei user IDs, and the file also reserves slots for listed players according to whitelist_slots in cluster.ini.
• Terraria with TShock has a whitelist, but it works on IP addresses, which change. A server password plus TShock's account system is usually more practical.
• Games with only a password - Palworld, Satisfactory, Sons of the Forest and many others - cannot whitelist individuals in vanilla. The password is the gate; change it when you remove someone, and keep the application process in Discord so the password is only shared with approved players.

These commands run from the server console, so whoever approves applications needs console access or a bot that has it. On RE:NODE that can be a subuser limited to the console, without file or billing access, and the per-server activity log shows who ran what. Subusers and least privilege has the setup.

Running the queue#

An application that sits unanswered for a week is worse than no application. The applicant has gone to another server.

• Answer within 24-48 hours, and say so on the form. If you cannot, the form is too popular for your staff and should be shorter or open fewer days a week.
• Use templates for accept and reject messages. An accept message includes the address, the version, how to join, and the three most important rules. A reject message is polite, brief, and says when they may reapply.
• Give a reason only if it helps. "Your answers were too short - feel free to reapply with more detail" is useful. A detailed critique invites an argument.
• Set a reapply period, such as two weeks, and stick to it.
• Two staff for borderline cases. One person rejecting someone they dislike is how communities get accused of favouritism.

Track the numbers occasionally: applications per week, approval rate, and how many approved players are still active after a month. If most approved players leave within a week, the form is not filtering for fit. If almost nobody is rejected, it may not be filtering at all.

Handling application data#

Applications are personal data, and on a whitelisted server they accumulate quickly.

• Keep applications only as long as you need them. Rejected applications can usually be deleted after the reapply period; approved ones can be reduced to the ID, Discord name and approval date.
• Restrict who can read them to the staff who process them.
• If a player asks for their data to be deleted, delete it - keeping only what you genuinely need for an active ban.
• Do not publish applications, quote them publicly, or share them with other communities without the applicant's consent.

This is good practice anywhere and an obligation in many places. A hobby community is not exempt from data-protection law simply because nobody is paid.

Removing players#

Removal is the other half of a whitelist, and it should be as routine as adding.

• Leaving the community: remove from the whitelist, remove the Discord role. No drama.
• Inactive for months: a periodic clean-up keeps the list meaningful. Tell people it happens, and let them return through a short re-request rather than a full application.
• Banned: remove from the whitelist and ban, so they cannot rejoin if the whitelist is ever turned off. Record the reason. Handling cheaters and ban lists covers evidence and appeals.

On password-only games, removing someone means changing the password and telling everyone else the new one. That is a good reason to keep the password in a channel only whitelisted members can see.

FAQ#

Does a whitelist application reduce how many players join?

Yes, by design. It filters out people who would leave or cause trouble quickly, so the server grows slower and keeps more of the players it gets. If nobody is joining in the first place, fix discoverability before adding an application.

How many questions should a whitelist application have?

Five to eight, taking under ten minutes. Include the in-game name, Discord name, what they want to do, how they found you, and one rules question that proves they read the rules. Long forms filter for free time rather than fit.

Can I ask applicants for their age?

Ask only for what you need: whether they meet a threshold, such as 18 or older, rather than a date of birth. Collect as little personal data as possible, store it securely, and delete it when you no longer need it.

How do I whitelist players on a game without a whitelist?

Use a server password and share it only with approved players, typically in a Discord channel visible to a whitelisted role. Change the password when someone is removed. Some games have server-side mods that add a real whitelist.

What if a whitelisted player turns out to be a problem?

Treat them like any other player under your rules: warning, then removal or ban. Remove them from the whitelist and the Discord role, record the in-game ID with the reason, and note who referred them if your form asks.

Should whitelisted players be able to invite friends without applying?

A vouch system works on small servers: an existing member vouches and becomes partly responsible. On larger servers it creates cliques and a back door around the form, so most require everyone to apply, with a referral noted.