We're excited to announce Develocity 2026.3, which offers powerful new features and enhancements designed to increase the efficiency of your build and test processes!

Key highlights include:

• Organization-Wide Build Optimization with Develocity Agents: Recover the CI hours your organization loses every week to avoidable cache misses, flaky-test reruns, and recurring failures. Develocity Agents rank the biggest sources of waste across every project, send your AI agents to fix them where it pays, and show you the recoverable CI time.
• Observability for Docker Builds: See how long your Docker builds take, which steps hit the cache, and the reasons why they fail, with the same Build Scan®, AI agent, and dashboard experience you already use for your other build tools.
• Enhanced Universal Cache Security with Trusted Artifact Isolation: Protect downstream consumers and customer-facing releases from cache poisoning by isolating trusted pipelines, while preserving the acceleration benefits of remote caching.

Develocity Agents keep your builds fast and green across the whole organization. They quantify the CI hours your organization loses each week to avoidable cache misses, flaky-test reruns, recurring failures, and show how many of those hours a fix recovers. This release adds the Build Caching Report skill, the Failure and Flaky Test Report skills, and the Failure Handler (Beta) skill. See the Develocity Agents documentation.

Recover the CI hours your organization spends rebuilding what the cache already had. See which projects waste the most, then send an agent to fix what has the biggest impact, and watch the recoverable hours turn into a lower CI bill. That way the agent's time and tokens go where they pay back most.

With the new Build Caching Report you can now identify in which projects you should address build cache misses first: it surveys your Develocity instance and ranks the top savings opportunities — the avoidable build cache misses that waste the most CI time. It works entirely on your existing Develocity data, no extra setup required.

Hand these ranked opportunities to your AI agent, which passes them to the Build Caching Optimizer skill, to diagnose and fix them. See the Develocity Build Caching Report documentation.

Get builds back to green faster, and stop paying for the same failure hundreds of times. The Failure Report ranks recurring build and test failures across your organization by the number of builds affected, so a targeted fix unblocks the most engineers and coding agents at once.

This report works on your existing Develocity data, across every project and build. It applies smart prioritization: failures on main pipelines rank above those confined to a single feature branch or one developer's machine, so the ranking reflects the impact on your entire organization. Failures that have gone quiet rank lower, so you never chase a transient issue that has already stopped.

Hand any failure to your AI agent, which can now pass it to the new Develocity Failure Handler skill. The Failure Handler diagnoses and triages the failure before it either fixes the code or routes operational failures to the owning team. See the Develocity Failure Report documentation.

Let your agents see which flaky tests burn the most CI time, so they fix those first. Because flaky tests pass on retry and the build goes green anyway, they never show up in a build failure ranking. Yet every retry still burns CI time.

The Develocity Failure Report ranks flaky tests in a separate list from build failures, ordered by the CI time each test class wastes. Tests rank lower when they have recently stopped flaking, so you never chase one that has already stabilized. Hand any flaky test to your AI agent, which passes it to the Develocity Failure Handler skill to diagnose why it flakes and find a fix. See the Develocity Failure Report documentation.

With the new Develocity Failure Handler, your AI agents can now fix issues that a single working tree can't explain — broken dependencies, CI environment drift, or operating-system-specific failures.

The Failure Handler assesses each issue against every build in your organization, local and CI, before it acts. It diagnoses an issue against Develocity's cross-build history and determines whether the problem is flaky or reproducible, pre-existing or caused by your change. It researches the root cause and how widely it occurs, establishes a reproduction recipe, and decides whether a code change can fix it. Then it acts: a pull request with the fix, an issue for the owning team, or a record of what it found so that nobody diagnoses it twice. Systemic failures either get fixed or reach the accountable team once, instead of disturbing your central CI team hundreds of times.

See the Develocity Failure Handler documentation and the skills getting-started guide.

You now get the same observability for Docker builds that you already rely on for your other tools. Every invocation of docker build produces a Build Scan, so you can see how long a build took, which steps hit the cache, and — when it fails — why. The same data flows into Develocity Analytics and your AI agent, so nothing changes in how you work. See the Develocity for Docker documentation for getting started.

