Skip to content
| Docs

Changelog

The latest improvements to Avrea.

See where every CI minute ran

  • console
  • runners

Settings > Usage shows how many CI minutes your organization spent and where they ran: on Avrea runners, on GitHub-hosted runners, or elsewhere. Use it to track a migration to Avrea, or to find the jobs that still run somewhere else.

  • Every job, whichever runner it used. Minutes are split by runner class and runner label, including jobs that did not run on Avrea.
  • Break it down. Switch between runners, workflows, jobs and operating systems, and group the chart by day, week or month for the current month, recent months or a rolling window.
  • Export to CSV for your own reporting.
  • Every member can see it. Totals cover the repositories you can read. Amounts stay on the Billing page.

Playwright and Puppeteer browsers now download from the cache beside your runners

  • cache
  • performance

npx playwright install no longer fetches the same Chromium, Firefox, and WebKit archives from the internet on every job, and neither do Puppeteer's Chrome for Testing and Chrome headless-shell downloads. Avrea now serves them from the packages cache in the same datacenter as your runners, so a repeat install fetches nothing upstream.

  • Nothing to set up. Runners are pointed at the cache automatically on Linux, macOS, and Windows. On a cache miss, Avrea fetches from the upstream download host; for Playwright it also tries the alternate mirrors if a request fails.
  • Puppeteer works as installed. Puppeteer's install script picks up the cache on its own. If your package manager blocks install scripts, pass --base-url to the Puppeteer browser CLI; the docs show the exact command.
  • Your choice per repository. Turn either cache off for an organization or a single repository under Settings, or with avr settings set.

Browsers are still unpacked on each run. Only the download is cached.

Playwright browsers · Puppeteer browsers

A quicker console on large runs, and job logs that start at the start

  • console
  • performance
  • reliability
  • Large runs stop dragging. Workflow analytics now respond in about 0.2 seconds instead of 2.5, scrolling and searching a long log takes about a fifth of the time it did, and the analytics view holds roughly half the memory.
  • Logs start at the start. Setup output and step names from the first moments of a job used to be dropped at times. They are now kept and shown in order, and step names stay attached to their lines even when the names arrive late. The console and the avr CLI read logs from the same store.
  • Filter jobs by name. The jobs activity view has a job-name filter, and the choice is kept in the link you share.
  • Pull request filters that combine. On a repository's Pull requests tab, pick any mix of Authored, Involved, and the rest, and of Open, Closed, and Merged. Merged is now separate from Closed.
  • A rail that remembers. The navigation rail stays expanded or collapsed the way you left it on each device, and a collapsed rail opens when you hover over it. Settings, Docs, What's New, and Log out are gathered in one account menu at the foot of the rail.
  • A clearer billing breakdown. The current-period breakdown lists each runner type with its minutes, share, unit price, and amount. It also shows how much of your free tier you have used.
  • Follow the changelog. Subscribe from the docs changelog by RSS, or with /feed subscribe in Slack.

Runners now report their real CPU core layout

  • runners
  • performance

Each Avrea runner with two or more vCPUs owns whole physical CPU cores, and its vCPUs are the two hardware threads of those cores. Runners now report that layout to the operating system instead of presenting every vCPU as a separate core, so the guest scheduler spreads work across real cores first.

  • Same layout as GitHub-hosted runners. A 4-vCPU runner reports 2 cores with 2 threads each, the way GitHub-hosted runners report theirs.
  • Tools that count physical cores see half the vCPUs. For example, pytest -n auto with psutil installed starts 2 workers on a 4-vCPU runner. Use pytest -n logical (or set PYTEST_XDIST_AUTO_NUM_WORKERS) to keep one worker per vCPU. nproc and most build tools count every vCPU and are unaffected.

Ubuntu apt installs now come from the cache beside your runners

  • cache
  • performance

apt-get install on Ubuntu runners no longer re-downloads the same .deb files from the internet on every job. Avrea now serves them from the package cache in the same datacenter as your runners.

Nothing to set up: Ubuntu 22.04, 24.04 and 26.04 runners are configured automatically. Every original repository stays in place as a direct fallback, and apt keeps verifying repository signatures and package hashes exactly as before.

Containers do not inherit the runner's apt configuration, so they opt in explicitly. Setup helpers are available for Alpine, Fedora 44 and Debian 13.

