How Do I Delete a BYOC Stack?

Delete the custom runner configurations first, then the stack, then the cloud connection. WarpBuild blocks each delete until its dependents are gone.

Answer

Delete BYOC objects in dependency order: the custom runner configurations that reference the stack, then the stack itself, then the cloud connection if you are disconnecting the account as well. WarpBuild enforces that order for you, because the BYOC documentation states that a stack cannot be deleted until the custom runner configurations depending on it are deleted, and a cloud connection cannot be deleted until the stacks depending on it are deleted.

Each delete shows a confirmation listing what still depends on the object, so the dashboard tells you what is blocking before it refuses.

Order	What you delete	What the confirmation lists	What blocks it
1	Custom runner configurations pointing at the stack	The runner configurations you selected	Nothing on the WarpBuild side, so this is where draining matters
2	The stack: region, VPC, subnets, object storage bucket	Custom runner configurations that depend on the stack	Any remaining runner configuration on that stack
3	The cloud connection and its IAM role	Stacks that depend on the connection	Any remaining stack on that connection

Step 3 is optional. Keep the cloud connection when you are deleting one stack out of several, or when you plan to recreate a stack in a different region: the stack name, the object storage bucket, and the region are fixed at creation, so changing any of the three means a delete and a rebuild rather than an edit.

Deleting stops the WarpBuild meter for those runners. Your cloud account keeps billing anything the delete leaves behind, which is what the checklist below is for.

Detail

Check for an update before you delete

Some deletes are unnecessary. The BYOC documentation notes that WarpBuild may require changes to cloud connections or stacks to support new features, and that those changes appear as updates to apply. Registry authentication on public-subnet runners is the common example: stacks on CloudFormation template versions before v1.4 can hit ECR login timeouts, and the fix is a template upgrade from the dashboard rather than a rebuild (AWS BYOC configuration guide). The update mechanics are covered in applying stack updates.

Three changes an update cannot make, because the values are fixed at stack creation: the stack name, the object storage bucket, and the region. A region move, a bucket move, or a rename is a delete and a rebuild.

Draining before the delete

Runner instances are ephemeral. Each job runs on a distinct, freshly provisioned instance that is terminated after the job completes, with no shared state between jobs (BYOC security hardening). There is no long-lived agent to unregister, so draining is a matter of stopping new work from arriving and waiting out the work already running.

Find every reference to the labels. Runner configurations are addressed by Runner ID with the warp-custom- prefix, so an organization-wide code search for warp-custom- finds the workflows, the reusable workflows they call, and the composite actions that hard-code a label.
Repoint those runs-on values at a label that will survive, and merge that change first.
Check the schedules. A nightly or weekly workflow on a release branch can still carry the old label days after main is clean.
Let in-flight jobs finish. The drain window is the duration of your longest job on that runner set.
Delete the runner configurations, then the stack.

A job that reaches the queue after its label has gone away does not fail immediately. GitHub cancels a job that has been queued for 24 hours (GitHub Actions limits, checked on 2026-08-13), so a missed scheduled workflow turns into a red run a full day later. Search first, delete second.

Only the labels served by the deleted stack stop working. Jobs on hosted warp- labels in the same workflow keep running through the deletion.

The leftover check in your account

The WarpBuild dashboard stops showing the objects once they are deleted. Your cloud bill is the thing to verify against. Names and tags below come from the AWS BYOC configuration guide, checked on 2026-08-13.

Resource	How to find it	Why it can linger
EC2 runner instances	Name pattern `warp-*`	A job that started before the drain finished
EBS volumes	Name pattern `warp-*`	Standby disk pools: the VM is shut down rather than terminated, and the network disk stays billable while the VM is not (standby disks)
Launch templates	Name pattern `tmpl-warp-*`	One per runner configuration
Object storage bucket	Name pattern `warpbuild-*`	Holds artifact cache and runner telemetry; in import mode the bucket is yours and was never WarpBuild's to remove
Custom AMIs and snapshots	Images built for custom VM image runners	Deregistering an image can leave its snapshots behind
Connection IAM role	`warpbuild-<integration-id>`	Created by the CloudFormation connection stack, so it outlives a stack-only delete
Addresses, gateways, endpoints	Quota usage in the region	Create mode provisions per-stack networking; import mode uses the resources you supplied

Filter by tag rather than by name where you can. Every resource the stack creates carries warpbuild-stack-id and warpbuild-stack-name, alongside warpbuild-managed-by, warpbuild-github-org, warpbuild-runner-id, and warpbuild-runner-labels. Stack resources are tagged from template version 1.3 in create mode; runners are tagged in all cases. The AWS quota table for BYOC is a second read on the same question, since elastic IPs and VPC counts per stack should drop back after a clean delete (BYOC on AWS).

One caveat on import mode. If you handed WarpBuild an existing VPC, subnets, security group, and bucket, those objects were yours before the stack existed and stay after it goes. The delete removes the stack record and the resources WarpBuild created inside it, and the bucket keeps whatever cache and telemetry objects accumulated under it until your lifecycle policy expires them.

Deleting on GCP and Azure

BYOC runs on AWS, GCP, and Azure, and the dependency rules above live in the shared BYOC documentation, so the runner-then-stack-then-connection order holds on all three. What changes per cloud is the leftover list: the naming patterns and tags in this section are the AWS ones, and on GCP and Azure you are checking the equivalent instances, disks, images, and storage in the project or subscription you connected. The creation side of that lifecycle is described in how BYOC runners are created and destroyed.

What order do I delete BYOC objects in?

Custom runner configurations first, then the stack, then the cloud connection if you are disconnecting the account as well. Each delete shows a confirmation listing its dependents and refuses to proceed until they are gone, per the BYOC documentation. Keep the connection if another stack still runs on it.

What happens to jobs that are still running when I delete a stack?

Drain before you delete. Runner instances are ephemeral and terminate after the job completes, so the drain window equals your longest running job on that runner set. Repoint the runs-on labels, merge, wait, then delete. A job that queues against a label with no runner behind it waits until GitHub cancels it at 24 hours (GitHub Actions limits, checked on 2026-08-13).

Which cloud resources should I check for after the delete?

On AWS: instances and volumes named warp-*, launch templates named tmpl-warp-*, the warpbuild-* bucket, the warpbuild-<integration-id> connection role, custom images and their snapshots, and standby disk volumes. Filter on the warpbuild-stack-id tag rather than the name where the console allows it. The naming and tagging tables are in the AWS BYOC configuration guide.

Rebuild the stack against the AWS BYOC page when you are moving regions, apply pending changes with stack updates, and price the replacement fleet against your own minutes on the pricing page.