Changes

Review the specific changes introduced in this release that require your attention or action during the upgrade process.

Review each item carefully to ensure a smooth and successful transition.

2026.3.0

Monitoring Logs Are Now Stored in Object Storage

Develocity’s monitoring component (gradle-monitoring) uses Loki to collect and store the logs used for support diagnostics. In this release, Loki now stores these logs in Object Storage, alongside the monitoring metrics, instead of in a dedicated persistent volume attached to the monitoring Pod.

The logs use the same Object Storage backend already configured for the rest of Develocity (s3, googleCloudStorage, azureBlobStorage, or the Develocity-provided embedded Object Storage), under a dedicated prefix. Your existing Object Storage configuration is reused automatically, so there is nothing to reconfigure.

This removes the dedicated monitoring logs volume from the deployment. With both metrics and logs now stored in Object Storage, the monitoring component no longer requires a dedicated persistent volume. That simplifies operations, lowers storage cost, and lets the component run without local state.

If you use the Develocity-provided embedded Object Storage, the logs get their own quota inside it, set by objectStorage.embedded.storage.monitoring.logging.capacity (default 5Gi). The embedded Object Storage runs on a single persistent volume sized to the sum of its quotas, so that volume grows by 5 GiB, from 75 GiB to 80 GiB at the defaults. A StorageClass that allows volume expansion resizes it for you; otherwise, provision the extra capacity before you upgrade.

As before, you can store monitoring data in its own bucket or with separate credentials by adding a monitoring block under your Object Storage provider. This is not required, but it is recommended for cleaner data separation. For details, see the Kubernetes or Standalone Helm Chart Configuration Guide.

Logs collected before the upgrade are not migrated to Object Storage. After the upgrade, Loki no longer mounts the previous log volume, so logs collected before the upgrade are no longer accessible through Develocity. Only logs collected after the upgrade are stored in Object Storage.

Whether the data on the previous volume is retained depends on your storage configuration (for example, the volume’s storage class and reclaim policy), but Develocity provides no mechanism to remount or recover it. To keep the logs from before the upgrade, generate a support bundle beforehand, which captures the current server logs.

Analytics MCP Server Helm Configuration Moved

The MCP server’s Analytics Helm values are now configured under mcpServer.analytics. The previous location at athenaDataExport.mcpServer for configuring the Athena connection still works but is deprecated. It will be removed with Develocity 2027.1.

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: athena
    athena:
      credentials:
        type: keys
        keys:
          accessKey: <AWS access key for read-only Athena role>
          secretKey: <AWS secret key for read-only Athena role>

See the Installation Manual for the full Helm configuration.

Develocity MCP Server Now Provides Reporting Kit Analytics MCP Tools

This section applies to Develocity installations connected to a Develocity Reporting Kit.

This change requires updates to your Reporting Kit and your Develocity configuration. Analytics MCP tools will remain unavailable after upgrading Develocity and the Reporting Kit until you make the adjustments explained below.

Starting in Develocity 2026.3.0, the Reporting Kit’s Develocity Analytics MCP tools are served from the single Develocity MCP Server at the /mcp endpoint, alongside the Develocity MCP tools. End users no longer need to configure a separate endpoint for the Reporting Kit’s tools. To serve the analytics data from the Develocity MCP Server, it queries the Reporting Kit over its Trino query-access endpoint.

Querying the Reporting Kit from the Develocity cluster adds a new connectivity direction, Develocity → Reporting Kit. Until now, traffic ran only the other way, Reporting Kit → Develocity, for data synchronization.

Before upgrading, confirm that:

The Develocity cluster allows outbound connectivity to the Reporting Kit, and the network policy for the mcp-server Pod permits it.
The Reporting Kit exposes ingress to its Trino query-access endpoint. This feature is off by default and must be enabled on the Reporting Kit side.

Develocity MCP: Configure the Reporting Kit as Analytics Source

First, enable Trino query access in the Helm values of your Reporting Kit installation:

Enable ingress SSL and set an ingress hostname.
Configure Trino user account credentials.
Set trino.ingress.enabled to true to expose the Trino query endpoint.
Configure how the Reporting Kit authenticates the Develocity MCP Server under auth.develocityMcpServer. The Develocity-side example below uses static credentials, which the Reporting Kit reads from auth.develocityMcpServer.staticCredentials.secretName.

See Develocity MCP Server Access in the Reporting Kit documentation for the full configuration.

In the Helm values of your Develocity installation, select the Reporting Kit and set its base URL (the host that serves the Reporting Kit’s web UI):

values.yaml

mcpServer:
  enabled: true
  analytics:
    type: reportingKit
    reportingKit:
      url: https://reporting-kit.example.com
      credentials:
        secretName: develocity-mcp-query-access-credentials (1)

1	Use the same credentials that you configured on the Reporting Kit side.

See the Installation Manual for the full Helm configuration.

The Develocity MCP Server authenticates to the Reporting Kit’s Trino query-access endpoint using one of two modes. The examples above use static credentials. When Develocity and the Reporting Kit run in the same cluster, you can use Kubernetes service account tokens instead.

