How to Migrate from RunsOn to Latchkey (Self-Hosted to Managed)
RunsOn runs GitHub Actions runners in your own AWS account; Latchkey runs them for you as a fully managed service. Migrating means handing off the ops, not learning a new CI system.
Per RunsOn's docs, RunsOn is a control plane you self-host under a license: ephemeral EC2 runners launch in your own AWS account, one machine per job, spot by default, with the EC2/S3 bills going to you directly with no markup (runs-on.com). That gives you maximum control and low raw compute cost, but you own the CloudFormation stack, IAM roles, spot capacity, and AWS quotas. Latchkey is fully managed: there is no AWS account or stack to operate, and it adds self-healing so transient and mechanical failures are detected, fixed, and retried automatically. Because both attach standard GitHub Actions runners by label, the migration itself is a one-line runs-on swap. Verify current RunsOn pricing and capabilities on runs-on.com before you plan a move.
RunsOn vs Latchkey at a glance
| Capability | RunsOn | Latchkey |
|---|---|---|
| Hosting model | Self-hosted in your AWS account | Fully managed (no AWS account needed) |
| Infra you operate | CloudFormation stack, IAM, VPC, spot, quotas | None |
| Compute billing | AWS bills you directly, no markup (RunsOn docs) | Per-minute, managed |
| Self-healing failures | No (spot auto-retry on-demand once, per docs) | Yes (detect, fix, retry) |
| Workflow change to switch | One-line runs-on label (RunsOn docs) | One-line runs-on label |
| Best for | Max control + lowest raw spot cost | Zero-ops + self-healing |
What you keep and what you hand off
Your workflows, actions, and YAML stay the same because both use standard GitHub Actions runners. What you hand off with Latchkey is the operational surface RunsOn asks you to run in your own AWS: the CloudFormation stack, VPC and subnets, IAM roles and permission boundaries, spot capacity management, and AWS service quotas (all documented at runs-on.com/quickstart and runs-on.com/docs). With Latchkey there is no stack and no AWS account to manage.
Migration steps
- Inventory the runner labels your workflows use today (RunsOn labels are constraint queries like
runner=16cpu-linux-arm64orcpu=4/ram=16/family=c7a+m7a, per runs-on.com/runners). - Map each label to an equivalent Latchkey managed runner size.
- Swap the runs-on label on one pilot workflow and compare wall-clock time and reliability.
- Roll out remaining workflows, then decommission the RunsOn CloudFormation stack in your AWS account once traffic is fully cut over.
What Latchkey adds
Latchkey is built around self-healing CI: out-of-memory kills, disk-full errors, registry timeouts, and other transient failures are detected and retried automatically, so you stop paying for re-runs. It also removes the AWS operations RunsOn leaves with you, since there is no stack, no IAM, and no spot capacity to manage.
The verdict
Stay on RunsOn if running runners inside your own AWS account for data residency and lowest raw spot cost is worth operating the stack yourself. If you would rather hand off the CloudFormation, IAM, spot, and quota work and get self-healing on every job, Latchkey is the managed destination. Start free and pilot one workflow before you cut over.