Changes

This applies only to Kubernetes cluster installations.

Develocity routes all external traffic through a bundled reverse proxy component (gradle-proxy). Starting in this release, you can try routing external traffic to Develocity yourself instead, using whatever routing infrastructure you already operate, for example an Ingress, a Gateway API implementation, or your own custom routes.

This option is provided for testing, so you can evaluate running without the proxy in your own environment. The gradle-proxy component is expected to be deprecated in a future release; trying this now lets you confirm the setup works for you ahead of that change.

To try it, set routedBy: ingress:

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

Leaving this unset keeps the current behavior, so upgrading without changing it requires no action.

Develocity 2026.2.2 introduces the global.workload.labels and global.workload.annotations Helm values, which apply custom labels and annotations to every Develocity workload and its pods. Use them for cost allocation, ownership tracking, and other organization-wide Kubernetes tooling, such as attributing cost from pod labels with Kubecost or OpenCost.

This is an optional, additive feature. No action is required unless you want to apply custom labels or annotations.

See the Kubernetes and standalone chart references for details, including reserved keys and precedence.

The embedded database connection limit is now derived from each component’s own replica count, instead of applying the Develocity app’s replica count to the combined connection pool. This prevents connection exhaustion when components such as the Develocity app and Keycloak are scaled to different replica counts.

No action is required for the embedded database: Develocity sizes the connection limit automatically. If you use a user-managed database, make sure it provides enough connections for your combined per-component replica counts.

Develocity 2026.2.1 introduces a new static-web-server container image that serves the static pages shown to users while Develocity is starting or restarting.

In standalone installations, Develocity deploys and activates this component automatically. No action is required.

In Kubernetes cluster installations, the static-web-server component isn’t deployed.

In standalone installations, the co-located Edge node now runs within its configured memory limit, matching Kubernetes cluster installations.

Before this release, standalone installations set no memory limit on the co-located Edge node, so it sized its JVM heap from the host’s total RAM instead of the intended 4 GiB default. The Edge node could claim a disproportionate share of the host’s RAM. The effect was most noticeable on hosts with a large amount of memory, where the Edge node could consume most or all of the available RAM.

Starting in 2026.2.1, the standalone chart applies the edgeNode.resources CPU and memory requests and limits. The co-located Edge node now defaults to a 4 GiB memory limit and sizes its heap from that limit.

In standalone installations, the co-located Edge node’s local cache is now bounded by edgeNode.storage.data.capacity, matching Kubernetes cluster installations.

Before this release, edgeNode.storage.data.capacity had no effect in standalone, so the Edge node’s cache could grow unchecked on the host filesystem and fill the disk, starving other co-located components such as the database and object storage.

Starting in 2026.2.1, the standalone chart bounds the cache to edgeNode.storage.data.capacity, which defaults to 50Gi.

The Develocity MCP Server ships disabled by default. When you enable it in a standalone installation, it now runs within its configured memory limit, matching Kubernetes cluster installations.

Before this release, standalone installations set no memory limit on the MCP Server, so when enabled it sized its JVM heap from the host’s total RAM instead of the intended 2 GiB default.

Starting in 2026.2.1, the standalone chart applies the mcpServer.resources CPU and memory requests and limits, which default to 1 CPU unit and 2 GiB of memory.

The "Delete Build Scan" (deleteScan) permission now respects project-level access control. Previously, a user with the "Delete Build Scan" permission could delete any Build Scan in Develocity, regardless of the Build Scan’s associated project. Starting in Develocity 2026.2.0, the permission only allows deleting Build Scans the user has project-level access to. This aligns the permission with the rest of the "Build data" permission group, which is already project-aware.

Additionally, the "Delete Build Scan" permission is no longer included in the default admin role.

Review custom roles that grant "Delete Build Scan" to confirm they align with your project access-control policies. To add or remove the permission on an existing role, navigate to Administration  Access control  Roles.

Access to both the Develocity MCP Server and the Develocity Analytics MCP Server is now gated by a new permission, "Access build data via the API and MCP" (useMcp). Previously, both servers were gated by "Access build data via the API" (exportData).

Both MCP servers now validate the access key and its permissions at the start of every request, including when listing the available tools. Previously, the Develocity MCP Server allowed listing tools and calling some tools without a valid access key.

Accessing the Develocity Analytics MCP Server still requires read access to build data across all projects, unchanged from previous releases. What’s new is an additional way to grant that access, described in Read access to all build data permission.

For a full description of the new permissions and their placement in the role editor, see Permissions and Roles.

A new permission, "Read access to all build data with or without an associated project" (readAllBuildData), grants read-only access to build data across all projects, including data that isn’t associated with a project. Unlike "Access all data with or without an associated project", it never elevates write permissions such as "Publish Build Scan" or "Read and write Build Cache data" across all projects. This makes it possible to give a user cross-project read access without also granting cross-project write access.

The Develocity Analytics MCP Server requires read access to build data across all projects, because Develocity Analytics data isn’t subject to project-level access control. This cross-project access is granted by either "Read access to all build data with or without an associated project" or the existing "Access all data with or without an associated project" permission.

This section applies to Develocity installations that use Develocity Reporting via Athena Data Export. The Develocity Reporting Kit is unaffected. See the note at the end of this section.

