Share your server with a friend — let them start it without handing over your account

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 right after 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 tab, the "Members" section lists your own row marked "Owner · can do everything", and 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, and a line under it warns that your friend must have signed in to uniz.host with Google before. 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 to give" heading with seven checkboxes. Two arrive already ticked — Power and Console — and the line under them says to start there and add more later. 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 on the Content tab, 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; on an empty list the invite button will not fire and the form says to pick at least one permission.

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

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.

The players tab opens on either grant, but the buttons inside differ

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 tab 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.

1. Deleting the server — the delete button in the Settings tab's danger zone renders for the owner only, and the action is irreversible: the world data is gone for good.
2. Anything that spends the owner's credits — resizing (more or less RAM) and moving to another hardware class, in the Settings tab's Size and machine group. Those hide themselves entirely from a non-owner.
3. 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: size and hardware class 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 — members are told to wait for the owner to top up — 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 the remove button on their row (its label reads "Remove" followed by their name). A confirmation asks "Remove this member?" and says they lose access to this server right away. Confirming with "Remove" 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

• Dashboard tour — how to read the tabs on a server page
• Credits and billing — when the owner's credits are actually spent
• Auto-sleep — let an empty server stop charging by itself
• Game server RAM — before you decide whether to resize