Same Kubernetes cluster

When Develocity and the Reporting Kit run in the same cluster, in separate namespaces, the Develocity MCP Server presents its Kubernetes service account token. The Reporting Kit validates that token against the cluster’s Kubernetes API. No secret is shared between the two deployments: they agree only on a trusted service account identity. This is the default mode, so configure the trusted service account on the Reporting Kit side and no credential is needed.

In this mode the Reporting Kit’s trino-cache app is granted the system:auth-delegator role so it can validate presented tokens.

Separate clusters

When Develocity and the Reporting Kit run in separate clusters, a service account token cannot be validated across the cluster boundary. The server then authenticates with a static username and password over HTTP Basic Authentication. You set the same credential independently on both sides: a Secret referenced by mcpServer.analytics.reportingKit.credentials on the Develocity side, and a matching Secret on the Reporting Kit side. Keep the two copies in sync.

For the Reporting Kit side of each mode, see Develocity MCP Server Access in the Reporting Kit installation manual.

Migrating AI Agents

The embedded Analytics MCP endpoint served by the Reporting Kit (/drv-mcp on the Reporting Kit instance) is deprecated in this release and will be removed in Reporting Kit 2.6.0. During this release it forwards requests to the consolidated Develocity MCP Server, so existing client configurations keep working.

Users who already have the main Develocity MCP Server configured can remove the extra MCP connection pointing to <reporting-kit-url>/drv-mcp. Users who were only using the Reporting Kit’s MCP server so far should change the configured URL to <develocity-url>/mcp.

See AI Agents for client configuration.

Opt In to Running Develocity Without the Bundled Proxy

This applies only to Kubernetes cluster installations.

Develocity has historically routed all external traffic through a bundled reverse proxy component (gradle-proxy). Starting in this release, you can opt out of that proxy and route external traffic to Develocity yourself, using whatever routing infrastructure you already operate. That can be an Ingress, a Gateway API implementation, or your own custom routes.

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 a future release, and the proxy will be removed after that. Opting in now lets you confirm the setup works for your environment before the default changes, rather than being migrated automatically later.

To opt in, set routedBy: ingress:

enterprise:
  routedBy: ingress
authenticationBroker:
  routedBy: ingress

The authentication broker already defaults to ingress, so in practice only the Develocity application changes. The broker setting is shown here so both routing settings sit together.

Leaving this unset keeps the current behavior, so upgrading without changing it requires no action. While the proxy is still in use, the chart emits a deprecation warning during rendering.

Benefits

One fewer component to deploy, scale, secure, and monitor, which lowers resource usage and simplifies the deployment topology.
Traffic reaches the application directly through the routing you already operate, so routing and access policies stay in one place, under your control.
One fewer network hop between clients and the application, which improves performance.

What Changes

Opting out of the proxy is transparent from a routing perspective. The proxy only forwarded traffic, so the paths Develocity exposes and their destinations are unchanged. If you manage your own routing, you can extract the exact set of routes for your chart version: see Extracting Ingress Rules.

The proxy serves the starting and restarting pages shown to users while the application is unavailable. When you opt out, the proxy no longer serves those pages, so providing a loading screen becomes an operator responsibility rather than an application one. If you want to keep that experience, use your own routing implementation, or any other custom object, to serve a loading screen tailored to your environment.

Test It Before the Default Changes

Because this is opt-in, you can confirm it works for you before it becomes the default:

Set enterprise.routedBy: ingress and upgrade.
From a machine that connects to Develocity, check that your routing reaches the application:
```
curl -sw \\n --fail-with-body --show-error https://«develocity-host»/ping
```
The command returns {"status":"UP"}.
Open Develocity in a web browser and sign in.

If Develocity doesn’t work as expected, set enterprise.routedBy: proxy and upgrade again to route traffic back through gradle-proxy. When that resolves the problem, direct routing is the cause. Report it through Develocity support, including your routing configuration, so it can be addressed before the default changes.

Standalone Installations No Longer Use the Bundled Proxy

This applies only to standalone installations.

Standalone installations no longer deploy the bundled reverse proxy component. External traffic reaches Develocity directly.

No action is required: the change is transparent for instance operators.

Automatic Resource Management Finds the Optimal Memory Distribution

This applies only to standalone installations.

Develocity now sets memory limits based on available host memory and your current configuration. It prioritizes memory allocation for components with higher demands, and enabling or disabling a component reallocates memory across the rest. Until now, its largest components set no memory limit and competed for whatever memory the host had, while a few smaller ones carried a fixed figure from the chart.

What Keeps Working

A host that meets the CPU & Memory requirements and runs the components Develocity enables by default upgrades with no configuration:

Develocity creates the Namespace the feature needs, and sizes every component for you.
A memory limit you set yourself in values.yaml is kept, and Develocity distributes the remaining memory around it.

What You Need to Do

Before you upgrade:

Confirm the host has enough memory for the components you run. If the host is too small, helm upgrade reports the exact shortfall and applies nothing, leaving the running installation untouched. See Troubleshooting Automatic Resource Management.
Copy your image pull secret into the Namespace the feature runs in, if you set global.image.imagePullSecret. Develocity cannot copy it for you, and the render stops without it. See Preparing the Webhook Namespace.
Raise the headroom if the host also runs workloads that are not part of Develocity. Raise it by the memory those workloads request, not by what they consume at peak. See Reserving Memory for Jobs and Other Workloads.
Review any memory figures you set in values.yaml. Previous versions of the chart allowed to modify the resource management settings for containers in the monitoring component. If you modified them, please see Pinning a Component’s Memory Limit, and if you want to keep them.
Review heap memory you have tuned by hand. The Develocity application and the Test Distribution broker now size their heap from their container limit rather than from the Develocity configuration, and Administration/Advanced shows the result as read-only. Develocity keeps the heap values you set, and they apply again if you disable automatic resource management. See Former Application Heap Memory.
Ensure permissions are sufficient you have restricted. The Helm chart now automatically creates a few resources outside the release namespace. See Cluster Permissions.

After upgrading, components that previously had no memory limits now have container limits applied. If a component exceeds its limit, K3s restarts it. A background component can restart without anyone noticing, and a component running under a tight limit spends more time collecting garbage, which shows up as Develocity being slower rather than as anything failing. If Develocity seems slower or less reliable after upgrading, send a support bundle to Develocity support. Disabling the feature restores the pre-upgrade behavior while you size the host. See Troubleshooting Automatic Resource Management and Disabling Automatic Resource Management.

Permission Configuration Values Now Match the UI

Develocity 2026.3.0 renames twelve permission values to match the permission names shown in the UI. These values name permissions in two places: unattended configuration files, and requests to the /api/auth/token endpoint that create access tokens. Previously, granting a permission through either one meant knowing a different name than the one the Administration console displays.

Renamed Permission Configuration Values
Previous Value	New Value
`administerEdges`	`configureEdgeNodes`
`administerCache`	`configureBuildCaching`
`administerTestDistribution`	`configureTestDistribution`
`administerProjects`	`configureProjects`
`administerAccessControl`	`configureAccessControl`
`administerOperationalSettings`	`configureOperationalSettings`
`readCache`	`readBuildCacheData`
`writeCache`	`readAndWriteBuildCacheData`
`readCacheWriteCas`	`readBuildCacheDataAndWriteBazelCasData`
`exportData`	`accessBuildDataViaApi`
`useMcp`	`accessBuildDataViaApiAndMcp`
`readAllBuildData`	`readAccessAllBuildDataWithOrWithoutAssociatedProject`

The remaining permission values are unchanged. For the full set of permissions and their configuration values, see Permissions and Roles.

What Keeps Working

Develocity still accepts the previous values, at every schema version, so no action is required to complete the upgrade:

Existing unattended configuration files apply unchanged.
Requests to the /api/auth/token endpoint that name permissions in a query parameter still succeed with the previous values, so CI integrations that create access tokens keep working.

Develocity never writes the previous values. Any configuration file it exports uses the new ones, so an exported file differs from the file you applied even when nothing else changed.

What You Need to Do

The previous values are deprecated and will be removed in the next major release. Update your unattended configuration files and any scripts that request access token permissions to the new values after you have upgraded to Develocity 2026.3.0.

Adopting the new values requires schema version 17. A configuration file that declares an earlier schema version must keep the previous values, because Develocity validates each file against the schema its version property names.

Moving a file to schema version 17 replaces the previous permission values with the new ones for you. Use either of the following:

Upgrade the file with develocityctl 1.24.0 or later:

develocityctl config-file upgrade unattended-config.yaml --overwrite

If your unattended configuration is embedded in values.yaml, upgrade only that subtree:

develocityctl config-file upgrade values.yaml --nested global.unattended.configuration -o upgraded-values.yaml

See config-file upgrade for the full set of options.

Export your configuration from the UI, which upgrades it to the latest schema version your instance supports, then apply the exported file. See The Export Workflow.

Very Large Builds Now Occupy More Than One Row in Athena

This section applies to Develocity installations that use Develocity Reporting via Athena Data Export.

Amazon Athena limits the size of a single row, and of any of its columns, to 32 MB. AWS documents this hard limit under Considerations and limitations for SQL queries in Amazon Athena. Before 2026.3.0, Develocity dropped a build whose model reached this limit, so the build never reached Athena. Starting in Develocity 2026.3.0, a build that reaches the limit is stored as more than one row of the build and internal_build tables. The drv_shard column numbers the rows of one build.

What Keeps Working

The summary views apply the shard rules for you. A query against build_summary or another summary view needs no change. The provided Grafana dashboards read the summary views, so they need no change either.

What You Need to Do

Update every query of your own that reads the raw build or internal_build table:

When the query counts builds, or reads a scalar or whole-build column, add AND COALESCE(drv_shard, 0) = 0. Without this condition, a very large build is counted once for each of its sharded rows.
When the query reads a sliced array, for example with CROSS JOIN UNNEST, do not filter on drv_shard. All rows of the build together hold the complete array.

For details, see Querying Very Large Builds.