What does BYOC stand for?

BYOC stands for bring your own cloud. It describes a deployment model where a vendor operates the control plane for a service while the compute, storage, and network resources that do the work are created inside the customer's own cloud account, under the customer's ownership and on the customer's cloud invoice.

How is BYOC different from self-hosted?

Both place the workload in infrastructure the customer owns. They differ in who operates it. Under self-hosted, the customer runs the orchestration, the scaling policy, the image builds, and the upgrades. Under BYOC, the vendor's control plane performs those operations remotely through a scoped role the customer grants.

Who pays the cloud bill under BYOC?

The customer does, directly to the cloud provider. Instance hours, disks, object storage, and data transfer are metered against the customer's own account at whatever rates and commitments that account carries. The vendor bills separately for its own service.

Does BYOC give the vendor access to my cloud account?

It gives the vendor a scoped identity, typically an IAM role, a service account, or a managed identity, with permissions limited to the resource types the service manages. The customer defines the trust relationship and the permission set, can audit every API call in the cloud provider's own audit log, and revokes access by removing the role.

BYOC (Bring Your Own Cloud)

BYOC, or bring your own cloud, is a deployment model where a vendor's control plane operates resources that run inside the customer's own cloud account.

Definition

BYOC, short for bring your own cloud, is a deployment model where a vendor operates the control plane for a service while the resources that do the actual work are created inside the customer's own cloud account. The vendor supplies the software and the operations; the customer supplies the account, and the resources appear under the customer's ownership, in the customer's chosen region, on the customer's cloud invoice.

The term is used across many categories of software, including databases, data warehouses, observability pipelines, and build infrastructure. The shape is the same in every case. One party operates the system, and the other party owns the machines it runs on.

The two planes

Almost every BYOC description reduces to a split between a control plane and a data plane.

The control plane is the part the vendor runs in vendor infrastructure. It holds configuration, scheduling decisions, the reconciliation loop that keeps reality matched to configuration, the dashboard, the API, and the billing meter for the vendor's own service. It calls cloud provider APIs on the customer's behalf.

The data plane is the part that lives in the customer's account. It is the set of instances, disks, buckets, network interfaces, and load balancers that carry the workload and hold the data. Requests, builds, queries, and logs move through these resources without leaving the customer's account boundary.

The cloud account boundary is what makes BYOC a distinct model rather than a hosting detail. Once the data plane sits in the customer's account, the customer's existing controls apply to it automatically: organization policies, service control policies, tag enforcement, private networking, encryption keys, audit logging, and the cost allocation the finance team already uses.

What "your own cloud account" means concretely

Four things move to the customer under this model, and they move together.

Ownership. Every resource is created with the customer as the account owner. The resources show up in the customer's console, respond to the customer's API calls, and can be deleted by the customer at any time without asking the vendor.

Billing. The cloud provider meters those resources against the customer's account, at the rates and commitments that account carries. Committed use discounts, savings plans, enterprise agreements, and any negotiated pricing apply, because the usage is the customer's usage.

Region and network placement. The customer picks the region, the virtual network, and the subnets. Resources land where the customer put them, which is what makes BYOC a common answer to data residency requirements.

Access. The vendor reaches the account through an identity the customer creates: an IAM role with a trust policy on AWS, a service account on GCP, or a managed identity or app registration on Azure. The permission set is visible before it is granted, every call the vendor makes appears in the cloud provider's own audit log, and deleting the role ends the vendor's access without a support ticket.

The resource categories a BYOC deployment touches

Whatever the product, a BYOC data plane is assembled from the same four categories of cloud primitive. The names differ per provider.

Category	What it holds	AWS	GCP	Azure
Compute	The instances that run the workload	EC2 instances	Compute Engine instances	Virtual Machines
Network	The private network the workload sits in	VPC, subnets, security groups	VPC, subnets, firewall rules	Virtual Network, subnets, NSGs
Object storage	Caches, artifacts, logs, state	S3 bucket	Cloud Storage bucket	Blob Storage container
Identity	The scoped grant the vendor assumes	IAM role	Service account	Managed identity

Reading a vendor's BYOC documentation is largely a matter of checking those four rows: which resources get created, which can be imported from what the customer already has, and which permissions the identity row carries.

Where BYOC sits between the two familiar models

BYOC is the middle option in a spectrum of three. The table below splits the operational duties that people usually argue about.

