EC2 VM
backend_type: ec2_vm. Connection: AWS. Status: production (GA).
Each execution is a dedicated EC2 instance (not ECS, not Fargate). This is the kind the warm-pool reconcile loop was designed around: GitHub's runner directory, EC2 instance lifecycle, and live disk-used percent are observed every tick.
When to choose it
- CI jobs that need a real VM, local disk, or instance-level IAM/SSM.
- Warm pools where you care about disk-pressure drain (full disks get reaped instead of hanging jobs).
- Debugging or specialized AMIs.
Choose Fargate when a task is enough. Choose EC2 Auto Scaling when ECS should schedule onto a shared ASG.
Connection
An AWS connection. Optional subnet_ids / security_group_ids pin placement; otherwise the default VPC is used.
Required config
| Key | Type | Meaning |
|---|---|---|
instance_type | string | EC2 instance type for the per-execution VM. |
Optional knobs
ami_id (SSM ECS-optimized AMI when omitted), subnet_ids, security_group_ids, key_name, capacity_type (ON_DEMAND / SPOT), spot_max_price.
Execution control
Suffixed workflows: runner.execution-{launch,stop,restart,sync,logs-sync}-ec2-vm. Pool reconcile: runner.pool-reconcile-ec2-vm. If a warm pool stops claiming jobs, use the operational notes in Runner management.
Purposes
CI and agent are both valid. Agent images are not the GitHub Actions runner image — mixing them on one group is the failure mode the eligibility gate exists to prevent.