Example values.yaml files

This directory contains example value overrides for the Apache Pulsar Helm chart. Each file is a small, focused override that demonstrates one deployment scenario. They are not complete production configurations — start from the chart values.yaml and layer one or more of these examples on top.

Finding all available values

These examples only set the keys that differ from the defaults. The full list of configurable values, with their defaults and inline documentation, is the chart values.yaml. You can view it in any of these ways:

# from the published chart (after `helm repo add apachepulsar https://pulsar.apache.org/charts`)
helm show values apachepulsar/pulsar
# pin a specific chart version with --version, e.g.
helm show values apachepulsar/pulsar --version 4.6.1

# or from a local checkout
helm show values charts/pulsar

The latest version is also browsable on the master branch: https://github.com/apache/pulsar-helm-chart/blob/master/charts/pulsar/values.yaml

How to use

Pass an example to helm install/helm upgrade with -f:

helm install pulsar apachepulsar/pulsar -f examples/values-one-node.yaml

Examples are composable — pass -f multiple times and later files win:

# A single-node cluster secured with self-signed TLS and JWT auth
helm install pulsar apachepulsar/pulsar \
  -f examples/values-one-node.yaml \
  -f examples/values-tls-selfsigned.yaml \
  -f examples/values-jwt-symmetric.yaml

You can render the resulting manifests without installing anything to review what an example produces:

helm template pulsar charts/pulsar -f examples/values-one-node.yaml

Merging examples into a single file

Repeated -f flags are usually all you need, but if you want a single merged values file (for review, for helm template, or to hand to other tooling) you can use merge-values.sh. It deep-merges the given files (later files win, the same precedence as -f) and strips the license header:

# from the examples/ directory; requires yq (https://github.com/mikefarah/yq)
./merge-values.sh values-jwt-asymmetric.yaml values-oxia.yaml values-one-node.yaml > merged-values.yaml
helm install pulsar apachepulsar/pulsar -f merged-values.yaml

Pass --download/-d to fetch the files by name from the examples/ directory on the master branch (via curl) instead of reading them from a local checkout:

./merge-values.sh -d values-jwt-asymmetric.yaml values-oxia.yaml values-one-node.yaml > merged-values.yaml

Combined with -d, the script itself can be fetched with curl, so no checkout is needed at all:

# download the script and make it executable
curl -fsSL https://raw.githubusercontent.com/apache/pulsar-helm-chart/refs/heads/master/examples/merge-values.sh -o merge-values.sh
chmod +x merge-values.sh

# -d downloads the named values files from master and merges them to stdout
./merge-values.sh -d values-jwt-symmetric.yaml values-oxia.yaml values-one-node.yaml > merged-values.yaml
helm install pulsar apachepulsar/pulsar -f merged-values.yaml

A note on persistence

By default the chart deploys stateful components (ZooKeeper, BookKeeper) with PersistentVolumeClaims so that data survives pod restarts. Most examples keep this default. The one deliberate exception is values-no-persistence.yaml, which uses emptyDir volumes and therefore loses all data when a pod restarts or the cluster is shut down — use it only for ephemeral testing/CI.

A note on the management UI

These examples use Dekaf (components.dekaf: true) as the web UI rather than the legacy pulsar-manager. Dekaf connects directly to the broker, so it is only enabled in examples that deploy a broker.

Examples by category

Cluster size and topology

Metadata store

Functions

Pulsar Functions run in a worker that is embedded in the broker (components.functions: true). See values-functions-fs-storage.yaml for a ready-to-merge example (suitable for Oxia).

Package storage (FileSystemPackagesStorage)

The function worker stores uploaded packages (pulsar-admin functions create --jar ...) via the broker's Packages Management Service. Its default BookKeeperPackagesStorage requires ZooKeeper, so on Oxia you must enable broker-hosted FileSystemPackagesStorage (broker.packageManagement.enabled: true + broker.packageManagement.fileSystemStorage.enabled: true) — see values-functions-fs-storage.yaml.

For the full configuration — choosing a volume (single broker vs. a ReadWriteMany shared filesystem with GKE / EKS / AKS CSI drivers) and creating the StorageClass / PersistentVolume / PersistentVolumeClaim from raw YAML — see the Pulsar Functions package storage section in the top-level README.

Functions

By default the Pulsar Functions worker runs embedded in the broker (components.functions: true). Alternatively it can run as its own standalone component (components.function_worker: true), which disables the embedded worker.

Running the function worker separately separates its workload from the brokers, which is useful for:

• Operational reasons — scale, schedule and manage the function worker independently of the brokers.
• Security reasons — a reduced attack surface. Functions run user code, so isolating the worker means a compromise of the function worker (for example a remote code execution) does not directly impact the brokers.

The standalone worker is “broker-attached” (it connects to the broker and keeps function metadata in system topics). Function instances run with the Kubernetes runtime (one pod per instance).

Storage

Security (TLS and authentication)

Monitoring

Other