You can turn operating system package caching off for an organization or a single repository under Settings.

Read the operating system package cache docs.

Git Checkout Acceleration now brings your code and pull requests with it

  • cache
  • console
  • repositories

Git Checkout Acceleration keeps a current copy of your repository in the datacenter where its jobs run, so actions/checkout finds the objects in place instead of downloading them from GitHub. That copy is now good for more than checkouts. Turn acceleration on for a repository and the console reads it directly, adding two tabs.

  • Files. Browse the tree at any branch or tag, read a file, open a single commit, and compare two refs. Commit history is addressable per ref, so a link points at what you meant.
  • Pull requests. Every pull request for the repository, filtered by state, narrowed to the ones you opened or were pulled into, with drafts hidden if you prefer. Search by title, number, author, or branch.
  • The row tells you where it stands. Size from XS to XL, draft marker, the rolled-up status of its checks, and the review decision - approved, changes requested, or waiting on a blocking reviewer.
  • A merge verdict that is current. Each open pull request is checked against the tip of its base branch as it is now, and says plainly when the answer is still being worked out or cannot be determined.
  • Commits and diffs. Each commit on the pull request and the changes it made, without opening GitHub.

Turn it on under Settings → Cache on an organization or a single repository, or with avr settings set cache.git.enabled true. Git Checkout Acceleration covers the checkout side.

See what your caches did on every run

  • cache
  • console

Open a workflow run, or a single job inside it, and expand the cache panel. There is nothing to switch on - every organization has it.

  • What your caches actually served. How much each cache handed to the job and when, across the GitHub Actions cache, build caches, and the packages cache, laid out over the life of the run.
  • Per job, not only per run. The same breakdown on an individual job, so a run with one odd job is easy to narrow down.
  • Gradle, task by task. Gradle builds report each task: which came from the cache, which were already up to date, and which ran. Go and Xcode builds report what their build cache served across the session.
  • It says when it does not know. A panel with partial or still-arriving data labels itself that way instead of quietly under-reporting.

Queued jobs explain themselves, and invitations arrive with a role

  • console
  • reliability
  • A queued job says what it is waiting for. Rather than sitting there, it names the reason: no host ready yet, no runner image that matches, a placement restriction, a limit on concurrent machines, or capacity that exists but not in one contiguous piece. Other blockers are listed alongside the main one, in the console and from the CLI.
  • Jobs stop when their target is gone. A job whose repository or GitHub installation has been removed ends promptly, with a reason and a notification naming what to fix.
  • Invite people as who they are. Choose Admin, Billing admin, or User when you send the invitation, by email address or GitHub username, instead of inviting and then changing the role.
  • Repository URLs you can type. Repositories live at their owner and name. Older links keep working, and a push notification opens the repository and the changes that caused it.
  • Screens that stay usable. A tab left open across a release repairs itself instead of going inert, and the activity repository filter follows your working set instead of listing every repository you can see.

Cache private npm packages on Avrea runners

  • cache

Private packages no longer have to be the part of an install that always leaves your runners. Point your scope at the Avrea packages cache and repeat builds reuse tarballs held beside them.

  • Your registry still decides. Every request is checked against your registry for access, cache hits included. Avrea never serves a private tarball to someone your registry would refuse.
  • Scoped to what you configure. Enable it for an organization or a single repository, then set the package scope and the registry token.
  • Counted against the repository cache quota. Private tarballs use the same quota as the rest of your cached packages.

Set up private npm caching

Repositories for every organization, on a much faster console

  • console
  • repositories
  • performance

The Repositories section is no longer something to ask for. Every organization has it, and the console around it got considerably quicker.

  • On for everyone. Repositories is generally available, so a new organization gets the section immediately, with per-repository settings, the cache view, and the SBOM tab.
  • Scoped to what you work on. Each person gets their own working set per organization. Below about twenty accessible repositories you simply get all of them; above that, Avrea suggests a starting set from where you actually show up - your collaborator permissions, the runs and jobs attributed to you, and your recent pull requests. Search brings in anything else, and the choice is yours to change.
  • Complete lists on large organizations. Broad repository views used to return only part of the picture, or nothing from one installation, once an organization passed a thousand repositories. Access is now resolved in the background and repaired continuously, so the list you see is the full one.
  • Seconds off every org-wide view. Workflow runs, dashboard metrics, the analytics overview, the organization cache page, and current usage took five to fifteen seconds on busy organizations. They no longer do.
  • Screens that hold still. Loading states no longer flash blank panels before content arrives, the cache view can be filtered to a single repository, and an unreachable cache storage now says so instead of showing an empty table.

