---
component: ROOT
version: "2026.1"
slug: ROOT/operations/changes
canonical_url: "https://docs.gradle.com/develocity/2026.1/operations/upgrade/changes/"
title: "Changes"
description: "List of changes for Develocity 2026.1."
keywords: []
status: current
---

<!-- llms-index: https://docs.gradle.com/develocity/llms.txt -->

# Changes

<a id="preamble"></a>

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.

<a id="2026-1-1"></a>

## 2026.1.1

<a id="authentication-broker-is-now-routed-through-the-ingress-by-default"></a>

### Authentication Broker Is Now Routed Through the Ingress by Default

The `authenticationBroker.routedBy` setting now defaults to ingress instead of proxy.

This means authentication-related routes (`/keycloak/realms` and `/keycloak/resources`) are now exposed directly through the Ingress resource rather than being routed through the internal proxy. This change aligns the authentication broker with the standard approach used for other Develocity services.

If your configuration includes custom or alternative routing rules, review and update them to account for this change. To explicitly restore the previous behavior, set:

```
authenticationBroker:
  routedBy: proxy
```

> [!NOTE]
> This previous behavior will eventually be deprecated in future releases

<a id="per-component-replica-configuration-replaces-global-scaling-replicas"></a>

### Per-Component Replica Configuration Replaces `global.scaling.replicas`

Each component can now be scaled independently using its own `scaling.replicas` key:

*   `enterprise.scaling.replicas`
    
*   `authenticationBroker.scaling.replicas`
    
*   `proxy.scaling.replicas`
    
*   `mcpServer.scaling.replicas`
    
*   `enterpriseBackgroundProcessor.scaling.replicas`
    

The `global.scaling.replicas` key is deprecated but still functional. When both `global.scaling.replicas` and a per-component key are set, the per-component key takes precedence. When only `global.scaling.replicas` is set, it continues to apply to all components as before.

We invite you to migrate to the per-component keys. For example, to scale only the enterprise app and authentication broker to 3 replicas while keeping other components at their default of 1:

```yaml
enterprise:
  scaling:
    replicas: 3
authenticationBroker:
  scaling:
    replicas: 3
```

> [!NOTE]
> A chart warning is displayed when `global.scaling.replicas` is still in use. If you require further assistance or clarification, please contact Develocity support.

<a id="2026-1-0"></a>

## 2026.1.0

<a id="liveness-readiness-and-startup-probes-available"></a>

### Liveness, Readiness, and Startup Probes Available

This release introduces a new probe mechanism offering unified and pre-configured **liveness**, **readiness**, and **startup** probes.

These probes are pre-configured with sensible defaults and apply to all deployment types. If you encounter issues, raise a ticket with Develocity support. You can disable this mechanism using the following entry in your `values.yaml`:

```yaml
global:
  internal:
    probesV2:
      enterprise:
        enabled: false
      operator:
        enabled: false
      testDistribution:
        enabled: false
```

<a id="embedded-database-is-upgraded-to-postgresql-18-from-14"></a>

### Embedded Database Is Upgraded to PostgreSQL 18 (From 14)

> [!NOTE]
> This change only affects customers whose Develocity instance is configured to use the embedded database. Customers using a user-managed database are unaffected.

In this release, Develocity’s embedded database is upgraded to PostgreSQL 18. When upgrading Develocity, the instance may take longer than usual to start up. For most instances, the impact shouldn’t be significant. For larger databases, there may be some downtime while the database is being upgraded, plan for at least an hour of downtime, possibly more depending on the size of your database. If you have any concerns about the database upgrade, contact Develocity Support.

<a id="port-names-are-unified-and-consistent-across-pods"></a>

### Port Names Are Unified and Consistent Across Pods

As part of the standardized probe initiative, this release applies consistent naming to all component ports.

The `http-monitoring` port (`9090`) is now the designated port for liveness, readiness, and startup probes, as well as all internal component operations. Other ports have been introduced or renamed, but these changes have no impact on standard deployments.

These updates affect all Kubernetes resources where named ports may be referenced, including:

*   Ingress
    
*   Service
    
*   Deployment (specifically `containerPorts`)
    
*   NetworkPolicy
    

> [!IMPORTANT]
> If your configuration uses strategic merge patch, JSON patch, or Helm post-rendering logic that references specific port names, verify and update these definitions before deployment to ensure compatibility.

