# Projects and Environments

Understand the names you will see while deploying and operating an application.

Canonical: https://docs.deliberate.space/start/model/

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.

## Next steps

- [Configure an application Project](/build/configuration/)
- [Understand the complete YAML vocabulary](/reference/yaml/)
- [Test a Project revision in a preview](/deploy/environments/)
