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

<a id="component-eol-banner"></a>

You are viewing **Develocity Documentation 2025.3**. To view the latest available version of the docs, see [2026.1](https://docs.gradle.com/develocity/2026.1/reference/helm-charts/cluster/).

# Kubernetes Helm Chart Configuration Guide

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

Develocity is a Kubernetes-based application, distributed as a [Helm](https://helm.sh/) chart. Helm is a package manager for Kubernetes applications.

Helm manages all Develocity components.

<a id="helm_overview"></a>

## Helm Overview

To use Helm, users must first import a Helm chart. A Helm chart is a Kubernetes manifest template, with variables that can be provided at installation time.

<a id="providing-configuration-to-helm"></a>

### Providing Configuration to Helm

Helm uses a `values.yaml` file to populate these variables and generate the Kubernetes manifests.

The variables in `values.yaml` configure the Develocity installation with information such as networking, database, or hostname settings.

Here is a sample `values.yaml` file:

**values.yaml:**

```
global:
  hostname: develocity.example.com
database:
  location: embedded
ingress:
  enabled: true
```

Helm configuration can be provided in several ways, in that documentation, we will prioritize `values.yaml` usage for clarity and simplicity.

> [!NOTE]
> Unless otherwise indicated, most values are optional and have usable defaults.

<a id="example-helm-values-file"></a>

### Example Helm Values File

A complete example of the values file can be found [here](#values_yaml_download).

<a id="considerations"></a>

### Considerations

Each section below contains an overview of Develocity installation options and their corresponding `values.yaml` variables:

1.  Global (Hostname, License)
    
2.  Horizontal Scaling
    
3.  Database Type (Embedded or External)
    
4.  Storage Settings
    
5.  Routing (Ingress or OpenShift)
    
6.  Networking (Ports, Proxies, SSL)
    
7.  Object Storage
    
8.  Unattended Configuration
    
9.  Using an external Bazel cache
    

For installations on hosts with limited to no network connectivity, see the additional section:

10.  Airgap Installation
     

By the end of this guide, you will have a complete `values.yaml` file, ready for your Develocity installation with storage, networking, database settings, and more.

<a id="helm-options"></a>

## Helm Options

<a id="global_options"></a>

### 1. Global

<a id="hostname"></a>

#### Hostname

When installing Develocity, you will need to provide a hostname such as `develocity.example.com`.

This should be the hostname that users of the installation use to access it and therefore should resolve within your network. It’s usually the name of the Develocity host or the hostname of a reverse proxy if one is being used.

> [!NOTE]
> Develocity will only accept requests with this hostname in their `Host` header.

A hostname for the application is supplied in the Helm values file as follows:

**values.yaml:**

```
global:
  hostname: develocity.example.com
```

<a id="license"></a>

#### License

You have been provided with a Develocity license file called `develocity.license`.

This file can be used in any testing, staging or production deployments of Develocity.

Only the "data" part of the license is needed in the Helm value file, but it’s acceptable to include the entire license file contents:

**values.yaml:**

```
global:
  license:
    file: R0VMRgF4nBWOSZKCMAAAX+QUu3BUIJAIwUQiwsViEwMIDKOyvH701n3p6nJBYxoRHnAUnwHwKLjb...
```

> [!TIP]
> The license file can also be supplied as a `helm` argument using `--set-file`. It’s also possible to specify the license file as a Kubernetes secret. This can then be managed manually, or by tooling such as [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) or [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/).

To manually create a secret with the Develocity license:

```shell
kubectl create secret generic my-example-license-secret --from-file=license=path/to/develocity.license
```

Then configure Helm with the name of the secret:

**values.yaml:**

```
global:
  license:
    secretName: my-example-license-secret
```

When specifying the license as a secret, an image pull secret must also be specified.

If performing an airgap installation, an image pull secret must be supplied anyway if the internal registry requires authentication.

If performing an online installation, the license file also needs to be created as an image pull secret:

```shell
kubectl create secret docker-registry my-example-license-image-pull-secret \
  --docker-username=ignored \
  "--docker-password=$(cat develocity.license)" \
  --docker-server=registry.gradle.com
```

**values.yaml:**

```
global:
  image:
    imagePullSecret: my-example-license-image-pull-secret
```

<a id="horizontal_scaling_configuration"></a>

### 2. Horizontal Scaling

A number of Develocity components can be scaled horizontally to provide greater performance and higher availability.

**values.yaml:**

```
global:
  scaling:
    replicas: 2
```

Develocity’s scalable components are implemented as Kubernetes `Deployment` resources. It is also possible to alter their replica count directly using [`kubectl scale`](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#scaling-resources), allowing integration with other Kubernetes tooling.

It is only recommended to alter the replica count directly when connecting to a user-managed database, as available embedded database connections are configured based on the replica count. The user-managed database should have (160 ✖️ replica count) connections available.

<a id="database_type"></a>

### 3. Database

Develocity can store data in either:

*   An **embedded database** that uses a local directory or volume to store its data.
    
*   A **user-managed database** that is completely separate from Develocity.
    

There are tradeoffs to consider for each option:

🔍 **Embedded database tradeoffs**

When using the embedded database, Develocity will run a PostgreSQL database in a container and store data in a persistent volume. In this mode Develocity can run backups on a regular or cron-like schedule.

The embedded database has several advantages:

*   Simple setup with no additional configuration needed.
    
*   Automatic updates to the latest PostgreSQL version supported.
    
*   Features that require disk space information are supported.
    
*   Typically more affordable for smaller installations.
    

However, there are downsides to the embedded database, in particular for larger installations:

*   Disk I/O throughput can be a bottleneck on a busy system and is difficult to address.
    
*   Backup management is slow for larger databases, creates a load on the server, and consumes a lot of memory.
    
*   It is not possible to keep a standby database.
    
*   The database is a single point of failure.
    

🔍 **User-managed database tradeoffs**

A **user-managed database** can be any PostgreSQL database compatible with versions 14 through 17.

There are several advantages, particularly in large installations:

*   Database customizations and optimizations are possible (memory, CPU, I/O throughput, etc…​).
    
*   Resources can be allocated for cost-effectiveness.
    
*   Third party tools to snapshot the database can be used.
    
*   Many cloud databases allow for scaling of resources post installation.
    
*   A standby database for fail-over protection can be used.
    

There are some downsides to using a user-managed database:

*   Extra system(s) are needed for provisioning and configuration.
    
*   Database connectivity and network latency is a factor.
    
*   Backups must be managed by an administrator or a tool.
    
*   Disk space management and alerting are required.
    
*   Develocity features related to disk space are not available.
    
*   Security considerations such as credential cycling must be considered.
    
*   Customer support may be limited for disaster recovery or backup restores.
    

By default, Develocity will use an embedded database that stores its data in a persistent volume provided by the cluster. For this configuration, no additional values are needed in the Helm values file.

<a id="user_managed_database_configuration"></a>

#### User-managed database configuration

When Develocity is configured to store data in a user-managed database, it must be provided with connection settings and credentials for the database.

<a id="connection-settings"></a>

##### Connection settings

These can be provided either to Helm as configuration or as Kubernetes `ConfigMap` and `Secret` resources. Configuring these in Helm is the simplest approach during installation. Providing these values via external Kubernetes resources allows performing update (for example, changing credentials) without having to rerun `helm`, and allows integration with other Kubernetes tooling (for example, for `Secret` provisioning).

Standard connection settings like host, port and database name must be provided. Optionally, additional JDBC parameters can be specified.

**values.yaml:**

```
database:
  location: user-managed
  connection:
    host: database.example.com
    port: 5432
    databaseName: gradle_enterprise
    params: "?connectTimeout=60"
```

These can also be provided as a `ConfigMap`. The name of the `ConfigMap` must be provided, and the resource itself must be created prior to starting Develocity.

**values.yaml:**

```
database:
  location: user-managed
  connection:
    configMapName: my-example-db-connection-details
```

The `ConfigMap` is then configured like this:

```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-example-db-connection-details
data:
  host: database.example.com
  port: 5432
  dbname: gradle_enterprise
  jdbcParams: "?connectTimeout=60"
```

The `port`, `dbname`, and `jdbcParams` properties have application-level defaults (`5432`, `gradle_enterprise`, and empty, respectively) and are optional in the inline `values.yaml` approach. When using a `ConfigMap`, every key the chart references via `configMapKeyRef` must be present in the resource. Omitting any of these keys causes Kubernetes to fail when starting the pod.

The database must have already been created using `CREATE DATABASE`, the `createdb` command or an equivalent mechanism in a cloud database interface prior to configuring Develocity with connection details.

<a id="credentials"></a>

##### Credentials

There are three options for credentials:

🔍 **Option 1** - superuser

If provided with credentials for a database superuser (such as the `postgres` user that is common on PostgreSQL database instances), Develocity can perform the database setup.

A superuser can be added to the values file in the database section:

**values.yaml:**

```
database:
  location: user-managed
  connection:
    host: db.example.com # ...
  credentials:
    superuser:
      username: postgres
      password: the_password
```

> [!NOTE]
> In some installations, often cloud-based, the default credentials provided are not a superuser. For example, the supplied `postgres` account in Amazon RDS PostgreSQL databases is not a superuser, but has the `rds_superuser` role. Such accounts are typically acceptable to use with Develocity.

These credentials can also be supplied as a Kubernetes `Secret`:

**values.yaml:**

```
database:
  location: user-managed
  connection:
    host: db.example.com # ...
  credentials:
    superuser:
      secretName: my-example-db-superuser-credentials
```

The `Secret` should have the typical `username` and `password` keys, encoded using Base64:

```yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: my-example-db-superuser-credentials
data:
  username: "cG9zdGdyZXM="
  password: "ZXhhbXBsZS1wYXNzd29yZA=="
```

🔍 **Option 2** - no superuser

To set up your database without database superuser credentials, run the `setup.sh` script from the [database setup scripts](#database_setup_download) **for your Develocity version** against it. The script will set up less privileged accounts for the application to use, and some privileged functions needed for the application to run.

> [!WARNING]
> The installation will fail if you don’t run the database setup scripts.

The credentials for the accounts must be set by you and provided to Develocity via Helm configuration or Secrets.

To set up your database without database superuser credentials, the values file must be updated as follows:

**values.yaml:**

```
database:
  location: user-managed
  connection:
    host: db.example.com # ...
  credentials:
    app:
      password: app_password
    migrator:
      password: migrator_password
```

These credentials can also be supplied as `Secret` resources. There are two accounts that must be configured, requiring a `Secret` each.

**values.yaml:**

```
database:
  location: user-managed
  connection:
    host: db.example.com # ...
  credentials:
    app:
      secretName: my-example-db-application-credentials
    migrator:
      secretName: my-example-db-migrator-credentials
```

In this example `stringData` is used (which does not require Base64 encoding) to show the correct usernames to use. The usernames are not configurable.

```yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: my-example-db-application-credentials
stringData:
  username: ge_app
  password: "app-example-password"

---
apiVersion: v1
kind: Secret
metadata:
  name: my-example-db-migrator-credentials
stringData:
  username: ge_migrator
  password: "migrator-example-password"
```

<a id="database_iam_authentication"></a>🔍 **Option 3** - AWS IAM database authentication (with or without superuser)

Develocity can be configured to access the database by acquiring short-lived passwords dynamically using [IAM database authentication](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html), rather than using any stored password credentials. This makes it possible for you to manage access to the Develocity database without managing passwords directly. Using IAM database authentication requires that your database is an instance of either Amazon RDS or Amazon Aurora, and that your Develocity instance is running on Amazon EC2 instance(s) or running in an Amazon EKS cluster.

To configure Develocity to use IAM database authentication, your database credentials Helm config needs to include information about your database provider and how Develocity should acquire short-lived passwords. If you want Develocity to perform database setup automatically when starting, you also need to configure [superuser access](#database_setup_with_iam_database_authentication).

The Helm value `database.provider` must be set to `aws-rds`, and the Helm value `database.credentials.type` must be set to either `irsa` or `instanceProfile`, where these two credentials types refer to [EKS IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) and [EC2 instance profiles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) respectively. Both of these authentication implementations are described below.

<a id="using-ec2-instance-profile-credentials"></a>

##### Using EC2 instance profile credentials

Instance profile credentials can only be used if your Develocity installation is running on Amazon EC2 instance(s).

You must set up the appropriate permissions in AWS beforehand in order for Develocity to be able to acquire short-lived passwords using an EC2 instance profile. The steps to take this are described in the [IAM database authentication for RDS](https://docs.gradle.com/develocity/2025.3/installation/aws/aws-ec2-standalone/#rds_iam_authentication) section of our Amazon EC2 Standalone Installation Guide..

To configure Develocity to acquire short-lived database passwords using instance profile credentials, update your Helm values file as follows:

**values.yaml:**

```
database:
  location: user-managed
  connection:
    host: db.example.com # ...
  provider: aws-rds
  credentials:
    type: instanceProfile
```

<a id="using-eks-irsa-credentials"></a>

##### Using EKS IRSA credentials

IRSA (IAM roles for service accounts) credentials can only be used if your Develocity installation is running in an Amazon EKS cluster.

You must set up the appropriate permissions in AWS beforehand in order for Develocity to be able to acquire short-lived passwords in this way. The steps to take this are described in the [IAM database authentication for RDS](https://docs.gradle.com/develocity/2025.3/installation/aws/aws-ec2-standalone/#rds_iam_authentication) section of our Amazon EKS Kubernetes Installation Guide.

When configuring Develocity to acquire short-lived passwords using IRSA authentication, specify the Helm value `database.credentials.irsa.serviceAccountAnnotations`. By setting this Helm value, you can specify the EKS role annotation in one place, and the Develocity Helm chart will automatically take care of applying it to the Kubernetes service accounts which require it in the Develocity installation.

To configure Develocity to acquire short-lived passwords using IRSA credentials, update your Helm values file as follows:

**values.yaml:**

```
database:
  location: user-managed
  connection:
    host: db.example.com # ...
  provider: aws-rds
  credentials:
    type: irsa
    irsa:
      serviceAccountAnnotations:
        eks.amazonaws.com/role-arn: «Amazon EKS cluster IAM role ARN» (1)
```

1. Replace «Amazon EKS cluster IAM role ARN» with the ARN of an IAM role which can assume the required permissions. You can create such a role by following the instructions in the IAM database authentication for RDS section of our Amazon EKS Kubernetes Installation Guide.

<a id="database_setup_with_iam_database_authentication"></a>

**Database setup with IAM database authentication**

The Database setup must either be performed automatically by Develocity on startup by connecting to the database as a superuser, or it must be performed manually by you before installation by running the `setup.sh` script from the [database setup scripts](#database_setup_download) **for your Develocity version** against the database.

If you want Develocity to be able to connect to the database as a superuser for automatic database setup, you need to provide either the username of a superuser (in which case Develocity will try to connect as the superuser using IAM authentication), or both the username and password of a superuser (in which case Develocity will try to connect as the superuser using the configured password).

> [!NOTE]
> If you want to use IAM authentication for the superuser, you must grant it the role `rds_iam`.

These can be provided directly using the Helm values `database.credentials.superuser.username` and `database.credentials.superuser.password`, or in a Kubernetes Secret, whose name must be provided in the Helm value `database.credentials.superuser.secretName` and which contains either only a `username`, or both a `username` and a `password`.

If you want to specify superuser credentials using a Kubernetes Secret, it should have the typical `username` and `password` keys, encoded using Base64:

```yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: my-example-db-superuser-credentials
data:
  username: "cG9zdGdyZXM="
  password: "ZXhhbXBsZS1wYXNzd29yZA==" (1)
```

1. Omit the 'password' field if you want Develocity to connect to the database using IAM authentication.

<a id="storage"></a>

### 4. Storage Settings

<a id="storage_class_configuration"></a>

#### Storage Class Configuration

The Kubernetes [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) can be configured for data and backup volumes. If omitted, the default storage class for the cluster will be picked, if there is one. Consult your cluster documentation for available storage classes.

> [!NOTE]
> Not all clusters provide a usable default storage class. It’s strongly recommended to consult your cluster documentation and select from the available storage classes explicitly.

**values.yaml:**

```
global:
  storage:
    data:
      class: some-provisioned-io-storage-class
    backup:
      class: slow-and-cheap-storage-class
```

> [!NOTE]
> Backup storage class is not necessary when connecting to a user-managed database.

<a id="storage_capacity"></a>

#### Storage Capacity Configuration

Here, you can configure the storage capacity for various Develocity components.  
If omitted, the shown default amount of storage will be requested from the cluster.

**values.yaml:**

```
database:
  storage:
    data:
      capacity: 1000Gi # default 250Gi
    backup:
      capacity: 1000Gi # default 250Gi
metrics:
  storage:
    data:
      capacity: 1Gi # default 200Mi
testDistribution:
  storage:
    data:
      capacity: 20Gi # default 10Gi
monitoring:
  storage:
    data:
      capacity: 20Gi  # Default 20Gi
objectStorage:
  type: embedded
  embedded:
    storage:
      buildCache:
        capacity: 20Gi  # Default 10Gi
```

> [!NOTE]
> Backup storage capacity is not necessary when connecting to a user-managed database.

<a id="routing"></a>

### 5. Routing

There are several ways to route web traffic to Develocity from outside the Kubernetes cluster. These include:

*   An [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
    
*   An [OpenShift Route](https://docs.openshift.com/en/container-platform/4.9/networking/routes/route-configuration.html).
    

Which you choose to use will depend on your organizational policies and available infrastructure.

<a id="supplied-ingress"></a>

#### Supplied Ingress

Develocity can create a Kubernetes Ingress resource for you that is managed as part of your Helm release. The Ingress will be bound to the hostname that is configured.

**values.yaml:**

```
ingress:
  enabled: true
```

> [!NOTE]
> Your Ingress-Controller implementation has to be compatible with `GRPC` to support some Develocity features (for example, Bazel Build Scans). For more details about this, consult your Ingress-Controller implementation.

<a id="user-managed-routing"></a>

#### User-managed Routing

For compatibility and configuration reasons, we strongly recommend to use the supplied Ingress definition. If the provided one isn’t suitable, you will need to provide your own configuration aligned with Develocity supplied Ingress.

Develocity creates a service named `gradle-proxy` exposing ports `80` and `443` (when HTTPS is enabled, see below) for accessing the application. This is the service to which alternative routing infrastructure such as load balancers will need to route traffic.

> [!NOTE]
> You may need to configure your Ingress differently to support `Bazel` using `GRPC`. Contact [Develocity Customer Support](https://docs.gradle.com/develocity/2025.3/administration/admin-manual/#troubleshooting) for help with `Bazel` and your own Ingress definition.

<a id="openshift-configuration"></a>

#### OpenShift Configuration

For security reasons, Develocity containers run as `nonroot` and they require an extra configuration at OpenShift level. The following flag, available in older versions, is no longer valid.

**values.yaml:**

```
global:
  openshiftInstallation: true
```

Instead, we recommend you to use your favorite solution to allow Develocity `nonroot` workloads to run in your cluster. One solution is to use the `ClusterRole` named `system:openshift:scc:nonroot-v2` and associate it to Pod’s `ServiceAccounts` used by Develocity.

You can apply the following manifest in the namespace where Develocity is installed:

**role-bindings-for-openshift.yaml:**

```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: system:openshift:scc:nonroot-v2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:openshift:scc:nonroot-v2
subjects: (1)
  - kind: ServiceAccount
    name: gradle-database
  - kind: ServiceAccount
    name: gradle-enterprise-app
  - kind: ServiceAccount
    name: gradle-enterprise-app-background-processor
  - kind: ServiceAccount
    name: gradle-keycloak
  - kind: ServiceAccount
    name: gradle-metrics
  - kind: ServiceAccount
    name: gradle-monitoring
  - kind: ServiceAccount
    name: gradle-embedded-object-storage
  - kind: ServiceAccount
    name: gradle-enterprise-operator
  - kind: ServiceAccount
    name: gradle-proxy
  - kind: ServiceAccount
    name: gradle-enterprise-operator
  - kind: ServiceAccount
    name: gradle-test-distribution-broker
```

1. Represent the list of ServiceAccount used by Develocity. This list may vary based on features you turn on or off

**Alternatively**, you can run the following command to achieve the same as the previous manifest:

**add-bindings-for-nonroot-to-openshift.sh:**

```
NAMESPACE="develocity"
for serviceaccountname in $(oc get serviceaccount -n $NAMESPACE -l "app.kubernetes.io/part-of=gradle-enterprise" -o jsonpath='{.items.*.metadata.name}')
do
  oc adm policy add-scc-to-user nonroot-v2 --namespace $NAMESPACE -z $servicecountname
done
```

> [!NOTE]
> Security depends on Operator’s choices and company rules, for that reason every element in that section are general examples, and you should not treat them as de facto solutions.

<a id="networking"></a>

### 6. Networking

There are several considerations for Develocity related to connectivity:

*   HTTP or HTTPS (with SSL certificates)
    
*   GRPC
    
*   Application Ports
    
*   Proxies
    

<a id="https"></a>

#### HTTP or HTTPS

Develocity can be configured to securely serve traffic over HTTPS based on user-provided certificates.

If certificates aren’t supplied, self-signed certificates will be generated and used, though this isn’t recommended for production operation.

<a id="https_using_ingress"></a>

##### HTTPS Terminated at Ingress

When using the Develocity supplied Ingress, HTTPS is enabled by default.

It can be disabled to serve traffic over HTTP only:

**values.yaml:**

```
ingress:
  enabled: true
  ssl:
    enabled: false
```

SSL certificates (trusted or untrusted) can be provided inline in the values file:

**values.yaml:**

```
ingress:
  enabled: true
  ssl:
    cert: |
      -----BEGIN CERTIFICATE-----
      MIIDKjCCAhKgAwIBAgIRAPNTIHf6/oUuzMKm3ffGNOgwDQYJKoZIhvcNAQELBQAw
      HDEaMBgGA1UEAxMRYXV0by1nZW5lcmF0ZWQtY2EwHhcNMjExMTMwMTU1NDU5WhcN
      ...
      Cn/3yUirFVTslrSYKAemLw8btLO6FDF9dc/lq1o7tKsYVuhEcjqnTah7puJjEN9h
      z+P5RmRxU/kaaFB+Vuw1pRezbaAtZNorVgXnBwrdseY4zLGyhAcGcR9v+VtCiQ==
      -----END CERTIFICATE-----
    key: |
      -----BEGIN RSA PRIVATE KEY-----
      MIIEpQIBAAKCAQEA4qV8JlqDMi7y85Ykq8dn7uIsi609D6KuFtlc+UvNYjatz0+u
      QzIr3iw//qf7sM8nx8fhGwuWvUWeCE6zbgKjuxDH82J9NQ0ctf70n0qVTeyW1CKR
      ...
      XlOfXr/xvkXA66PROgvVxfwpN/GNrLXFi1HvMg7MVZJUZQpNzpAzw5JTk2MbawOl
      G7tI0qQ6F20e5R4tPpEDKCFZykyvgGMhfLzsvVlrgaVW8QbVK4YWNtQ=
      -----END RSA PRIVATE KEY-----
```

Or the certificate can refer to a [Kubernetes TLS Secret](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) already available in the cluster:

**values.yaml:**

```
ingress:
  enabled: true
  ssl:
    secretName: example-ssl-certificate-secret-name
```

<a id="https_ssl_certificate"></a>

###### HTTPS SSL Certificate

It is strongly recommended that production installations of Develocity are configured to use HTTPS with a trusted certificate.

Develocity natively supports serving traffic over HTTPS when configured with a certificate and key. If you intend to use an Ingress Controller for directing external traffic to Develocity, you may opt to terminate HTTPS there. It is also possible to terminate HTTPS connections in an external reverse proxy.

<a id="untrusted_ssl_certificates"></a>

###### Untrusted SSL Certificates

By default, Develocity uses the default trust settings of the Java runtime that is included with when connecting to other systems using SSL.

If your organization uses certificates that are not signed by a trusted certificate authority, you must perform additional configuration for this to work (see below). This may be the case if you use self-signed certificates or an internal certificate authority.

<a id="additional-certificates"></a>

###### Additional Certificates

Additional trusted certificates for outbound traffic can be specified at installation time via the [unattended configuration mechanism](#helm_config_unattended_configuration), using the `additionalTrust` field in the unattended configuration file. The value of this field should be the X509 certificates to trust in PEM format, newline-separated if there are more than one.

For example, using the inline Helm values support to include the unattended configuration in a values file:

**values.yaml:**

```
global:
  unattended:
    configuration:
      version: 13
      systemPassword: "«hashed-system-password»"
      network:
        additionalTrust: |
          -----BEGIN CERTIFICATE-----
          MIIDfzCCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
          ...
          s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
          -----END CERTIFICATE-----
          -----BEGIN CERTIFICATE-----
          DSE3a3CCAmegAwIBAgIURqPslYGu7cHXs22q3RK6e5L87PwwDQYJKoZIhvcNAQEL
          ...
          s10yB5VjVBES6A22rYwYb8mImpQiVP/mr4ao5U5m+h50l3E=
          -----END CERTIFICATE-----
```

<a id="https_terminated_externally"></a>

##### HTTPS Terminated Externally

In many setups, a reverse proxy or load balancer will perform SSL termination. In this case, SSL certificates must be configured accordingly.

Develocity needs to know that the application will be accessed over externally terminated HTTPS. This is done with the following configuration:

**values.yaml:**

```
global:
  hostname: develocity.example.com
  externalSSLTermination: true
```

If you’re using the provided Ingress, you may want to communicate between the load balancer and the application using HTTP by disabling SSL at the Ingress:

**values.yaml:**

```
ingress:
  enabled: true
  ssl:
    enabled: false
```

<a id="grpc"></a>

#### GRPC

Develocity uses the `GRPC` protocol for `Bazel` features. To support this, the application has to be exposed with `grpc/http2` compatible components (for example, Ingress-Controller, Firewall, Load balancers…).

Please consult the documentation of those infrastructure or Kubernetes components to get more information about support and requirements for `grpc` compatibility. All examples below use example annotations that are not relevant for your installation.

<a id="grpc_with_ingress_annotations"></a>

##### GRPC with Ingress annotations

Some Ingress-Controller implementations require extra implementation-specific annotations on `Ingress` objects to be compatible with `grpc`. You can provide them using the following entry in the `values.yaml`:

**values.yaml:**

```
ingress:
  enabled: true
  grpc:
    annotations:
      acme.ingress.kubernetes.io/backend-protocol: "GRPC"
```

<a id="grpc-with-service-annotations"></a>

##### GRPC with Service annotations

Some Ingress-Controller implementations require extra implementation-specific annotations on `Ingress` objects to be compatible with `grpc`. You can provide them using the following entry in the `values.yaml`:

**values.yaml:**

```
ingress:
  enabled: true
  grpc:
    serviceAnnotations:
      acme.ingress.kubernetes.io/upstream-protocol.h2c: "grpc"
```

<a id="application-ports"></a>

#### Application Ports

The ports that the application accepts traffic on can be altered from the default of 443 (or 80 if accepting plain HTTP) as follows:

**values.yaml:**

```
ingress:
  enabled: true
  port:
    http: 8080
    https: 8443
```

<a id="proxy_configuration"></a>

#### Proxy Configuration

By default, Develocity requires an internet connection to make several outbound HTTP requests (such as license validation).

In case your organization requires all outbound HTTP traffic to go through an HTTP proxy, you must perform additional configuration for this to work.

HTTP proxy configuration can be specified under the `network` section in the unattended configuration section:

**values.yaml:**

```
global:
  unattended:
    configuration:
      version: 13
      systemPassword: "«hashed-system-password»"
      network:
        proxy:
          protocol: http (1)
          host: proxy.gradle.com (2)
          port: 8080 (3)
          excludedHosts: (4)
            - some.external
            - '*.internal'
          auth: (5)
            username: proxy_user
            password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
```

1. The protocol used to connect to the proxy. Note that this is not the protocol used to connect to the destination/target addresses. Supported values are http and https, if no value is provided http will be used as the default protocol.
2. HTTP proxy host name.
3. HTTP proxy port, if no value is provided 80 will be used ad the default port.
4. A comma-delimited list that controls what hosts should not be proxied. The list can contain individual host names as well as domain patterns (for example, '*.internal') which match all hosts for a particular domain. Any requests sent to these hosts will be sent directly rather than being sent through the HTTP proxy.
5. A username and password used to authenticate with the HTTP Proxy.

<a id="helm_config_object_storage"></a>

### 7. Object Storage Configuration

> [!WARNING]
> The new monitoring system introduced in 2025.1 requires some extra configuration to be fully operational. Review the changes in the Develocity 2025.2 Upgrade Guide before upgrading.

Develocity can store different kinds of data in a user-managed Object Storage service, such as Amazon S3:

*   Build Scan data is stored in the [database](#database_type) by default, but [Develocity can be configured to store Build Scans in an object store](#object_storage_for_build_scans) instead.
    
*   Build Cache data is stored in embedded object storage - a persistent volume backed server installed with Develocity - by default, but can be configured to store Build Cache data in a user-managed object store instead.
    
*   Monitoring data such as metrics collected during application lifetime.
    

> [!NOTE]
> Storing data in different buckets allows you to apply various strategies, such as access control, replication, soft-delete, backup, and more. However, you can use only one bucket for both application (Build Scans and Build Cache data) and monitoring data; this is an operation’s decision based on your practices.

The [Build Scan object storage section of the Administration Manual](https://docs.gradle.com/develocity/2025.3/administration/admin-manual/#build_scan_object_storage) discusses the tradeoffs of using object storage rather than a database for Build Scan data. We recommend that your object storage is hosted close to your Develocity installation to minimise latency and network usage costs. For example, if using S3 as an object storage service, verify that your S3 bucket and Develocity installation reside in the same AWS region.

Most popular object storage services are supported. Alternatively, Develocity has the ability to run an embedded object store as one of its components. The rest of this section describes how to configure Develocity to use AWS S3, an S3-compatible object storage service, Google Cloud Storage, Microsoft Azure Blob Storage, or the embedded object storage.

> [!NOTE]
> To finish configuring Develocity to store Build Scan data in the configured object storage, you must also configure Develocity with an unattended configuration stanza in your Helm `values.yaml` file. See [Objects Storage for Build Scans](#object_storage_for_build_scans) for details.

> [!NOTE]
> If Develocity is connected to a user-managed object storage service, then Develocity will switch to storing Build Cache data there, instead of embedded object storage.

<a id="object_storage_s3"></a>

#### Amazon S3

For steps to set up a bucket in S3 with an appropriate access policy, see the [Amazon S3 appendix of the EKS Installation Guide](https://docs.gradle.com/develocity/2025.3/installation/aws/aws-eks-cluster/#s3) for Kubernetes cluster deployments, or the [Amazon S3 appendix of the EC2 Installation Guide](https://docs.gradle.com/develocity/2025.3/installation/aws/aws-ec2-standalone/#s3) for VM standalone deployments.

To use Amazon S3 as the object store for Develocity, you need to set the type of the object storage as `s3` and configure the bucket name and region.

**values.yaml:**

```
objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data (1)
    region: aws-region (2)
    credentials:
      type: keys # ...
    monitoring: (3)
      bucket: develocity-monitoring-data (4)
      region: aws-region (5)
      credentials:
        type: keys # ...
```

1. Your S3 bucket name used for build-scan and build-cache data.
2. The cloud provider region where your object storage resides.
3. Mandatory block to configure the connection and location where monitoring data are stored. Those values can be the same as above to share the same bucket and credentials, or different if you want to separate application data from monitoring data.
4. Your S3 bucket name used for monitoring data, stored by the monitoring component.
5. The cloud provider region where your object storage for monitoring data resides.

It is necessary to provide credentials to access the bucket. There are several options to do this as documented below.

> [!NOTE]
> If Develocity is hosted on AWS, it’s strongly recommended to set up and configure access to the S3 bucket via a VPC endpoint to reduce access cost and latencies. Refer to the [official AWS VPC endpoint documentation](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html) to learn more.

<a id="object_storage_s3_credentials_irsa"></a>

##### IAM Roles for Service Account credentials configuration

**values.yaml:**

```
objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: irsa
      irsa:
        serviceAccountAnnotations:
          "eks.amazonaws.com/role-arn": arn:aws:iam::«account-id»:role/«Amazon EKS cluster IAM role ARN»
    monitoring:
      bucket: develocity-monitoring-data
      region: aws-region
      credentials:
        type: irsa
        irsa:
          serviceAccountAnnotations:
            "eks.amazonaws.com/role-arn": arn:aws:iam::«account-id»:role/«Amazon EKS cluster IAM role ARN»
```

<a id="object_storage_s3_credentials_pod_identity"></a>

##### Pod Identity: IAM Roles for Service Account

You can provision credentials to Develocity dynamically using [IAM Role for Service Account](https://docs.gradle.com/develocity/2025.3/installation/aws/aws-eks-cluster/#s3_create_eks_role). You need to enable Pod Identity on your cluster and associate the IAM role with the Develocity service accounts [Pod Identity](https://docs.gradle.com/develocity/2025.3/installation/aws/aws-eks-cluster/#s3_pod_identity).

**values.yaml:**

```
objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: podIdentity
    monitoring:
      bucket: develocity-monitoring-data
      region: aws-region
      credentials:
        type: podIdentity
```

<a id="object_storage_s3_credentials_keys"></a>

##### Keys credentials configuration

To provide an access key and secret key as credentials in the Helm chart, set `type` to `keys` and provide the `accessKey` and `secretKey`.

**values.yaml:**

```
objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: keys
      keys:
        accessKey: "AKIA1234ABCD7890"
        secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
    monitoring:
      bucket: develocity-monitoring-data
      region: aws-region
      credentials:
        type: keys
        keys:
          accessKey: "AKIA1234ABCD0987"
          secretKey: "dfml3s9rfdlsok390wledck30rtzwp"
```

<a id="object_storage_s3_credentials_keys_secret"></a>

##### Keys credentials configuration via Kubernetes secret

To provide an access key and secret key stored in a Kubernetes secret as credentials, set `type` to `keys` and provide the `secretName` to the Kubernetes resource name of the secret. The secret must contain `accessKey` and `secretKey` properties.

**values.yaml:**

```
objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: keys
      keys:
        secretName: develocity-s3-credentials
    monitoring:
      bucket: develocity-monitoring-data
      region: aws-region
      credentials:
        type: keys
        keys:
          secretName: develocity-s3-credentials
```

**develocity-s3-credentials.yaml:**

```
apiVersion: v1
kind: Secret
metadata:
  name: develocity-s3-credentials
stringData:
  accessKey: "AKIA1234ABCD7890"
  secretKey: "dfml3s9rfdlsok390wledck30rkdfs"
```

This option allows credential cycling without needing to rerun Helm to reconfigure Develocity with the new credentials and separate sensitive credentials from other settings. A manual Pod restart is required to apply the new credentials.

```shell
kubectl rollout restart deployment --selector 'app.kubernetes.io/component in (enterprise-app, enterprise-app-background-processor)
```

<a id="object_storage_s3_custom_endpoint"></a>

##### Custom endpoint

There are circumstances in which it is necessary to specify the endpoint URL of the service:

*   If you need to connect to S3 directly from a VPC using a [gateway VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html).
    
*   If your object storage service is not S3 but provides an S3-compatible interface.
    

To do this, set the `endpoint` property to point to the service endpoint:

**values.yaml:**

```
objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    endpoint: https://object-store.example.com
    credentials:
      type: keys # ...
    monitoring:
      bucket: develocity-monitoring-data
      endpoint: https://object-store.example.com
      credentials:
        type: keys # ...
```

> [!NOTE]
> AWS S3 supports two styles of endpoint URLs: virtual-hosted-style and path-style URL access. In either case, the bucket name must NOT be included in the URL. For example, for the following virtual-hosted-style URL `https://develocity-application-data.s3.«region-code».amazonaws.com` you configure bucket as `develocity-application-data` and endpoint as `https://s3.«region-code».amazonaws.com`.

<a id="object_storage_gcs"></a>

#### Google Cloud Storage

For steps to create a bucket and configure access, see the [Google Cloud Storage appendix of the GKE Installation Guide](https://docs.gradle.com/develocity/2025.3/installation/google-cloud/gke-kubernetes/#google_cloud_storage) for Kubernetes cluster deployments, or the [Google Cloud Storage appendix of the GCE Installation Guide](https://docs.gradle.com/develocity/2025.3/installation/google-cloud/gce-standalone/#google_cloud_storage) for VM standalone deployments.

To use Google Cloud Storage as the object storage, set the `type` of object storage as `googleCloudStorage` and configure the `bucket`.

**values.yaml:**

```
objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: develocity-application-data
    credentials:
      type: gceServiceAccount # ...
    monitoring:
      bucket: develocity-monitoring-data
      credentials:
        type: gceServiceAccount # ...
```

It is necessary to provide credentials to access the bucket. There are several options to do this as documented below.

<a id="object_storage_gcs_credentials_workload_identity"></a>

##### Workload Identity Federation credentials configuration

You can provision credentials to Develocity dynamically using [Workload Identity Federation](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/workload-identity).

**values.yaml:**

```
objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: develocity-application-data
    credentials:
      type: workloadIdentity
    monitoring:
      bucket: develocity-monitoring-data
      credentials:
        type: workloadIdentity
```

<a id="object_storage_gcs_credentials_service_account"></a>

##### Service Account Key credentials configuration

To provide the service account key as credentials in the Helm chart, set `type` to `serviceAccount` and provide the `key`.

**values.yaml:**

```
objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: develocity-application-data
    credentials:
      type: serviceAccount
      serviceAccount:
        key: |
          {
            "type": "service_account",
            "project_id": "PROJECT_ID",
            "private_key_id": "KEY_ID",
            "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
            "client_email": "SERVICE_ACCOUNT_EMAIL",
            "client_id": "CLIENT_ID",
            "auth_uri": "https://accounts.google.com/o/oauth2/auth",
            "token_uri": "https://accounts.google.com/o/oauth2/token",
            "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
            "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
          }
    monitoring:
      bucket: develocity-monitoring-data
      credentials:
        type: serviceAccount
        serviceAccount:
          key: |
            {
              "type": "service_account",
              "project_id": "PROJECT_ID",
              "private_key_id": "KEY_ID",
              "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
              "client_email": "SERVICE_ACCOUNT_EMAIL",
              "client_id": "CLIENT_ID",
              "auth_uri": "https://accounts.google.com/o/oauth2/auth",
              "token_uri": "https://accounts.google.com/o/oauth2/token",
              "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
              "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
            }
```

<a id="object_storage_gcs_credentials_service_account_secret"></a>

##### Credentials configuration via Kubernetes secret

To provide a service account key stored in a Kubernetes secret as credentials, set `type` to `serviceAccount` and provide the `secretName` to the Kubernetes resource name of the secret. The secret must contain `serviceAccountKey` property.

**values.yaml:**

```
objectStorage:
  type: googleCloudStorage
  googleCloudStorage:
    bucket: develocity-application-data
    credentials:
      type: serviceAccount
      serviceAccount:
        secretName: develocity-gcs-credentials
    monitoring:
      bucket: develocity-monitoring-data
      credentials:
        type: serviceAccount
        serviceAccount:
          secretName: develocity-gcs-credentials
```

**develocity-gcs-credentials.yaml:**

```
apiVersion: v1
kind: Secret
metadata:
  name: develocity-gcs-credentials
stringData:
  serviceAccountKey: |
    {
      "type": "service_account",
      "project_id": "PROJECT_ID",
      "private_key_id": "KEY_ID",
      "private_key": "-----BEGIN PRIVATE KEY-----\nPRIVATE_KEY\n-----END PRIVATE KEY-----\n",
      "client_email": "SERVICE_ACCOUNT_EMAIL",
      "client_id": "CLIENT_ID",
      "auth_uri": "https://accounts.google.com/o/oauth2/auth",
      "token_uri": "https://accounts.google.com/o/oauth2/token",
      "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
      "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL"
    }
```

This option allows credential cycling without needing to rerun Helm to reconfigure Develocity with the new credentials and separate sensitive credentials from other settings. A manual Pod restart is required to apply the new credentials.

```shell
kubectl rollout restart deployment --selector 'app.kubernetes.io/component in (enterprise-app, enterprise-app-background-processor)
```

<a id="object_storage_azure"></a>

#### Azure Blob Storage

For steps to set up the storage account and configure access, see the [Azure Blob Storage appendix of the AKS Installation Guide](https://docs.gradle.com/develocity/2025.3/installation/azure/azure-aks-cluster/#azure_blob_storage) for Kubernetes cluster deployments, or the [Azure Blob Storage appendix of the Azure VM Installation Guide](https://docs.gradle.com/develocity/2025.3/installation/azure/azure-vm-standalone/#azure_blob_storage) for VM standalone deployments.

To use Azure Blob Storage as the object storage, set the `type` of the object storage as `azureBlobStorage` and configure the `container` name.

**values.yaml:**

```
objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: develocity-application-data
    credentials:
      type: workloadIdentity # ...
    monitoring:
      container: develocity-monitoring-data
      credentials:
        type: workloadIdentity # ...
```

It is necessary to provide credentials to access the bucket.

There are several options to supply these as documented below.

<a id="object_storage_azure_credentials_workload_identity"></a>

##### Workload Identity Federation credentials configuration

You can provision credentials to Develocity dynamically using [Workload Identity Federation](https://learn.microsoft.com/en-us/azure/service-connector/tutorial-python-aks-storage-workload-identity).

**values.yaml:**

```
objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: develocity-application-data
    credentials:
      type: workloadIdentity
      workloadIdentity:
        accountName: "develocity-application-data-account"
        serviceAccountAnnotations:
          azure.workload.identity/client-id: "develocity-application-data-client-id"
    monitoring:
      container: develocity-monitoring-data
      credentials:
        type: workloadIdentity
        workloadIdentity:
          accountName: "develocity-monitoring-data-account"
          serviceAccountAnnotations:
            azure.workload.identity/client-id: "develocity-monitoring-data-client-id"
```

<a id="object_storage_azure_credentials_account_information"></a>

##### Account Key credentials configuration

To provide an account name and key in the Helm chart, set `type` to `accountInformation` and provide the `accountName` and `accountKey` properties.

**values.yaml:**

```
objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: develocity-application-data
    credentials:
      type: accountInformation
      accountInformation:
        accountName: "develocity-application-data-account"
        accountKey: "dfml3s9rfdlsok390wledck30rkdfs"
    monitoring:
      container: develocity-monitoring-data
      credentials:
        type: accountInformation
        accountInformation:
          accountName: "develocity-monitoring-data-account"
          accountKey: "dfml3s9rfdlsok390wledck30rtzwp"
```

<a id="object_storage_azure_credentials_connection_string"></a>

##### Connection String credentials configuration

To provide a connection string in the Helm chart, set `type` to `accountInformation` and provide the `connectionString` property.

**values.yaml:**

```
objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: develocity-application-data
    credentials:
      type: accountInformation
      accountInformation:
        connectionString: "DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://devstoreaccount1.gradle-enterprise.svc.cluster.local:10000"
    monitoring:
      container: develocity-monitoring-data
      credentials:
        type: accountInformation
        accountInformation:
          connectionString: "DefaultEndpointsProtocol=http;AccountName=develocity-azure-account;AccountKey=dfml3s9rfdlsok390wledck30rkdfs;EndpointSuffix=core.windows.net"
```

<a id="object_storage_azure_credentials_account_information_secret"></a>

##### Credentials configuration via Kubernetes secret

To provide an account name and key credential stored in a Kubernetes secret, set `type` to `accountInformation` and provide the `secretName` to the Kubernetes resource name of the secret. The secret must contain an `accountName` and `accountKey`.

**values.yaml:**

```
objectStorage:
  type: azureBlobStorage
  azureBlobStorage:
    container: develocity-application-data
    credentials:
      type: accountInformation
      accountInformation:
        secretName: develocity-azure-credentials
    monitoring:
      container: develocity-monitoring-data
      credentials:
        type: accountInformation
        accountInformation:
          secretName: develocity-azure-credentials
```

**develocity-azure-credentials.yaml:**

```
apiVersion: v1
kind: Secret
metadata:
  name: develocity-azure-credentials
stringData:
  accountName: "develocity-azure-account"
  accountKey: "dfml3s9rfdlsok390wledck30rkdfs"
```

**develocity-azure-credentials-with-connection-string.yaml:**

```
apiVersion: v1
kind: Secret
metadata:
  name: develocity-azure-credentials
stringData:
  connectionString: "DefaultEndpointsProtocol=http;AccountName=develocity-azure-account;AccountKey=dfml3s9rfdlsok390wledck30rkdfs;EndpointSuffix=core.windows.net"
```

This option allows credential cycling without needing to rerun Helm to reconfigure Develocity with the new credentials and separate sensitive credentials from other settings. However, a manual Pod restart is required to apply the new credentials.

```shell
kubectl rollout restart deployment --selector 'app.kubernetes.io/component in (enterprise-app, enterprise-app-background-processor)
```

<a id="object_storage_embedded"></a>

#### Embedded object storage

Embedded object storage is a component that is deployed as part of the Develocity installation if no other object storage is configured.

The `type` of the object storage is `embedded`.

**values.yaml:**

```
objectStorage:
  type: embedded
```

Data will be stored on a persistent volume. See [Storage Capacity Configuration](#storage_capacity) for details on specifying the capacity of the embedded object storage.

> [!NOTE]
> Build Scans cannot be stored in embedded object storage. See the [relevant section of the Administration Manual](https://docs.gradle.com/develocity/2025.3/administration/admin-manual/#build_scans_object_storage_develocity_configuration_reference) for more information on setting the storage type for incoming Build Scans using unattended configuration.

> [!WARNING]
> Data in the embedded object store is not part of a Develocity database backup.

<a id="object_storage_advanced_params"></a>

#### Configuring advanced parameters

Each object storage provider can be further configured using `advancedParams`. You should only configure advanced parameters if the Develocity support has directed you to do so.

**values.yaml:**

```
objectStorage:
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: irsa
      #...
    advancedParams:
      client.maxConcurrency: 12
    monitoring:
      bucket: develocity-monitoring-data
      region: aws-region
      credentials:
        type: irsa
        #...
```

<a id="helm_config_unattended_configuration"></a>

### 8. Unattended Configuration

Many aspects of Develocity' behavior can be configured via the Admin user interface or by providing an unattended configuration file. These settings are described in the [unattended configuration](https://docs.gradle.com/develocity/2025.3/administration/admin-manual/#unattended_configuration) section of the Develocity Administration Manual.

> [!TIP]
> Unattended configuration settings can also be in their own yaml file and given to the `helm` command as follows: `--set-file global.unattended.configuration=./unattended-config.yaml`

While most of Develocity can be configured post-installation, there are two items that can and should be configured at installation time:

*   Proxy settings
    
*   Object Storage for Build Scan data
    

You will need the hashed system user password and a configuration version to use the unattended configuration in your Helm values file, and you must install the [Develocity command line tool](https://docs.gradle.com/develocity/develocityctl/1.22/) (develocityctl).  

Full instructions are available [in the Administration Manual](https://docs.gradle.com/develocity/2025.3/administration/admin-manual/#unattended_configuration).

Having prepared a Develocity configuration file and optionally an encryption key, you can provide it to Helm in one of two ways.

Example key:

**develocity-configuration.key:**

```
aes256:B0uVHRDhng+PraUI:Aj25DOwJsrXnWYcprreHAS4l66k/7q5CIjFDg5PTR7U=
```

Example YAML file:

**develocity-configuration.yaml:**

```
version: 13
systemPassword: "«hashed-system-password»"
buildScans:
  keepDays: 30
email:
  administratorAddress: develocity-adminstrator@example.com
  fromAddress: develocity@example.com
  smtpServer: smtp.example.com:587
  sslProtocol: startTls
  authentication:
    type: login
    username: develocity-adminstrator@example.com
    password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
```

The file and encryption key can be provided inline in a Helm values file under the `global.unattended` property:

**values.yaml:**

```
global:
  unattended:
    key: "aes256:B0uVHRDhng+PraUI:Aj25DOwJsrXnWYcprreHAS4l66k/7q5CIjFDg5PTR7U=" (1)
    configuration: (2)
      version: 13
      systemPassword: "«hashed-system-password»"
      buildScans:
        keepDays: 30
      email:
        administratorAddress: develocity-adminstrator@example.com
        fromAddress: develocity@example.com
        smtpServer: smtp.example.com:587
        sslProtocol: startTls
        authentication:
          type: login
          username: develocity-adminstrator@example.com
          password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
```

1. The encryption key used for any secrets in your configuration. In this example, the password for email authentication is encrypted. Not required if the configuration does not contain any encrypted passwords. Note that the systemPassword is a hashed value, not an encrypted one, and so does not require an encryption key.
2. The Develocity configuration yaml is put inline underneath this property. Content needs to be indented such that it is all correctly under the global.unattended.configuration property.

Or they can be supplied as `helm` arguments using `--set-file`:

```shell
(helm command) \
  --set-file global.unattended.configuration=path/to/develocity-configuration.yaml \
  --set-file global.unattended.key=path/to/develocity-configuration.key
```

> [!NOTE]
> Develocity configuration that is set in Helm like this will not be reapplied (i.e. overwrite manual changes made in the Admin UI) in subsequent installations unless the contents of the config file(s) has changed.

<a id="proxy-settings"></a>

#### Proxy Settings

HTTP proxy configuration can be specified under the `network` section in the unattended configuration section:

**values.yaml:**

```
global:
  unattended:
    configuration:
      version: 13 (1)
      systemPassword: "«hashed-system-password»" (2)
      network:
        proxy:
          protocol: http (3)
          host: proxy.gradle.com (4)
          port: 8080 (5)
          excludedHosts: (6)
            - some.external
            - '*.internal'
          auth: (7)
            username: proxy_user
            password: "aes256:B0uVHRDhng+PraUI:2bOz71vKTexz0QH5:z7lO+1wOC/tA3izLAwV0BXMugg=="
```

1. The version of the unattended config. See the Administration Manual.
2. The hashed system user password. See the Administration Manual.
3. The protocol used to connect to the proxy. Note that this is not the protocol used to connect to the destination/target addresses. Supported values are http and https, if no value is provided http will be used as the default protocol.
4. HTTP proxy hostname.
5. HTTP proxy port, if no value is provided 80 will be used ad the default port.
6. A comma-delimited list that controls what hosts shouldn’t be proxied. The list can contain individual host names as well as domain patterns (for example, '*.internal') which match all hosts for a particular domain. Any requests sent to these hosts will be sent directly rather than being sent through the HTTP proxy.
7. A username and password used to authenticate with the HTTP Proxy.

<a id="object_storage_for_build_scans"></a>

#### Objects Storage for Build Scans

To configure Develocity to store incoming Build Scan data using your object storage service bucket or container, add the following to your Helm values file:

**values.yaml:**

```
global:
  unattended:
    configuration:
      version: 13 (1)
      systemPassword: "«hashed-system-password»" (2)
      buildScans:
        incomingStorageType: objectStorage

enterprise:
  resources:
    requests:
      memory: 8Gi (3)
    limits:
      memory: 8Gi (3)

objectStorage: (4)
  type: s3
  s3:
    bucket: develocity-application-data
    region: aws-region
    credentials:
      type: irsa
      #...
    monitoring:
      bucket: develocity-monitoring-data
      region: aws-region
      credentials:
        type: irsa
        #...
```

1. The version of the unattended configuration. See the Administration Manual.
2. Your hashed system password. See the Administration Manual.
3. If you have already set a custom value here for memory limits and requests, increase it by 2Gi.
4. The object storage stanza you created in 7. Object Storage Configuration. If you set incomingStoragetype to objectStorage, then you must configure an object storage service with this stanza in values.yaml for your Develocity instance.

This example uses S3 with a credential type of IRSA, but your object storage configuration may be different.

<a id="helm_config_bazel_cache_client"></a>

### 9. Using an external Bazel cache

If you want to use Build Scans for your Bazel builds while using a [remote cache](https://docs.gradle.com/develocity/bazel/bazel-config/) other than the one built into Develocity, you will need to configure the necessary details. Note that your remote cache must expose a GRPC endpoint for Develocity to be able to speak to it.

The only mandatory value is the host and port of your external cache:

**values.yaml:**

```
enterprise:
  bazel:
    remoteCacheConnection:
      url: grpc{s}://<hostname>:<port>
```

If your external cache allows anonymous reads, this is the only value you need. Otherwise, see [the section on authentication](#helm_config_bazel_cache_client_auth).

<a id="helm_config_bazel_cache_client_tls"></a>

#### Trusting a server certificate

See the section on [Untrusted SSL certificates](#untrusted_ssl_certificates).

<a id="helm_config_bazel_cache_client_auth"></a>

#### Authenticating to an external Bazel cache

Any credentials you provide must allow a user to **read** from the cache.

The following authentication methods are currently supported:

<a id="helm_config_bazel_cache_client_auth_bearer"></a>

##### Bearer token authentication

In this authentication method, an external token will be passed to the server in the Authorization header prefixed by "Bearer" - `Bearer <token>`. The configuration for this scenario should look like this:

**values.yaml:**

```
enterprise:
  bazel:
    remoteCacheConnection:
      url: grpc{s}://<hostname>:<port>
      authType: bearerToken
      auth:
        bearerToken:
          token: <TOKEN>
```

<a id="helm_config_bazel_cache_client_auth_tls"></a>

##### TLS client authentication

In this authentication method, a client certificate + key will be used to authenticate to the cache. Please note that the certificate and key must be separate values and in [PEM format](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail). You can provide these values directly, in which case the configuration looks like this:

**values.yaml:**

```
enterprise:
  bazel:
    remoteCacheConnection:
      url: grpc{s}://<hostname>:<port>
      authType: tls
      auth:
        tls:
          cert: |-
            <PEM_FORMATTED_CERT>
          key: |-
            <PEM_FORMATTED_KEY>
```

If you don’t want to include these values in your YAML file, you may create a [TLS Secret](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) in your cluster **in the same namespace where you are installing Develocity** and then pass in the name of that secret:

**values.yaml:**

```
enterprise:
  bazel:
    remoteCacheConnection:
      url: grpc{s}://<hostname>:<port>
      authType: tls
      auth:
        tls:
          secretName: <SECRET_NAME>
```

<a id="airgap"></a>

### 10. Airgap Installations

Develocity can be run on hosts without internet connectivity, referred to as an _airgap_ installation.

<a id="airgap-configuration"></a>

#### Airgap Configuration

In an airgap installation, Helm is configured so that no attempt is made to pull images from the outside world with the values below:

**values.yaml:**

```
global:
  image:
    imagePullPolicy: Never
```

<a id="11-access-control-policies"></a>

### 11. Access Control policies

Develocity will use a set of access control policies that are secure by default. The settings can be customized to better match your organization’s policies.

<a id="access-keys-max-lifespan"></a>

#### Access Keys Max Lifespan

Develocity, by default, requires access keys to have a finite lifespan. The maximum allowed lifespan can be adjusted, or this policy can be disabled entirely.

**values.yaml:**

```
accessControl:
  accessKeys:
    maxLifespan:
      enabled: true (1)
      duration: "P365D" (2)
```

1. Whether the maximum access key lifespan policy should be enabled; default true
2. The maximum access key lifespan to allow when the policy is enabled; ISO 8601 duration with default of "P365D" (365 days)

If the maximum lifespan policy for access keys is **enabled**, all access keys must have an expiration date no greater than the current date plus the maximum lifespan duration. This is applied automatically to newly created access keys. Any non-compliant access keys are brought into compliance on startup by applying the maximum allowed expiration date.

If the maximum lifespan policy for access keys is **disabled**, _newly created_ access keys will not be assigned an expiration date. Even if the maximum lifespan policy is **disabled**, existing access key expiration dates will be retained and enforced.

Your `values.yaml` file is complete. You can return to the installation manual.

<a id="changing_configuration_values"></a>

## Changing Configuration Values

You can also specify configuration values using the `--set` or `--set-file` parameters. However, these options are **not saved**, and you must specify all the options **again** whenever you make changes.

First, you need to specify the currently installed Develocity version to change configuration values without updating the Develocity version.

> [!IMPORTANT]
> It’s important to specify the Develocity version, because if you don’t, you may accidentally install a newer version and initiate an upgrade rather than merely a configuration change.  
> **Such accidental upgrades may be irreversible.**

**Use case:** You have an existing configuration and want to update the license value and disable Ingress SSL, but keep the rest of the configuration.

Check the deployed Develocity version:

```shell
helm history --namespace develocity ge --max 1
```

To apply new configuration values to a Helm-managed online installation, run:

```shell
helm upgrade \
  --namespace develocity \
  ge gradle/gradle-enterprise \
  --version «deployed-version» \(1)
  --reuse-values \
  --set-file global.license.file=./develocity.license \(2)
  --set ingress.ssl.enabled=false \(3)
```

1. «deployed-version» is the deployed version of Develocity.
2. The path to the new license file.
3. Disable the Ingress SSL.

Or for a Helm-managed airgap installation:

```shell
helm upgrade \
  --namespace develocity \
  ge gradle-enterprise-«deployed-version».tgz \(1)
  --version «deployed-version» \
  --reuse-values \
  --set-file global.license.file=./develocity.license \(2)
  --set ingress.ssl.enabled=false \(3)
```

1. «deployed-version» is the deployed version of Develocity.
2. The path to the new license file.
3. Disable the Ingress SSL.

> [!WARNING]
> Running helm upgrade with --reset-values will cause any previous values to be lost. Consult our upgrade documentation to learn more about it.

* * *

If you have any questions or need any assistance don’t hesitate to get in touch with the Develocity support team or your customer success representative.

<a id="helm_config_background_processor"></a>

## Appendix A: Background Processing Configuration

Depending on the volume and frequency of your builds, background tasks for newly uploaded Build Scans can require a significant amount of CPU and memory. Moreover, some upgrades or configuration changes of Develocity require reprocessing existing builds to extract new data. For example, when enabling Predictive Test Selection for the first time all existing builds will be processed to collect change and test execution history.

Therefore, background work can optionally be processed in a separate Pod that can be scaled independently of other components to avoid any adverse effect on the Develocity frontend. You should only enable background processing after being prompted by the Develocity support team.

> [!NOTE]
> Enabling the background processor will increase hardware resource requirements. It also increases required number of database connections when a user managed database is used (80 connections ✖️ background processor replica count).

**values.yaml:**

```
enterpriseBackgroundProcessor:
  enabled: true
  scaling:
    replicas: 2
```

<a id="helm_chart_downloads"></a>

## Appendix B: Downloads

<a id="values_yaml_download"></a>

### Example Helm Values File

You can download and verify the example Helm values file with the following commands:

```shell
curl -L -o example.values.yaml https://docs.gradle.com/downloads/gradle-enterprise-values/gradle-enterprise-values-2025.3.yaml
```

```shell
curl -L -o example.values.yaml.sha256 https://docs.gradle.com/downloads/gradle-enterprise-values/gradle-enterprise-values-2025.3.yaml.sha256
```

```shell
echo "$(cat example.values.yaml.sha256)  example.values.yaml" | sha256sum -c -
```

A direct download is available below:

*   [Download Example Values File](https://docs.gradle.com/downloads/gradle-enterprise-values/gradle-enterprise-values-2025.3.yaml)
    
*   [Download Example Values File SHA256 Checksum](https://docs.gradle.com/downloads/gradle-enterprise-values/gradle-enterprise-values-2025.3.yaml.asc.sha256)
    
*   [Download Example Values File PGP Signature](https://docs.gradle.com/downloads/gradle-enterprise-values/gradle-enterprise-values-2025.3.yaml.asc)
    
*   [Download Example Values File PGP Signature SHA256 Checksum](https://docs.gradle.com/downloads/gradle-enterprise-values/gradle-enterprise-values-2025.3.yaml.asc.sha256)
    

> [!NOTE]
> Older versions example values file can be found in the legacy Legacy Documentation. Refer to the Kubernetes Helm Chart Configuration Guide of the Develocity version you are looking for.

<a id="database_setup_download"></a>

### Database Setup Scripts

*   [Download Database Setup Scripts](https://docs.gradle.com/downloads/gradle-enterprise-database-setup-zip/gradle-enterprise-database-setup-zip-2025.3.zip)
    
*   [Download SHA256 Checksum](https://docs.gradle.com/downloads/gradle-enterprise-database-setup-zip/gradle-enterprise-database-setup-zip-2025.3.zip.sha256)
    

> [!NOTE]
> Older versions (prior of Develocity 2025.3) of the Database Setup Scripts can be found in the legacy Develocity User-Managed Database Migration Guide.