Open a Docker Build Scan and you get the same drill-down you already rely on for any other tool: a summary you can read in seconds, and a full trace of every step underneath it when you need to go deeper.

Visualize and understand your most impactful failures. Build Scan allows you to see failures the moment they happen, and share them with the person who can act on them: failures are grouped against your build history, so you know immediately whether it's something new or a recurring issue. Or zoom out to the Failures dashboard for the big picture across every Docker build on your instance.

Identify and diagnose performance bottlenecks. The Timeline shows every build step in execution order with the critical path highlighted — the steps actually defining your build time — plus a filter to highlight the cached ones, so you can see at a glance what is cheap and what is expensive in a rebuild. The Performance and Trends dashboards aggregate that same data over time, so a systemic Docker slowdown or caching issue is easy to spot.

Docker builds are now included in your organization-wide picture. With the same cross-project views you use for every other build tool, you can spot any spike in Docker build time or failure rates — no separate tooling, no separate query. Two entirely new dashboards focus specifically on Docker builds.

The Docker Build Caching dashboard shows how effectively Docker builds across your entire estate reuse the BuildKit cache — total Build Cache hits, average hit rate, and a breakdown per project, per requested build, and per step, so you know exactly where a caching investment pays off. Synthetic BuildKit steps (like loading the build context or exporting the image) are excluded from the hit rate, since they can't be cached and would only drag the number down.

The Docker Build Parallelism dashboard surfaces how well your Dockerfiles allow for the parallel execution of their steps. The serial execution factor — effectively the average number of instructions in flight — tells you how many Dockerfile instructions ran in parallel, on average, during a build. It is the sum of all instruction durations divided by their wall-clock time, shown as median and P90 per project and per step. Higher is better. A wide gap between median and P90 means some of your builds already parallelize well, while others still have room to improve.

Your AI agent can now reason over Docker build data the same way it already does for your other build tools — no separate tooling, just a question. This capability is part of the existing Develocity MCP Server. See its documentation for setting it up.

Your agent can now leverage Docker observability data from Develocity to reason and act in three different areas:

1. Identify the most common failures: Docker build failures are clustered and surfaced with the failing command and its exit code, enabling your agent to tell whether a failure is new, recurring, or already known — and explore the best solution.
2. Spot performance bottlenecks and potential caching improvements: ask your agent which Docker builds are slowest and why. Your agent is now equipped to trace a slow build back to the specific uncached layer costing the most time.
3. Gain insights into your dependencies: ask which base images are in use across your Docker builds. Your agent starts from Develocity's build dependency data and can cross-check it with other relevant context such as vulnerability databases.

Develocity now protects your release pipelines from cache poisoning without sacrificing the performance benefits of Universal Cache. By isolating cache entries produced by trusted builds from those of untrusted builds, Trusted Artifact Isolation ensures your production workloads remain secure and fast.

You can now designate specific workloads, typically your release and main-branch pipelines, as trusted. These trusted builds read from and write to an isolated namespace, meaning they will never contain content produced by untrusted builds, such as a pull request built from a feature branch. Meanwhile, untrusted builds read from both the trusted and untrusted namespaces. This protection spans across the Universal Cache: Setup Cache, Artifact Cache and Build Cache.

Trust is bound directly to the pipeline rather than relying on shared secrets. For CI environments authenticating via GitHub Actions or other OIDC providers, you map the provider's identity directly to the trusted cache role. Because there is no static access key, an untrusted job cannot impersonate a trusted build, maintaining isolation even in the event of a credential leak.

Artifact Cache now covers Python packages installed via pip, so your dependency-heavy Python projects set up faster and depend less on external networks.

Python pip fetches package metadata, resolves package constraints, and downloads pre-packaged wheels from the Python Package Index or builds them from the resolved source distributions. In a dependency-heavy project, these steps can dominate your pip install runs.

Artifact Cache now stores and serves both the package metadata and the resolved wheels, making CI executions faster and more reliable. Artifact Cache has been observed to cut Python virtual environment setup time by up to 40% compared to a cold cache run.

See the Artifact Cache CLI compatibility matrix for supported version combinations.

