CRACI vs RunsOn

The short answer

RunsOn is self-hosted GitHub Actions runners without the upkeep of a runner fleet. One CloudFormation stack or Terraform module deploys it into your AWS account; every job then gets a fresh EC2 instance of any type you choose, and AWS bills the compute at cost. If you want runners inside your own cloud account and the lowest possible compute bill, especially on spot instances, RunsOn is hard to beat.

CRACI is CI that handles supply chain security natively. It is a managed, GitHub Actions-compatible runner, and the security is part of the runner rather than a tool added to it: CRACI records every external dependency the build fetched, enforces an egress policy on the build network, and turns that record into SBOMs, vulnerability monitoring and evidence. Both products replace the runner your jobs run on, so you choose one.

At a glance

What RunsOn does well

Your account, your data. The control plane, the runner VMs, the S3 cache and the logs all live in your AWS account, and RunsOn's own data flows are limited to license validation, telemetry and support. For teams whose security review stops at "a third party runs our code and secrets", that is the answer RunsOn is built to give. CRACI runners are managed today; customer-hosted runners are on its roadmap for Enterprise.

Any instance, one per job. The runs-on label picks the machine, so a job can ask for a large compute-optimized instance, a GPU, local NVMe storage or Windows. Every job gets a new EC2 instance that is destroyed when it finishes, and RunsOn says jobs typically start in about 30 seconds, or under 6 with warm pools.

Cost. RunsOn adds no markup to AWS compute and charges a flat license, from about $348 (€300) a year. It says the result is 7 to 12 times cheaper than GitHub-hosted runners. Spot instances with automatic fallback to on-demand keep the bill down further. These are RunsOn's figures; your instance mix and region decide the real number.

Caching and observability. An S3-backed cache in your VPC replaces GitHub's cache without its size ceiling, Docker layer caching is built in, and EBS sticky disks and EFS shared volumes keep state across jobs. Per-job metrics and cost reporting go to CloudWatch and OpenTelemetry.

Security add-ons. An integration with StepSecurity Harden-Runner adds egress monitoring and filtering and detection of source code tampering during the build, with a StepSecurity enterprise license.

Price and sizing

On compute alone, RunsOn on spot instances costs a fraction of CRACI's $0.004 per 2 vCPU minute. The comparison is not only per minute, though. With RunsOn you also pay the license and the AWS services around the runners, such as NAT gateways for static IPs, and your team owns the stack: upgrades, AWS quotas and incidents. CRACI is one per-minute price, metered per second, with no monthly fee, and CRACI runs the infrastructure. See CRACI pricing for current terms and managed vs self-hosted runners for the wider trade-off.

On speed, CRACI runs builds about twice as fast as GitHub-hosted runners, thanks to faster hardware, shorter queue times and caching. RunsOn's speed depends on the instance type you pick. We have not benchmarked the two against each other.

Where CRACI is different

A record of what the build fetched

While each job runs, a package-aware proxy records traffic to package sources: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus download presets. Dependency evidence travels with CI caches, so packages restored from a cache are still counted. That includes the hidden dependencies no lockfile lists, such as code downloaded by install hooks or build scripts, and base image layers. Every job produces a CycloneDX or SPDX SBOM with a completeness state per job and per cache.

Control over what the build can reach

Security groups decide which networks a RunsOn runner can reach; they do not know which package registry a job is supposed to use. CRACI's egress policy does: default deny or default allow, 24 built-in software-source presets, typed custom sources for npm, PyPI, apt, apk, the Go proxy, Nix, Cargo, OCI registries and Git over HTTPS and SSH, and explicit TLS, TCP, UDP and ICMP rules. Policies are validated before the job starts, fail closed, and send an alert on a violation. Because the policy allows only what the build needs, it blocks exfiltration to hosts the build does not need, even in an attack nobody has seen before.

Harden-Runner on RunsOn goes further in one place: it also watches for source files being modified during the build, which CRACI does not do.

Provenance and monitoring

The API returns SBOMs, network traces and provenance. CRACI does not sign provenance and claims no SLSA level. It aggregates vulnerabilities across builds and repositories and keeps re-evaluating monitored SBOMs.

Two different security questions

RunsOn answers "who holds my code, secrets and runner state?" by keeping all of it in your AWS account. CRACI answers a different question: "what did this build pull in, and where did it connect?" CRACI runs every job in its own isolated VM, does not store your source code, and is ISO 27001 certified. The second answer is what an auditor, a customer or the Cyber Resilience Act asks you for.

Book a demo to see the SBOM, network trace and provenance from one of your own workflows.

Which one fits