Your repository is ready before the job starts

  • cache
  • performance

Waiting on a checkout no longer has to be the first thing every run does. Open Settings → Cache in the console, on an organization or a single repository, to turn on the new options.

  • Checkouts start warm. With Git Checkout Acceleration on, Avrea prepares the repository from a datacenter-local Git mirror while the runner boots. Keep actions/checkout exactly where it is: it still runs, and it still decides what the job sees. Linux and macOS runners.
  • Submodules too. Git Submodule Precheckout preloads authorized submodules at the depth you choose - root only, direct submodules, or the full nested tree. Avrea discovers them from the commits your repository already pins, so there is no list to maintain and no extra credentials to hand over.
  • It never blocks a run. If a prepared repository is not usable, the workflow falls back to fetching from GitHub as it always did. The first run after you switch it on may still fetch from GitHub while the mirror finishes its initial sync.
  • Stop re-downloading the same actions. The new GitHub Actions Action Cache serves the action archives a workflow pulls with uses: from datacenter-local storage.

Each of these is off until you turn it on, in the console or with avr settings set. See Git Checkout Acceleration for workflow examples and current limits, and Managing caches for the full list of settings.

Faster Apple builds, and private Swift packages that resolve locally

  • cache
  • apple
  • performance

Two additions for teams building Apple platforms on Avrea, both under Settings → Cache in the console.

  • Tuist projects stop rebuilding the same modules. Turn on Tuist Module Cache and binary module artifacts are stored alongside your runners, so a later job or workflow run reuses a warm module instead of compiling it again. Give the project a stable fullHandle in Tuist.swift and Avrea wires up the rest of the environment for you.
  • Private packages resolve like public ones. Private Swift Packages extends the Avrea Swift registry to your organization's own private packages, so SwiftPM pulls them from the same colocated registry as everything else. Private package source stays isolated to the organization it belongs to, and access is still decided by your GitHub App installation.

Both caches are off by default and apply to new jobs. See Tuist Module Cache and Swift packages for project setup and eligibility rules.

A Software Bill of Materials for every repository

  • security
  • compliance

Open a repository in the console and select the SBOM tab to see a commit-pinned record of its production dependencies, versions, and licences.

  • Generated for you, or on demand. Repositories are analysed when first synced and when default-branch workflows change; Generate SBOM starts a fresh run against the default-branch tip whenever you need one.
  • Licence posture at a glance. Dependency and copyleft counts, plus the full licence distribution - and each count links to the packages behind it.
  • A dependency browser built for questions. Search by name or licence, narrow by ecosystem, or isolate packages that carry copyleft obligations.
  • History that keeps its receipts. Every recorded snapshot stays retrievable, including per-commit views and downloads for the SBOM that shipped with a release.
  • Standard formats. Every snapshot exports CycloneDX and SPDX documents plus the machine-readable inventory, from the console or the API.

Send your audit log to your own bucket

  • security
  • audit

Organization admins can now send the organization's audit log to a bucket they control. Open Settings → Audit log export to connect Amazon S3, another S3-compatible service, or Google Cloud Storage.

  • Keyless by default. Avrea can assume a tenant-bound AWS IAM role with Google OIDC, or write to GCS through an Avrea service account bound to the organization by a verified bucket label. Access keys and GCS JSON keys remain available when needed and are encrypted at rest.
  • Append-only buckets work. The exporter needs create permission, not delete or overwrite permission, so WORM retention policies are supported.
  • History is included. The first export backfills existing audit events; later events are delivered periodically as gzip-compressed NDJSON.
  • Failures are visible. Settings show the latest failure, and repeated failures automatically disable the destination and notify organization admins instead of retrying invisibly forever.

Delivery is at least once, so downstream ingestion should deduplicate using the stable event_id. See Audit log export for the AWS role-trust and GCS bucket-label setup.

Organization controls for SSH access to CI runners

  • runners
  • security