Artifact Cache expands its coverage to frontend automation frameworks and adds support for caching Playwright browser bundles and Cypress application bundles, making end-to-end test jobs start faster and more reliably by reducing their reliance on external networks.

On a cold start, frontend automation frameworks normally download hundreds of megabytes of external runtimes, such as Playwright's pinned browser revisions or Cypress's standalone test runner binaries. Every fresh CI runner pays the penalty for these downloads, making them one of the largest inputs for a typical test job. Artifact Cache now stores and serves these inputs. For Playwright, this acceleration applies regardless of whether your tests use JavaScript, Python, Java, or .NET bindings.

Artifact Cache is compatible with Playwright 1.9 or later and Cypress 3.0 or later.

See the Artifact Cache CLI compatibility matrix for supported version combinations.

Develocity now precisely identifies which dependencies were served by Artifact Cache, providing greater visibility into your dependency origins and enabling more granular calculations of download volume savings. You can now easily trace whether a dependency was served directly by a remote binary repository or served by Artifact Cache.

For a Gradle and Maven Build Scan, the Dependencies section now surfaces the location and the specific URL of the Edge that served the dependency when Artifact Cache is used. Meanwhile, the Repository section continues to correctly attribute the original repository that published the artifact, ensuring you always have the complete picture of your dependency supply chain.

This enhanced visibility extends fully to Develocity Reporting and Visualization. The Dependency Caching dashboard introduces a new Cache filter, allowing you to precisely quantify the volume of dependency artifacts served by Artifact Cache across your organization. Additionally, in the JVM Dependencies dashboard, you can filter by specific dependency coordinates and use the new Details per Origin table to understand exactly which components served the artifacts for matching builds.

For deeper investigations and custom workflows, this origin data is also fully queryable through the Develocity API and the Develocity MCP Servers.

First-class integrations for GitHub Actions and Jenkins are now available, substantially simplifying the configuration of Artifact Cache and Setup Cache with a single workflow step declaration.

Each CI run automatically generates a concise report directly in the GitHub job summary or Jenkins build page detailing the outcome and caching overhead.

To set up the integration in your environment, please refer to the Artifact Cache and Setup Cache Configuring GitHub Actions and Configuring Jenkins user guides.

Artifact Cache and Setup Cache content now replicates across all Develocity Edge locations, extending the replication capabilities previously available only for Build Cache. A dependency downloaded or build configuration computed and cached at one Edge location is made available to other Edge locations.

Replication operates on demand to optimize network transfer and local storage. An Edge node copies an artifact the first time a local build requests it, eliminating redundant downloads over the WAN and subsequent regional cold starts. Replication is enabled by default for all Universal Cache content.

CI jobs can now authenticate directly with Develocity using short-lived OpenID Connect (OIDC) tokens issued by your CI system. Eliminating persistent access keys simplifies credential management across pipelines while safeguarding your environment against stolen secrets.

Administrators can configure granular permissions per pipeline by matching specific workload identity token claims. This ensures jobs receive only the exact authorization needed. For instance, Administrators can restrict CI jobs to a target project when using Project-Level Access Control.

Most major continuous integration platforms, including GitHub Actions, GitLab, TeamCity, and Jenkins, offer support for Workload Identity.

See Workload Identity for more information.

AI agents can now authenticate with the Develocity MCP Server using standards-based OAuth 2.0 rather than static access keys. This simplifies setting up agent integrations by removing the need to provision long-lived credentials, while protecting your environment from accidental secret exposure.

See the Develocity MCP Server Authentication documentation to learn how to configure OAuth.

When a single task type dominates a comparison, exclude it to focus on everything else. Type a negative prefix, such as not:KotlinCompile, in the task input filter to hide those entries and immediately surface the input differences that drive your cache misses.

Task durations appear directly in the Build Scan comparison, so you can see what each difference costs.

To provide immediate clarity, unnamed properties are now labeled as "unnamed" following the $1. They also include a tooltip with a link to documentation explaining how to name your properties. Additionally, you can filter for unnamed properties to determine how many exist in this category.

Enabled states in the Switches section now feature a distinct green status icon alongside text labels. Row highlighting on hover across all Build Scan tables improves clarity and scanning accuracy at a glance.

