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

# Pipelines concept

> Pipelines orchestrate builds, deploys, and other code-execution tasks across Ravion modules and environments using reusable, declarative steps.

Ravion Pipelines are a full featured CI/CD system that runs in your cloud account.

They are *optional* for you instead of using GitHub Actions or Circle CI.

Regardless, you will need to have a pipeline *somewhere* to build your code, upload the artifacts to a store, and trigger a deployment of that in Ravion.

```mermaid theme={null}
flowchart LR
  GitPush[Git push or API] --> BuildCode[Build code]
  BuildCode --> TriggerDeploy[Trigger Ravion deploy]

  class GitPush source
  class BuildCode build
  class TriggerDeploy deploy

  classDef source fill:#F6DDCE,stroke:#FE6104,color:#2a1208
  classDef build fill:#1f2937,stroke:#111827,color:#fff
  classDef deploy fill:#FE6104,stroke:#BD4406,color:#fff
```

### Two kinds of pipeline runs

Pipelines fill two roles in Ravion, and you'll see both in your run history:

1. **Pipelines you author** — build and deploy workflows triggered by git pushes, the API, or manually. These are the optional replacement for GitHub Actions described on this page.
2. **Stack pipelines** — the change and destroy pipelines attached to every module [stack](/modules/stack), which run Terraform plan → approval → apply whenever a module's infrastructure config changes or the module is deleted. By default these are Ravion-managed system pipelines; your platform team can substitute custom ones.

When other docs mention a "stack change pipeline run", it's the second kind: a normal pipeline run that was triggered by a config change instead of a git push.

### One pipeline, many environments

A pipeline describes a workflow, not an environment. Don't create a "Production pipeline" and a "Staging pipeline" — create one pipeline named after what it does, like **Build & Deploy**, and add a [variant](/pipelines/variants) per environment. Steps reference module instances through `<< pipeline.variant.id >>`, so the same steps deploy to whichever environment a run targets:

```yaml theme={null}
variants:
  - id: production
    name: Production
  - id: staging
    name: Staging
steps:
  - id: deploy_web_app
    type: deploy
    # resolves to production.web-app or staging.web-app
    module_instance: << pipeline.variant.id >>.web-app
```

### You might want to use Ravion pipelines for the following reasons:

<Steps>
  <Step>
    You get **a single pane of glass and CLI/API surface area** to see all your builds, deploys, and infrastructure.
  </Step>

  <Step>
    You get **enhanced security and control** because you no longer have to open up your database or
    image registries to GitHub Actions. Ravion pipelines execute entirely in your cloud account.
  </Step>

  <Step>
    You can **define all your build configuration in the module** alongside your runtime config.
  </Step>
</Steps>

```mermaid theme={null}
flowchart LR
  Ravion[Ravion control plane]

  subgraph CustomerCloud[Your cloud account]
    subgraph VPC[Your VPC]
      Runner[EC2 runner]
      PrivateResources[Private resources]
    end
  end

  Ravion --> Runner
  Runner -- accesses --> PrivateResources

  class Ravion external
  class CustomerCloud,VPC cloud
  class Runner runner
  class PrivateResources resource

  classDef external fill:#FE6104,stroke:#BD4406,color:#fff
  classDef cloud fill:#F6DDCE,stroke:#FE6104,color:#2a1208
  classDef runner fill:#1f2937,stroke:#111827,color:#fff
  classDef resource fill:#fff,stroke:#BD4406,color:#2a1208
```

See [Pipeline configuration](/pipelines/config-reference) for the detailed config schema.