Migrate from AWS CodeBuild GitHub Actions Runners to Latchkey
CodeBuild hosts GitHub Actions runners inside your AWS account. Latchkey hosts them for you. Here is exactly what changes when you move.
According to AWS CodeBuild docs, running GitHub Actions on CodeBuild means creating a Runner-type CodeBuild project, connecting GitHub, configuring a webhook that filters WORKFLOW_JOB_QUEUED events, and targeting it with a runs-on label of the form codebuild-<project>-${{ github.run_id }}-${{ github.run_attempt }}. That is powerful if you are all-in on AWS, but you own the project, the IAM service role, the VPC wiring, and the webhook. Latchkey runs the same jobs on fully-managed, self-healing runners reached by a one-line runs-on change, with no AWS account or infrastructure to operate. Here is how a migration looks.
CodeBuild-hosted runners vs Latchkey
| Capability | AWS CodeBuild (self-hosted runner) | Latchkey |
|---|---|---|
| Where runners live | Your AWS account | Fully managed for you |
| Setup | CodeBuild project + IAM role + webhook | One-line runs-on label swap |
| AWS account / IAM / VPC required | Yes | No |
| Webhook to configure | Yes (WORKFLOW_JOB_QUEUED) | No |
| Self-healing (auto-retry transient failures) | No | Yes |
| Deep AWS integration | Yes (IAM, VPC, AWS services) | Not AWS-native |
| Best known for | AWS-native runners you operate | Managed self-healing runners, no AWS setup |
What CodeBuild is genuinely good at
CodeBuild is AWS-native. According to AWS CodeBuild docs, its GitHub Actions runners run inside your account with an IAM service role and can run in your VPC to reach resources like RDS or ElastiCache. If your builds already assume AWS credentials, private subnets, and tight IAM boundaries, that native integration is a real advantage and a good reason to stay.
What you stop operating with Latchkey
Latchkey removes the pieces you configure and maintain in AWS: no Runner-type CodeBuild project, no service role to scope, no VPC subnets and security groups to wire up, and no WORKFLOW_JOB_QUEUED webhook to debug. GitHub Actions sees a managed runner, and transient or mechanical failures self-heal and retry automatically instead of failing the job.
How the migration works
- Pick one workflow and change its runs-on from the codebuild-<project>-... label to the Latchkey label.
- Run it side by side with the CodeBuild path and compare wall-clock time and reliability on real builds.
- Roll out remaining workflows one label at a time; your YAML, actions, and steps stay the same.
- Keep CodeBuild for any job that truly needs in-VPC AWS access, and move the rest.
The verdict
Stay on CodeBuild for jobs that need native, in-VPC AWS access and tight IAM. For everything else, if operating a CodeBuild project, service role, VPC, and webhook is more than you want to own, Latchkey gives you fully-managed self-healing runners with a one-line runs-on swap. Pilot it on one workflow and compare against your real CodeBuild builds.