Private Servers and Passwords: How They Actually Work

You want a server for you and eight friends. Nobody else. The obvious answer is a password, and it mostly works, but a password does a narrower job than people expect, and there are two or three situations where it is the wrong tool entirely.

What a password does

It stops people connecting without it. That is the whole function, and it is worth being precise about what it does not cover.

It does not hide the server. A password-protected server still appears in server lists, still answers status queries, and still reports its name, map and player count. Anyone can see it exists and who is on it. How server queries work explains why — the query and the connection are different things, and the query is answered before any password is checked.

It does not secure the machine. A game password protects the game. It does nothing about SSH, RCON, your control panel or your database. Game server security basics covers the things that get servers compromised, and a game password is not on the list.

It is shared, which means it leaks. Nine people who know a password is nine people who might paste it somewhere. Passwords are fine for keeping out strangers and useless for keeping out someone determined.

It does not identify anyone. Everyone who has it is equivalent. If you need to remove one person's access, you change it for everybody.

For "a small group of friends, nobody random", all of that is fine and a password is the right answer.

Setting one up

Nearly universal across games, and it is a single setting.

Source games: sv_password yourpassword in the server config. Clients set password yourpassword in console before connecting, or are prompted.

Minecraft has no built-in password, and the equivalent is a whitelist. white-list=true in the properties file, then add names. This is better than a password: it identifies individuals, and removing one person does not affect the others.

Most survival and building games have a password field in the server configuration, and the client prompts on connect.

To remove it, set it empty. Note that some games keep the old value cached in the client, which produces confusing failures, clearing it on both ends is worth doing.

On listing sites, a password-protected server is usually marked as such, and many people filter them out precisely because they cannot join. Server tags and filters covers that.

Whitelists are usually better

If the game supports one, a whitelist beats a password for almost every private-server case.

It identifies individuals. You add and remove specific people. No shared secret, no changing it for everyone when one person leaves.

It cannot be pasted into a Discord by accident.

It scales. A group of thirty friends-of-friends is unmanageable with a password and trivial with a list.

It survives a leak. Nothing to leak.

The cost is administrative: somebody has to maintain the list. For a group of eight that is thirty seconds; for a public server with applications it is a real job, and running a whitelist people actually apply to covers doing it well.

The genuinely private options

If you want the server not merely gated but invisible:

Do not list it. Simplest. The server still answers queries if asked, but nobody is asking unless they know the address.

Firewall it to known addresses. If your group has stable connections, allowing only their addresses is stronger than any password and costs nothing. Awkward if anyone's address changes, which on most home connections it does.

Run it on a VPN. Tailscale, WireGuard and similar put everyone on a private network, and the server binds to that network only. Nothing is exposed to the internet at all. More setup, and private rather than merely gated.

Turn off the query response, where the game allows it. The server stops answering status requests entirely and vanishes from lists. Note that some games handle this badly and some plugins depend on it.

For most groups the first option is enough. For a server you do not want found, the VPN approach is the only one that delivers it.

The hybrid that works well

A pattern worth knowing: public listing, private access.

List the server normally, with a description saying it is a private community and how to ask for access. Anyone browsing sees a real server with real uptime history and a real description, and the people who want in have a route.

This is how most good whitelisted communities work, and it is strictly better than hiding; you get discovered by people who want what you have, while nobody random can join. Listing your server covers the submission, and the description is where you say what the entry route is.

The alternative — an unlisted server that only grows by word of mouth, works for a fixed group of friends and does nothing at all for a community that wants to grow.

Passwords for a public server

Occasionally people password a public server temporarily, and there are two legitimate reasons.

During maintenance. Keeps players out while you test something. Better than taking the server down, because the listing stays online and you are not producing a gap in your uptime history.

During an incident. A raid, a griefing wave, a cheating problem you are mid-way through solving. A temporary password buys you an hour.

Both are fine. What does not work is using a password as a permanent moderation tool: it filters for people who were given a password rather than for people who behave, and those are different sets. Moderating a community covers the actual answers.

Handing the password out without losing it

If a password is the right tool, a few habits keep it useful for longer than a fortnight.

Put it in one place, not in a chat message. A pinned message or a channel topic that you can edit is better than a message scrolling away in history, because when you change the password you change one thing rather than hoping people find the newest of nine mentions.

Do not put it in the server name. Done surprisingly often, and it defeats the entire mechanism.

Change it when someone leaves the group. The whole weakness of a shared secret is that revocation is all-or-nothing, so use it, a password nobody has ever changed is a password an unknown number of people know.

Do not reuse it anywhere. Not the RCON password, not the panel, not anything on the machine. A game password is handed to nine people by design and should therefore protect exactly one thing. Game server security basics covers the rest.

Expect to explain where it goes. Every game asks for it in a different place, and on several the prompt only appears after a failed connection attempt. Half the support questions on a private server are somebody who has the password and cannot find the box — why you cannot connect covers the general case.

Write down what happens when it fails. On some games a wrong password produces a clear message, on others a generic timeout, which is indistinguishable from the server being down.

For a group that might grow

Worth thinking about at the start, because the choice is annoying to reverse.

Password: fine for a fixed group, becomes unmanageable past about a dozen people, and offers no path to growth.

Whitelist: scales indefinitely, needs someone to maintain it, and gives you a natural application process if you ever want one.

Open with rules: the only option that grows on its own, and the one that requires actual moderation.

Most private servers that last end up on the middle option, because it is the only one that lets a friend bring a friend without either handing out a secret or opening the doors entirely.

Should a private server be listed at all

The question most private-server owners answer by default rather than deliberately, and it is worth a minute.

Arguments for listing it: you get uptime history, which is useful to you as the operator; a record of when the server was unreachable, without setting up monitoring yourself. You get a page you can point people at. And if the group ever grows, the discovery is already in place rather than starting from zero.

Arguments against: a listing invites questions from people who cannot join, and a permanently password-protected entry in a directory is a small amount of noise for everyone browsing it.

The middle position that works: list it, mark it clearly as private in the description, and say what the entry route is even if the answer is "invite only, we are not taking new members". A stranger reads one line and moves on, and you keep the history and the page.

The case for not listing: a server that must not be found, a group that values privacy, or a test server. There, the answer is not a password at all but one of the private options above, because an unlisted server still answers anyone who asks its address directly.

The gist of it

A password stops strangers joining and does nothing else: not hiding, not security, not identification. For eight friends that is exactly enough.