Tenki vs. RunsOn: Pricing, Architecture, and Ops

GitHub's default runners work fine until they don't. At some point, your team hits the wall: builds take too long, costs balloon, or you need capabilities that GitHub simply doesn't offer at your plan tier. That's where third-party runner providers come in.

RunsOn and Tenki are two of the more interesting options available right now, but they take fundamentally different approaches. RunsOn deploys into your own AWS account and gives you full infrastructure control. Tenki runs everything for you as a managed service. That core difference shapes almost every other decision: what you pay, what you maintain, and what you give up.

This comparison covers both products' pricing, deployment architecture, security posture, and operational burden, using data pulled directly from their public documentation as of April 2026.

Deployment Architecture

The single biggest difference between these two products is where the infrastructure lives.

RunsOn: Your AWS Account, Your Infrastructure

RunsOn deploys a server component into your AWS account via CloudFormation or, as of v2.11.0 (March 2026), Terraform and OpenTofu. The server runs on AWS AppRunner with a limited IAM role. When a GitHub Actions job is queued, RunsOn spins up an ephemeral EC2 instance, runs the job, and terminates the instance. No persistent runners, no state leakage between jobs.

Everything stays in your account: runner VMs, S3 caches, CloudWatch logs, SQS queue payloads, and the GitHub App credentials you create during setup. RunsOn's own infrastructure only handles license validation and limited product telemetry.

Installation takes about 10 minutes according to RunsOn's docs. That's not a throwaway marketing claim — it really is a single CloudFormation stack or Terraform module. But "10 minutes to install" and "10 minutes to production-ready" aren't the same thing. You'll still need to decide on VPC configuration, spot instance policies, cache storage, and monitoring. That's operational surface area your team owns going forward.

Tenki: Managed From the Ground Up

Tenki takes the opposite approach. You connect your GitHub account, select runner sizes, and change one line in your workflow YAML. That's the entire setup. Tenki runs on its own bare-metal servers, handles runner images, manages caching (up to 10 GB on the Developer tier), and deals with scaling. Your code runs on ephemeral VMs, but you never touch the underlying infrastructure.

The migration path is genuinely low-friction. Tenki's site advertises "Start in less than 2 min," and based on the setup flow (connect GitHub, pick runners, update YAML label), that's plausible for a single repository. Rolling it out across a large org with dozens of workflow files takes longer, obviously, but the per-repo work is minimal.

Pricing: What You Actually Pay

This is where things get interesting, because the pricing models are structured differently enough that a direct per-minute comparison only tells part of the story.

RunsOn's Model: License + AWS Compute

RunsOn charges a flat annual license fee for the software. You pay AWS separately for compute.

• Commercial: €300/year — unlimited runners, all features, email support
• Sponsorship: €1,500/year — adds source code access, dedicated Slack Connect, priority support
• Demo: Free for 15 days

The license is per-organization, not per-seat. A team of 5 and a team of 500 pay the same €300/year for the software. Actual compute costs depend entirely on your AWS usage. RunsOn publishes spot-price comparisons showing savings of 7-12x over GitHub-hosted runners for Linux x64 instances. For example, a 2-vCPU runner costs $0.0008/min on RunsOn (spot, us-east-1) versus $0.006/min on GitHub — a 7.3x difference.

The catch: spot prices vary by region and time. Those per-minute numbers are best-case in us-east-1. You can run on-demand instances for more predictable pricing, but the savings shrink. And you need to factor in the cost of EBS storage (40 GB gp3 per runner), data transfer, and whatever S3/CloudWatch usage the cache and monitoring generate.

Tenki's Model: Pay-Per-Minute

Tenki's pricing is simpler but higher per-minute. There's no license fee. You pay for what you use.

• Free tier: 700 minutes (one-time), no credit card required
• Developer tier: $0.0015/CPU-minute, with 1,700 free minutes per month. Per-minute rates by runner size: 2 vCPU at $0.003/min, 4 vCPU at $0.006/min, 8 vCPU at $0.012/min, 16 vCPU at $0.024/min
• Enterprise: Custom pricing with committed-use discounts, white-glove onboarding, and self-hosting options