Organization administrators can now enable or disable SSH access to CI job runners from the SSH access settings page.

  • One policy for the organization. The setting applies to SSH credential requests and browser terminal sessions across the organization's CI jobs.
  • New access is denied immediately. After SSH access is disabled, members cannot request new credentials or start new browser terminal sessions.
  • Existing sessions are not interrupted. Sessions that were already established continue until their job VM is torn down.
  • Access attempts are auditable. Allowed requests and requests denied by organization policy or repository permissions are recorded in the organization's audit log.
  • console
  • ui

The console has been dark since day one. It now follows your system, and the places where a link or a picker used to put you somewhere unhelpful put you where you expected.

  • Light mode. The console follows your browser's appearance preference, and a System / Light / Dark switch in the side navigation overrides it when you'd rather choose. The choice is remembered per device. The log viewer, the SSH terminal, and the VM console stay dark on purpose — they read better that way, in either theme.
  • Links land where a click would. Open a link someone sent you to a run, a job, or a pull request and you get the list with the detail over it, exactly as if you had clicked it yourself — instead of a cramped page with nothing behind it. Closing leaves you on the list, ready to look at the next one.
  • Run a workflow on any branch. The branch picker now lists every branch, loading more as you scroll. It previously offered only the default branch, and closed itself the moment the list scrolled.
  • The audit log opens for every organization. For some organizations, one old entry was enough to stop the whole page from loading. Settings changes are also attributed to the person who made them now, rather than to "System".
  • A dashboard about your work, and analytics you can aim. The dashboard is one navigable feed instead of separate stacks, analytics take 7-, 30-, and 90-day presets or a custom range that stays in the link you share, and rows across the activity, job, workflow, pull request, and machine lists are properly clickable.
  • Members can read the settings that affect them. Anyone in your organization can now open Settings and Organization info and see how things are configured, clearly marked as view-only. Changing them still takes an organization admin.
  • The runner filter counts skipped jobs correctly. Jobs that GitHub skipped but that asked for an Avrea runner now appear under "Avrea only" instead of "exclude Avrea" — in the lists, in the totals, and in the API.
  • Fewer blank pages. A page that fails to load its data now says so and offers to try again, instead of leaving you to reload and hope.

Repository data follows your GitHub access

  • security
  • permissions

Access to a repository's data in Avrea is now decided the same way access to the repository itself is: by GitHub.

  • Reading a repository needs read on GitHub. Its cache entries and keys, analyses and reports, dependency inventory, and repository settings — all of it now requires that you can read the repository on GitHub. Belonging to the organization is no longer enough on its own. The organization-wide cache listing follows the same rule, so it names only the repositories you can see. Anything you can't reach reads as not found.
  • Changing a repository's egress rules needs admin on GitHub. Creating, editing, reordering, and deleting the egress firewall rules that a repository's build machines run under now requires admin access to that repository. Rules that apply to the whole organization remain an organization-admin matter.

Nothing to configure — this applies automatically. If someone on your team no longer sees a page they used to, the fix is to give them access to the repository on GitHub.

VPN connections from your runners now work

  • runners
  • networking

If your build needs to reach something inside your own network, a runner can now dial your VPN and keep the tunnel up.

  • Return traffic is no longer dropped. VPNs run over UDP, and replies from your VPN server come back on whatever port it uses. Those replies used to be discarded at the network edge unless the port happened to match one of a handful we allowed — which is why a VPN could look like it worked from one provider and silently failed from another. Every UDP reply to a connection your runner opened now gets back to it.
  • WireGuard is built into the runner kernel. No module to install and no kernel headers to chase before wg-quick up works. The runner kernel is current, too.
  • Your egress rules still decide who you can reach. The connection to your VPN server is an outbound connection like any other, so it has to be permitted by the egress firewall rules you've set for the organization or repository.

Nothing to change in your workflows — connect the way your VPN's own documentation describes.

Packages checked against the publisher, and no stray runners left behind

  • cache
  • security
  • reliability

Your lockfile already checks what you install. Avrea now checks the same bytes on the way in, so a cached copy can never differ from what the publisher published — and a job that fails to start no longer leaves anything behind on your repository.

