The classic situation: your friends want to play at ten at night, the server is asleep, and you are nowhere near a computer. The usual answer is to hand over your account password so somebody else can press start — which hands over everything, including your credits, your other servers and the delete button. On uniz.host you do not have to. There is a team system that shares exactly one job, such as "can start the server and nothing else", while your friend signs in as themselves.
Your friend needs their own account first
An invite looks up an existing account by email. If that address has never signed up, the invite fails with a user-not-found error — nothing is sent to an address that has no account behind it. So the working order is: your friend signs in to the site once, then tells you the email they signed up with.
Two other cases are refused. You cannot invite your own address — the owner is implicitly on the team already — and you cannot invite someone who is already a member of this server's team. If you want to change what an existing member can do, edit them in the member list instead of inviting them again.
How to invite a friend to the team
Open the Team tab on a server you own
Go to the server page at /dashboard/servers/<id> and look at the tab strip. The "Team" tab sits in the same row as Console and Settings.
That tab only exists for the owner. If you are on somebody else's server as a member, you do not see the tab at all — not a greyed-out tab, no tab. That is the permission system working, not a broken page. Inside the card, before you have invited anyone, you get the line "No team members yet — invite someone below."
Enter the email your friend signed up with
Under the "Invite a member" heading there is an "Email" field whose placeholder tells you to use the email they signed up with. It has to be that account's address — not their in-game name and not their username on the site. Surrounding spaces and letter case are handled for you.
Tick only the permissions the job actually needs
Below the email field sits the "Permissions" heading with seven checkboxes. Two arrive already ticked — Power and Console. That is the default grant for a fresh invite, and it is deliberately narrow.
This is the single most misread thing about the feature. "Invited to the team" does not mean "can do everything." Send the invite untouched and your friend can start, stop and restart the server, watch the live log and type commands — but they cannot change settings, install mods, touch files or restore a backup. If the job really is "press start while I am out", untick Console and leave Power alone.
At least one box has to stay ticked; the invite button will not fire on an empty list.
Send the invite and have your friend open their own server list
The "Invite" button reads "Inviting…" while the request is in flight, and a successful invite raises a "Member invited" message with the new member appearing in the list straight away.
Nothing is required on your friend's side — the access is live immediately. They open /dashboard/servers in their own account and your server shows up mixed in with theirs, carrying a "Shared" badge that means they are not its owner. Opening it, they see exactly the tabs their permissions justify.
What each of the seven permissions really grants
| Permission | What it lets a member do |
|---|
| Power | The "Start", "Stop" and "Restart" buttons, including bringing an archived server back |
| Console | Live logs, the command box, and console-tier player actions — op, deop, gamemode, tp, give, effect |
| Settings | The whole settings tab, including changing the server address, scheduled tasks, world reset and the per-game settings |
| Mods | Add and remove mods and plugins, upload mod files |
| Files | The file manager — read and edit configs, upload onto the server's volume |
| Manage players | Whitelist, kick, ban, unban |
| Backups | Create, restore, download, upload, delete and schedule backups |
The two that reach further than their names suggest
Five of those rows are exactly what they sound like. Two are much wider than their label, and they are the two worth thinking about before you tick them.
Settings is not just the MOTD and the sleep timer. It is the whole settings tab. So a member with it can change the server address — which quietly breaks the address everyone else bookmarked — set up scheduled tasks so the server restarts itself at three in the morning, attach and detach a custom domain, edit the full per-game settings, toggle crossplay, and on a Java Minecraft server trigger a world reset. Grant it to someone you trust to make decisions on your behalf, not to someone who just wants to tweak the message of the day.
Console is not just reading logs. The command box is the server's real console, and in the permission model a group of player actions is filed under Console rather than under Manage players: op, deop, gamemode, tp, give and effect. In plain terms, a member with Console can op themselves in-game. If that is not what you want, do not grant Console — grant Manage players instead.
One asymmetry is worth knowing because it surprises people: the "Players" tab appears if a member holds either Manage players or Console. Either one alone is enough. Which means the default invite already sees the players tab, since Console comes ticked by default.
But seeing the tab and being allowed to press everything in it are different things. Player actions are split into two tiers. The moderation tier — whitelist, kick, ban, unban — passes with either of those two permissions. The console tier — op, deop, gamemode, tp, give, effect — requires Console specifically. A member holding only Manage players opens the tab and is then refused on the console-tier actions. That is the design, not a bug.
What can never be shared, however you tick the boxes
The team card offers seven checkboxes, and those seven are genuinely the whole grantable set. Three things have no checkbox at all and stay with the owner permanently.
- Deleting the server — the delete card renders for the owner only, and the action is irreversible: the world data is gone for good.
- Anything that spends the owner's credits — resizing (more or less RAM), moving to another hardware class, and switching between the hourly and monthly plan. Those cards hide themselves entirely from a non-owner.
- Team management itself — a member cannot invite anyone, widen their own permissions, or remove someone else, even holding all seven grants.
The reasoning behind the second group is blunt: a member must never be able to change the rate on somebody else's bill. If they could add RAM, they could raise the hourly price charged to your wallet. The third group stops access from leaking sideways — if members could invite members, the circle of people who can reach your server would grow without you knowing.
And none of this is only hidden buttons. The backend re-checks every request itself and rejects a non-owner before any work begins, even if the request is sent directly without going through the site. Every permission in the table above is checked the same way.
Who pays — always the owner
Cost attaches to the server, not to whoever pressed the button. The hours a server spends online are recorded against its owner and billed to the owner's credits, no matter who pressed "Start" and no matter whether it was a button press at all or a player waking it by trying to connect.
Both halves of that are worth saying plainly. A member with Power can make your bill run, because a server they started is billed like any other. What they cannot do is change the rate: specification, hardware class and plan are locked to the owner. If the total is the worry, the tools are to withhold Power from people who do not need it, and to turn on auto-sleep so an empty server stops charging by itself.
There is a related consequence. When credits run out and the platform stops the server, the warning banner is visible to everyone on the team, but the top-up button appears for the owner only — because it is the owner's wallet.
Changing permissions later, and removing someone
Nothing you grant is permanent. Each row in the member list carries the same seven checkboxes as the invite form; tick or untick there and press "Save". The button only becomes active once the set actually differs from what is stored, and at least one permission must remain. A successful change raises "Permissions updated".
If the intent is that someone should no longer reach anything, do not untick everything — that will not save anyway. Press "Remove" on their row. A confirmation asks "Remove this member?" and explains that "They will immediately lose access to this server." Confirming gives you "Member removed".
"Immediately" is literal. The next time they open that server page it is no longer in their list, and any request sent afterwards is refused as if they were a stranger. What does survive is whatever they did while they had access — the backups they created, the files they uploaded. Removing a member does not undo their work.
Read next
- — how to read the tabs and cards on a server page
- — when the owner's credits are actually spent
- — let an empty server stop charging by itself
- — before you decide whether to resize