Your Palworld server is up and friends are playing on it. Three questions always arrive together: how do I become admin inside the game, who is online right now, and how do I remove someone who is ruining it for everyone. This guide answers all three from what is really on your server page at uniz.host, and is honest about one limitation that looks exactly like a bug but is not.
What makes this different from Minecraft is that Palworld no longer has RCON. The publisher's own RCON page is marked deprecated and says plainly, "RCON is now deprecated. Please consider to use REST API," adding that it "is scheduled to stop functioning in an upcoming update." The documented management surface is the dedicated server's REST API, which our Palworld servers run with RCON switched off — so every action below travels down that one pipe.
Claiming in-game admin with the admin password
In-game admin and your access on the website are unrelated. On the site you are the owner; inside the game you are an ordinary player until you type the admin password into chat once.
Set the admin password in the Palworld settings card
Open the server's Settings tab and find the "Palworld settings" card. The field is labelled "Admin password (in-game)" and always renders empty, prompting you to "Set a new admin password", whether or not one was set before. Do not confuse it with "Server password" nearby — that one every player needs to join, while the admin password elevates someone who already joined.
It must be 8–32 characters using only English letters, digits, hyphens and underscores; anything else is rejected before it is sent. The 8-character floor exists because the claim command is stock Palworld — every player who can join can also sit there guessing at it. Each server starts with a long random one in place, so if you never set your own, nobody knows it, including you.
The field is write-only. What you type goes into that server's Kubernetes Secret on the cluster rather than the site's database, the input clears the moment the save succeeds, and no page ever shows it back. Write it down before you hit save; success confirms with a "Settings saved" toast.
Restart the server so the new password takes effect
The card says so itself: saving updates the server's setup right away but will not interrupt it while running, and you have to restart for the change to apply. That rule covers every value in that card, not just the password. If people are playing, tell them first — the announce box is covered at the end of this guide.
Claim admin from the game chat
Join the server, open chat, and type /AdminPassword followed by a space and the password you just set. The command belongs to the game, not to uniz.host, so it behaves the same wherever a Palworld server is hosted, and the hint text under the settings field spells out the same formula. Once accepted, your character can use the game's other admin commands for that session; after a restart, or after you leave and rejoin, type it again.
Confirm it worked from the Players tab
The most reliable confirmation is on the site, not in the game. Open the Players tab: if "Online now" lists the people actually in the game, the platform is talking to the REST API with the current password — the same one you just used in chat. If it instead says "Can't read online players (server stopped or RCON down)" while the server is running with people on it, read the next section first.
The window where the new password is not live yet
This surprises people most, and it is intended rather than a fault. A new admin password reaches the server's Secret immediately, but the running game process does not re-read that Secret mid-flight — it keeps the copy it read at boot. That leaves a window in which the website holds the new password and the game still accepts only the old one.
During that window every call to the game's REST API is refused, and each surface shows it differently. "Online now" degrades to the cannot-read message, the Console tab's stats strip becomes a row of dashes, and Announce and Save world now report failures. The game itself is fine throughout — players notice nothing, and only the management path from the website is broken. One restart fixes all of it at once, so change the password when the server is quiet and restart in the same sitting.
Reading the online roster
The Players tab for Palworld carries more than most games, because the REST API reports far more per player than a bare name list. Each player gets a Steam avatar (or an initials tile if they play from another platform), a level, and three numbers: "Ping", "Buildings" and "Position". Switch between the "Cards" and "Table" views; in the table the numeric headers sort on click. Above the list sits a whole-server summary — how many are online, "Avg ping", "Buildings total", and, when the game reports stats, "Server FPS" and "Uptime".
The roster is not instant. The page refetches every 15 seconds while the server runs and your tab is in the foreground, and the server side caches the roster for 10 seconds, because a shared server's whole team on the same page would otherwise multiply those requests onto the game pod. So someone who just joined can take ten-odd seconds to appear; "Refresh" is there, but if they are still missing, wait one more cycle.
"No one is online" means something different from the cannot-read message — the first says the read succeeded and the world is empty, the second says the read failed.
Kick and ban target the player id, not the display name
Every player row carries a "Kick" and a "Ban" button, shown only while the server runs and only to viewers whose permission allows it.
What is easy to miss is that those buttons do not send the display name — they send the player's identifier, the one beginning with steam_. That is forced, not cosmetic. Palworld display names can be Thai, and the action contract's target pattern rejects characters outside ASCII, so a Thai name would be refused at the API boundary before reaching the game server. The steam_ identifier is the only thing that makes the kick button work for Thai-named players at all.
That identifier sits under each player's name, next to a button labelled "Copy player ID"; pressing it confirms with "Copied". Do not confuse it with the "Character ID" column in the table view — a different in-game number that cannot be substituted.
The line a kicked or banned player sees is fixed English text saying an operator did it; there is no field for your own reason yet. To explain something to the whole server, use the announce box.
A successful action shows "Done" and refetches the list at once, clearing the 10-second cache in the same step so a player you just kicked cannot linger and make the button look broken. A failure shows "Action failed" with the reason.
The limitation to know before you ban anyone
Plainly: the "Banned" card on a Palworld server is always empty, even ten seconds after you banned somebody.
The reason lies with the game, not the site. Palworld's REST API offers the write actions in full — kick, ban, unban — and a read of who is online right now. It offers no read at all for any persistent list: not a whitelist, not operators, not bans. Rather than guess, the platform returns empty lists. The card still renders because its ban and unban controls do genuinely work.
So your ban did reach the game server, but the site cannot prove it back afterwards. Read the toast instead — if no failure message appeared, it went through. An empty card is not evidence of failure.
The sharper consequence is unbanning. Type an ordinary name into the "Player name, then Enter" field and it is matched against the live online roster first — and a banned player is never on it, so you get a player-not-found error every single time. The one thing that works is pasting the identifier beginning with steam_, which goes straight to the game server without consulting the roster.
So build this habit: before you ban anyone, press the copy button on their player ID and keep it. They are still online at that moment, so the identifier is still visible. Once the ban lands they drop off the roster and uniz.host has no way to surface it again — without it, unbanning becomes very hard.
Announce, save now, and what an unreachable game API looks like
The Console tab of a Palworld server has no command box, because there is no RCON to type into. Three things stand in its place. First is the text field prompting you to "Broadcast a message to everyone online". Type and press "Announce", or hit Enter; messages run to 256 characters and confirm with "Message sent". Second is "Save world now", which makes the game write the world out immediately instead of waiting for its autosave cycle; success shows "World saved". Third is the stats strip beside those controls — "Server FPS", "Players" against the cap, and "Uptime" — polling every 10 seconds, and stopping while you are on another browser tab.
These three treat failure differently, on purpose. Announce and Save world now are commands you pressed, so an unreachable game API produces "Could not send the message" or "Could not save the world" — staying silent would fool you into thinking the message went out. The stats strip never complains; it simply shows dashes, because it polls itself while a server may still be booting, which is normal rather than an error. Dashes mean "no reading yet", not "the server is broken". This whole block appears for owners and their team, and not on the admin support view.
Which grant unlocks what
If you share a server with friends who help run it, this is what each grant opens up. The owner passes all of it holding no grant at all.
| What you want to do | Grant needed |
|---|
| Set or change the admin password | settings |
| View the online roster | players or console |
| Kick, ban, unban | players or console |
| Announce, save world, stats strip | console only |
The two middle rows are where people get it wrong. The players grant alone covers kicking and banning in full, so someone whose job is keeping the peace does not need the much broader console grant — widen it only if you also want them announcing or forcing saves. The admin password sits apart from both, on the settings grant.
Read next
- — from home hosting to running it on uniz.host
- — reading the cards, tabs and graphs on a server page
- — why Palworld is heavier than people expect