Skip to content
| Docs

Changelog

The latest improvements to Avrea. Subscribe via RSS.

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.