Team management

Vaultic layers three things on top of each other, from broadest to narrowest:

1. A workspace-wide role per member.
2. Optional per-project or per-environment access grants that narrow or broaden that role.
3. Service tokens for machines instead of people.

Workspace roles

Every member has one workspace-wide role: owner, admin, developer, or read-only. Owners can't be demoted or removed except by another owner. Invite someone by email and role from the web app's Team page or with vaultic workspace invite — both generate a shareable accept-invite link rather than sending an email themselves.

Access grants

Roles apply everywhere in the workspace. If you need someone to touch exactly one project (or even one environment within it) without making them a developer or admin everywhere, grant them scoped access instead:

vaultic access grant dev@example.com --role developer --env production

Access grants are additive on top of a role, never a replacement for one — see Access, team & tokens for the full grant/revoke reference and how an environment's Access tab shows the resulting effective permissions.

Service tokens

Machines don't log in — they use scoped service tokens instead, created with an access level (read-only or read/write), an optional scope (one environment, one project, or the whole workspace), and an optional expiry:

vaultic tokens create ci-deploy --env production --read-only --expires 90d

The token value is shown once, right after creation — store it immediately, since it can't be retrieved again. Service-token reads never consult personal overrides, so what a deploy pulls is always the same value a teammate would see with --reveal, not whatever they've locally overridden for themselves.

Next steps