Forge runs your GitHub Actions workflows on managed runners in Forge team AWS accounts — no infra management needed. You just write your workflow and pick the runner type.
| Runner Type | Description |
|---|---|
small |
Lightweight, cost-effective runner |
standard |
Balanced performance for general workloads |
large |
High-performance runner for demanding jobs |
metal |
Bare-metal runner for heavy workloads |
dependabot |
Dedicated runner for Dependabot automation jobs |
k8s |
Kubernetes pod runner for lightweight jobs excluding Docker-based actions |
dind |
Kubernetes pod runner supporting Docker-in-Docker (DinD) in rootless mode |
Add this snippet to .github/workflows/your-workflow.yml:
jobs:
build:
runs-on:
- self-hosted
- x64
- type: standard
For Kubernetes pods, use:
jobs:
build:
runs-on:
- k8s
If you need a runner type not listed here, contact the Forge team.
If your workflow needs to access external AWS resources (S3, EC2, etc.), check advanced doc.
runs-on: self-hosted and Forge runners will pick them up.Forge is designed for flexible, secure, and scalable CI/CD operations, integrating seamlessly with GitHub Actions. Key features include:
dependabot, small, standard, large, metal) to match workload needs.Forge supports automated dependency updates using Dependabot and Renovate Bot:
See the detailed comparison guide.
By default, Forge Runners do not require access to external AWS resources. However, if a team needs the runner to interact with resources (e.g., launch EC2 instances, access DynamoDB, S3, or Secrets Manager), IAM role-based access can be configured.
To allow the runner to access external AWS resources:
To configure role assumption, the external AWS account must allow the Forge runner’s role to assume its IAM role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::EXTERNAL_AWS_ACCOUNT_ID:role/ForgeRunnerRole"
}
]
}
Once the Forge runner assumes this role, it will have the permissions defined in the external AWS account’s IAM role (e.g., to launch EC2 instances, access S3, pull ECR, etc.).
If your runner’s AMI does not contain the necessary tools, you can run your job inside a Docker container.
To allow the Forge runner to pull a Docker image from Amazon ECR, you’ll need to create an ECR policy in the AWS account hosting the ECR repository. This policy should grant permissions to the Forge runner (or the IAM role it assumes) to pull images from ECR.
Example ECR policy (JSON):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:GetAuthorizationToken",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:<aws-region>:<aws-account-id>:repository/<container-name>"
}
]
}
Replace:
<aws-region> with your ECR region<aws-account-id> with your AWS account ID hosting the ECR<container-name> with your ECR repo nameAttach this policy to the IAM role that the Forge runner uses.
Ensure runner is set up to authenticate against the ECR repo. Usually this means your runner’s IAM role can assume the role with this policy.
Example job YAML:
jobs:
my-job:
runs-on:
- self-hosted
- x64
- type:small
- env:ops-prod
timeout-minutes: 60
container:
image: <aws-account-id>.dkr.ecr.<aws-region>.amazonaws.com/<container-name>
Go to a repository where the GitHub App for the tenant is installed.
Once approved, your repository is ready to use Forge runners.