Packages are verified before they're served

  • Checked against the publisher. npm tarballs are validated against the hash npm itself publishes, and crates against the checksum in the registry index. Anything that doesn't match never becomes a cache hit.
  • Verified before publishing, not after. Packages that Avrea fetches ahead of your first request are now validated in a holding area and only made available once they match. Previously the most popular packages — the ones most likely to be fetched ahead of time — were the ones most likely to skip this check.
  • Damaged entries repair themselves. An entry that fails a check while being read is discarded precisely, so a healthy copy written at the same moment survives instead of being thrown away with it.
  • Cache entries stay put. Once an entry is committed it can't be overwritten, so a second job writing the same key can't change what earlier jobs already read.
  • A cache problem can't fail your checkout. Git LFS downloads fall back to the origin across more failure modes, including slow and stalled responses, not just outright errors.

Runners clean up after themselves

When a job failed to start, the runner Avrea had already registered on your repository could be left behind with nothing to remove it — visible in your repository settings and never picking up work. Runners are now claimed before they're registered, and any that end up unclaimed are removed automatically. Nothing accumulates.

All of this applies to existing setups. No workflow changes are needed.

Git LFS checkouts without the repeat download

  • cache
  • performance

Large files tracked with Git LFS no longer need to cross the internet on every fresh runner. Turn on Git LFS Cache for an organization or repository and the first checkout fills a cache beside the runner; later checkouts of that repository reuse the local copy.

  • No workflow changes. Keep using actions/checkout with lfs: true or git lfs pull as usual. The cache applies to Git LFS running directly on an Avrea runner; traffic originating inside a container is not intercepted yet.
  • GitHub still authorizes every transfer. Avrea caches the object download, while GitHub continues to decide whether the job can access the repository.
  • Repository boundaries stay intact. Objects are cached per repository, count toward its existing cache quota, and follow the same retention and eviction rules as other cache entries.
  • Checkout keeps working if the cache cannot. A cache miss or service issue falls back to GitHub instead of blocking the job.

The Git LFS cache is off by default. Enable it in the console or with avr settings set cache.lfs.enabled true.

See the Git LFS cache docs →

See your work and your spend at a glance

  • console
  • billing

The dashboard used to show you everything happening in your organization and leave you to find yourself in it. It now opens with your work and your spend.

  • Your work, first. Runs you triggered are matched to your GitHub account and listed on their own, with a pull request view alongside them, so you can pick up where you left off without filtering an org-wide activity feed.
  • What you're actually spending. The organization header shows the period total in real money instead of an approximate billable-minutes figure, and makes it clear when you're still inside the free tier. Open the breakdown to see minutes and cost per runner type — the answer to "which machines are this bill?" without exporting anything.
  • Metrics worth reading. Average duration is weighted properly and shown as a trend, and success rate no longer skews when a metric has no data yet.

Loading is calmer too. Pages keep their content while refreshing instead of flashing back to placeholders, lists reserve the space they're about to fill, and cards no longer shuffle as data arrives — so nothing moves under your cursor while you're reading it.

Swift dependencies without the clone storm

  • cache
  • performance

SwiftPM's default way of fetching a dependency is a full git clone of its repository, history and all, repeated on every fresh CI runner. Avrea's macOS runners now resolve public Swift packages through a hosted package registry instead, enabled by default with Xcode 26 and newer: each version is served as a small checksummed archive from storage sitting next to your runners.

  • Faster resolution. A dependency downloads as one archive instead of a full repository clone, and repeat builds hit the cache.
  • Less exposure to GitHub. Once a version is cached, resolving it no longer touches GitHub at all.
  • Nothing else changes. Private packages and branch- or commit-pinned dependencies keep resolving via git exactly as before, in the same build.

Resolving through the registry changes how Package.resolved records its pins (registry identities and checksums instead of git URLs and commits), so the first resolve rewrites them. Repositories that need to keep git-form pins can opt out with the Swift Package Registry setting, per organization or repository.

While benchmarking the rollout we measured what the classic lockfile advice is worth here. Resolving vapor's 28-package graph on a fresh runner:

Setup Resolve time
git, no lockfile 23s
Registry, no lockfile 11s
Registry, committed lockfile + --force-resolved-versions 4s

So: commit Package.resolved, and resolve in CI with swift package resolve --force-resolved-versions (for Xcode projects, xcodebuild -disableAutomaticPackageResolution). Like npm ci, it uses exactly the committed pins and fails loudly on drift instead of silently re-resolving, and it skips the version exploration that dominates cold resolution. See the Swift registry docs →

