> ## Documentation Index
> Fetch the complete documentation index at: https://docs.amnify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How It All Fits Together

Before diving into the individual concepts, it helps to understand how all the pieces of Amnify Deploy relate to each other. This page provides a mental model you can refer back to as you explore the rest of the documentation.

***

## The Four Building Blocks

Amnify Deploy is built around four entities. Each has a clear, distinct role:

| Entity         | Role                                                          | Lives in               |
| -------------- | ------------------------------------------------------------- | ---------------------- |
| **Template**   | The *what* — defines what infrastructure can be created       | Your GitHub repository |
| **Project**    | The *where* — groups and organizes related deployments        | Amnify Deploy          |
| **Deployment** | The *instance* — a template applied to a specific environment | Amnify Deploy          |
| **Pipeline**   | The *sequence* — orchestrates multiple deployments in order   | Amnify Deploy          |

***

## Entity Relationships

```mermaid theme={null}
flowchart TD
    GH["🗂️ Your GitHub Repository<br/>(Templates)"]
    T["Template<br/>e.g. 'Kubernetes Cluster'"]
    P["Project<br/>e.g. 'Platform Team — Prod'"]
    D1["Deployment<br/>e.g. 'EU Cluster'"]
    D2["Deployment<br/>e.g. 'US Cluster'"]
    PL["Pipeline<br/>e.g. 'Full Platform Rollout'"]

    GH -->|sync| T
    T -->|used by| D1
    T -->|used by| D2
    P -->|contains| D1
    P -->|contains| D2
    PL -->|runs in order| D1
    PL -->|runs in order| D2
```

Key relationships to understand:

* One **Template** can be used by many Deployments across many Projects
* One **Project** can contain many Deployments (but each Deployment belongs to one Project)
* A **Pipeline** references existing Deployments; it does not create new ones

***

## The Deployment Lifecycle

When a Deployment is executed, it goes through a structured lifecycle with two required approval gates:

```mermaid theme={null}
stateDiagram-v2
    [*] --> Queued: Execute triggered
    Queued --> Planning: Execution starts
    Planning --> AwaitingPlanApproval: Plan generated
    AwaitingPlanApproval --> Applying: Plan approved
    AwaitingPlanApproval --> [*]: Cancelled
    Applying --> Completed: Apply succeeded
    Applying --> Failed: Apply failed

    state "Awaiting Plan Approval" as AwaitingPlanApproval
```

Both approval gates are intentional safety mechanisms. No infrastructure change is applied without a human reviewing what will happen first. See [Deployment Lifecycle](/cspm-deploy/concepts/deployment-lifecycle) for the full breakdown.

***

## Templates Live in Your Repository

A critical aspect of Amnify Deploy is that **you own your templates**. They are not locked inside the Amnify platform. Your templates live in a GitHub repository under your organization's control, and Amnify Deploy syncs from that repository. You can add new templates, update existing ones, and version everything through standard Git workflows.

***

## Navigating the Concepts

Continue reading the individual concept pages in order:

1. [Projects](/cspm-deploy/concepts/projects) — How to organize your work
2. [Templates](/cspm-deploy/concepts/templates) — Your infrastructure blueprints
3. [Deployments](/cspm-deploy/concepts/deployments) — Instances of templates in action
4. [Pipelines](/cspm-deploy/concepts/pipelines) — Orchestrating multiple deployments
5. [Deployment Lifecycle](/cspm-deploy/concepts/deployment-lifecycle) — Statuses, approval gates, and the execution flow