Responsibility	Vendor-hosted	BYOC	Self-managed
Provisioning resources	Vendor, in vendor account	Vendor, in customer account	Customer
Patching images and agents	Vendor	Vendor	Customer
Scaling policy	Vendor	Vendor, using customer capacity	Customer
Network placement	Vendor decides	Customer decides	Customer decides
Data location	Vendor regions	Customer regions	Customer regions
Cloud bill for the workload	Included in vendor price	Customer, direct from cloud provider	Customer, direct from cloud provider
Ending vendor access	Cancel the contract	Delete the granted role	No vendor access exists

The trade is visible in the table. Vendor-hosted asks the least of the customer and gives the least control over placement. Self-managed gives full control and hands the customer the on-call rotation for the orchestration layer. BYOC keeps the operational burden with the vendor while the resources and their audit trail stay in the customer's account.

Terms that get confused with BYOC

Self-hosted describes where software runs. It leaves open the question of who operates it, and in common usage the customer operates it.

On-premises means hardware in a data center the customer owns or leases. BYOC usually refers to a public cloud account, though the same control plane and data plane split is what hybrid deployments describe.

Single tenant or dedicated hosting means the vendor runs isolated infrastructure per customer inside the vendor's own account. The isolation improves; the account boundary stays with the vendor, so the bill and the audit trail stay there too.

Remote agent or connector models install an outbound agent in the customer's network to reach private data. That solves connectivity. It leaves the workload itself in vendor infrastructure.

Example

GitHub Actions makes the model easy to see, because a workflow job runs on exactly one machine and the job says which machine it wants.

A job that names a GitHub-hosted label runs on a machine GitHub owns:

name: ci
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make build

The instance is created and destroyed inside GitHub's infrastructure. The repository owner picks a size from what GitHub publishes, and the charge for the job time appears on the GitHub bill. Region, virtual network, disk encryption key, and instance family are decisions someone else has already made.

Under a BYOC model, the same job changes one line. The label points at a runner configuration the customer defined in a connected cloud account. In the WarpBuild implementation, that configuration registers a runner ID carrying the warp-custom- prefix, documented in the BYOC setup guide:

name: ci
on: [push]

jobs:
  build:
    runs-on: warp-custom-ci-linux-use1
    steps:
      - uses: actions/checkout@v4
      - run: make build

Nothing else in the file moves. The checkout action, the cache actions, the secrets, and the label matching rules behave exactly as before, because the machine still registers with GitHub through the standard runner registration API.

What happens after that job is queued

GitHub queues the job and looks for an online runner advertising the label warp-custom-ci-linux-use1.
The vendor control plane, watching the queue for the connected repositories, sees the queued job.
The control plane calls the cloud provider API using the role the customer granted, and launches an instance in the customer's account, in the customer's region and subnet.
The instance boots the runner agent, registers with GitHub, and claims the job.
Steps execute on that instance. Source code, build outputs, caches, and logs are written to storage in the customer's account.
When the job ends the instance is terminated, and the storage the workload used remains under the customer's control.

Every resource created in steps 3 through 6 is tagged and billed to the customer's account. The vendor never held the build data; it held the decision to create the instance.

Which invoice each line item lands on

The billing split is the part teams most often get wrong when they model the change, because it turns one invoice into two.

Line item	Billed by
Instance hours for the runner	Your cloud provider, to your account
Block storage attached to the runner	Your cloud provider, to your account
Object storage for caches, artifacts, and logs	Your cloud provider, to your account
Data transfer generated by the workload	Your cloud provider, to your account
The managed service that orchestrates the runners	The vendor

Two consequences follow. The cloud line items inherit the account's existing discounts and its existing cost allocation tags, so the spend appears in the same reports as the rest of the infrastructure. And capacity choices such as instance family or purchase model become the customer's decision, since the customer is the party being metered for them. Which capabilities are available per cloud is documented in the feature matrix.

BYOC runners on AWS for GitHub Actions: the AWS architecture for this model, the IAM surface it asks for, and the stack configuration knobs.
Data residency: why the account boundary described above is the usual answer to a residency requirement.
Spot instance: the purchase model that becomes available once instance choice moves to the customer's account.
Can GitHub Actions runners run in my own cloud account: the short answer for GitHub Actions specifically, with the setup path.
BYOC setup documentation: the three step flow of connecting a cloud account, creating a stack, and defining a custom runner.
WarpBuild pricing: per minute rates by runner type.