Projects

Projects are the organizational unit inside your vault. Every secret belongs to exactly one project. Machines are added to specific projects. Organization members are scoped to specific projects. Nothing crosses a project boundary without an explicit grant.

Creating a Project

From the Overview page, click the + on the Projects card and choose New project. The sidebar offers the same action at the top of the Projects section. (The same menu also offers New application, which creates a service's Prod, Staging, and Dev projects together; see Applications.)

Name the project (up to 100 characters), optionally add a description, and create. It appears in the sidebar under Projects.

Applications

An application is a named set of projects for one service: a Prod, a Staging, and a Dev project, created together. Creating an application provisions those three projects in one step, and the dashboard and CLI group them under the application. The projects are created with the application: you cannot move an existing standalone project into one, and its projects cannot be renamed or deleted individually. Standalone projects, those in no application, work exactly as described on this page. See Applications for the full model.

Project IDs

Every project gets a unique ID in the format proj_ followed by 10 random alphanumeric characters (e.g. proj_x9y8z7w6v5). The ID is what you pass to the SDK and CLI. You can copy it from the project header on the secrets page.

What a Project Groups

• Secrets you create inside it (single-value, structured, managed, or TTL)
• Machines you have added to it
• Organization members scoped to it
• Access policies scoped to it (see Access Policies)

Adding any of these to a project never implies access by itself. Each relationship is a separate explicit grant.

The project sidebar surfaces three sub-pages for each project: Secrets, Policies, and Machines. Policies are project-scoped reusable bundles of access constraints (time windows, IP allowlists, rate caps, co-sign, lifecycle triggers) that you bind to secrets opt-in. Read the dedicated Access Policies page for the full model.

Machines in a Project

A machine registered with your vault is not automatically in any project. From the project's Machines tab, click the + icon (hover tooltip: "Add machine to project") and pick the machine.

Adding a machine only makes it eligible to receive secret grants in the project. It cannot read anything until you configure the grants.

Granting Secret Access

Click Configure next to the machine to open the access panel. Move secrets from Available to Granted and save. The machine can now read the granted secrets and nothing else.

There is no wildcard, no "grant all", no inheritance. A machine in a project with access to the database password cannot read the Stripe key in the same project unless you grant it explicitly.

To revoke access, move secrets back to Available and save. The revocation takes effect on the machine's next request.

Removing a Machine from a Project

Removing a machine from a project revokes all its secret grants within the project immediately. The machine itself stays registered in your vault and can be added to other projects without re-bootstrapping.

Organization Members

If you convert your vault to an organization, other people can act inside it. A member's access to a project is governed by their access role: which applications and projects it brings into scope, and what it lets them do in each. A member sees and acts on only the projects their access role grants.

Secret management in the dashboard never exposes plaintext. Even a member with full secret-management capability works on metadata and configuration; reading a raw value always requires an authenticated machine with its own per-secret grant.

What a member can do in a project is governed by their access role: per-project toggles for managing each secret kind, adding and removing machines, and authoring access policies. The full model lives in the Organizations docs: see Vault Roles & Access Roles.

Renaming or Editing

In the sidebar, hover over a project to reveal the edit icon. Click it to open the edit dialog and update the name or description. This is a metadata-only change: encryption, machines, secrets, and grants are unaffected.

Projects that belong to an application cannot be renamed individually; manage the application instead. See Applications.

Deleting

Hover over a project in the sidebar to reveal the delete icon. Deletion requires you to type the project name exactly as confirmation.

Deleting a project permanently removes:

• All secrets in the project, including full version history
• All rotation schedules and managed secret agent configurations
• All TTL secrets created in the project
• All access policies scoped to the project, and the bindings that referenced them
• All machine-to-project memberships for this project
• All machine-to-secret grants for the project's secrets
• Any organization-member capabilities scoped to this project

Machines and members remain in your vault. They lose only their relationships to the deleted project.

Projects that belong to an application cannot be deleted individually; deleting the application removes all of its projects at once. See Applications.

This cannot be undone.