Projects
The boundary every secret, server, and grant is scoped to, and the reason to have more than one.
What a project is
A project is the access boundary. Every secret, server, database, cloud credential, profile, runbook, and grant belongs to exactly one, and permission is resolved per project.
That is the only structural decision the product asks you to make, so it is worth making on purpose.
How to split them
Split by blast radius, not by tidiness. The question is not "what belongs together" but "who should be able to reach this without reaching that".
| Situation | Projects |
|---|---|
One application, several environments |
|
Several applications, one team, same trust level | One project each, so an incident in one does not widen into the others. |
A client engagement | One project per client. Ending an engagement is then removing one membership. |
A monolith and its worker fleet | One project. They share credentials and the same people operate both; splitting adds friction and no boundary. |
Permissions on a project
A member's workspace role is their default on every project. A per-project membership overrides it for that project alone, which is how "developer in staging, read-only in production" is expressed.
The override can lower as well as raise. A workspace admin can be reduced to viewer on one particularly sensitive project.
See Roles and permissions for how a decision is actually reached.
Creating and deleting
Admins create projects under Projects → New project. A project has a name, a slug used by shortspan project use, and an environment label. Free allows three; every paid tier is unlimited.
The project page
A project's page shows what it contains and who can reach it: secret and group counts, registered infrastructure by kind, profiles, runbooks, active temporary grants, and recent activity. It is the fastest way to answer "what would someone with developer access here actually be able to do".
Something here wrong or missing? Tell us.