Control access and deploy tokens
Access to a project is granted per environment, with read, write, and admin roles — and pipelines use tokens bound to a project and an environment, never the whole vault.
Who already has access
- The project creator and Vault managers have implicit administration on every environment.
- Everyone else needs a per-environment grant — for a
Pessoa(Person) or aGrupo(Group), with roleLeitura(Read),Escrita(Write), orAdministração(Admin). - A newly created project is visible only to the creator and managers until grants are issued.
- All of this is enforced on the server; the UI only reflects it.
Grant access per environment
- 1
On the matrix, open `Configurações do projeto` (Project settings) and go to the `Acesso por ambiente` (Access per environment) block.
Each matrix column's
⋯also has theGerenciar acesso(Manage access) shortcut, which opens settings already on the right environment. - 2
Select the environment and grant access.
Choose a
Pessoa(Person) or aGrupo(Group) and the roleLeitura(Read),Escrita(Write), orAdministração(Admin). A duplicate grant for the same subject on the same environment is rejected. - 3
Revoke with the trash icon when the access no longer makes sense.
Groups are the same team groups, created in Groups. Anyone who sees the project but lacks a sufficient role on an environment cannot read or write anything there — and anyone who cannot read any environment does not see the project.
Create a deploy token
- 1
In `Configurações do projeto` (Project settings), go to the `Token de deploy` (Deploy token) block.
- 2
Choose the scope: the project — and, optionally, a single environment.
The selector defaults to least privilege. For a pipeline that only reads, the read scope is enough; writes need the write scope.
- 3
Generate and copy the token immediately.
The token is shown once: "Copie agora — este token não volta a ser exibido." (Copy now — this token will not be shown again.) Store it in your CI provider's secret store.
- The token only works on project routes; legacy Vault routes reject it.
- It is bound to your project (and environment, when set) — if it leaks, the blast radius is one environment, not the vault.
- The owner's permissions are re-evaluated on every call: revoking the owner's access demotes the token immediately.
- Token reads are grouped by hour in the audit log, with a counter — a deploy loop does not flood the history.
CI usage
See the full pipeline flow — token in the secret store, MOVITERA_TOKEN, and movitera run — in Write and restore secrets in the CLI docs.
Follow the history
The Histórico (History) block in Configurações do projeto (Project settings) lists recent actions: creation, aggregated writes with the keys, reveals with author, exports, and grants issued and revoked. Token reads appear grouped by hour with a counter. History is visible only to the creator and Vault managers.
Danger zone
In the settings Zona de risco (Danger zone), Excluir projeto (Delete project) requires typing the slug to confirm. Deletion removes secrets, versions, environments, and access and revokes tokens scoped to the project. Deleting an environment is also cascading — and a project's last environment cannot be deleted.