Can I Use My Existing VPC With BYOC Runners?

Yes. On AWS you create the BYOC stack in import mode, which takes an existing VPC, subnets, and security group as inputs instead of having the CloudFormation template provision them, and the import works once that network meets the prerequisites in the AWS BYOC configuration guide. BYOC runs on AWS, GCP, and Azure, and import mode is the AWS path; on the other two clouds the stack creates its own network resources.

Answer

Import mode is a choice made once, at stack creation. The configuration guide and the security hardening guide both state the same split: in create mode the CloudFormation template provisions the security group and the surrounding network, and in import mode you select an existing security group when creating the stack.

That makes the import a compliance question for whoever owns the network. Here is the documented prerequisite list as a checklist, drawn from the AWS BYOC configuration guide, checked on 2026-08-13.

Nothing on that list is specific to WarpBuild except the outbound destinations. A VPC already carrying production workloads usually satisfies most of it, and the two rows that fail most often are address headroom and the private subnet routes.

Pricing does not change with the network you bring. BYOC Linux runners carry a WarpBuild fee of $0.002 per runner minute and BYOC Windows runners the same $0.002 per runner minute, with your own AWS account billing EC2, EBS, and data transfer at your rates (pricing page, checked on 2026-08-13).

Detail

What the stack still creates around your VPC

Importing the network does not make the stack empty. It still creates an S3 bucket in the stack region for the artifact cache, the container image layer cache, and runner telemetry, and it still creates the per-job EC2 instances, EBS volumes, and launch templates. The connection role holds ec2:CreateVpcEndpoint and ec2:DeleteVpcEndpoints, and the configuration guide lists those network permissions as the ones supporting stack creation in import mode, so the endpoints the runners need can be added to the VPC you handed over.

Three stack properties are fixed at creation and cannot be changed afterwards: the stack name, the S3 bucket, and the region. An imported VPC pins the region for you, so the decision left is the bucket and a stack name that still reads clearly later.

Resource naming makes the imported network auditable afterwards. Buckets are named warpbuild-*, instances and EBS volumes warp-*, and launch templates tmpl-warp-*, and every provisioned resource carries a managed-by: warpbuild tag that AWS IAM tag-based access control can key on.

When a dedicated account beats importing the VPC you have

The security hardening guide recommends isolating GitHub Actions workloads from production infrastructure by deploying the stack in a separate VPC within the same account, or in a separate AWS account dedicated to CI/CD, because that limits the blast radius if a runner is compromised and simplifies audit boundaries.

The separation is worth the setup when workflow jobs run untrusted code, such as pull requests from outside collaborators, when the shared VPC has routes to production databases that a build step has no business reaching, or when an auditor wants the boundary drawn at the account rather than at a security group rule. Import the existing VPC when the opposite is true: the network is already segmented, the platform team manages it under Terraform, or an organizational policy forbids a template from creating network resources.

Either choice keeps the same default posture. Each job runs on a distinct, freshly provisioned EC2 instance that is terminated when the job finishes, and the permissions available to a runner are the ones you attach through the instance profile, since WarpBuild injects no additional permissions into runner workloads.

The two prerequisites that fail most, and what the failure looks like

One more failure is worth pre-empting on an imported network. Stacks created with CloudFormation template versions before v1.4 may hit ECR authentication failures, seen as an ECR login timing out, for runners in public subnets. The documented fix is upgrading the stack to template v1.4 from the WarpBuild dashboard (AWS BYOC configuration guide).

The workflow does not know which mode you picked

Stack mode is invisible to the workflow file. The job references the runner ID as its label, prefixed with warp-custom-, on an imported VPC exactly as it would on a created one.

name: build
on: [push]

jobs:
  test:
    runs-on: warp-custom-linux-imported-4x
    steps:
      - uses: actions/checkout@v4
      - run: make test

Platform coverage is also unchanged by the import. On AWS BYOC the runners that land in your VPC are Linux and Windows, so Apple platform jobs keep a hosted macOS label in the same workflow.

Related Questions

How do I point a BYOC stack at a VPC I already have?

Choose import mode when you create the stack on AWS. Import mode takes an existing VPC, subnets, and security group as inputs, where create mode has the CloudFormation template provision those resources instead. BYOC runs on AWS, GCP, and Azure, and import mode is the AWS path. The stack creation flow is walked through on the AWS BYOC page.

What does my existing VPC have to look like before it works?

At least one public and one private subnet with internet connectivity, NAT gateways serving the private subnets, route tables sending internet-bound traffic through the Internet Gateway, a security group that blocks all inbound and allows the required outbound destinations, and enough addresses, vCPU, and EBS headroom in the region. The documented recommendation is three public and three private subnets across availability zones with at least 250 addresses each. The row-by-row reference is on the BYOC networking page, and what a VPC decides covers the parts if the network is new to you.

Should I import a shared VPC or build a separate one for runners?

The security hardening guide recommends a dedicated VPC within the account or a separate AWS account dedicated to CI/CD, because it limits the blast radius if a runner is compromised and simplifies audit boundaries. Importing a shared production VPC is supported and puts every runner instance inside a network your production workloads also use, which is a reasonable trade when the network is already segmented and centrally managed.

What still gets created in my account when I import a VPC?

An S3 bucket in the same region as the stack for the artifact cache, container layer cache, and runner telemetry, plus VPC endpoints and the per-job EC2 instances, EBS volumes, and launch templates. The stack name, the bucket, and the region are fixed once the stack exists. The full resource inventory and the IAM surface behind it are on the AWS BYOC page.