Self-Hosted Standalone Installation Guide

This guide covers the installation of Develocity into a single host.

Develocity is a Kubernetes-based application, distributed as a Helm chart. Helm is a package manager for Kubernetes applications. In a standalone installation, you install the K3s lightweight Kubernetes distribution onto the host. You then use Helm to install Develocity into that K3s instance. Helm manages all Develocity components.

For instructions on installing Develocity on a host without public network connectivity, see Airgap Installation.

Prerequisites

Develocity License

If you have purchased Develocity or started a trial, you should already have a license file called develocity.license. Otherwise, you can request a Develocity trial license.

Host Requirements

Operating System

Develocity is expected to work on most modern Linux systems (x86_64 only). The operating system requirements are mainly the same as those for the used K3s Kubernetes distribution.

K3s

K3s needs several ports to be accessible from the host.

Protocol Port

TCP

6443

TCP

10250

UDP

8472

While these ports don’t need to be accessible from outside the host machine, K3s may access them using a different network interface or non-localhost IP.

RHEL / CentOS Stream

On Red Hat Enterprise Linux and CentOS Stream hosts, if nm-cloud-setup is enabled, you must disable the service and reboot the system.

🔍 Disable nm-cloud-setup.service

First, check if the nm-cloud-setup.service is enabled on your system:

sudo systemctl is-enabled nm-cloud-setup.service

If the service is disabled, the command returns disabled, otherwise it returns enabled.
If nm-cloud-setup is enabled, disable it with the following command:

sudo systemctl disable nm-cloud-setup.service nm-cloud-setup.timer

Reboot the system:

sudo systemctl reboot

Disabling firewalld is recommended, too. If you can’t, ensure that the ports mentioned above are accessible and enable IP address masquerading. This can be done with the following command:

firewall-cmd --add-masquerade --permanent

For more details on IP address masquerading, see the Red Hat documentation.
For more details on the RHEL / CentOS requirements, see the K3s documentation.

CPU & Memory

The minimum installation requirements are:

  • 10 CPUs (x86_64 architecture)

  • 24 GiB of memory

Database

By default, Develocity stores its data in a PostgreSQL database that runs as part of the application itself. The data lives in a directory mounted on the host machine.

Develocity installations have two database options:

  1. An embedded database, which depends heavily on disk performance.

  2. A user-managed database, which can be any PostgreSQL database compatible with versions 15 through 18.

The compatibility matrix lists the supported versions for every Develocity release.

 Using PgBouncer with a user-managed database is not supported.

Storage

In addition to the database, Develocity needs storage capacity for configuration files, logs, Build Cache artifacts, and database backups. To simplify managing disk space, Gradle recommends mounting separate persistent storage volumes for data, logs, and backups.

Capacity

By default, Develocity stores its data under /opt/gradle. You can remount each subdirectory to a separate persistent volume with the global.storage.* Helm values. Develocity recommends a dedicated volume for the installation directory, with at least 10% of the volume’s space free at all times.

Location Helm Value Minimum Size Notes

/opt/gradle

global.storage.directory

Sum of the layers below

This volume hosts multiple storage layers stacked on the same SSD. Size it as the sum of the layers that apply to your configuration:

Layer Default size Present when

Application data and logs

~5 GiB

Always

Co-located Edge node cache

50 GiB (edgeNode.storage.data.capacity)

Always

Embedded object storage (durable Build Cache + monitoring + internal buffer)

75 GiB (sum of objectStorage.embedded.storage.{internalBuffer,buildCache,monitoring}.capacity)

objectStorage.type: embedded (the standalone default; external object storage moves these off this volume)

Embedded database with Build Scan retention

~250 GiB recommended (grows with Build Scan volume × retention)

Embedded database mode (the standalone default)

Requires SSD performance.

/opt/gradle/logs

global.storage.logs.directory

10 GiB

Application logs.

/opt/gradle/backups

global.storage.backup.directory

250 GiB

Database backups. Applicable only when using the embedded database.

/var/lib/rancher/k3s

-

30 GB

K3s runtime. Not performance-sensitive.

