Skip to content
RunsOn - 10x cheaper self-hosted GitHub runners RunsOn
Blog

Reuse existing VPC

RunsOn requires a proper networking stack to be setup, for launching EC2 instances that act as runners.

By default when the NetworkingStack parameter is set to embedded, RunsOn will create a new VPC, public subnets, security groups, VPC endpoints, S3 gateway etc. with all the best practices enabled. This is the recommended setup for most users.

For more advanced requirements, or if you already have an existing networking stack you want to reuse, you can set NetworkingStack to external. In which case, you will need to perform the networking setup by yourself, and provide the necessary parameters to RunsOn.

Embedded vs External

Availability

  • This feature is available since v2.8.0.

Configuration

To reuse an existing VPC, you will need to provide the following parameters when creating or updating your RunsOn CloudFormation stack:

  • NetworkingStack - set to external.
  • ExternalVpcId - the ID of the VPC to reuse.
  • ExternalVpcSubnetIds - comma separated list of subnet IDs from the VPC, including public, private, or both.
  • ExternalVpcSecurityGroupId - the ID of the security group from the VPC, to assign to runner instances.

Requirements for external networking

Public subnets

If you plan to launch runners in public subnets, you must ensure that those subnets can reach the Internet through the VPC’s Internet Gateway.

A minimum number of 2 private subnets is recommended, so that RunsOn can properly spread the runners across multiple AZs to benefit from the best prices and reliability.

If you set Private=only mode (parameter Private in the CloudFormation stack), you do not need to provide any public subnets.

Private subnets

If you use the Private mode, you must provide private subnets that can reach the Internet. This can be through NAT gateway(s), NAT instance(s), or any other means. The RunsOn service will complain if you don’t have at least one subnet that appears to be able to reach the Internet.

If you use the Private mode, a minimum number of 2 private subnets is recommended, so that RunsOn can properly spread the runners across multiple AZs to benefit from the best prices and reliability.

Security group

If you plan on using the SSH feature, your security group must allow inbound and outbound traffic on port 22 (SSH).

VPC endpoints

  • Optional, but recommended: your VPC should always have an S3 gateway endpoint (this is free). With your route tables correctly configured. This will make sure all the S3 traffic stays within your VPC.

  • Optional: If you are using private subnets, you can add VPC endpoints for EC2, ECR, etc., as you see fit. Those endpoints are not free.

IPv6

If you have enabled IPv6 in the RunsOn stack (parameter EnableIPv6), you must ensure that your VPC has an IPv6 CIDR block assigned, and that your route tables are correctly configured to route IPv6 traffic to the Internet.

Examples

Example external networking stacks are available in the RunsOn GitHub repository ↗.

We welcome community contributions.

Switching from embedded to external and vice versa

Switching from external to embedded requires no service interruption.

Switching from embedded to external requires a service interruption, as the embedded VPC, subnets, etc. will be deleted. It is best to perform this during a low traffic period, and stop the AppRunner service before performing the switch.

You can also simply install RunsOn from scratch again, and delete the old RunsOn installation once the new one is fully operational.