Projects and Environments

You only need five concepts to find your way around the console, CLI, and YAML.

Team: who owns it

A Team owns Projects, people, billing, published Blueprints, and shared access policy. The active Team selected by the CLI must match the Team pinned in .deliberate/project.yaml.

Project: what you deploy

A Project is one version-controlled desired-state tree. Its identity and Environment flow live in project.yaml; resources live in the other YAML files below .deliberate/.

Environment: where it runs

An Environment is one running revision of a Project, such as production or preview-pr-42. Creating a derived Environment copies the complete Environment according to the Project’s Flow, including supported data resources.

Component: one running process

A Component runs one container image as a web service, worker, or scheduled job. It may consume databases and storage, expose routes, and declare health and alert policy.

Blueprint: a maintained application

A Blueprint is a versioned application definition published by a Team. A deployed Blueprint is an instance inside an Environment and may manage several Components, databases, storage resources, and nested Blueprint dependencies.

Resource: one declaration

Each YAML document declares one resource, identified by resource:. Resources are namespaced by Project and Environment. Explicit references under needs authorize dependencies, their outputs, and their network edges.