Can I Restrict Outbound Traffic From Runners?

Yes. Narrow the egress rules on your BYOC runner security group, as long as runners keep reaching the WarpBuild control plane, GitHub, and your registries.

Yes. Narrowing outbound rules on BYOC runners is documented WarpBuild guidance, and the constraint is that the runner still has to reach the destinations the platform documents: api.warpbuild.com for registration and lifecycle, github.com and api.github.com for git and GitHub Actions API traffic, and the package registries your builds pull from (BYOC AWS security hardening); cover those in the allowlist and the runner behaves exactly as it does under the default allow-all egress rule.

Answer

BYOC runners launch inside your own cloud account, so the firewall in front of them is yours to write. BYOC runs on AWS, GCP, and Azure (BYOC on AWS). On AWS the rules live on the security group the CloudFormation stack attaches to every runner instance, which the stack either provisions for you in create mode or imports from an existing security group you select (BYOC AWS security hardening).

The default posture the stack ships with is deliberately permissive on the way out and already closed on the way in:

Stack resource	Default configuration
Security group	All egress allowed to `0.0.0.0/0`; ingress allowed from VPC subnet CIDRs only
Network ACLs	Default VPC ACLs, which allow all traffic
Subnets	Public subnets, with optional private subnets when you need stable outbound addresses

Rows come from the BYOC AWS security hardening guide, checked on 2026-08-13.

Tightening the egress side means replacing the single allow-all rule with a list. This is the set that has to survive the edit:

Destination	What depends on it
`api.warpbuild.com`	Runner registration and lifecycle against the WarpBuild control plane
`github.com`	Git operations, including `actions/checkout`
`api.github.com`	GitHub Actions API calls the runner makes during a job
WarpBuild AWS S3 over HTTPS	Runner telemetry and system logs
Your package registries and any external service a step calls	Dependency installs, image pulls from outside AWS, deploy targets

Rows come from the BYOC AWS security hardening guide, checked on 2026-08-13. Two categories do not need a public rule: cache traffic to the stack S3 bucket and ECR image pulls are routed by the stack inside the AWS network, which the BYOC AWS config reference covers along with the stack template version required for ECR logins from public subnets.

Detail

What a security group can actually match

Security group rules match IP ranges and prefix lists, so the destination list above cannot be entered as written. Two paths get you from a hostname list to an enforceable rule set.

The first is address ranges. GitHub publishes the ranges its services use through the REST meta endpoint (GitHub REST API meta documentation), which covers the github.com and api.github.com side. Those ranges change, so a list built from them needs a scheduled refresh and a review step; a stale allowlist fails as a build outage rather than as an alert.

The second is a proxy or a name-aware firewall in front of the runner subnets. The security group then allows egress to the proxy only, and the hostname policy lives in one place you can edit without touching the stack. Teams that want to allow registry.npmjs.org but nothing else on the public internet usually end up here, because package registries publish no stable address ranges to allowlist against.

The failure signature when a destination is blocked

Egress mistakes are diagnosable because each blocked destination fails at a different point in the job lifecycle. Use this to work out which rule you got wrong:

Blocked destination	What you observe
`api.warpbuild.com`	The EC2 instance launches and shows up in your account under the `warp-` name pattern, then the GitHub Actions job stays queued with an empty log until it times out, because no runner ever registered
`github.com`	The runner picks up the job and the first steps run, then `actions/checkout` stalls and fails on a connection timeout during the git fetch
`api.github.com`	Registration and job hand-off break the same way as a control plane block, and steps that call the GitHub API, such as release asset uploads, fail with connection timeouts
WarpBuild AWS S3 over HTTPS	Jobs complete normally and runner logs and telemetry go missing, so the next real failure is harder to diagnose
A package registry	A single step fails with the package manager's own connect or DNS timeout while the rest of the job stays healthy

The instance naming pattern in the first row comes from the BYOC AWS config reference, which documents warp-* for EC2 instances and EBS volumes and tmpl-warp-* for launch templates. That naming is what lets you confirm an instance launched at all before you start reading rules.

The dividing line is worth keeping in mind. If the job never gets a runner, the block sits on the control plane or GitHub path. If the job gets a runner and one step fails, the block sits on a registry or a service that step calls.

The two checklist items that pair with it

Restricting egress is one line of the BYOC security checklist, and it works best next to two others.

Blocking all inbound comes first. Runner instances have no reason to accept inbound connections, including from inside the VPC, so the hardened shape is a security group with an empty inbound rule set. In import mode you supply that security group when creating the stack:

{
  "InboundRules": [],
  "OutboundRules": [
    {
      "IpProtocol": "-1",
      "Destination": "0.0.0.0/0",
      "Description": "Allow all outbound"
    }
  ]
}

That shape comes from the BYOC AWS security hardening guide. Start here, confirm jobs pass, then replace the single outbound rule with the narrower destinations once you have the ranges or the proxy in place. Inbound stays empty either way.

Instance isolation comes second. Runner instances have no reason to talk to each other, so network ACLs on the runner subnets can deny intra-subnet traffic and close off lateral movement between concurrent jobs (BYOC AWS security hardening). Each CI job already runs on a freshly provisioned instance that is terminated when the job completes, so there is no shared state between jobs to protect; the isolation rule protects the window while jobs run side by side. Pair both with IMDSv2 required on the runner, set per runner under Runner Specs in the dashboard (IMDSv2 configuration), which closes the metadata credential path that SSRF bugs in a build step would otherwise reach.

The full list, including S3 lifecycle policies and tagging for cost attribution, is in the BYOC on AWS security checklist. The rule-writing mechanics themselves are covered in outbound traffic controls for BYOC runners, and the AWS object the rules live on is defined in security group.

What tightening egress does not change

Rule changes are free. BYOC Linux and Windows runners carry a WarpBuild fee of $0.002 per minute and the compute itself is billed by your own cloud account (pricing page, checked on 2026-08-13). Every cost number on this page carries a source link and a checked-on date, and the same numbers appear on the pricing page.

Platform coverage does not change either. A hardened stack runs the same labels a permissive one does, so no workflow edit follows an egress change.

Can I allowlist outbound traffic by hostname on an AWS security group?

No. Security group rules match IP ranges, so a hostname allowlist belongs on an outbound proxy or a firewall placed in front of the runner subnets. GitHub publishes its address ranges through the REST meta endpoint, and those ranges change, so an address-based list needs a refresh job.

What breaks first if I block the WarpBuild control plane?

The job never gets a runner. The instance launches in your account with the warp- name tag, registration fails, and the GitHub Actions job stays queued with an empty log until it times out. Compare that against a github.com block, where the runner does pick up the job and actions/checkout is the step that fails.

Do GCP and Azure BYOC stacks follow the same outbound rules?

BYOC runs on AWS, GCP, and Azure, and the runner needs the same destinations on all three. The rule-by-rule hardening guidance WarpBuild publishes is written against the AWS stack (BYOC AWS security hardening), so translate it into firewall rules on GCP or network security group rules on Azure.

Start from the default stack, confirm jobs pass, then narrow the rules one destination at a time using the BYOC on AWS overview and the hardening docs.