Skip to content

Bring in your team

Clusters belong to a team in the portal, not to a person. This page invites people into the team and says what a member and an admin may each do, who accepts the terms, and who gets the mails.

You need to be a team admin.

  1. Open Team Settings in the team menu.

  2. Under Invite Team Members, enter the person’s email address and choose the role, Member or Administrator, then Send Invitation.

  3. The invitation waits under Pending Invitations until it is accepted; you can resend or cancel it there. The person follows the link in the invitation and either signs up, with the address the invitation went to, or signs in and accepts.

Under Team Members, an admin opens a member to change their role. Nobody can change their own role, and the team’s only administrator cannot be removed: make someone else an administrator first.

Reading needs membership; anything that changes a cluster needs a team admin. The one exception is your own kubeconfig.

ActionMemberAdmin
See clusters, their health, nodes, operations, snapshots, upgrades, add-ons and settingsyesyes
Get a kubeconfigview, or admin if the team allows itadmin or view
Revoke their own kubeconfigsyesyes
Revoke someone else’s, or everyone’s—yes
Add a Hetzner projectyesyes
Check or replace a project’s token—yes
Accept the terms, create a cluster, start the subscription—yes
Take a snapshot, restore, change backups and keys—yes
Schedule an upgrade, change the channel or the window—yes
Switch add-ons, change who can reach the API, replace the token inside the cluster—yes
Retry, detach or delete a cluster—yes
Billing, Cloud Viewer, API keys—yes

Admin kubeconfigs for members. On any cluster’s Access tab, under Who may ask for admin access, an admin can tick Team members may ask for admin kubeconfigs too (all clusters of the team). The switch is one for the whole team, not per cluster. Leave it off where members should only read.

API keys In progress. Only an admin creates them. A key acts as the admin who created it, narrowed to its scopes: a scope never gives more than that person may do. Give an agent access.

Removing a member, or a member leaving, revokes their kubeconfigs on every running cluster of the team In progress: pbx-agent deletes their ServiceAccounts, and every kubeconfig issued to them stops working. In the lab a revoked kubeconfig was refused within 11 seconds. Their API keys stop working too, because a key works only while its person is a member.

A team admin accepts the terms of PaaSbox Clusters once for the team, before the first cluster, on the New cluster page. PaaSbox Clusters → Terms shows the text, its version and who accepted it when. A new version of the terms is accepted again before the team’s next cluster.

The portal sends every team mail to the team’s admins, all of them. In progress The mails are built; in the lab run of 2026-10-10 they went to the portal’s log, not to a mailbox.

  • Kubeconfigs and restores: whenever someone asks for a kubeconfig or queues a restore, with who did it, so that no account can act unseen.
  • Cluster alerts: two scheduled snapshots missed, an upgrade failed, a certificate with under 30 days left, pbx-agent silent for 24 hours.
  • Your Hetzner project: a resource in it that the portal did not create.
  • Billing In progress: when a payment is missing, on day 1, 7 and 13; on day 14 the team’s clusters are detached, and keep running without the portal.

Paddle is the merchant of record. The admin who starts the subscription in Paddle’s checkout becomes Paddle’s customer with their email address, and Paddle’s own mails go there. Any admin sees the invoices under PaaSbox Clusters → Billing. Costs and billing has the rest.