Ankra Pipelines vs GitHub Actions runners

Two different jobs

Runner products make GitHub Actions cheaper or faster to run. RunsOn starts each job on a fresh EC2 instance in your own AWS account. Blacksmith, Depot and Namespace run jobs on their own machines. GitHub sells its own hosted runners. In every case the workflow stays the same, and so does everything around it.

Ankra Pipelines replaces the workflow. One file, .ankra/pipeline.yaml, tests the code, builds the image, scans it, publishes an immutable tag and hands it to the deploy. It runs on Kubernetes you already operate through Ankra, and Ankra writes the file for you when you add an application.

Choose a runner product to keep GitHub Actions and run it on different machines. Choose Ankra Pipelines when you want one system from commit to production, on infrastructure you choose.

Where jobs run and how they are billed

• RunsOn runs each job on a fresh EC2 instance in your AWS account and VPC. You pay a flat yearly licence per legal entity, plus your AWS bill.
• Blacksmith runs jobs on its own machines and bills per runner minute, with 3,000 free minutes a month.
• Depot runs jobs on its own machines in US or EU regions, or in your AWS account on its Business plan. Monthly plans include runner minutes, then it bills per minute.
• Namespace runs jobs on its own hardware and bills per unit minute, 1 vCPU and 2 GB for one minute, pay as you go or on a plan.
• GitHub-hosted runners run on GitHub’s machines and bill per minute after the minutes your plan includes.
• Ankra Pipelines runs jobs as Kubernetes Jobs on a cluster you run through Ankra, on any provider. There is no per-minute charge. Your provider bills the nodes, and Ankra bills per worker vCPU beyond the first 30.

Where RunsOn is good

RunsOn is a strong product, and it is easy to adopt. After a CloudFormation stack and a GitHub App, the change is one line in each workflow, a new runs-on label. Actions, caches and secrets keep working as before.

The pricing is simple too. AWS bills the instances, spot ones included, at its own price with no markup from RunsOn. RunsOn itself is a flat yearly licence per legal entity, from €300 a year, free for non-commercial use, and one licence covers every GitHub organisation and AWS account you own. Jobs and the cache stay in your own AWS account and VPC.

The limit is the cloud. RunsOn’s pricing page counts one install as “a CloudFormation stack in one AWS account/region” and describes only AWS. If your servers are on Hetzner, OVHcloud or your own hardware, your CI still runs on AWS.

Hosted runner vendors

Blacksmith, Depot and Namespace sell faster machines for GitHub Actions and bill by the minute. Blacksmith includes 3,000 free minutes a month. Depot includes runner minutes in its monthly plans and can deploy into your AWS account on its Business plan. Namespace bills in unit minutes of 1 vCPU and 2 GB. Depot and Namespace also sell remote container builds.

GitHub cut the price of its hosted runners by up to 39% from 1 January 2026. It also announced a per-minute platform charge for self-hosted runners, then postponed it to re-evaluate.

Ankra Pipelines does not run on GitHub Actions, so it uses no Actions minutes at all.

Any provider, on the Kubernetes you already run

Ankra Pipelines runs every step as a Kubernetes Job on a cluster you already run through Ankra. It does not have to be a dedicated cluster. Steps run in their own namespace, with their own workers, so a busy pipeline never delays a deploy. Many teams start on their staging cluster.

That cluster can be on any provider Ankra supports. Ankra builds Kubernetes on Hetzner, OVHcloud, UpCloud, DigitalOcean, AWS EC2 and Proxmox VE, and on Scaleway and Ankra Cloud in closed beta. It creates EKS, GKE, AKS and other provider services, or imports a cluster you already run. When steps need more room than the nodes have free, the cluster’s autoscaler adds nodes, and you can add more clusters to the CI pool.

No per-minute bill

There is no CI vendor charging by the minute. The nodes are yours, so your provider bills them at its own price. Ankra’s fee is per worker vCPU across your clusters, CI nodes included, and the first 30 vCPU are free.

Ankra Pipelines also avoids work rather than buying bigger machines for it. Affected-only stages follow your real Go and pnpm import graph and skip what a change cannot reach. With promote_from, a merge whose tree its pull request already tested publishes that exact image as a re-tag instead of building it again. Every run records the time it saved.

One system from commit to production

A runner ends when the job ends. An Ankra pipeline carries on to the running service.

• Test. Run stages in the image you choose, with sidecar databases, caches and test reports.
• Build. Rootless BuildKit builds the image inside your cluster and pushes it by digest.
• Scan and gate. Semgrep, Checkov and Trivy scan the source, the configuration and the image. A gate judges the exact digest against your organisation’s policy, and nothing is published until it passes.
• Publish. The image gets an immutable sha- tag. With verified provenance on, a deploy refuses any image that did not pass your organisation’s gate.
• Deploy and promote. Development can follow every merge while a person promotes the same tag to production, never a rebuild.
• Preview. A GitHub pull request gets a preview environment with the image its pipeline built.
• AI review. Ankra’s AI reviews pull requests with the pipeline’s result in view, explains a failed run and can open the fix as a pull request.

Security is part of the design. Anyone can change what a pipeline runs, but secrets, network access, compute and caches come only from the default branch after an administrator approves them. A pull request that adds a secret still runs, without it, and the check says why.

Where your code and data stay

Pipeline steps check out and build your code on your own nodes, in the region you pick. Images go to the registry you declare, or to Ankra’s registry. Ankra’s control plane runs in Finland. The full list of providers and locations is on the trust page.

When to choose Ankra Pipelines, and when to choose a runner

Choose Ankra Pipelines when you want CI and CD in one system, your servers are on Hetzner, OVHcloud, UpCloud, DigitalOcean, your own hardware or any cloud, and you want scans, an immutable tag and the deploy in the same pipeline.

Choose RunsOn when you run on AWS and want your GitHub Actions workflows unchanged, on EC2 in your own account.

Choose Blacksmith, Depot, Namespace or GitHub-hosted runners when you want faster GitHub Actions with no infrastructure of your own to run.

Try it on one repository

1. Pick a CI cluster. Any cluster you run through Ankra works, including your staging cluster.
2. Convert one workflow. Ankra converts a GitHub Actions, GitLab CI, Bitbucket or CircleCI file into .ankra/pipeline.yaml, and for an application ankra application pipeline convert opens the pull request. Migrate from GitHub Actions covers running both side by side.
3. Open a pull request. Read the Ankra pipeline check, the scan findings and the preview.
4. Merge and promote. Watch the same tag reach development, then promote it to production.

See RunsOn’s pricing, Blacksmith’s pricing, Depot’s pricing, Namespace’s pricing, GitHub’s runner pricing and Ankra’s pricing.

Reviewed 28 October 2026 against the pricing pages of RunsOn, Blacksmith, Depot and Namespace and GitHub’s Actions pricing documentation. Product scope and plans can change.