Projects

A project is the place you work. It is a container in its own right: it holds vaults, the task workflows over them, its DevOps secrets, and its own members. Entering a project takes over the sidebar the same way opening a vault does, so everything you see while you are inside it belongs to that project.

Projects live at Projects in the console (/console/projects), and each one opens at /console/projects/<slug>. They are available from Solo Professional upward; the Members tab (and everything about staffing a project) starts at Team — see Which plans include projects.

The projects list#

Projects shows a card per project — its icon, name, permanent slug, a DevOps tag when the machine plane is on, a Default tag on your own default project, and how many vaults and members it has. Cards are alphabetical. New project is offered only if your organization has let you create projects.

• Search matches name or slug ("Search by name or slug…") and reports "N of M projects match".
• The reserved Shared project is pinned in its own row above the grid, tagged System.
• Active / Archived tabs split the list; the Archived tab carries a count. See Archiving, restoring and deleting.
• You see the projects you are on. If you are a member of some projects — directly or through a team — and not others, the list shows only yours.

What a project holds#

Contents	What it means
Vaults	Any number of vaults are attached to the project. A vault belongs to at most one project.
Task workflows	Tasks scoped to the project itself, plus every task in the vaults it owns.
DevOps secrets	Namespaces, machine identities, permissions, alerts and validation — when the project has the machine plane enabled.
Members	People and teams given a role on this project specifically.
Task settings	A key prefix, default priority, default assignee and a suggested tag vocabulary.

The project workspace#

Opening a project switches the sidebar to that project's own navigation:

Section	What it is for
Overview	The project at a glance — see the Overview.
Vaults	The vaults attached here — attach another, detach one, or open one in place.
Tasks	The project's board and list, rolled up over the project and its vaults.
Namespaces, Activity, Machine Identities, Permissions, Alerts, Validation	The project's DevOps secrets (the machine plane). These appear only when the project has DevOps Secrets switched on and your plan includes it. Machine Identities is shown only to people allowed to read machines.
Members	Who has access to this project, and with which role. Team and above only — hidden on Solo Professional.
Settings	Name, description, icon, DevOps switch, default environment, your default project, task settings, and archiving.

The Overview#

Overview is a health page for the project:

• A health strip — an overall verdict, how many things need attention and how many are critical, and a row of counts (vaults, members, and — with DevOps on — namespaces, secrets, machines and validated paths). Each count links to where it lives, and there is a refresh button.
• Needs attention — a queue of what has gone wrong. On a validation problem, Run check runs it again, Acknowledge marks it seen, and the clock button silences the alert for 60 minutes. Where an item needs a different action, Open takes you to it. An empty queue says "Nothing needs your attention".
• Get set up — with DevOps on, a getting-started checklist: Create a namespace, Issue a machine identity, Validate a credential. It disappears once all are done.
• Quick actions — shortcuts such as New namespace, New machine identity, Validation cockpit, Invite a member and Project settings, plus links to the CLI and quickstart docs.
• Machine activity — with DevOps on, the most recent machine requests in the project, filterable by All, Denied and Writes.
• A Turn on DevOps Secrets card when the machine plane is off, with Enable in Settings.

Creating a project#

1. Open Projects and choose New project.
2. Details — give the project a name, an optional description, and a slug. The slug is the project's address in every URL, and it is checked for availability as you type: you cannot continue until it comes back free.
3. Vaults — optionally attach vaults straight away, using the same searchable list as the Vaults tab. You can always do this later instead.
4. DevOps — on a plan that carries the machine plane, choose whether to enable DevOps secrets for this project. This step is simply absent on plans without it.
5. Review — everything the project will be created with, in one list: name, slug, description, the vaults about to be attached and the DevOps choice. Each row has an Edit link back to its step, and Create project lives only here.

You can jump back to any step you have already seen by clicking it in the step bar at the top — useful when the review shows you a typo.

Vaults in a project#

The Vaults tab lists what the project owns, and Attach vault opens a panel to add more. Each card opens that vault's full workspace in place, with the project's breadcrumb kept around you.

Attaching a vault makes it part of the project — its tasks roll up into the project's board, and the project's members can be given access to it. Detaching returns the vault to standing on its own; it does not delete the vault or touch a single secret inside it.

Choosing what to attach#

The panel lists every vault on your account, each with its description, encryption type, item counts and the date it was added — so you can tell two similarly named vaults apart before committing. Search matches the description as well as the name, which is usually the faster way to find the one you mean. Lists longer than ten vaults are paged.

Tick as many as you like and attach them in one go. They are attached one at a time, so if any is refused the panel stays open and marks that row with the reason — the ones that succeeded stay attached.

