Core Concepts
Projects & Roles
Organizing your secrets
Project Structure
Envault organizes secrets into Projects. Each project typically corresponds to a specific application or service (e.g., "Main Website", "Backend API", "IOS App").
Projects are cleanly structured via semantic routing (e.g., /[username]/[project-slug]), allowing for global uniqueness and easy navigation between owned and shared projects.
Hierarchy
Roles and Permissions
Envault implements a Role-Based Access Control (RBAC) system.
| Role | Description | Capabilities |
|---|---|---|
| Owner | Full administrative access | Manage settings, delete project, Read/Write secrets, approve share requests. |
| Editor | Active contributor | Read and Write secrets. Can initiate Share requests (requires owner approval). Cannot delete/rename the project. |
| Viewer | Read-only access | Can only Read (pull) or download secrets. Entirely blocked from modifying settings or initiating shares. |
Sharing Projects
You can invite team members to your project via email. They will receive an invitation link to join.
Transfer Ownership
Owners can initiate transfer from the project settings dropdown using Transfer Ownership.
- Transfers are pending until the target user accepts.
- Target users can reject requests without ownership changes.
- Pending transfer requests expire after 48 hours.
- During acceptance, Envault performs ownership promotion/demotion and secret liability reassignment atomically to avoid partial permission states.
- In delete confirmation dialogs, owners also get a quick Transfer ownership instead action to avoid accidental project deletion.