Inviting people
Invite by email with a role, change it, revoke it, remove somebody — and the two rules that stop a workspace locking itself out.
The team screen is who is in this workspace, who has been invited, and what
an admin can do about it. It needs the Teams plan.
Inviting
Invite by email, with a role. They get a link; when they accept and sign in,
they are in the workspace. They see the machines you have shared with them —
see who may open what. Admins see every machine.
An invitation that has gone unanswered can be resent or revoked.
…and then let them onto your network
This is the step people miss, and it looks like a fault in beafk when it is
missed: somebody accepts, signs in, presses a machine you shared with them —
and nothing opens.
A machine is reached over your Tailscale network, and beafk cannot put
anybody on it. That is not a gap we are going to close: minting an invitation
to your tailnet would mean holding a credential for it, and a credential that
can add a person to your network can add a machine to it too. We would rather
not be able to.
So the last step is Tailscale's, and it takes about ten seconds per machine.
The team screen lists it under a pending invitation, with a link straight to
each machine in Tailscale's console. There, Share and their email address:
Tailscale emails them a single-use link of its own.
Share the machine rather than inviting them to the tailnet. Sharing gives them
that one machine, costs you no seat, and leaves the rest of your network
invisible to them; an invitation gives them everything and adds to your user
count.
They do not need an account with you first — Tailscale accepts a share to any
address, and it does not have to be the one you invited them at.
beafk cannot see your tailnet, so the team screen cannot tell you who you
have already shared with. It offers the link and says so; the truth is in
Tailscale's own console.
Until that is done, a machine you have already shared with them still will
not open. The card says why, rather than failing silently.
The two roles
Admin — everything. Invite and remove people, change roles, connect and
disconnect machines, decide who may open which machine, read the access log, and
handle the bill.
Member — use the machines. Open them, run agents, read and write code,
everything the product is actually for. Not the team, the billing, or the audit.
There is no third role.
Changing somebody's role
From their row. It takes effect on their next action, not on their next
sign-in.
Removing somebody
From their row. They lose the workspace immediately.
Their chats and their work on the machines are not deleted — that is
your code and your history, and it stays where it is.
The two rules that cannot be broken
The last admin cannot be demoted or removed. A workspace with no admin is a
workspace nobody can add one to, and the machines in it would belong to nobody.
Nobody can remove themselves from under their own session. It is not a
recoverable mistake.
How an admin's permission is checked
Every action that changes something asks the identity service what your role is,
right then — never a copy we are keeping. And every identifier in an address is
checked against the workspace it claims to belong to, so an admin here cannot
revoke an invitation there.
Then: who may open what
Being in the workspace is not the same as being able to open every machine. That
is who may open what.