Team members and permissions

Rather than sharing one login, add each person their own under Account → Team. Each gets their own credentials, and their actions are recorded against them — which matters the first time you need to know who rebooted something.

Add someone

1. Go to Team.
2. Add the member with their email address.
3. Grant the permissions they need.

They can be given as little or as much as you like. Permissions are additive: a member has exactly what you grant and nothing else.

What each permission allows

Servers

Permission	Allows
View servers	See servers, specifications and metrics. Read-only.
Power control	Start, shut down, reboot and force stop.
Console access	Open the browser console, and reset the server password.
Snapshots	Create, restore and delete snapshots.
Resize	Request more CPU, memory or disk.
Reinstall	Mount installer images and reinstall the operating system.
Volumes	Attach, detach and manage additional storage.

Networking and security

Permission	Allows
Firewall	Add, change and remove firewall rules.
NAT	Map public addresses to private servers.
Routes	Manage routing.
WAF / IDS	Change alert preferences and monitored addresses.
Tunnels	View tunnel status and logs, and reload their own tunnels.
VPN peers	Manage WireGuard peers.
DNS	Manage DNS records.
VLANs	Manage VLANs.

Account

Permission	Allows
Billing	View invoices and billing information.
Storage	Manage storage resources.

Some permissions also depend on your plan. If a capability isn’t included in your plan, granting it to a member doesn’t unlock it — the member simply won’t see it.

Choosing sensibly

Start from what the person’s job needs, not from what’s convenient.

A developer who deploys usually needs view, power control and console — enough to restart a service and get in when something’s wrong.

Someone doing networking needs firewall and NAT. These are the permissions most able to cause an outage: a wrong rule can cut off every service at once, including your own access.

An accounts person needs billing and nothing else.

Three worth being deliberate about:

• Console access includes resetting the server password, which is effectively full control of the operating system. Treat it as an administrative permission.
• Reinstall can erase a server. Grant it only to people who install operating systems.
• Firewall and NAT can take your services offline, and can lock out the person making the change. Anyone with these should read Route traffic to your server first.

Removing access

Remove the member from the Team page when they no longer need it — that’s immediate, and better than changing a shared password afterwards.

If they had console access, also rotate anything they could have seen inside your servers: root passwords, SSH keys, and application credentials stored on disk. Removing the panel login closes the front door; it doesn’t change a password they already know.