Skip to main content

​
Pipelines

Pipelines let you deploy complex, multi-resource environments by chaining deployments together in a defined order. The key feature: outputs from one deployment automatically feed as inputs to the next.

​
Why pipelines?

Real-world infrastructure rarely consists of a single resource. A production environment might need:
  1. A VPC/VNet (networking foundation)
  2. Subnets and security groups (network segmentation)
  3. EC2/VM instances (compute — must reference the VPC)
  4. A database (must be in the same network)
  5. A load balancer (must reference the instances)
Without pipelines, you’d need to manually copy resource IDs between deployments. With pipelines, Amnify handles this automatically.

​
Output chaining

The core of pipelines is output chaining — outputs from a completed deployment become available as inputs for subsequent deployments.

​
How it works

  1. Each template defines outputs in its Terraform code (e.g., vpc_id, subnet_ids, security_group_id)
  2. When a deployment completes, Amnify captures these outputs
  3. The next deployment in the pipeline can reference these outputs as input variables
  4. This creates a dependency chain where infrastructure builds on itself

​
Example: VPC + EC2 + RDS Pipeline

Pipeline: "Production Network + Compute"

Step 1: Deploy VPC Template
  ├── Inputs: region, cidr_block
  └── Outputs: vpc_id, public_subnet_id, private_subnet_id, security_group_id

Step 2: Deploy EC2 Instance Template
  ├── Inputs: vpc_id ← (from Step 1), subnet_id ← (from Step 1), instance_type, ami_id
  └── Outputs: instance_id, public_ip, private_ip

Step 3: Deploy RDS Database Template
  ├── Inputs: vpc_id ← (from Step 1), subnet_ids ← (from Step 1), db_engine, db_size
  └── Outputs: database_endpoint, database_port
In this example:
  • Step 1 creates the network foundation and outputs the VPC ID and subnet IDs
  • Step 2 receives the VPC ID and subnet ID from Step 1 to deploy the EC2 instance inside the correct network
  • Step 3 receives the VPC ID and subnet IDs from Step 1 to deploy the database in the same network

​
Creating a pipeline

  1. Navigate to Deploy in the sidebar
  2. Go to Pipelines
  3. Click “Create Pipeline”
  4. Configure:
    • Name — Descriptive name for the pipeline
    • Cloud provider — AWS, Azure, or GCP
    • Description — What the pipeline deploys
    • Deployment order — Select and order the deployments that make up the pipeline
The deployments referenced in a pipeline must already exist. Create your individual deployments first, then assemble them into a pipeline.

​
Executing a pipeline

  1. Navigate to the pipeline and click “Execute”
  2. Amnify runs each deployment sequentially in the defined order
  3. Each step goes through the full plan → approve → apply cycle
  4. Outputs from completed steps are passed to subsequent steps
  5. Track progress across the entire pipeline in the Pipeline Run detail view

​
Execution flow

Step 1: Plan → Approve → Apply → Capture Outputs
           ↓
Step 2: Plan (with Step 1 outputs) → Approve → Apply → Capture Outputs
           ↓
Step 3: Plan (with Step 1 + 2 outputs) → Approve → Apply → Done

​
Pipeline statuses

StatusDescription
QueuedPipeline execution is queued
PlanningCurrent step is running terraform plan
Awaiting ApprovalCurrent step needs approval to proceed
ApplyingCurrent step is provisioning infrastructure
CompletedAll steps completed successfully
FailedA step failed — the pipeline stops

​
Referencing existing resources

Not every pipeline needs to create everything from scratch. You can also:
  • Reference existing VPCs, subnets, and security groups using the resource discovery dropdowns when configuring deployment variables
  • Mix new and existing resources — create a new EC2 instance in an existing VPC
  • Build incrementally — add new deployments to a project over time
For enterprises with existing network infrastructure (VPCs managed by a networking team, for example), use resource discovery to reference those existing resources instead of creating new ones. This works seamlessly with your organization’s existing governance model.

​
Common pipeline patterns

​
Network + Compute

Deploy a VPC first, then compute instances inside it:
  • VPC → EC2 instances
  • VNet → Azure VMs
  • VPC → GCE instances

​
Full application stack

Deploy the complete infrastructure for an application:
  • VPC → Subnets → Security Groups → EC2 → RDS → Load Balancer

​
Database + Application

Deploy a database first, then the application that connects to it:
  • RDS → Application (with database endpoint as input)

​
Multi-tier architecture

Deploy frontend and backend tiers in the same network:
  • VPC → Frontend instances → Backend instances → Database