The four layers above are independent, so adding capacity to one does not help the others.

  • The durable Build Cache lives inside the embedded object storage row, where the Build Cache target storage size setting governs its size, up to the objectStorage.embedded.storage.buildCache.capacity limit. See Space Management for sizing.

  • The co-located Edge node cache is a separate, ephemeral low-latency cache on this same volume that serves recent artifacts to build agents. Size edgeNode.storage.data.capacity to hold your active working set: the artifacts for the projects your teams are building. The more of that working set the Edge keeps resident, the more requests it serves from the local cache instead of reaching back to peers or durable storage. Size it for the warm-hit performance you want, not to a fixed figure. Going beyond the Build Cache target storage size gains nothing, though. The durable Build Cache holds long-tail retention and is often far larger (terabytes). The Edge cache, by contrast, is ephemeral: it repopulates from peers or durable storage after a restart. A volume larger than the durable Build Cache therefore only wastes capacity.

Sum only the rows that apply to your configuration. With external object storage and an external database, drop both of those rows. With an external database alone, drop the embedded-database row and keep the embedded-object-storage row.

If you produce more than 1 GB of Build Scan data a day, or retain Build Scan data for 30 days or more, provision more storage for the data volume.

If your volumes cannot be expanded later, add disk capacity upfront for future data growth.

Performance

For production workloads, storage volumes should exhibit SSD-class disk performance of at least 3000 IOPS (input/output operations per second). Most NFS based storage or desktop-class, non-SSD disk drives don’t provide this level of performance.

 Disk performance has a significant impact on Develocity performance. Network file systems (such as Amazon EFS) aren’t compatible with Develocity due to their performance characteristics.

Object Storage

Develocity administrators can store Build Scan® data and monitoring data such as metrics in an object storage service, such as Amazon S3, Google Cloud Storage, and Microsoft Azure Blob Storage. This can help performance in high-traffic installations by reducing the load on the database. Object storage services offer performance and cost advantages compared to database storage. If you deploy Develocity to a cloud provider or have an available internal S3-compatible object store, Gradle recommends using object-based storage for your installation. See Build Scan object storage in the Develocity Administration Manual for a description of the benefits and limitations.

Network Connectivity

Develocity requires network connectivity for periodic license validation.

 An installation of Develocity won’t start if it cannot connect to both registry.gradle.com and harbor.gradle.com.

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

Verify that your DNS points to your Develocity instance.

develocity.example.com A 12.34.56.78

You should verify that your DNS record works correctly before installing Develocity by running dig develocity.example.com or ping develocity.example.com in a console window.

For an airgap installation, you need a temporary machine with internet access to download the installation files. Transfer those files from that machine to your Develocity host.

Installation

If you are installing Develocity on a host without public network connectivity, follow the Airgap installation instructions.

Copy Files

Make sure that your Develocity license file is available on your host machine.

Install K3s

Install K3s and make it available to the current user:

curl -sfL https://get.k3s.io | sh -
sudo chown $UID /etc/rancher/k3s/k3s.yaml
mkdir -p "${HOME}/.kube"
ln -sf /etc/rancher/k3s/k3s.yaml "${HOME}/.kube/config"

Verify that you can interact with the K3s cluster:

kubectl get namespace

The expected output should be similar to this:

Output
NAME                STATUS   AGE
default             Active   1h
kube-system         Active   1h
kube-public         Active   1h
kube-node-lease     Active   1h
 For more information on K3s installation, see the K3s Quick-Start Guide and K3s Installation.

Install Helm

Develocity requires Helm version 3.13.x (or later) to install.

It’s recommended to use the latest version available as this will have all known security vulnerabilities addressed. This document describes the maximum version skew supported between Helm and Kubernetes.

 For more information on installing Helm (including alternate installation approaches), see Installing Helm.

Install Helm with the following command:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
 This guide covers installation of the gradle-enterprise-standalone chart. The Self-Hosted Kubernetes Installation Guide covers the gradle-enterprise chart.

Prepare a Helm Values File

Installation options for Develocity are depicted in a Helm values file.

Follow the instructions in the Standalone Helm Chart Configuration Guide and return to this document with a complete values.yaml file.

Install the Helm Chart

Develocity is distributed from the Develocity Helm repository.

Add the Develocity Helm repository to your Helm installation and fetch its contents into the local cache:

helm repo add gradle https://helm.gradle.com/
helm repo update gradle

Verify that the Develocity chart is accessible:

helm search repo gradle-enterprise

This will report the latest versions available for the two Develocity charts:

Output
NAME                                CHART VERSION       APP VERSION         DESCRIPTION
gradle/gradle-enterprise            2026.2.5            2026.2.5            Official Develocity chart for Kubernetes cluster installations
gradle/gradle-enterprise-standalone	2026.2.5            2026.2.5            Official Develocity chart for standalone installations

Install Develocity