Projects and environments

Projects

A project holds everything one product needs: its services, databases, domains, secret groups, buckets and jobs, the repositories it builds from, its members and their roles, its tokens and its audit log. Its slug, such as rungholt, is fixed when it is created.

People reach a project through a membership with a role. The roles that come with ops:

role	may
Project admin	everything in the project: settings, members, resources
Developer	build, deploy and operate services; no settings, no members
Viewer	read everything, change nothing
Deployer	a machine that deploys what ops built

A project admin can make roles of the project's own under Settings, Access.

Environments

An environment is one running copy of the project, with its own services, databases, domains, secret groups and jobs. A bucket belongs to the project, not to one environment.

environment	how it gets there	what it runs
`production`	made with the project	the default branch, deployed on every push
`staging`, `development`	added in Settings, Environments	a branch it follows, or only what you promote into it
`preview-<n>`	opened by a pull request	the pull request's branch, see previews

Leave an environment's branch empty and it changes only when you promote into it.

Each environment has its own private network. A service reaches the other services and databases of its own environment and nothing in another one, so a staging service is never handed production's database.

The console's sidebar picks the environment under the project name, and every page follows it. The CLI acts in production unless you pass --env:

ops resources --env staging
ops deploy web --commit 7c1d0e2 --env staging

Quota

Each environment has a CPU and memory budget. Production gets 16 cores and 32 GB, every other environment half of that. A project admin can change an environment's figures in Settings, Quota.