Team & roles

An organization is where a team works together: its members, its clusters and projects, its domains, its templates, its service tokens and its invoice. Everyone who joins holds exactly one organization role, and that role is the default reach they have into every cluster and every project. When one role for the whole organization is too coarse, access control narrows it per cluster or per project.

The three roles

Viewer is for people who need to see what is running and why: a stakeholder, a support engineer, an on-call rota that watches but does not change. Logs stream and metrics render; the forms are read-only and secret values stay hidden.

Developer is the everyday role. A developer ships: deploys from GitHub or an image, changes environment and ports, adds a domain, creates a database, reads a secret. Deleting a cluster is not a developer's call, because it takes every project on it with it.

Admin administers. Admins hold the member list, the billing, the cluster tokens and the audit log, and only an admin changes who may see what. The person who creates an organization is its first admin and its owner; the owner cannot be removed from the organization.

There is no per-project or custom role. When you need "these three deploy to production and nobody else", that is an access level with grants, not a fourth role.

Inviting someone

Organization settings, Team, Invite member: an email address and a role. The invitation is sent by mail and appears on the invitee's Invitations page the next time they sign in, with the organization's name and the role offered. Nothing happens until they accept: signing in does not join anyone to an organization they did not agree to.

If the address has no Anyport account yet, the invitation waits for it. The first sign-in with that address, once it is verified, finds the invitation ready. If the address already belongs to an account, the invitation goes there, whichever way that person signs in.

An admin can cancel a pending invitation, change a member's role at any time, and remove a member. Removing a member ends their access to the organization on the next request and revokes every grant they held; they are told by mail, and a re-invited member starts clean. The organization's owner cannot be removed.

Teams

A team is a named set of people. Grant a cluster or a project to the team once and everyone in it holds that access, including people added later; take someone out and it is gone for them on their next request. Teams exist for exactly this: a team never changes what someone's organization role is, only where it applies. "The platform team deploys to production" is one team, one grant, and a member list that says why each person can.

Organization settings, Team, Teams: create a team (a short lowercase name, such as platform), add people, then grant it from any cluster's or project's Access tab, where teams appear in the same picker as members. A person's Access column on the Team table reads "developer on prod-eu, via platform" for what a team gives them. From the terminal:

anyport team create platform --description "Runs prod-eu and prod-us"
anyport team add platform alice@example.com bob@example.com
anyport access grant prod-eu team:platform --role developer
anyport team show platform

Removing someone from a team, like revoking a grant, asks first and says what they lose; anyport team remove prompts the same way, with --yes to skip in a script.

Two deliberate limits. A team holds people only: a service token is granted directly, so what a credential can do is always one list against that credential. And a team holds no organization role: someone who is an organization viewer stays a viewer everywhere the team is not granted. Removing a member from the organization removes them from every team; a re-invited member starts in no team.

Service tokens are members too

A service token acts as a member with a fixed role, so most of this applies to it: it can be a viewer, a developer or an admin, it can be granted access on one cluster or project, and revoking it ends its grants. It cannot join a team. Tokens are managed from the Service tokens panel rather than the Team table, and they do not count towards anything.

One account, several ways to sign in

Your account is your email address. Sign in with Google, or with an email and password, and as long as the address is the same and verified you land in the same account with the same organizations: a Google sign-in and a password sign-up on one address are two ways into one account, not two accounts.

Adding a way to sign in is just using it: sign up with a password on the address you already use with Google, verify the address from the mail you receive, and the two are joined. Because that mail is what joins them, it says so: if you did not start the sign-in, ignore it and nothing is added to your account. Account settings, Sign-in methods lists every way your account can be signed in to.

There is no password to reset on an account that only ever used Google. To add one, sign up with a password on the same address, as above.

Where the record is

Every access level change and every grant is in the organization's audit log, with who did it and to whom. Admins read it under organization settings, Audits. Invitations, role changes and removals are not recorded there yet; the Team table shows the current state.