Projects and environments
Create a project and an environment, and grant a role that reaches only one of them.
A project groups the places you deploy to. An environment is one of those places, and it holds the keys your app reads. Projects in the sidebar is the top of that tree.
The project list
/projects lists every project with a count of its environments and the date it was created. The header carries your plan badge, and the button becomes an upgrade prompt once the plan's project limit is used.
Free allows 3 projects and 3 environments per project. Pro and Enterprise allow as many as you like. The counts on the page are advisory. The write is what enforces the limit.
One project
/projects/[projectId] lists that project's environments with a count of keys in each. Two buttons sit in the header: Access, shown only to somebody who could read the page it leads to, and the one that adds an environment.
Who can reach this project
/projects/[projectId]/access is the page that answers "who could reach production". It lists every grant on the project and on each of its environments, naming the person, the role they hold and where it reaches.
Granting from here is how somebody gets an environment they do not hold at the workspace level. There is no separate production unlock. Access to an environment is a role scoped to that project or that environment, and this page is where it is given.
You cannot grant a role carrying a permission you do not hold yourself at that scope. The picker hides those roles, and the server checks again, because a form post goes around the picker.
What each action needs
| Action | Needs | Confirm it is you | Recorded as |
|---|---|---|---|
| Open the project list | project:read | No | not recorded |
| Create a project | project:create | No | project.created |
| Create an environment | environment:create on the project | No | environment.created |
| Open the Access page | member:read on the project | No | not recorded |
| Grant a role there | member:role_assign at the target scope | No | role.assigned |
| Revoke a grant there | member:role_assign at that scope | No | role.unassigned |
The scope you name is checked rather than trusted. The project is derived from the environment, so a grant on one project can never authorize an environment belonging to another.
A project created by penv push from the command line lands the same project.created entry the console does, carrying the agent session that asked for it.
role.assigned and role.unassigned are written to the record but are missing from the action filter on the Audit Log page. Narrow by actor and date, then export. See browsing the record.
Next: keys and their values.