Members and roles
Who is in your organization and what each of them may do.
On this page
What it is
Everyone who can see anything in klickops is a member of an organization with exactly one role. That role decides what they can do across every project in it.
There are three, and they are deliberately few. Most access questions are answered by "can this person change things", and inventing a fourth role usually means the projects want splitting instead.
| Role | Can | Cannot |
|---|---|---|
| Member | Work in every project: deploy, edit, restart, restore and delete workloads, and see usage and the plan | Create or delete projects, manage members, or change the plan |
| Admin | Everything a member can, plus create and delete projects, invite and remove members, manage API tokens and change the plan | Rename or delete the organization, or manage owners |
| Owner | Everything | nothing |
When you'd use it
- Somebody joins and needs access.
- A contractor should see logs but not touch production.
- Somebody leaves, and their access has to go with them.
Invite somebody
- Go to Members in the organization and choose Invite member.
- Enter their email address and pick the role. Choose the smallest one that lets them do their job; raising it later is one click.
- klickops emails them the invitation; you can also copy the sign-in link and send it yourself. They see the invitation the next time they sign in with that address, or right after they create their account.
- They accept and land in the organization.
An invitation is not access. Nobody joins until they accept, and until then they wait under Pending invitations, where you can revoke it. The answer you get when inviting is the same for every address, so it never tells you whether somebody already has an account.
Admins can also list addresses or a domain (@acme.io) under Allowed to join. Anyone signing in with a matching verified email is offered an invitation as a member and joins only if they accept. Only your own company's email domain can be listed, never a public provider such as Gmail.
Accept an invitation
Invitations addressed to you show up under Invitations in the sidebar, with a count. When you belong to no organization yet, they are on the page you land on after signing in.
- Accept joins the organization at the role it names and takes you there.
- Decline removes the invitation. Nobody is told anything beyond that you declined.
Signing in never joins you anywhere by itself, and an invitation you leave open does not stop you from creating your own organization.
Leave an organization
Under Members, Your membership has Leave organization. You lose access to the organization's projects right away; nothing in them changes. To come back, an admin has to invite you again.
Delete your account
Your Account page ends with a Danger zone and Delete account. Before anything happens it shows what goes: your sign-in methods and passkeys, your memberships, and any personal API tokens. Tokens you created for an organization belong to it and keep working. Your organizations keep their projects, billing history and support tickets; where those name you, they say "deleted user" instead of your address.
You type your email to confirm, every session signs out at once, and one last email confirms it. There is no undo: signing in again with the same address starts a new, empty account.
While you are the only owner of an organization, the button is off and the organization is listed. Delete it, or make another member an owner, first. From the terminal: klops account delete <your-email>, with --dry-run to see the list without deleting.
Narrowing access to one project
A role applies to the whole organization. A per-project role, set under Members in the project's settings, raises or lowers one member's role on a single project, for example viewer on production. It does not hide the other projects: somebody who should only see one belongs in an organization of their own.
Use it sparingly. Per-project overrides are how an access model becomes something nobody can reason about; two organizations are often the clearer answer.
Settings reference
| Setting | Default | What it does |
|---|---|---|
| Role | member | The organization-wide permission level. |
| Per-project role | none | admin, editor or viewer on one project, replacing the organization role there. |
| Invitation | pending | Grants nothing until accepted. Revocable at any time. |
Limits and gotchas
- Removing somebody is immediate. They lose access to this organization's projects at once, their account keeps working, and anything they were running keeps running.
- Only admins create and delete projects. A member works inside the projects that exist, and deleting one needs admin on that project.
- A per-project role replaces the organization role on that project, higher or lower, so a member set to viewer on production cannot deploy there.
- Everyone sees what the organization spends. Usage, Plan and Statements are open to every member; only admins and owners change the plan.
- An SSO group is not an invitation. On a self-hosted install, when your platform administrator maps a sign-in group to the organization, its members are in automatically, and only a change to that mapping takes them out. You can't leave such a membership from Members.
The only owner cannot be removed, demoted or leave, since nobody could then rename or delete the organization. Make someone else an owner first.
Related
- Organizations, projects, workloads for what an organization contains.
- Plans and costs for what the organization pays, which every member can see.