Cache writes that keep up with parallel builds

  • cache
  • reliability
  • performance

Cache writes are now more reliable when busy workflows compile the same code in parallel or upload large artifacts. Jobs are less likely to report a cache write error just because another job reached the same result at the same time.

  • Parallel builds converge cleanly. When jobs produce the same cached artifact together, they reuse the completed write instead of treating the overlap as a failure.
  • Large uploads complete more consistently. Build-cache and package-cache uploads now use a more reliable path for larger objects.
  • Fewer missing results on the next run. Successful writes are checked before they become available for reuse.

The improvements apply automatically to existing cache integrations, including sccache. No workflow or tool configuration changes are needed.

Company sign-in, managed in one place

  • security
  • sso
  • enterprise

SAML single sign-on is now available with Avrea Enterprise. Your team can use the same company sign-in, MFA, and access policies they already use for other business applications, while administrators keep authentication under the control of their identity provider.

  • Connect your existing IdP. Import Avrea's service-provider metadata and map the email and name attributes your company already uses.
  • Bring members in automatically. A successful first sign-in can create the member with a least-privilege default role.
  • Require company SSO. After testing the connection, enforce SAML for verified company domains so direct OAuth sign-in no longer bypasses company policy.
  • Support both sign-in directions. Members can start at Avrea or, when enabled, launch Avrea from their IdP application tile. Single logout is supported when the IdP provides it.

Admins can test the complete SAML exchange before creating a session or turning on enforcement.

Set up SAML SSO →

Ubuntu 26.04 runners are here

  • runners
  • linux
  • ubuntu

Ubuntu 26.04 LTS is now available on Avrea runners, so you can build and test against the newest Linux toolchains while keeping existing workflows pinned to their current environment.

Opt in per job by choosing an Ubuntu 26.04 label:

jobs:
  build:
    runs-on: avrea-ubuntu-26.04-4-vcpu   # or avrea-ubuntu-26.04-arm-4-vcpu
  • Newer toolchains. Use newer compilers, language runtimes, and system libraries when your project is ready for them.
  • x86 and Arm. Both architectures are available across the standard Avrea runner sizes.
  • Explicit and predictable. Existing workflows do not move automatically, and avrea-ubuntu-latest continues to point to Ubuntu 24.04.
  • The same rates as Ubuntu 24.04. Moving to 26.04 does not add a version premium.

See the runner labels →

Send CI logs to your own observability stack

  • observability
  • integrations

You can now send Avrea runner logs directly to your own OpenTelemetry collector. CI activity can live alongside your application and infrastructure logs, using the dashboards, searches, retention, and alerts your team already has.

Configure an OTLP/HTTP endpoint under Settings → OTel export. Set it once for the organization, then override it for individual repositories that need a different destination.

  • Use your existing backend. Send logs to any compatible OTLP/HTTP endpoint.
  • Keep repositories flexible. Organization settings provide the default; repository settings take precedence where needed.
  • Connect authenticated collectors. Add an optional authorization header without exposing its value again in the console.

Avrea validates the destination when you save it, so configuration mistakes are caught before the export is enabled.

One stable IP for every workflow

  • networking
  • security
  • enterprise

Static IP egress gives your Avrea organization one stable public IPv4 address for outbound runner traffic. Add it to a database, API, payment provider, or corporate firewall once, instead of maintaining rules for addresses that change from run to run.

  • One address across the organization. The same IP covers runner VMs across your repositories, making allowlists easier to review and maintain.
  • No workflow changes. New jobs use the address automatically after an organization admin enables the feature.
  • Easy to copy and verify. The Static IP settings page shows allocation progress and the active address as soon as it is ready.

Static IP egress changes only outbound internet traffic. Your existing egress firewall rules, service credentials, and destination-side permissions continue to apply.

Set up static IP egress →

Smart monorepos, even faster CI

  • cache
  • performance

Nx is built to keep monorepo CI fast: it runs only the projects a change touches and reuses what it already computed for the rest. That reuse is only as quick as the cache behind it, so Avrea now hosts an Nx remote cache right next to your runners.

On Avrea runners there's nothing to wire up. Your tasks pick up the cache as-is:

- run: pnpm install --frozen-lockfile
- run: pnpm nx run-many -t build test lint

