Three questions turn up together for every Minecraft server: how do I let only my friends in, how do I make someone an admin, and how do I get rid of the person who burned my base down. On uniz.host all three live in the Players tab of the server page, and all three are the same kind of thing underneath — a list of names the server reads. The list you need depends on the job, and the surprising part is that you do not need the server running to edit any of them.
Three lists, and where they actually live
The Players tab shows three cards below the online grid: Whitelist, Operators and Banned.
| Card | The file behind it | What it does |
|---|
| Whitelist | whitelist.json | Who is allowed in, once the whitelist setting is on |
| Operators | ops.json | Who has operator (OP) status in game |
| Banned | banned-players.json | Who is refused, by name and UUID |
Those three files sit on your server's own world volume — the same volume the world, the mods and the configs are on. They are not rows in our database. uniz.host reads and writes those files; the server reads the same files. Nothing else stores a second copy.
That has one consequence people meet the hard way: restoring a backup restores that backup's lists too. A Minecraft backup here archives the whole volume, and restoring it unpacks that archive back over the volume, so a restore made from last Tuesday brings back last Tuesday's whitelist, operators and bans along with last Tuesday's world. If you banned someone on Friday and restored a Tuesday backup on Saturday, that ban is gone. Re-apply it after the restore, not before.
The part most people miss: it works while the server is stopped
This is the best-kept secret of the Players tab. Adding and removing names does not require a running server.
- Server running — the change goes over the server console as the matching command, and the server applies it immediately.
- Server stopped — the list file is opened on the volume, edited in place and written back. Nothing is started, nothing is billed for running, and the change is already there the next time the server boots.
The add and remove controls in the three list cards are therefore enabled by your permission alone. They do not grey out when the server goes offline. The only thing you lose while stopped is the online grid, which says it cannot read online players — that message is about the live roster, not about the lists underneath it.
Open the Players tab for that server
Go to your server at /dashboard/servers and pick the Players tab. The three list cards render whether the server is up or down. If the server is archived or in the middle of a restore, the world is not on the volume at that moment and the lists come back empty — wait for the restore to finish rather than re-adding everyone.
Type the player name into the list card you want, then press Enter
Each card has a single input labelled Player name, then Enter. Enter submits. Removing is the small button on the row itself.
While the server is stopped, an add has to resolve the name to a real Minecraft account first, because the files are keyed by UUID rather than by name. A name that resolves to nothing is refused outright — the entry is never written with a made-up identifier. Adds are idempotent, so re-adding someone already on the list changes nothing rather than duplicating them. An operator added while stopped is written at level 4, the full operator level. A ban added while stopped is written with no expiry and, if you gave no reason, the default reason Banned by an operator.
Removals match by name and ignore case, so Steve takes steve off the list.
Read the reply the server sends back
On a running server the action is a console command, and a console command can complete without doing anything — a name that matches nobody online, for instance. A successful call is not a successful command, so uniz.host shows you the server's own reply text instead of a generic confirmation. If the reply says nothing happened, nothing happened, and the text tells you why.
Turn the whitelist switch on in the settings card, then restart
Editing the whitelist does not switch it on. That is the next section — and the single most common way to lock yourself out.
The toggle and the list are two different things
In the Server properties card there is a whitelist switch, in the players group. It is off by default on a new server, and all it does is tell Minecraft to check the whitelist file. It does not add anybody to that file.
So the failure mode writes itself: turn the switch on while the whitelist is still empty, restart, and everyone the server checks is refused — including you, unless you put yourself on the list first. Do it in this order:
- Add every name you want in, yours first, in the Whitelist card.
- Confirm the names appear in the card.
- Turn the switch on and restart.
There is one more asymmetry worth holding on to. List edits apply as described above; the switch does not. Saving anything in the server properties card while the server is running updates the stored setup but deliberately does not disturb the running server, and the page flags that a restart is pending. So a name added to the whitelist reaches a live server straight away, while turning the whitelist switch on reaches it at the next restart.
What does not work while the server is stopped
Five actions need a live server, because they act on a player who is connected right now rather than on a file:
- kick
- gamemode
- teleport
- give
- effect
Ask for any of those on a stopped server and the request is refused rather than quietly queued. The tab reflects it: while stopped, the Banned card still takes a name, and there is no kick to be had — the online grid it would act on is empty. That split is the whole rule in one line — a ban is a list entry, a kick is an event.
The same reasoning explains why the row of buttons over each online player only exists while the server is running. There is no online player to act on otherwise. Free-form commands live in the Console tab, whose input is available only while the server is online; the placeholder there is literally Type a command, e.g. whitelist add PlayerName, and the offline state says so plainly.
Two permission tiers, and why they are split
If you share the server with a team, two different grants cover the Players tab.
| Grant | What it unlocks |
|---|
| Manage players | Whitelist add and remove, kick, ban, unban |
| Console | Everything above, plus operator and de-operator, and the gameplay commands |
The split is not cosmetic. Moderating a server means deciding who may be there — a bounded job, and the worst outcome of a mistake is that someone gets let in or shut out for an evening. Granting operator status is different in kind: an operator holds in-game command authority on that world, which is a strictly larger power than the moderation buttons, and the gameplay commands sit in the same tier for the same reason.
The grant names are the ones you see in the Team tab when you invite someone. The rules are enforced on our side as well as in the interface, so a member with only the moderation grant is refused an operator change even if the button were somehow reachable.
Bedrock servers work differently in three ways
A native Bedrock edition server is a different program with different files, so three things change:
- There is no ban system at all. Bedrock's dedicated server has none, so the banned card does not appear and a ban request is refused. Your options there are the allow list and a kick.
- Operators are keyed differently. Bedrock stores operators by the player's Xbox account identifier rather than by a Minecraft account UUID, so making someone an operator needs that identifier looked up first — and if it cannot be found for the gamertag you typed, the change is refused instead of guessed. The allow list, unlike the operator file, is stored by name.
- The console is a different channel. Bedrock's server has no RCON; uniz.host drives it over a remote console session instead. When that session is not reachable, a list change still lands in the file and the page tells you the change takes effect after a restart — which is honest, not a failure.
One extra wrinkle applies to Java servers with crossplay switched on. Bedrock players who join through it are tagged with a Bedrock badge in the online grid, and their names carry a prefix and no Minecraft account behind them. Since a stopped-server add has to resolve to a real Minecraft account, add those players while the server is running, over the console, rather than offline.
Read next
- — where the whitelist switch lives, and what else in that card needs a restart
- — the grants above, from the invite side
- — the tabs, the badges and the address your players actually type
- — the whole picture, self-hosted or here