RunsOn is the better fit when

• Runners must run inside your own AWS account, next to your VPC resources.
• The lowest compute cost matters most, and you are comfortable operating a stack in AWS.
• You need Windows runners, GPU instances or specific EC2 instance types today.
• Your projects are non-commercial, which RunsOn covers for free.

CRACI is the better fit when

• You ship software where you must show what went into each release, from the build itself.
• You want to restrict what builds can reach, with a policy that fails closed and needs no extra license.
• You need monitoring of what shipped, without adding tools to every workflow.
• You would rather not run CI infrastructure, and want builds on European infrastructure.

What you give up with CRACI. Runners in your own AWS account, which are on the roadmap for Enterprise, Windows runners, which are on the roadmap too, and the lowest compute bill. What you gain is a build record that security and compliance can use without another scanner in the pipeline, on infrastructure you do not have to run.

For the Cyber Resilience Act

The EU Cyber Resilience Act expects manufacturers to know what is in each release and to handle its vulnerabilities, with reporting obligations from September 2026 and full application from December 2027. A self-hosted runner does not produce that evidence by itself; you would add SBOM and scanning tools to your workflows. CRACI produces it from the build record and exports SBOMs as CycloneDX or SPDX. It automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process.

Moving from RunsOn

CRACI replaces the runner, not GitHub Actions. Workflows and the GitHub UI stay the same, and the job label becomes runs-on: craci. Jobs get Docker Engine, Buildx and Compose v2, a GitHub-compatible Ubuntu 24.04 image, and nested virtualization on x86-64. Read more about CI/CD integration and build-time SBOM generation. Startups can apply for the startup program.

RunsOn vs CRACI: common questions

Pricing, hosting, platforms and security, answered from each vendor's published information

What is RunsOn?

RunsOn is self-hosted GitHub Actions runners, done as a product. You deploy one CloudFormation stack or Terraform module into your own AWS account, and RunsOn launches a fresh EC2 instance for every job and terminates it when the job ends. Runners, caches, logs and credentials stay in your AWS account. It was founded in 2023 by Cyril Rohr, who is based in Rennes, France.

How much does RunsOn cost?

As of September 2026, RunsOn charges a flat annual license per legal entity: from about $348 (€300) a year on Starter, about $1,044 (€900) on Growth, about $2,088 (€1,800) on Scale and about $4,176 (€3,600) on Enterprise, depending on how many runners you launch a month. AWS bills the compute directly, per second, with no RunsOn markup. RunsOn lists a 2 vCPU x64 spot instance in us-east-1 at about $0.0009 per minute. It is free for non-commercial use and has a 15-day trial.

Is RunsOn cheaper than CRACI?

For compute, yes, and by a wide margin on spot instances. CRACI charges $0.004 per 2 vCPU minute, while a 2 vCPU spot instance through RunsOn costs about $0.0009 per minute in us-east-1, plus the license. The total also includes your AWS networking and storage, and the time to run the stack. What CRACI adds on the runner is the build record: an SBOM for every job, an egress policy, provenance data and vulnerability monitoring.

Does RunsOn generate SBOMs or build provenance?

Not among its documented features. RunsOn focuses on compute, caching, cost and observability in your AWS account. CRACI records the packages every job fetches, including packages restored from caches, and produces a CycloneDX or SPDX SBOM with a completeness state. The API returns SBOMs, network traces and provenance.

Can RunsOn restrict what a build can reach on the network?

RunsOn runners sit in your VPC, so AWS security groups and routing apply, and static egress IPs come from NAT gateways. For egress filtering inside the job, RunsOn integrates StepSecurity Harden-Runner, which builds a baseline of each job's outbound traffic and can enforce it as an allow list; on RunsOn it needs a StepSecurity enterprise license. CRACI enforces an egress policy at the runner itself: default deny or allow, 24 built-in software-source presets, validated before the job starts and failing closed.

Can I run CRACI in my own AWS account?

Not today. CRACI runners are managed, on European infrastructure, and customer-hosted runners are on the roadmap for the Enterprise plan. If runners inside your own AWS account are a hard requirement, RunsOn is built for exactly that.

Does CRACI support Windows or macOS runners?

CRACI runs Linux on x86-64 and ARM64 today, with Windows and macOS on the roadmap. RunsOn offers Windows Server 2022 and 2025 and GPU instances; macOS jobs stay on GitHub-hosted runners with RunsOn too.

Do I have to rewrite my GitHub Actions workflows to switch?

No. Both products replace the runner, not GitHub Actions. Workflows, triggers and the GitHub UI stay the same; on CRACI the job label becomes runs-on: craci.