Tasks in a project#

The project's Tasks tab is the same surface as the global Task Workflows screen — the same inbox tabs, board, list and filters — scoped to this project.

"Scoped to this project" means the project and every vault it owns, rolled up into one view. A project with no vaults at all still has a working board, because a project is a task scope in its own right and not merely a label on its vaults. When the project owns more than one vault, a row of vault chips appears above the board; picking one narrows the view to that vault, and All vaults returns to the whole project.

Raising a task from inside a project scopes it to that project automatically, and locks the scope — a task raised here belongs here. Pick a different home on the global screen instead.

Task keys#

A project gives its tasks a readable key. Set a key prefix in the project's task settings and each new task takes the next number in sequence: ENG-1, ENG-2, ENG-3. Tasks with no project fall back to a generic TSK-… key.

Settings#

The Settings tab, for people with the project Admin role (everyone else sees it read-only, with a note saying so):

Setting	What it does
Name	Free to change at any time.
Slug	Shown but fixed, marked Permanent. There is no control to change it.
Description	Optional text about what the project is for.
Icon	The icon shown on the project's card and in the sidebar.
DevOps Secrets	Switches the machine plane on for this project. It is one-way once used: when a project is using it, the switch is locked on, because turning it off would strand every namespace, secret, machine identity and validation check beneath the project. Archive the project instead. On a plan without DevOps Secrets, the switch cannot be turned on.
Default environment	With DevOps on, the environment this project's secrets screens open on. Leave it unset to use the space default.

Select Save changes (or Discard) to apply. Your default project sits below as its own section: a per-person switch that makes this the project screens such as Tasks start on. It applies immediately, needs no Admin role and changes nothing for other members.

Task settings#

Under Settings, a project also carries the defaults its tasks inherit:

Setting	What it does
Key prefix	2–10 characters; prefixes every task key in the project.
Default priority	Prefilled on new tasks raised in this project.
Default assignee	A teammate proposed on new tasks.
Suggested tags	A vocabulary offered when tagging tasks here.

None of these are binding — they are the starting point for a new task, and every one of them can be overridden on the task itself.

Members#

Team Business Enterprise

A project has its own membership, separate from the vaults inside it. Add a person or a whole team and give them one of three roles:

Role	What it grants
Project admin	Full control of the project, including its settings and members.
Project DevOps	The machine plane — namespaces, machine identities and validation.
Project viewer	Read access to the project.

Only a project admin can staff a project — add a member, change a member's role, or remove one. A DevOps member or a viewer sees the member list read-only. An organization administrator holds project-admin authority on every project in the organization without appearing in any member list.

Changing a role changes vault access, because the three roles map to three different levels of it: admin gets edit access to the project's vaults, viewer gets read access, and DevOps gets none at all. So a role change revokes the access the old role granted and queues the new one — a teammate who already holds the vault key has to complete the key wrap before the member can decrypt again, exactly as when they were first added. The same page tells you which vaults now need their key rotating.

Archiving, restoring and deleting#

Archiving is a reversible way of putting a project away; deleting is not, and is a separate step.

Archive. Under Settings, Archive this project is confirmed by typing the project's slug exactly, because it takes a whole workspace out of circulation. The project moves to the Archived tab. Nothing inside it changes. If the project has DevOps Secrets on, archiving takes effect for machines immediately: pipelines reading its secrets start failing at once, and scheduled credential checks stop. The confirmation warns you about this.

Restore. On the Archived tab, Restore brings the project back with its vaults, members, secrets and machine identities exactly as they were, and machine access resumes. Archived cards are not links — an archived project can't be opened by its address, which is why these actions live on the card.

Delete permanently. Also on the Archived tab, for people allowed to delete projects. It asks you to type the slug and then confirm your master password, and it schedules the deletion rather than doing it: nothing is destroyed for 30 days. The card then shows Deletes in N days (or Deletes today), and its single action is Cancel deletion, which calls it off and returns the card to the ordinary archived state. When the 30 days pass, the project's namespaces, secrets, every version and its machine identities are destroyed and cannot be recovered. Vaults are not deleted — they leave the project and stay yours — and tasks keep their ticket keys. The slug stays reserved forever.

Which plans include projects#

Solo Pro Team Business Enterprise

Projects are included from Solo Professional upward. On Free, Premium and Family, projects aren't part of your plan, and neither are task workflows. The Members tab, project roles and everything about staffing a project need Team or above, so on Solo Professional a project is just you.

Related#

• Task Workflows — the work that lives inside a project
• Vaults, items & item types — what a project's vaults hold
• DevOps Secrets overview — the machine plane a project can enable
• Calendar — see task deadlines on a timeline