The Performance → Network Activity page adds a selector to break its charts down per repository. Compare one repository against another or against the combined total, rather than only seeing everything aggregated.

On a cache hit in a Gradle build, the Dependencies and Build Dependencies sections tell you the dependencies came from the cache and link straight to the matching view in the origin Build Scan. When the origin scan is deleted, expired, or outside your permissions, the message stays, but the link is omitted.

Pick Hour, Day, Week, or Month on the Failures dashboard. Hourly resolution shows whether a mitigation reduced the failure count on the same day it landed, while Week or Month emphasizes longer ranges that are too noisy day-to-day.

Develocity can now store Build Cache artifacts in a dedicated object storage bucket separate from Build Scan data. Since backup tools like AWS Backup target entire buckets, a separate bucket lets you exclude disposable cache artifacts from backups — lowering storage costs, speeding up restores, and enabling the use of custom storage classes as well as precise cost attribution. Existing single-bucket setups remain supported.

Ensure the following versions are installed to have the best experience and full compatibility with the latest features:

• Develocity Gradle plugin: 4.6.0
• Develocity Maven extension: 2.6.0
• Develocity sbt plugin: 1.4.5
• Develocity npm agent: 4.1.1
• Develocity npm agent loader: 1.0.0
• Develocity Python agent (beta): 0.10.0
• Develocity Docker agent: 0.9.0
• Develocity Edge: 2.3.0
• Develocity Test Distribution agent: 3.8.0
• Develocityctl: 1.24.0
• Develocity Reporting Kit: 2.4.0
• Develocity Reporting Dashboards bundle: 2.4.0
• Develocity IntelliJ plugin: 1.3.1
• Develocity Provenance Governor: 1.9.0
• Develocity Artifact Cache CLI: 1.7.0

Ensure you are using the latest version of the Develocity plugin for your CI provider:

• Gradle Jenkins plugin
• Develocity TeamCity plugin
• Develocity Bamboo plugin
• Develocity GitLab templates
• Develocity GitHub Actions

Under the Supported Develocity Versions policy, all Develocity releases older than 18 months are not supported. We encourage all users to upgrade to a supported version to receive feature improvements, maintenance updates, and security fixes.

Support for the Develocity Build Cache Node component will end on December 31, 2026. Consequently, versions of Develocity starting with 2027.1 will no longer include or support this component.

Action Recommended: Begin migrating the deployments from the Develocity Build Cache Node to Develocity Edge. Develocity Edge offers the identical remote build caching service, but is designed for enhanced resiliency, scalability, and easier operation. Develocity Edge also serves as the infrastructure foundation of the Develocity Universal Cache platform, enabling you to benefit from a unified caching experience during the entire build life cycle across your entire software supply chain.

The Develocity Edge User Manual contains everything needed to configure and operate Develocity Edge.

Develocity supports storing data in a user-managed PostgreSQL database. We will remove support for PostgreSQL 14, which is reaching its end-of-life in November 2026, in Develocity 2026.4.

Action Recommended: Upgrade to a more recent, supported version of PostgreSQL (15, 16, 17, or 18).

When using the Reporting Kit, the Develocity Analytics MCP tools used to be served directly by the Reporting Kit at <reporting-kit-url>/drv-mcp. With 2026.3, the Develocity MCP server provides all MCP tools consistently via the single MCP endpoint at <develocity-url>/mcp. Versions of Develocity starting with 2027.1 will no longer provide the <reporting-kit-url>/drv-mcp endpoint.

Action Recommended: Users should update their AI agent's MCP configuration from the <reporting-kit-url>/drv-mcp to the <develocity-url>/mcp endpoint.

Action Required: Administrators of Reporting Kit installations must follow the instructions in the Upgrade Guide to ensure the uninterrupted availability of Develocity Analytics MCP tools.

The gradle-proxy component is being phased out. Proxy-based routing is deprecated as of 2026.3, direct routing is planned to become the default in 2026.4, and the proxy component will be removed in 2027.1. Opting in now lets you confirm that the setup works in your environment before the component is removed.

Standalone installations run without proxy since 2026.3; the action applies only to cluster-based installations.

Action Recommended: Follow the instructions in the Upgrade Guide and try it now.