Installing Sisense using Provisioner and Helm

Last updated: October 21, 2026

Provisioner provides an elegant and efficient solution for installing, upgrading and/or maintaining Sisense on an existing Kubernetes cluster. The Provisioner application deploys Sisense using a single Helm Chart, the simplest way of getting started with our applications on Kubernetes.

The Provisioner chart creates one Kubernetes Job. The Job runs the Sisense installer inside a pod in your cluster and installs the Sisense Helm chart and the add-ons you select (storage drivers, monitoring, logging, NGINX Gateway Fabric, and the cluster autoscaler). Because everything runs inside the cluster, no Linux user, SSH key, or sudo is needed anywhere. Run helm from any computer that has kubectl, helm, and cluster-admin access to the cluster.

Introduction

This single Helm Chart bootstraps the Sisense installation on an existing Kubernetes cluster, including monitoring and logging stacks.

Chart Details

The Helm Chart provides the following deployments on an existing Kubernetes cluster:

• Sisense application
• Prometheus and Grafana (kube-prometheus-stack), when monitoring.internal is true
• Logging solution (fluent-bit)
• Storage drivers for the shared ReadWriteMany storage (Amazon FSx for Lustre, Amazon EFS, NFS) and the AWS EBS CSI driver
• Kubernetes Cluster Autoscaler for Amazon EKS
• NGINX Gateway Fabric for terminating SSL for Sisense

Prerequisites

• Supported Kubernetes Version
• A current Helm 3 release on the computer from which you run helm. See Preparation.
• RBAC cluster-admin privileges. The Provisioner binds its service account to the cluster-admin ClusterRole, so the identity that runs helm install must be able to create that ClusterRoleBinding. No Linux user, SSH key, or sudo is required. For details, see Privileges and Permissions for Self-Deployment.
• Storage for a multi-node or managed cluster: either storage that the Provisioner can set up (persistence.storageType), or existing ReadWriteMany (RWX) and ReadWriteOnce (RWO) StorageClasses. See Storage.
• Each node that Sisense uses must report a pod capacity of at least 58 (kubectl get node <node-name> -o jsonpath='{.status.capacity.pods}'). The installer checks this and stops if a node has a lower capacity.
• Access to the Sisense images in quay.io/sisense_release, or to your own registry (docker.registry and pullSecretsName).
• When persistence.enabled is false (the default), the Provisioner Job and Sisense use hostPath volumes, so the namespace must allow hostPath volumes (Pod Security level privileged).

Node Labels

The Sisense Helm chart schedules its pods only on nodes that carry the label node-<namespace>-Application=true (for example, node-sisense-Application=true). By default, the Provisioner labels the nodes listed in labeling.kubernetesNodes, or all nodes when labeling.labelAllNodes is true. Labels applied this way are lost when a node is replaced (for example, by an autoscaler).

To keep the labels, apply them to your node groups or node pools and pass skip_labeling: true through installer-values. On AKS, this is the recommended setup, because labels that AKS manages at the node-pool level cannot be changed with kubectl. See Autoscaling and Linux.

SSL Prerequisites

Setting tlsSecretName enables SSL. The installer then deploys NGINX Gateway Fabric (NGF) to terminate TLS. NGF requires Kubernetes 1.32 or later. Before installing Provisioner, perform the following steps:

1. Create the TLS secret in the namespace of the NGF Gateway. By default, this is the default namespace:

   Copy

   kubectl create secret tls <tlsSecretName> \
     --namespace default \
     --key <ssl_key_filename> \
     --cert <ssl_cer_filename>

   To use a different namespace for NGF, create that namespace, create the TLS secret in it, and set the following value in the Provisioner Helm chart installation:

   Copy

   ERROR: Invalid Code Highlighting Language

   The installer checks that the secret exists in this namespace and stops if it does not.

2. On the Provisioner, set tlsSecretName to the name of the secret from the previous step, and set applicationDnsName to the Common Name of the certificate.

Preparation

Install a current Helm 3 release on a computer with access to the cluster. See Installing Helm in the Helm documentation.

Storage

When persistence.enabled is true, Sisense uses the following volumes:

The shared volume must be writable by the UID and GID that Sisense runs as (securityContext.runAsUser and runAsGroup, 1000 by default).

Use exactly one of the following storage patterns. If you set both, or neither, the Provisioner Job stops with an error:

• Let the Provisioner set up the storage: set persistence.storageType (fsx, efs, or nfs) and the related persistence.* values.

• Use your own StorageClasses: set both persistence.rwxScName and persistence.rwoScName. For Azure Files, create the RWX StorageClass with the mount options described in Deploying Sisense on AKS with Azure Files Premium.

For more information, see Storage Requirements for Self-Deployment.

Parameters

This section lists the Provisioner's chart configurable parameters.

To install Sisense using Provisioner on an existing Kubernetes:

The commands below use the release name prov-sisense and the namespace in $NAMESPACE. Use the same release name and namespace for all later upgrade and uninstall commands.

1. Download the Provisioner Helm Chart supported version (Replace SISENSE_VERSION with Sisense external version):
   Copy

   wget https://data.sisense.com/linux/provisioner-<SISENSE_VERSION>.tgz

2. Run the following to export the Helm chart's default configuration/values file:
   Copy

   helm show values provisioner-<SISENSE_VERSION>.tgz > values.yaml

3. Edit Sisense Provisioner configuration for your setup:

   Copy

   vim values.yaml

   For example, a minimal values.yaml for a managed cluster with existing StorageClasses:

   Copy

   ERROR: Invalid Code Highlighting Language
4. Install or upgrade Sisense Provisioner Helm Chart:
   Copy

   helm upgrade prov-sisense ./provisioner-<SISENSE_VERSION>.tgz \
     --namespace $NAMESPACE \
     --create-namespace \
     --install \
     -f values.yaml

   Each helm install or helm upgrade creates a new Provisioner Job. Completed Jobs are not deleted automatically; you can delete them when they are no longer needed.

5. Observe the Sisense Provisioner provisioning process via its logs:
   Copy

   kubectl logs -f --namespace $NAMESPACE -l app.kubernetes.io/name=provisioner

6. Once the installation is complete, some Sisense pods will remain in the Init state until the license activation. To activate the license, navigate to the Sisense web application URL (without extra paths such as /app/account/login) in your browser and enter your license credentials.

Using the Extra-Values Feature to Override Extended Configuration

You can override any values within Sisense Helm Charts by using the Extra-Values Feature.
Select a target Helm Chart and create your own override values file for each of the following supported Helm Charts:

• installer-values (installer settings; see the Parameters table)
• sisense (the Sisense Helm chart)
• kube-prometheus-stack
• logging
• nginx-gateway-fabric
• alb-controller (used only when alb_controller.enabled is true in installer-values, on Amazon EKS)
• cluster-autoscaler
• aws-ebs-csi
• efs

Run the following command to install the selected Helm Chart:

helm upgrade prov-sisense ./provisioner-<SISENSE_VERSION>.tgz \
  --namespace $NAMESPACE \
  --create-namespace \
  --install \
  -f values.yaml \
  --set-file <TARGET-VALUES-NAME-FROM-THE-LIST>=<YOUR-OWN-VALUES-FILE-PATH> \
  --set-file <TARGET-VALUES-NAME-FROM-THE-LIST>=<YOUR-OWN-VALUES-FILE-PATH>

For example, sisense-override-values.yml for overriding the "sisense" major Helm Chart values:

Run the following command for the above example:

helm upgrade prov-sisense ./provisioner-<SISENSE_VERSION>.tgz \
  --namespace $NAMESPACE \
  --create-namespace \
  --install \
  -f values.yaml \
  --set-file sisense=./sisense-override-values.yml

Adding Custom Labels to Sisense Pods

Sisense also provides the ability to add custom labels to each type of Sisense pods (Sisense service).

To add custom labels to Sisense pod types:

1. Create a YAML file for the custom labels.
2. Enter only the Sisense services whose pod labels you want to change, each with its new custom labels. Use the service names as they appear in the Sisense Helm chart (for example, api-gateway, management, query, build), in the following format:
   
   Copy

   ERROR: Invalid Code Highlighting Language
3. From the directory where the YAML file resides, run the following command:
   
   Copy

   helm upgrade prov-sisense ./provisioner-<SISENSE_VERSION>.tgz \
     --namespace $NAMESPACE \
     --create-namespace \
     --install \
     -f values.yaml \
     --set-file sisense=./<sisense-custom-labels>.yml

Upgrading Sisense using the Existing Provisioner Installation

Download the Provisioner chart of the new version, and run the following command with the same values file you installed with (updated as needed). The Provisioner sets the installer's update flag automatically on every upgrade.

helm upgrade prov-sisense ./provisioner-<NEW_SISENSE_VERSION>.tgz \
  --namespace $NAMESPACE \
  -f values.yaml

Uninstalling Sisense

Run the following command to uninstall Sisense:

helm upgrade prov-sisense ./provisioner-<SISENSE_VERSION>.tgz \
  --set uninstall.namespacedResources=true \
  --set uninstall.clusterResources=false \
  --set uninstall.removeUserData=true \
  --namespace $NAMESPACE \
  --reuse-values \
  --force \
  --install

Uninstalling the Provisioner Chart

Run the following command to uninstall the Provisioner Chart. This removes only the Provisioner's own objects (service account, role binding, ConfigMaps, and Jobs). It does not uninstall Sisense; to remove Sisense, first follow Uninstalling Sisense.

helm uninstall prov-sisense -n $NAMESPACE