Standalone Projects
Create an independent project for a workload, then manage its secrets, machines, policies, member access, and lifecycle.
Standalone projects give a workload, environment, or team its own place for secrets, machines, policies, and member access. Each project is created and managed independently, so you can choose its name, purpose, access model, and lifecycle.
Every standalone project has its own encryption key. Secrets, machine memberships, secret grants, policies, and organization access are configured within that project.
#How standalone projects work
A standalone project is a project that sits directly in the Projects & Applications area of the sidebar. It provides one complete boundary for the resources required by a workload.
Project resource | How it is scoped |
|---|---|
Secrets and versions | Stored and versioned in the project |
Machines | Added to the project before they can receive secret grants |
Secret grants | Granted to a machine one secret at a time within the project |
Access policies | Created in the project and attached to selected secrets |
Organization members | Given project visibility and capabilities through an access role |
Encryption | Protected with the project’s own encryption key |
Canary freeze | Locks machine reads for this project when its configured trigger fires |
Standalone projects work well for isolated workloads, one-off environments, shared infrastructure, teams with their own access requirements, and services that do not use the fixed Prod, Staging, and Dev structure of an application.
A standalone project remains independently managed throughout its lifetime. When you need the three-environment application structure, create an application and place the required resources into its Prod, Staging, and Dev projects.
#Create a standalone project
You need permission to manage projects in the vault.
Find Projects & Applications in the dashboard sidebar.
Select New project.
Enter a project name between 1 and 100 characters.
Add an optional description that explains the workload, environment, or owner.
Select Create Project.
The dashboard opens the new project’s Secrets page. The project also appears directly in the sidebar with its name, description, and current secret count.
Choose a name that provides enough context on its own, such as Shared CI, Data Platform, or Customer Portal Production. Standalone projects are listed without an application name above them.
#Find and identify a project
Select a project in the sidebar to open its Secrets page. Expand the project to move between Secrets, Policies, and Machines. The available links reflect the access provided by your organization role.
The number beside the project name is the number of active secrets currently in the project.
A Frozen badge appears when a canary trigger has frozen machine reads for the project.
The project ID appears in the Secrets page header with a copy button.
Project IDs begin with proj_ followed by 10 letters and numbers.
The project ID is the stable identifier used when a command, SDK, machine workflow, or integration needs to select the project. Renaming the project does not change its ID.
#Add and manage secrets
Open the project’s Secrets page to create and manage the credentials used by the workload. The selected project is applied to every action on the page.
Standard secrets store a single value.
Structured secrets store named fields together.
Managed secrets synchronize values from a connected provider.
Rotating secrets generate new values on a schedule.
Canary secrets detect unexpected machine access and can trigger protective actions.
Temporary secrets create expiring, human-recipient shares.
Leased secrets issue temporary database credentials on demand.
Secrets remain inside the project where they were created. Their versions, rotation settings, access policies, and machine grants are managed in that same project.
#Add machines and grant access
A registered machine must join the project before it can receive access to the project’s secrets. Project membership and secret grants are separate controls.
Expand the project in the sidebar and open Machines.
Select the plus button.
Find and select an approved machine.
Save the project membership.
Open the machine’s row menu and select Configure.
Select the individual secrets the machine may read.
Save the secret grants.
A machine can belong to multiple projects, but each project membership and secret grant is configured separately. Removing a machine from this project removes all of its grants here while preserving its machine identity and access to other projects.
Adding a machine to a project makes it available for secret grants. The machine can read only the secrets you explicitly grant to it.
#Create and apply access policies
Open Policies beneath the project to create reusable access rules, then attach a policy to the secrets it should protect. A policy can combine controls such as time windows, source-address rules, read-rate limits, co-signing, and credential lifetime settings.
Policies are configured per project. This lets the same machine have different requirements when it reads secrets from different projects.
#Give organization members access
In an organization vault, access roles determine which members can see a standalone project and what they can manage inside it.
Open Organization, then Access roles.
Create or edit an access role.
In Scope, find Standalone projects and select the project.
Choose the Secrets, Machines, and Policies capabilities the role should receive.
Save the role and assign it to the appropriate members.
A project placed in scope with every management capability turned off provides view-only access. You can also select the broad scope View & manage all standalone projects when a role should cover every current and future standalone project.
Capability group | Examples of controlled actions |
|---|---|
Secrets | Manage selected secret kinds, including standard, structured, managed, canary, temporary, and leased secrets |
Machines | Add machines, remove machines, and configure machine-to-secret grants |
Policies | Add or remove policies and configure their individual controls |
#Respond to a frozen project
A canary secret can be configured to freeze its project when a granted machine reads it. While the project is frozen, every machine fetch in that project returns Locked, regardless of the machine’s normal grants. The sidebar displays Frozen and the Secrets page shows which canary triggered the freeze and when it happened.
Open the frozen project’s Secrets page.
Review the canary ID, trigger time, offending machine, and source address in the project banner and Audit Log.
Investigate and contain the unexpected access.
As the vault owner, select Unfreeze when machine access is safe to resume.
Unfreezing restores machine reads but keeps the canary armed. If the underlying cause is still present, another read can trigger the freeze again.
#Rename or update a project
Find the standalone project in the sidebar.
Select the edit icon beside its name.
Update the name or description.
Select Save.
The change updates the project’s display information. Its project ID, encryption key, secrets, policies, machines, grants, access-role scope, and audit history remain associated with the same project.
#Delete a standalone project
Deleting a project permanently removes the project and its stored contents. This action cannot be undone.
Find the project in the sidebar.
Select the delete icon beside its name.
Review the permanent-deletion warning.
Enter the exact current project name.
Select Delete Project.
Deletion removes the project’s secrets and version history, temporary secrets, rotation and managed-secret configuration, machine-to-secret grants, and machine memberships. Active leased credentials are queued for cleanup. Registered machine identities remain in the vault, but their relationships to the deleted project are removed.
The confirmation name must match exactly, including capitalization and spacing. After deletion, the dashboard clears the project selection and returns to the vault overview.
#Permissions and visibility
Access | Result |
|---|---|
Vault owner | Can see every standalone project and manage its lifecycle |
Manage projects permission | Can create, rename, and delete standalone projects |
Project included in an access role | Member can see the project and use its enabled capabilities |
All standalone projects broad scope | Member receives full view and management across every standalone project |
Project outside the member’s scope | The project is not shown to that member |
Vault owner during a freeze | Can unfreeze the project after reviewing the incident |
#Troubleshoot standalone projects
Symptom | What to check |
|---|---|
Project is missing | Confirm that your access role includes the project or the broad scope for all standalone projects. |
New project button is missing | Confirm that your vault role includes permission to manage projects. |
Policies or Machines link is missing | Confirm that your project access includes the corresponding view and management capabilities. |
Machine cannot read a secret | Confirm the machine is approved, belongs to the project, has an explicit grant for the secret, and satisfies its access policy. |
Machine receives Locked | Check whether a canary trigger has frozen the project. Review the Audit Log before the vault owner unfreezes it. |
Project ID changed in a local configuration | Copy the stable project ID from the Secrets page header; renaming changes only the display name. |
Delete confirmation is unavailable | Enter the current project name exactly, including capitalization and spacing. |