Can BYOC Runners Reach Internal Services?

Yes. WarpBuild BYOC runners are ephemeral EC2 instances launched inside your own VPC with no tunnel or broker in the path, so an internal database, an internal package registry, or an internal API is reachable when your route tables, the runner security group, and the service's own inbound rules allow it, per the AWS BYOC configuration guide.

Answer

Reachability on BYOC is a property of where the instance sits. The control plane calls the AWS API with the IAM role you granted and launches the instance in the subnets of your stack, and from that point the runner is an EC2 instance like any other in the account. Four things decide whether it can open a connection to an internal service, all of them yours:

1. Subnet placement. The stack runs in one region of your account, with public subnets and optional private subnets, per the configuration prerequisites.
2. Route tables. The runner subnet needs a route to the service network.
3. The runner security group. The security hardening guide states that the default stack security group allows all egress and permits ingress from VPC subnet CIDRs only, and recommends removing inbound rules entirely.
4. The inbound rule on the service. An internal database accepts the connection when its own security group allows the runner security group or the runner subnet CIDR.

The workflow file does not change. A job targets a custom runner by its runner ID, prefixed with warp-custom-, and reaches the internal endpoint by its private address:

name: integration

on:
  pull_request:

jobs:
  migrate:
    runs-on: warp-custom-linux-ci-4x
    steps:
      - uses: actions/checkout@v4

      - name: Check the internal API is reachable
        run: curl -fsS http://internal-api.svc.internal:8080/health

      - name: Run migrations against the internal database
        run: psql "postgres://db.internal:5432/app" -f migrations.sql

      - name: Publish to the internal package registry
        run: npm publish --registry https://registry.internal

BYOC Linux runners carry a WarpBuild fee of $0.002 per runner minute and your own AWS account bills the compute, storage, and data transfer (pricing page, checked on 2026-08-13).

Detail

Placement options and what each one reaches

BYOC runs on AWS, GCP, and Azure. The placements below are the AWS ones, taken from the configuration prerequisites and the security hardening guide, checked on 2026-08-13.

The security guide recommends the dedicated VPC or the dedicated account for CI, because it limits the blast radius if a runner is compromised and gives auditors a clean boundary. The subnet-level detail behind these rows, including address headroom and the recommendation of three subnets per tier across availability zones, is laid out in BYOC networking on AWS and in the BYOC on AWS overview.

Two destination classes bypass the question entirely. The stack routes S3 cache traffic and ECR image pulls inside the AWS network for runners in both public and private subnets, so those calls do not depend on your own routing work, per the configuration prerequisites.

Reaching AWS services rather than IP endpoints

An internal service fronted by an AWS API, such as an S3 bucket, a private ECR repository, or a database using IAM authentication, needs identity as well as reachability. That comes from an instance profile attached at the runner level in the WarpBuild dashboard, under Custom Runner configuration > Instance Profile ARN, documented in the security hardening guide. Each runner configuration carries its own profile, so a deploy runner and a test runner can hold different permissions while sharing a stack. WarpBuild does not add permissions to runner workloads beyond what the profile you attach grants.

The alternative on WarpBuild-hosted runners

Teams that do not run BYOC get private access from the networking addon. You create a network addon configuration holding a Tailscale OIDC client ID, then append network.name=<config-name> to the runs-on label. At job start WarpBuild authenticates the runner to your tailnet with a short-lived OIDC token and an ephemeral node key, the runner reaches whatever the ACL policy allows, and the node is removed when the job ends:

jobs:
  deploy:
    runs-on: warp-ubuntu-latest-x64-4x;network.name=production-tailnet

The addon is documented as supported on all four. It also works on BYOC runners, so a fleet can use subnet placement for services inside the account and the addon for a tailnet that spans offices and other clouds. The full setup, the reserved flags, and the ACL shape are covered in can GitHub Actions runners reach my private network. For hosted runners, US and EU are the regions WarpBuild names publicly.

What a network security review asks

Rows come from the security hardening guide and the configuration guide, checked on 2026-08-13. The same table works as the answer sheet when a network team reviews the stack before approval.

What the internal-service path costs

Take 3,000 jobs a month at 12 minutes each on a BYOC Linux runner, every job reading from an internal database and publishing to an internal registry. That is 36,000 runner minutes.

WarpBuild rates come from the pricing page, checked on 2026-08-13. The two runner lines cover different things: the hosted rate includes the compute, while the BYOC fee sits on top of an EC2 bill you already control. Private subnets add managed gateway charges from AWS on top of both, and that arithmetic is worked through in BYOC networking on AWS.

Related Questions

Do BYOC runners need a tunnel to reach an internal service?

No. The instances launch inside your own VPC, so reachability is decided by your route tables, the runner security group, and the inbound rules on the service. The wider design decision between joining a private network and placing the runners inside it is covered in running GitHub Actions runners inside your own VPC.

Can a runner reach a service in a different VPC or account?

Yes, when the two networks are already connected and the routes exist on both sides. The security hardening guide recommends a dedicated CI VPC or a dedicated CI account for exactly this shape, which keeps CI away from production while leaving a controlled path to the services a build needs.

How does a runner authenticate to AWS services such as S3 or RDS?

Through an instance profile set at the runner level under Custom Runner configuration > Instance Profile ARN. Scope one profile per runner configuration, and see the BYOC on AWS overview for how the profile fits the rest of the IAM surface.

Can WarpBuild-hosted runners reach internal services too?

Yes, through the networking addon, which joins the runner to your Tailscale tailnet as an ephemeral node for the life of the job and works on hosted and BYOC runners alike.

Check your network against the AWS BYOC configuration prerequisites, harden the stack with the security guide, and price a fleet against your own minutes on the pricing page.