Skip to main content
Copy these complete pipeline configs as starting points. Each example is a full config file you can apply with ravion pipeline config apply <pipeline-id> --file <file> — see Pipeline config file. A pipeline describes a workflow, not an environment — name it after what it does, like Build & Deploy, and reuse it across environments with variants. Every example references module instances as << pipeline.variant.id >>.module-given-id, so with variant IDs that match your environment given IDs, the same steps deploy to whichever environment a run targets. Adjust module given IDs, repos, and AWS references to match your project. For every field and step type, see the configuration reference and step types.

​
Build and deploy

The simplest pipeline: build one module, then deploy it. Steps run sequentially in list order. The deploy pins the exact artifact by consuming the build’s image_digest output. One pipeline serves both environments: running the staging variant deploys staging.web-app, and the production variant deploys production.web-app — no duplicate pipeline needed.
pipeline.yaml
The remaining examples declare a single variant for brevity. Add a variant per environment the same way — the steps don’t change.

​
Parallel builds, then parallel deploys

Build two modules concurrently, and once both builds succeed, deploy both concurrently. Each parallel block completes before the next step starts, so no deploy begins until both builds finish. The build block sets fail_strategy: finish-all, so if one build fails the other still runs to completion before the block fails — the default cancel-all would cancel it instead.
pipeline.yaml

​
Build and test in parallel, then deploy

Run the module build and a custom CI step side by side, then deploy only after both succeed. The test step runs your commands on provisioned compute selected by the infrastructure block — reference a pre-configured execution environment with execution_environment_id, or an AWS account and region as shown here. The runner starts as a bare instance, so use setup actions to install tools like Node.js before your commands run.
pipeline.yaml

​
One image build, two deploys

Build a Docker image once with a build:image CI step, then deploy it to two module instances in parallel — for example, a web app and a worker that share the same image. The build pushes the image to ECR tagged with the commit input, and both deploys pin the exact pushed image by consuming the build’s image_digest output.
pipeline.yaml