The Develocity MCP Server and Develocity Analytics MCP Server now share a single endpoint, /mcp, on the Develocity instance. The Analytics tools, previously available separately at /drv-mcp, are now also exposed from /mcp alongside the Develocity MCP tools. Visibility of the Analytics tools continues to be governed by the requesting user’s permissions, so a user without the cross-project read permission described in Read access to all build data permission doesn’t see them.

The legacy /drv-mcp URL on the Develocity instance is deprecated and will be removed in a future release. Existing clients configured against /drv-mcp keep working without any change at upgrade time. Migrate client configurations to /mcp before /drv-mcp is removed.

The Reporting Kit’s Analytics MCP endpoint is unchanged and continues to be served at /drv-mcp on the Reporting Kit instance.

The network.additionalTrust field in unattended configuration is deprecated and should be migrated to the top-level global.additionalTrust section in the Helm values. The global.additionalTrust section is available in both the cluster and standalone charts and lifts the setting out of the unattended-configuration nest, so it no longer requires the surrounding version and systemPassword scaffolding.

The legacy network.additionalTrust method continues to work for existing deployments, so no immediate action is required, but it’s deprecated as of 2026.2 and may be removed in a future Develocity release.

See Trusted and Additional TLS Certificates for standalone deployments or the cluster equivalent for the full reference.

To migrate, move the contents of global.unattended.configuration.network.additionalTrust, or network.additionalTrust from a separate unattended configuration file, to global.additionalTrust.certificates in your values.yaml:

Or, create a separate ConfigMap with the content from global.unattended.configuration.network.additionalTrust under the tls.crt key:

Then reference the ConfigMap from values.yaml:

You can now store Build Cache data in a dedicated object storage bucket, separate from your Build Scans and other application data, by adding an optional cache block under your object storage provider (s3, googleCloudStorage, azureBlobStorage). Build Scans and all other application data continue to use the parent objectStorage.<provider> configuration.

A dedicated bucket lets you apply different policies to Build Cache data than to your other data, such as a different retention policy, storage class, access controls, or backup and replication strategy, for operational cost, security, or other policy reasons.

This change is optional and backward compatible: existing single-bucket configurations are unaffected, and no action is required to upgrade.

This release deploys a co-located Edge node to provide a local cache layer, without separately provisioning Edge infrastructure. It runs as a new edge-node Pod, and registration with Develocity is handled automatically by the Helm chart.

Before upgrading, verify your cluster has spare capacity for the new Edge node Deployment. The cluster Resource Requirements already account for the co-located Edge node in the total resource requests and limits.

By default, each replica requests the following:

These values are a baseline minimum, not a universal recommendation. Many deployments need more, depending on your Build Cache load and size.

Because the co-located Edge node takes over the traffic your built-in Build Cache node serves today, size it against that built-in node’s volume, not against any other Edge node in your network. Review the Build Cache usage at /admin/edges/overview for the "Built-in" entry, then scale each resource against it:

If you have not deployed Develocity yet and do not have usage data, use these traffic-based tiers as a starting point instead. After deployment, confirm your tier from the co-located node’s "Data Served" over the past 24 hours, found in Administration  Edges:

In the same view, Storage Size is the node’s local cache capacity. The Incoming Data Storage Rate chart on the Build Cache administration page’s Usage tab shows how fast new entries are written, a useful cache-health signal but not a tier selector.

To scale or resize the co-located Edge node, see the Edge Node configuration for cluster installations or the standalone equivalent.

Since the Edge node now handles cache traffic the Develocity application previously served, you can reduce the enterprise-application Pod’s resources to offset the Edge node’s needs. If you’re unsure or need assistance in finding the correct sizing, please contact Develocity support.

No data is lost during upgrades or updates: the durable copy of cached data remains in the object storage connected to Develocity, and the Edge node repopulates its local cache afterward. In cluster installations the cache is a dedicated volume; in standalone installations it’s stored under global.storage.directory (/opt/gradle by default) and counts toward that volume’s capacity.

Because the co-located Edge node is now enabled by default, the Helm chart also adds routes for it to the Ingress. If you use the Develocity-supplied Ingress (ingress.enabled: true), no action is required: these routes are configured automatically.

If you route Develocity’s paths through your own Ingress or gateway instead of the supplied Ingress, add the following routes to the edge-node service on its http port (8080):

Also add the following gRPC Remote Execution API routes to the edge-node service on its grpc port (6011):

Before this release, these routes pointed to the Develocity application. With the co-located Edge node enabled, they now route to the Edge node instead.

The legacy metrics component, a standalone VictoriaMetrics Pod (gradle-metrics), has been removed from the chart. The modern monitoring stack under monitoring.metrics (containers inside the gradle-monitoring Pod) is unaffected and continues to handle metrics collection and storage.

If your values.yaml contains a top-level metrics: block, delete it before upgrading. Settings under monitoring.metrics are unrelated and should stay.

Both cluster-wide global.scaling keys are deprecated:

Configure replicas and pod disruption budgets through each component’s own scaling.replicas and scaling.podDisruptionBudget keys instead — for example enterprise.scaling.replicas and enterprise.scaling.podDisruptionBudget.

Both keys continue to work; when a per-component key is also set, the per-component key takes precedence.