Tenki advertises 50% savings versus GitHub-hosted runners. Comparing the two directly: a 2-vCPU runner costs $0.003/min on Tenki versus $0.0008/min on RunsOn (spot). That's a meaningful gap. But Tenki's price includes everything: compute, storage, networking, caching, monitoring, and zero ops overhead. RunsOn's $0.0008 doesn't include EBS, data transfer, or the time your team spends managing the infrastructure.

For a team running 10,000 minutes/month on 2-vCPU runners: Tenki costs roughly $30 (after free minutes). RunsOn's AWS bill would be around $8 in spot compute plus ~€25/month for the license (€300/year), putting total cost around $33. At that scale, the cost difference is negligible. At 100,000 minutes/month, RunsOn's flat license amortizes to almost nothing and the raw compute gap widens in RunsOn's favor.

Scale and Throughput

RunsOn has hard public numbers here. In March 2026, RunsOn processed 1.36 million jobs in a single day across all customers — roughly 15.7 jobs per second, sustained over 24 hours. That's up from 990k just six weeks earlier and 200k in November 2024. The growth trajectory is steep, and RunsOn's founder Cyril Rohr has claimed the product handles approximately 1.5% of all GitHub Actions jobs.

Because RunsOn deploys per-customer, those 1.36M jobs are distributed across hundreds of independent installations. Each customer's RunsOn instance scales against their own AWS account limits — EC2 service quotas, VPC capacity, and so on. The throughput ceiling is effectively your AWS account.

Tenki's published benchmarks focus on per-job performance rather than aggregate throughput: 67% faster than GitHub runners on the Citrea project, 48% faster on n8n. The Developer tier supports up to 40 concurrent jobs. Tenki doesn't publish daily job volume numbers the way RunsOn does, so it's hard to compare aggregate scale directly. The 40-concurrent-job limit is worth noting for teams with very high parallelism, though the Enterprise tier removes that cap.

Runner Images and Maintenance

RunsOn publishes public AMIs for its runner images, built from an open-source repository. These get updated within 48 hours of new GitHub runner image releases. The images cover Ubuntu, Windows, and ARM64 GPU variants. If you want maximum control, you can build your own AMIs from RunsOn's templates or use entirely custom images via Packer.

That flexibility is a genuine advantage for teams with specific toolchain requirements. But it's also more surface area. You're responsible for auditing those images, keeping them current, and managing the AMI lifecycle across regions.

Tenki handles runner images entirely on your behalf. You pick a runner size, Tenki provides the environment. The available OS options are Linux x64 and macOS (M4 chips, available as an add-on). Tenki doesn't expose AMIs or image customization — you get what they provide. For teams that just need standard GitHub Actions runner tooling, that's a non-issue. For teams running custom compilers, proprietary SDKs, or specific OS configurations, it's a constraint.

Security and Data Residency

RunsOn's security model starts with a structural advantage: your code and secrets never leave your AWS account. Runner VMs, caches, logs, queue payloads, and GitHub App credentials all stay in your environment. The RunsOn server itself runs in your account on AppRunner with a limited IAM role. The only data that flows to RunsOn's infrastructure is license validation and product telemetry (org identifier, version, region, instance metadata).

RunsOn also has a partnership with StepSecurity (announced February 2025) for supply-chain protection on runners. StepSecurity provides network monitoring, file integrity checks, and security insights for GitHub Actions workflows. This is meaningful for teams in regulated industries where CI/CD audit trails and runtime integrity monitoring are compliance requirements.

For data residency, RunsOn wins by default. You choose the AWS region, so you can keep builds in eu-west-1 for GDPR compliance or in a GovCloud region for FedRAMP. That's not something a managed provider can match without explicit regional infrastructure.

Tenki runs ephemeral VMs for each job, which prevents cross-job state leakage. That's the same isolation model RunsOn uses, just on Tenki-owned bare-metal servers instead of your AWS instances. Your code does transit through Tenki's infrastructure during execution. For many teams, that's perfectly acceptable — it's the same trust model as GitHub-hosted runners. For teams with strict data residency or sovereignty requirements, it's a hard constraint.

Nested Virtualization and Specialized Workloads

