What Gets Created in My Cloud Account?

Answer

WarpBuild BYOC creates a stack of resources inside your own cloud account, and every one of them follows a documented naming convention so it stays identifiable in an account you share with other workloads. On AWS that stack is a CloudFormation stack holding network and storage resources, plus an IAM role created once when you connect the account, plus EC2 instances, EBS volumes, and launch templates that appear and disappear around individual GitHub Actions jobs. The resource graph is drawn out in the BYOC AWS architecture reference and the per-resource configuration is in the AWS BYOC configuration guide.

BYOC runs on AWS, GCP, and Azure. This page covers the AWS inventory, because AWS is the cloud with import mode and with the published CloudFormation resource list.

Resource lifetimes and default configurations come from the BYOC AWS security guide, checked on 2026-08-13.

The instances the stack launches in your account are the Linux and Windows ones. macOS runners stay on WarpBuild-hosted capacity, so no macOS resource is created in your AWS account.

Detail

The connection role, created once

Connecting an AWS account creates a single IAM role named warpbuild-<integration-id>, applied by a CloudFormation template you run yourself. The role is the whole access surface, and its statements are grouped into named policy contexts so you can read them one block at a time: FineGrainedEC2Permissions and SpotServiceLinkedRolePermissions for launching just-in-time runners, NetworkPermissions for describing your network and managing VPC endpoints, StoragePermissions for EBS snapshots and the S3 actions behind the cache action and runner logs, and CloudFormationPermissions for changeset requests when a stack needs an upgrade. Deleting the role ends the access. The full policy document is expandable in the configuration guide.

The stack, created once per region

The stack name, the S3 bucket, and the region are fixed at creation. In create mode CloudFormation builds the network: a VPC with public subnets, optional private subnets behind NAT when runners need static egress IPs, route tables, and a security group attached to every instance the stack launches. In import mode you supply an existing VPC, subnets, and security group, and none of those network resources are created.

The bucket is where durable data lands, under two documented key layouts:

<bucket_name>/<org_id>/artifact_cache/<vcs_org>/<vcs_repo>/<vcs_ref>/<version>/<key>
<bucket_name>/runner/logs/all/<runner_id>.<log_file_name>

Both prefixes grow until you expire them, and the documented recommendation is a 7 day lifecycle rule adjusted to your own retention policy. The stack also provisions the endpoints that let runners in both public and private subnets reach that bucket and pull images from ECR, which is why an ECR login on a public subnet runner needs CloudFormation template version 1.4 or later.

The per-job resources

Each GitHub Actions job runs on a distinct, freshly provisioned EC2 instance that is terminated when the job completes. Nothing survives to serve a second job. Standby disks are the exception worth knowing about for an account inventory: a standby disk is a VM of the runner instance type, booted once and then shut down, so a stopped instance and its EBS volume sit in your account waiting. The stopped instance bills no compute; the volume bills storage at your rates.

Naming and tagging in a shared account

Custom tags you set on the stack are added to everything the stack creates, which is how cost attribution by team or product works. WarpBuild also adds a managed-by: warpbuild tag to provisioned resources, and that tag is usable as a condition key for AWS IAM tag-based access control. Stack resource tagging in create mode arrived in CloudFormation template version 1.3; runner instances are tagged in every case. A cost report filtered on warpbuild-runner-labels gives you spend per runner class with no extra instrumentation.

What the control plane does from outside

The control plane holds the GitHub App connection, the runner configurations, and the watch on the GitHub Actions job queue. When a queued job matches one of your runs-on labels, it calls the AWS API through the connection role and launches an instance. It never holds your build data. Runners reach api.warpbuild.com and GitHub outbound, so the recommended security group blocks all inbound traffic. The permissions your build steps carry are the ones you attach through an instance profile, and WarpBuild injects none into runner workloads.

What the account placement costs

WarpBuild charges $0.002 per runner minute for BYOC Linux runners and $0.002 per runner minute for BYOC Windows runners, listed with every other rate on the pricing page, checked on 2026-08-13. AWS bills your account for the EC2 instances, EBS volumes, NAT gateways, and S3 storage in the table above at your own rates.

Related Questions

Can WarpBuild use a VPC I already have?

Yes, on AWS. Import mode takes an existing VPC, subnets, and security group as inputs, so the stack creates the S3 bucket and the runner-level resources and leaves your network untouched. Create mode is the path where CloudFormation builds the VPC, subnets, route tables, and security group for you. The choice is made once, when the stack is created, and the AWS BYOC page walks through both modes.

How do I tell WarpBuild resources apart in a shared account?

By name and by tag. S3 buckets are named warpbuild-*, EC2 instances and EBS volumes warp-*, and launch templates tmpl-warp-*. Every provisioned resource carries the managed-by: warpbuild tag, and runner instances also carry warpbuild-github-org, warpbuild-runner-labels, warpbuild-runner-id, warpbuild-stack-id, and warpbuild-stack-name. The naming and tagging tables live in the configuration guide.

What does WarpBuild run outside my account?

The control plane. It holds the GitHub App connection, the runner configuration, and the watch on the GitHub Actions job queue, then calls the AWS API through the IAM role you created to launch and terminate instances. Job workspaces, caches, logs, and artifacts stay on the instances and in the bucket inside your account. The control plane definition covers the split in general terms, and the BYOC runner lifecycle follows one instance from queue to termination.