Skip to content
Esc
↑↓navigate↵open⌘Jpreview
On this page

Onboard and offboard your team

Give a new teammate the right role and a working CLI on their first day, and cut off their access cleanly when they change jobs or leave.

CLI v7.7.0

This page follows one person through a team: choosing their role, inviting them, their first day with the CLI, changing their access, and what to do after they leave. It links to the reference pages for the details.

Prerequisites

  • The Owner or Admin role in the team. Only they invite, change roles and remove people.
  • A confirmed email address on your own account. varsafe asks you to confirm it before you invite anyone.

1. Choose a role

Each member has exactly one role per team. Pick the narrowest one that covers the work:

This person needs to… Role
Manage members, API tokens, environments and production secrets Admin
Change development and staging secrets, and read production Developer
Read every environment, production included, without changing anything (on-call, support) Operator
Read development and staging configuration, never production Viewer
Handle invoices and the subscription, with no access to secrets Billing

The Owner role is not on this list: a team has exactly one owner, at first the person who created it, and ownership is only transferred, never given by invitation. When unsure, start with Developer, the role the invitation form suggests, or narrower. You can widen it later.

Roles and permissions has the full matrix, including who can create projects, read the audit log and manage billing.

2. Protect production before inviting

A role’s reach depends on which environments are protected. In a protected environment, developers can read but not write, and viewers and billing members cannot read at all. Only owners and admins can write there, and only they can turn protection on or off.

Every new project starts with Production protected. Before the first invitation goes out, check the environments that hold real values:

  1. Open Secrets, pick the project, and look at the environment tabs. A protected one shows a Protected pill.
  2. To protect another environment, such as a staging that shares production credentials, open Manage environments from the gear icon next to the tabs, click the pencil next to the environment, turn on Protected and Save.
  3. Duplicated environments start unprotected. Protect any copy that holds production values.

Whatever its protection, a viewer can never read an environment whose slug is production. See Protect an environment.

3. Invite someone

  1. Open Teams in the dashboard and click the team to expand it.
  2. Click Invite member.
  3. Enter their Email address: the one they will sign in with. The invitation only works for an account with that exact address.
  4. Choose a Role. The info icon next to it (Compare roles) opens the permission grid.
  5. Click Send invite.

They receive an email with a link. The invitation expires after 7 days. Until then it is listed on the team, where × cancels it. To send a fresh link after it expires, invite them again.

Your plan limits how many people a team can hold. On the Developer plan, three members are free, and more need paid seats, up to 25. The Team plan has no practical limit. If the team is full, the invitation is refused. If it fills up before they accept, accepting is refused until a seat is free. See Billing and plans.

If your team uses single sign-on, colleagues on your verified email domain can join by signing in through your identity provider, without an invitation.

4. The new teammate’s first day

Send this section to the person you invited. It takes about ten minutes.

Accept the invitation

  1. Open the link in the invitation email.
  2. Click Create Account if you are new to varsafe, or Sign In to Accept if you already have one. Use the address the invitation was sent to: if you are signed in under another address, the page says so and asks you to sign in with the right account.
  3. Click Accept Invitation.
  4. If you have not confirmed your email address yet, varsafe asks you to before you join. Click Send verification email and open the link it sends. It brings you back to the invitation, even on another device. Accept again.

The page confirms that you joined the team and opens Teams, where the new team is listed with your role.

Install the CLI and sign in

Install the CLI (it is a single binary, not an npm package), then open a new shell:

curl -fsSL https://varsafe.dev/install.sh | bash

Sign in:

varsafe login

Your browser opens on varsafe and the terminal shows a short code. Type the code into the page, check that it matches the terminal, and then choose what this login may do:

  • Read only: browse projects, environments and secret names. Values stay hidden.
  • Standard (the default): what varsafe run, get and export need. It reads values and changes nothing.
  • Full access: adds creating, updating and deleting secrets.