<a id="default-cache-size-increased-from-10-gib-to-50-gib"></a>

### Default Cache Size Increased from 10 GiB to 50 GiB

The default Build Cache size has increased from 10 GiB to 50 GiB. If your installation uses embedded storage with the previous default cache size, this change requires action before upgrading. You must either configure the cache to retain the 10 GiB size or resize the storage to use the new 50 GiB default.

If your installation uses the default 10 GiB size on the default embedded storage solution and you want to keep that value, apply the following change to your Helm values:

**values.yaml:**

```
objectStorage:
  embedded:
    storage:
      buildCache:
        capacity: 10Gi (1)
```

1. The new default is 50 GiB, so you must specify 10 GiB explicitly to retain it.

This applies to standalone setups, but is more important in cluster installations because the change attempts to resize the PersistentVolumeClaim (PVC). If the PVC doesn’t support resizing, PVC creation fails and the Pods don’t start.

To adjust the cache size to the new default (50 GiB) or to any other value, follow these steps:

1.  Adjust the values YAML to use your desired value (not needed when moving to the new 50 GiB default):
    
    ```yaml
    objectStorage:
      embedded:
        storage:
          buildCache:
            capacity: 50Gi
    ```
    
2.  For cluster installations with PVCs that don’t support resizing, scale down the instance:
    
    ```console
    kubectl scale --replicas=0 deployment --all -n develocity
    ```
    
3.  Delete the `gradle-embedded-object-storage` PVC. This also deletes the current contents of the cache.
    
    ```console
    kubectl delete pvc -n develocity gradle-embedded-object-storage
    ```
    
4.  Run the upgrade and scale the replicas back up. The PVC recreates with the new value (75 GiB, as there is by default another 25 GiB of other internal component data).
    
    ```console
    kubectl get pvc -n develocity gradle-embedded-object-storage
    ```
    
5.  Set the **Target storage size** in the UI or unattended configuration to match your Helm value (default 51200 MiB). In the UI, navigate to `https://<DEVELOCITY_URL>/admin/build-cache/configuration` and update the value. After saving and applying, the cache uses the new size.
    

<a id="new-subcomponent-for-monitoring-database-metrics"></a>

### New Subcomponent for Monitoring Database Metrics

This release adds a new container to `gradle-monitoring` that provides application metrics from the database. This component is used only for internal operations, as part of the support-bundle generation.

The component runs as a new container in the `gradle-monitoring` Pod, using a dedicated `ge_monitor` database role to connect to the database, embedded or user-managed.

<a id="the-global-openshiftinstallation-flag-is-removed"></a>

### The `global.openshiftInstallation` Flag Is Removed

The `global.openshiftInstallation` flag has been removed in this release. If this flag is still present in your `values.yaml`, remove it before upgrading. Otherwise, Helm schema validation fails.

```yaml
global:
  openshiftInstallation: false # <-- remove this line
```

There is no change in functionality. The flag was deprecated and the only allowed value was `false`.

If you previously used `global.openshiftInstallation: true`, refer to the [2025.2 Upgrade Guide](https://docs.gradle.com/develocity/legacy/upgrade/2025.2/#openshift_restricted_v2_scc_prior_to_develocity_2025_1) for migration instructions before proceeding.

<a id="components-now-use-seccompprofile-type-runtimedefault"></a>

### Components Now Use `seccompProfile.type: RuntimeDefault`

All components now set `seccompProfile.type: RuntimeDefault`. This restricts system calls and aligns with the Kubernetes principle that explicit security configurations are preferable to implicit runtime behaviors.

<a id="mcp-servers-require-dedicated-license-entitlements"></a>

### MCP Servers Require Dedicated License Entitlements

Access to the MCP Server and Analytics MCP Server is now controlled by dedicated license entitlements. Licenses existing to date have been updated to include these new entitlements.

<a id="2025-4-5"></a>

## 2025.4.5

<a id="gradle-monitoring-subcomponent-for-logs-is-modified"></a>

### `gradle-monitoring` Subcomponent for Logs Is Modified

The log-collector component used inside `gradle-monitoring` has been replaced by a new one that consumes less CPU and memory.

The component is bundled in a new image (`registry.gradle.com/develocity/monitoring-vector`). Adjust your infrastructure or installation process to reflect this addition (image cache or registry, firewall rules for image download).