Choosing an Installation Method

Last updated: October 21, 2026

You can deploy Sisense on Linux in three ways: with the sisense.sh installer, with the Provisioner, or by installing the Sisense Helm chart directly. Use this page to choose a method before you start. The following reference topics apply to every method:

• Privileges and Permissions for Self-Deployment: where sudo is and is not needed, the Kubernetes RBAC each method needs, and Pod Security Standards.

• Storage Requirements for Self-Deployment: the ReadWriteMany and ReadWriteOnce storage Sisense needs, and the StorageClasses each method creates or expects.

Which Method Should I Use?

Read the rows in order. The first row that matches your situation is the recommended method.

Your Situation	Recommended Method
You do not have a Kubernetes cluster, and you want Sisense to build one on your Linux servers (a single node or multiple nodes).	sisense.sh with single_config.yaml (single node) or cluster_config.yaml (multiple nodes). See Installing Sisense on Linux.
You have an existing cluster that is shared with other workloads, or that enforces admission policies (for example, Pod Security Admission, Gatekeeper, Kyverno, or Azure Policy), or your security team must review every RBAC object before installation.	Helm. See Installing Sisense with Helm on an Existing Cluster (Multinode/Cloud).
You have an existing cluster, and no Linux machine can be given passwordless sudo, or your operators work from Windows or macOS.	Helm or the Provisioner. Both need only kubectl and helm.
You have an existing cluster that is dedicated to Sisense, you want the installation to set up storage drivers, monitoring, logging, and the gateway for you, and you accept that the installation Job runs with cluster-admin rights.	Provisioner. See Installing Sisense using Provisioner and Helm.
You have an existing Amazon EKS, Azure AKS, Google GKE, or OpenShift cluster, a Linux machine where you can use passwordless sudo, and you prefer the guided installer.	sisense.sh with cloud_config.yaml or openshift_config.yaml. See: Deploying Sisense on Amazon EKS Deploying Sisense on Azure Kubernetes Service Deploying Sisense on Google GKE Installing Sisense on OpenShift
You already run your own monitoring stack, gateway or ingress controller, and storage (CSI) drivers, and you want to install only Sisense.	Helm. See Installing Sisense with Helm on an Existing Cluster (Multinode/Cloud).
You expose Sisense through an ingress controller other than NGINX Gateway Fabric, the AWS Load Balancer Controller, or a cloud load balancer (for example, Azure Application Gateway).	The sisense.sh installer does not support other ingress controllers. With Helm, you can attach the Sisense HTTPRoute to a Gateway API Gateway that you manage (api-gateway.httpRoute.* values). See Helm below.

About Each Method

sisense.sh Installer

The sisense.sh installer runs on a Linux machine and is configured with a YAML file:

• On your own Linux servers (single_config.yaml or cluster_config.yaml): The installer connects to each server over SSH, prepares the operating system, installs an RKE2 Kubernetes cluster, and then installs storage, NGINX Gateway Fabric, and Sisense.

• On an existing EKS, AKS, GKE, or OpenShift cluster (cloud_config.yaml or openshift_config.yaml): The installer works only through the Kubernetes API with your kubectl access. It does not connect to or run anything on the cluster nodes.

The installer writes its log to sisense-installer.log in the directory from which you run sisense.sh.

Provisioner

You install the Provisioner Helm chart with a single helm install command from any computer that has kubectl and helm. The chart starts a Job inside the cluster that runs the Sisense installer there: it installs the storage drivers and StorageClasses you select, installs Sisense, and runs the post-installation steps. The Job's ServiceAccount is bound to cluster-admin. No Linux user, SSH key, or sudo is needed. See Installing Sisense using Provisioner and Helm.

Helm

You install the Sisense Helm chart directly with helm, from any computer that has kubectl and helm. No Linux user, SSH key, or sudo is needed. You provide what the installer otherwise sets up: the namespace, the node labels, the ReadWriteMany and ReadWriteOnce StorageClasses, the way users reach Sisense, and (optionally) monitoring. This method also supports a namespace-scoped installation that creates no cluster-wide RBAC objects.

• For an existing multi-node or cloud cluster, see Installing Sisense with Helm on an Existing Cluster (Multinode/Cloud).

• For a single node, see Manually Installing Sisense Helm Chart - Single Node.

To expose Sisense through a Gateway API implementation that you manage, enable api-gateway.httpRoute.enabled and set api-gateway.httpRoute.gatewayName and api-gateway.httpRoute.gatewayNamespace to your Gateway. The chart creates the HTTPRoute only; it does not create the Gateway. global.applicationDnsName must be set to a host name (not an IP address).

Privileges at a Glance

The install machine is the computer where you run the installation command. The Kubernetes nodes are the servers that run the Sisense pods.

Method	Install Machine	Kubernetes Nodes	SSH to Nodes	Kubernetes Identity
Helm	Any computer with kubectl and helm. No Linux user or sudo.	No privileges	No	cluster-admin, or a namespace-scoped installation
Provisioner	Any computer with kubectl and helm. No Linux user or sudo.	No privileges	No	cluster-admin (the installation Job's ServiceAccount is bound to cluster-admin)
sisense.sh on EKS, AKS, GKE, or OpenShift	Linux. A regular (non-root) user with passwordless sudo for the duration of the installation. You can remove the passwordless rule afterwards.	No privileges. The installer does not run anything on the nodes.	No	cluster-admin through your kubeconfig
sisense.sh on your own Linux servers (RKE2)	Linux. A regular (non-root) user with passwordless sudo.	The same user with passwordless sudo on every server. The installer prepares the operating system and installs RKE2 on each server.	Yes	Created by the installer

For details, see Privileges and Permissions for Self-Deployment.

Questions to Answer Before Deployment

Answer these questions with your infrastructure and security teams before you start. The answers determine the method and the values you need.

• Do you already have a Kubernetes cluster, or should Sisense build one on your Linux servers?

• Is the cluster dedicated to Sisense, or shared with other workloads?

• Who manages the cluster: a cloud provider (Amazon EKS, Azure AKS, Google GKE), your own team (for example, OpenShift), or Sisense (an RKE2 cluster built by the installer)?

• Which Kubernetes version does the cluster run?

• How will users reach Sisense: NGINX Gateway Fabric, another Gateway API implementation, an ingress controller, a cloud load balancer, or a NodePort? Do you need HTTPS, and where is TLS terminated?

• Which ReadWriteMany (RWX) and ReadWriteOnce (RWO) StorageClasses are available, and which mount options do they use? See Storage Requirements for Self-Deployment.

• Can Sisense create cluster-wide RBAC objects (ClusterRoles), or must the installation stay within one namespace?

• Is Pod Security Admission or a policy engine (for example, Gatekeeper, Kyverno, or Azure Policy) enforced in the cluster?

• Which operating system do the people who run the installation use, and can any Linux machine be given passwordless sudo?

• Do you already run your own monitoring (for example, Prometheus and Grafana) and logging?

• Is the environment air-gapped, or must images come from a private registry?