RunsOn v2.12.2 (March 26, 2026) added nested virtualization support on both Linux and Windows runners. This enables KVM acceleration for Android Emulator tests, QEMU/KVM boot tests, Firecracker and Kata microVM workloads, and Hyper-V scenarios on Windows. You enable it with a nested-virt label and it requires specific instance families (c8i, m8i, or r8i).

This matters for mobile teams. Running Android instrumented tests on CI has historically been painful — most runner providers don't support the hardware virtualization extensions that Android Emulators need. RunsOn's nested-virt support is a concrete, verifiable differentiator.

RunsOn also supports GPU runners (NVIDIA) for ML training and inference workloads, including ARM64 GPU images as of v2.12.2.

Tenki doesn't currently advertise nested virtualization or GPU runners. Its runner lineup covers Linux x64 and macOS M4, which handles the majority of standard CI workloads. If your team needs Android emulator testing on CI or Firecracker-based validation, RunsOn is the clear pick today.

Operational Overhead

This is the dimension that doesn't show up in pricing tables but determines whether a tool is sustainable for your team long-term.

With RunsOn, you're responsible for: upgrading the CloudFormation/Terraform stack when new versions drop, monitoring your AWS costs and EC2 service quotas, managing spot instance interruptions (RunsOn's agent handles graceful fallback, but you still need to configure the policies), maintaining or at least tracking AMI updates, configuring VPC networking and security groups, and handling S3 cache cleanup.

RunsOn does a lot to minimize this — ephemeral runners eliminate server management, the agent handles spot interruptions automatically, and CloudFormation one-click upgrades keep the update process simple. But "minimal ops" isn't "zero ops." Someone on your team needs to own the AWS account, watch for cost anomalies, and handle edge cases.

With Tenki, the ops burden is genuinely close to zero. You don't manage infrastructure, images, caching systems, or networking. If something breaks on the runner side, it's Tenki's problem. Your team's only operational task is choosing the right runner label in your YAML files. Tenki's Developer tier includes Discord support; Enterprise gets a dedicated Slack channel.

For a team with a dedicated platform engineering group, RunsOn's operational requirements are table stakes. For a 5-person startup where nobody wants to be the AWS admin, Tenki's managed model is far more practical.

Where Each Product Wins

RunsOn is the stronger choice when:

• You need data residency control — picking specific AWS regions for compliance
• You have high CI volume where raw compute cost dominates (100k+ minutes/month)
• You need nested virtualization for Android emulators, Firecracker, or Hyper-V
• You require GPU runners for ML workloads
• You need custom runner images with specific toolchains or OS configurations
• Your security policy prohibits code execution on third-party infrastructure
• You want Windows runner support

Tenki is the stronger choice when:

• Your team doesn't have (or want) an AWS account dedicated to CI
• Zero operational overhead matters more than squeezing out every cent per minute
• You need macOS runners (M4 chips) and don't want to manage Mac infrastructure
• You want predictable pricing with no surprise AWS bills
• Migration speed is a priority — one line change in YAML, done in minutes
• You also want AI-powered code reviews alongside your runners (Tenki bundles a code reviewer product separately)

The Real Decision

The choice between RunsOn and Tenki isn't really about which one is "better." It's about whether your team wants to own the infrastructure or not.

RunsOn gives you full control, best-in-class per-minute costs at scale, and capabilities like nested virtualization that no managed provider currently matches. The price of that control is AWS expertise on your team and ongoing operational attention. At €300/year for the license, the software cost is almost trivially low — but the total cost of ownership includes whatever your team spends managing the AWS side.

Tenki trades raw cost efficiency for simplicity. You're paying a premium per minute compared to RunsOn's spot pricing, but that premium buys you zero infrastructure management, zero AWS complexity, and a setup that takes minutes instead of hours. For small-to-mid teams that need faster, cheaper runners without a platform engineering investment, that's a sensible trade.

Both products use ephemeral VMs. Both are cheaper than GitHub's default runners. Both handle the common case well. The fork in the road is whether "self-hosted in my AWS" or "fully managed" better matches your team's risk tolerance, budget, and available engineering bandwidth.

Pricing and feature sets in this comparison are sourced from public documentation as of April 2026. Both products ship frequently — verify current numbers before making a purchasing decision.