Because the cache is shared, a result computed once is reused everywhere: the next CI run, other branches, and teammates sitting on the same commit. The first run fills it; after that, the projects nobody changed are restored instead of rebuilt, so CI spends its time only on what's new.

Works with Nx 20.8 and newer. See the Nx caching docs →

Docker builds that reuse layers instead of rebuilding them

  • cache
  • docker
  • performance

Docker builds on Avrea runners can now pull their layers from a cache that lives right next to the runner, so unchanged steps come back in seconds instead of rebuilding from scratch.

Add url_v2=https://cache.avrea.com/ to your type=gha cache settings:

cache-from: type=gha,url_v2=https://cache.avrea.com/
cache-to: type=gha,url_v2=https://cache.avrea.com/,mode=max

On the first run, BuildKit builds and stores every layer. On the next run with unchanged inputs, each RUN step hits the cached layer and the build finishes in seconds — no more waiting on the slow upstream GitHub Actions cache.

Set up Docker build caching →

Your first cached build of the day starts faster

  • cache
  • performance

The first build to reach the cache used to pay a small cold-start cost while the index loaded. Now that index is pre-warmed across every scope ahead of time, so the first cached build of the day is as quick to start as the rest — no change needed on your end.

Invite teammates by email, and skip the setup they don't need

  • console
  • onboarding
  • notifications

Getting a teammate into Avrea no longer means sending them a link out of band and walking them through setup.

  • Invites arrive in their inbox. When an admin invites someone by email, they get an email notification with a direct link to join — no separate heads-up needed.
  • A shorter first run for invited members. If your org already has the GitHub App installed, invited members skip the install step and the onboarding wizard steps out of the way, so they land on a working console instead of a setup screen.

Runs that keep going when GitHub drops a webhook

  • reliability
  • runs

GitHub occasionally drops or delays the webhooks that tell us a job is ready. When that happened, a run could sit waiting. It no longer has to.

  • Stuck queues unstick themselves. When a webhook never arrives, Avrea reconciles queued jobs by polling the workflow run directly, so they start instead of hanging.
  • Dropped notifications get retried. Failed webhook deliveries are redelivered automatically, so a transient hiccup on either side no longer strands a run.
  • A job that can't start tells you, instead of waiting. If a job's container image can't be found, the run now stops and notifies you right away rather than sitting indefinitely.

Fewer runs that quietly go nowhere.

The fastest Apple Silicon yet, now running your builds

  • runners
  • performance
  • macos
  • arm

Apple M5 Max Macs are now part of the Avrea fleet — the fastest ARM CPUs available. If your build is CPU-bound, the wall-clock you've been waiting on just got shorter, with no changes to your workflow.

  • macOS builds, on the latest Apple Silicon. Xcode builds, test suites, and signing run on M5 Max hardware, so the heaviest macOS jobs finish sooner instead of holding up the rest of your pipeline.
  • Linux ARM, on the same fast cores. It isn't only for macOS. Your Linux ARM workloads run on this hardware too, so ARM container builds, cross-compiles, and ARM-native test runs get the same top-tier single-thread speed — without keeping a separate machine class around.

One fleet, the fastest ARM CPUs available, whichever OS your work needs.

More of your build cached out of the box — and SOC 2 Type 2

  • cache
  • runners
  • compliance
  • security

Two threads landed this week: the cache covers more of what your build actually downloads, and the platform underneath it picked up another attestation.

More of your build, cached out of the box. If your runner pulls it, we probably cache it now — with no workflow changes on your side.

  • .NET on Linux. Linux dotnet runners used to go straight to api.nuget.org. They now resolve through the Avrea NuGet cache, the way Windows already did — so cold restores stop being the slow part of the build.
  • Gradle, on every OS. repositories { mavenCentral() } was silently going direct, because Maven's mirror config doesn't govern Gradle's resolver. Gradle builds now flow through the Avrea cache via a surgical URL rewrite that leaves your other repositories — google(), gradlePluginPortal(), JitPack, corporate Maven, mavenLocal() — exactly as you wrote them.
  • Go build cache on Windows. Windows runners now get the same Go build cache as Linux and macOS, instead of a silent no-op. Repeat Go builds on Windows feel like Go builds anywhere else on Avrea.