Below the access level, a summary line names the team the login will cover. Click it to open the list of your teams and tick the team you just joined: only the teams ticked there are reachable from this login, and the page preselects just one. Then click Authorize.

Whatever you choose, the login can never do more than your role allows in each team.

Run your project

Clone the repository and work from inside it. If the repository has a committed .varsafe file at its root, it already selects the project and environment, and every command uses them. If not, choose them once:

varsafe use

Check that a secret reaches your command without printing its value:

varsafe run -- sh -c 'echo "${DATABASE_URL:+set}"'

It prints set when DATABASE_URL was injected. Replace DATABASE_URL with a key your project has. If you are refused, the selected environment is one your role cannot read; name another one for that command, with the project too, for example varsafe run -p my-api -e development -- npm start: a flag on its own skips the .varsafe file and takes the project from your user-level context. varsafe whoami shows the credential this machine is using and what it may do.

What your role will not let you do

Role What is refused
Developer Changing a protected environment, such as production. varsafe set and varsafe unset there are refused; reading works. Managing members, tokens and environments.
Operator Changing any secret. Reading works everywhere, production included.
Viewer Reading protected environments and any environment whose slug is production, and changing any secret.
Billing Any access to secrets, from the dashboard, the CLI or an agent.

To connect a coding agent, see Connect an agent. The agent’s access is capped by your role in the same way.

5. Change a role, deactivate or remove

Open the ⋯ menu next to a member on the Teams page. The three actions treat credentials differently:

Action What happens to their access
Change role Takes effect at once. Their CLI logins for this team, their agent connections and the API tokens they created are revoked. They sign in again under the new role.
Deactivate member Nothing is revoked. They keep full access for a 7-day grace period. After it, they keep their role but lose all access, including CLI logins, agent connections and the tokens they created. Reactivate member restores it.
Remove from team Takes effect at once. Their CLI logins for this team, their agent connections and the API tokens they created are revoked, and their membership ends.

A few consequences are easy to miss:

  • Their other teams. A CLI login loses only this team; it keeps working for the person’s other teams. An agent connection is different: one connection can cover several teams, and changing the person’s role or removing them in one team revokes the whole connection, including the teams they still belong to. They reconnect their agent through the consent screen to keep using it in their other teams. See Manage connections.
  • Pipelines on their tokens. An API token stops working when the person who created it is removed or changes role, so a pipeline that runs on one of their tokens breaks. Before you remove someone, find the tokens they created: in the Audit log, search for their email address and filter All actions to Created API token. Rotate each one from the team’s API tokens list, which issues a new value under your name, and update the pipeline’s CI variable. See Narrow, rotate or revoke a token.
  • Deactivation is not immediate. Use it for a planned departure or a leave of absence. To cut someone off now, remove them.
  • The owner cannot be deactivated or removed, and cannot leave. Transfer ownership first, from the team’s Team Settings. A member other than the owner can also leave a team themselves, with the same effect as removal.

6. After someone leaves

Revocation stops new access. It cannot take back what the person already had:

  • Values they read stay known to them. Anything they revealed in the dashboard, fetched with varsafe get, or injected into a process on their machine.
  • Files they kept. A plain .env file they exported with --plain still holds the values. An encrypted .env file no longer opens for them, because varsafe opens those only for someone still allowed to read the environment. The exception is a private key downloaded with a version from before July 2026: it still decrypts, offline, the files encrypted with it.

So rotate, at the source, every secret they could read that matters: the database password, the third-party API key, the signing key. Start with protected environments. Secret rotation has the runbook.

To see what they accessed, open the Audit log and search for their email address. The search matches the email of the person who acted, so it lists what they did: the secrets they read and exported, and the API tokens they created, among the rest. See Find an event.

7. Review access periodically

Once a quarter, check each team for people who have left, roles wider than the work needs, and deactivated members who should be removed. On the Team plan, the Access Review button on the Audit log page produces a report of every member, their role and which environments it reaches. Access reviews has the checklist.