# Choosing an Installation Method

> Compare the Sisense self-deployment methods (the sisense.sh installer, the Provisioner, and the Sisense Helm chart) and choose the one that fits your cluster, privileges, and storage.

*Source: https://docs.sisense.com/main/SisenseLinux/choosing-an-installation-method.htm*

---

Last updated: October 21, 2026

|  |  |
| --- | --- |
| [Tier](https://www.sisense.com/pricing/#pricing) | [Deployment](https://docs.sisense.com/main/SisenseLinux/introduction-to-sisense-cloud-managed-services.md#ComparisonofManagedCloudandSelfHosted) |
| Enterprise | On-Prem |

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](https://docs.sisense.com/main/SisenseLinux/self-deployment-privileges-and-permissions.md): where `sudo` is and is not needed, the Kubernetes RBAC each method needs, and Pod Security Standards.
- [Storage Requirements for Self-Deployment](https://docs.sisense.com/main/SisenseLinux/self-deployment-storage-requirements.md): 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](https://docs.sisense.com/main/SisenseLinux/installing-sisense-on-linux.md). |
| 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)](https://docs.sisense.com/main/SisenseLinux/installing-sisense-helm-multinode.md). |
| 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](https://docs.sisense.com/main/SisenseLinux/installing-sisense-using-provisioner-and-helm.md). |
| 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](https://docs.sisense.com/main/SisenseLinux/deploying-sisense-on-amazon-eks.md) - [Deploying Sisense on Azure Kubernetes Service](https://docs.sisense.com/main/SisenseLinux/deploying-sisense-on-azure-kubernetes-service.md) - [Deploying Sisense on Google GKE](https://docs.sisense.com/main/SisenseLinux/deploying-sisense-on-google-gke.md) - [Installing Sisense on OpenShift](https://docs.sisense.com/main/SisenseLinux/installing-sisense-on-openshift.md) |
| 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)](https://docs.sisense.com/main/SisenseLinux/installing-sisense-helm-multinode.md). |
| 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](#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](https://docs.sisense.com/main/SisenseLinux/installing-sisense-using-provisioner-and-helm.md).

### 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)](https://docs.sisense.com/main/SisenseLinux/installing-sisense-helm-multinode.md).
- For a single node, see [Manually Installing Sisense Helm Chart - Single Node](https://docs.sisense.com/main/SisenseLinux/installing-sisense-helm-singlenode.md).

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).

**Note:**

When `api-gateway.httpRoute.enabled` is `true`, the chart also creates NGINX Gateway Fabric resources by default (`api-gateway.clientSettingsPolicy`, `api-gateway.upstreamSettingsPolicy`, and `api-gateway.snippetsFilter`), which require the NGINX Gateway Fabric CRDs. If your `Gateway` is not NGINX Gateway Fabric, set the `enabled` value of each of these three to `false`.

## 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](https://docs.sisense.com/main/SisenseLinux/self-deployment-privileges-and-permissions.md).

## 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](https://docs.sisense.com/main/SisenseLinux/self-deployment-storage-requirements.md).
- 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?