SOC 2 Type 2, continuously verified. Avrea is now SOC 2 Type 2 attested, in addition to ISO 27001:2022 certified — both are listed on the security page. To keep the posture honest between audits, the hosts that run your builds are continuously scanned against the same hardening controls, with results streamed into our observability stack. So the attestation isn't a once-a-year snapshot; it's the steady state.

The console now talks back — and the log view keeps up

  • console
  • notifications
  • performance

The console now tells you about the things you used to find out by accident.

  • A notification center, in the product. A new bell in the top bar collects anything Avrea needs to surface to you — and the important ones (like running low on credits) appear as an acknowledge banner you have to dismiss, so you don't first hear about them from a failed run. Each notification has its own seen / acknowledged state per user, scoped to the right people in your org.
  • A log viewer that follows the work, not the other way around. Click any point on the job's metrics chart and the log scrolls straight to that moment — even if the line is inside a collapsed group or filtered out, you land near it instead of nowhere. Scroll back to the bottom of a live log and follow-tail re-engages on its own; an explicit Pause / Play control is back when you'd rather drive manually. Big logs render with noticeably less stutter.
  • A cleaner metrics chart. CPU, memory, and the other series toggles moved into a settings popover on the chart itself, so the chart area stays focused on the data. Line colours are retuned for the dark theme so the series stay readable when they overlap.

Small stuff — but the kind you notice every time you open a job.

Your console just got a lot faster — and shows more

  • console
  • performance
  • observability

The console feels noticeably snappier, and it finally answers the question you actually have: what did this job use?

Job lists and dashboards now load up to 22x faster, with workflow aggregations roughly 4x faster. If you have a repository with a long history of jobs, you'll stop waiting on spinners to see what's going on.

Every job and step now reports its average CPU and peak memory, and the workflow metrics chart adds step-level markers, multi-job tooltips, and an inline picker when several jobs overlap on a busy graph. Spotting the slow step — or the one that's about to run out of memory — is now a glance, not an investigation, which makes it easy to right-size the runner you pay for.

Fewer interruptions, more reliable runs

  • console
  • reliability
  • cache

A batch of changes whose whole point is that you notice them less.

  • Stay signed in while you work. Console sessions now extend on activity (up to 36 hours idle, with a 14-day cap) instead of logging you out mid-task.
  • A sidebar that fits your screen. The navigation auto-collapses on smaller screens, so the console stays usable on a laptop or a split window.
  • No more zombie runs. Cancelled GitHub runs no longer spin up doomed retry loops, and pending workflow webhooks no longer leave run status out of sync.
  • Caches you can trust. Package and GitHub Actions cache now verify end-to-end integrity with native checksums and compressed-frame checks, at near-zero overhead — including a fix for the Bundler / RubyGems checksum errors some Ruby projects were hitting.

Individually small; together, fewer surprises in your day.

Lock down runner network egress per repository

  • security
  • runners
  • compliance

You can now meet network compliance requirements without moving work off Avrea.

Define exactly what a repository's runners are allowed to reach — by CIDR, fully-qualified domain, protocol, and port. The policy is enforced on both the IP and DNS planes, so a workflow can only talk to the destinations you've explicitly allowed, and attempts to reach anything else are blocked rather than quietly succeeding.

For regulated and security-conscious teams, that means CI builds can run on Avrea while still satisfying the egress controls your auditors expect.

Move a workflow to Avrea runners in a few clicks

  • console
  • runners
  • onboarding

Trying Avrea on a real workflow no longer means hand-editing YAML.

From the console, pick an existing GitHub Actions workflow and convert it to run on Avrea runners. We generate a pull request for you to review and merge — so the change goes through your normal review process, and you can see exactly what's different before anything ships.

It turns "evaluate Avrea" from an afternoon of edits into a few clicks and a PR.

Drive Avrea from your terminal with the new avr CLI

  • cli
  • automation

Anything you do in the console, you can now do from your terminal — and from your own scripts.

The first public release of the avr CLI is here. It's designed to feel like GitHub's gh: structured --json output for piping into other tools, --watch modes so you can follow runs live, clickable hyperlinks, and pipe-friendly formatting that does the right thing whether you're at a prompt or in a pipeline.

That means you can wire Avrea into your existing automation without scraping the UI — kick off and monitor work, pull status into a dashboard, or gate a deploy on a result, all from the command line.