Skip to content
Rynox HostingRynox.

Minecraft · Access

Whitelist, bans and ops answer three completely different questions.

They get lumped together as server security, but they do separate jobs: who may join, who may not return, and who may run commands. Keeping them straight is most of the way to keeping a server under control.

Three systems that are often confused

Before touching any of them, know which question you are actually answering. A whitelist is an allow-list, a ban is a deny-list, and operator status is a privilege. They can be used together, but none of them replaces the others.

Whitelist, bans and operator status on a Minecraft server
SystemQuestion it answersStored inCommands
WhitelistWho is allowed in at all?whitelist.jsonwhitelist add / remove / list
BansWho is blocked from returning?banned-players.json, banned-ips.jsonban / ban-ip / pardon
OperatorsWho can run server commands?ops.jsonop / deop

The whitelist: an allow-list

A whitelist flips the default. Instead of anyone being able to knock on the door, only names on the list get in and everyone else is refused at the join screen, with no need to ban them individually. It is the right tool for a private server, a build test world, or the early days of a community before you are ready to be public.

You enable it in server.properties with white-list=true, and you can make the server disconnect anyone who drops off the list at runtime by also setting enforce-whitelist=true. Once enabled, manage it from the console: run whitelist add <name> or whitelist remove <name>, and whitelist list to review it.

Names must match exactly, so a whitelist entry for a player who has since changed their name will no longer let them in. On a whitelisted server, keep the list tight and tidy; an old entry is a forgotten key still in the lock.

Bans: a deny-list, and its limits

A ban is the opposite of a whitelist: it names players who are refused entry. Run ban <name> to block a player and pardon <name> to lift it. Bans are stored in a JSON file in the server directory, so they survive restarts and travel with a full backup.

An IP ban, run with ban-ip, blocks an address instead of a name, and it is much weaker than it looks. Players on mobile or home connections rarely keep the same address for long, and on a proxy network every connection can appear to arrive from the proxy itself unless forwarding is set up correctly. Use an IP ban as a short-term speed bump and rely on a name ban or the whitelist for the real control.

Ops: full privilege, so use them sparingly

Operator status is not a rank or a badge; it is permission to run server commands. An operator can change the time and weather, teleport, give items, kick and ban other players, and in the highest permission levels can do genuinely destructive things. Hand it out and you have handed out control of the world.

Modern Minecraft versions let you grant operators a specific permission level rather than all-or-nothing, which is a real improvement. Use the lowest level that does the job. Above all, never op a player you do not know, and never op the account you play on as a convenience.

Permissions plugins: granular control

The better answer for a growing server is a permissions plugin instead of blanket operator status. A well-known example is LuckPerms, and the idea is the same across them: instead of one switch, you grant individual commands and abilities.

  • Groups. Define a default group for ordinary players, and separate groups for helpers, moderators and admins.
  • Inheritance. A moderator group can build on the default group and add only the extra commands that role needs.
  • Per-command permissions. A helper can be allowed to mute or kick without also being allowed to ban or edit the world.
  • Prefixes and suffixes. The same system usually handles chat tags, so roles are visible without changing how the server works.

The payoff is that promoting someone is a low-stakes decision. You are not handing over the keys; you are adding one ability, and you can take it back just as easily. Configure permissions once, and staff changes stop being a risk.

Keeping an admin account secure

The strongest permissions in the world mean nothing if the account holding them is easy to take. Treat your admin access the way you would treat a bank login.

  • Keep a separate account for administration rather than doing everything from the account you play on.
  • Use a strong, unique password and enable two-factor authentication on the panel account that controls the server.
  • Do not share logins. Give someone their own access and their own role instead of passing around credentials.
  • Audit operators, staff groups and the whitelist regularly, and remove anyone who no longer needs access.
  • Keep tested backups, so a mistake or a bad promotion is recoverable rather than final.

These habits sit alongside the wider picture on the server security basics page, and if you run a proxy network, the networks page explains the forwarding setup that makes bans and permissions behave.

Access control — questions

Does a whitelist stop hacking?

It stops anyone who is not on the list from joining, which closes off a whole class of troublemakers, but it is not a security system on its own. Someone who is on the list can still be a bad actor, so pair a whitelist with sensible permissions, current software and backups.

Should I just op my moderators?

Rarely. Operator status is full control, and it is easy to hand out and forget. A permissions plugin lets you give a moderator exactly the commands they need, like kicking or muting, without also giving them the power to delete the world. Use ops for the smallest number of people possible.

Why do IP bans not always work?

Most players do not keep a fixed address; their internet provider reassigns it, and a determined player can change it. On a proxy network every connection can also appear to come from the proxy itself, so an IP ban may block the wrong thing or nothing at all unless forwarding is configured. Treat an IP ban as a speed bump, not a wall.

Do I still need a whitelist on a public server?

A public server is open by design, so a whitelist would defeat the point. There, the correct controls are a permission plugin with tight default groups, a watchful staff team and current software. A whitelist is the right tool for a private or semi-private server, not a substitute for permissions.

Decide who gets in before the world does.

The panel console is where whitelist, ban and permission commands run, and every plan includes the accessories you need to run them. Compare what each tier includes on the pricing page.

Rynox Hosting · built for people who play