This guide can help you install Dash Enterprise on your Kubernetes cluster.
Dash Enterprise runs in a single namespace. It operates safely in Kubernetes clusters running applications other than Dash Enterprise, as well as other instances of Dash Enterprise.
Installing Dash Enterprise involves using a Plotly-provided Helm chart.
Here are the infrastructure pieces that you’ll need before you can install Dash Enterprise.
A (Optional) A private container registry to host the Dash Enterprise images. You’ll need a private container registry for the Dash Enterprise images if you’re unable to install directly from the Helm chart registry (oci://registry.replicated.com/dash-enterprise). This private container registry has the following requirements:Must support “create on push”. This notably excludes ECR, which requires each image destination to exist before pushing.
B (Optional) A private Python package index. By default, public Python packages installed with pip are fetched from pypi.org. If the Kubernetes cluster in which you’re installing Dash Enterprise doesn’t have network access to pypi.org, you’ll need to provide a private Python package index in order for the Dash apps deployed to Dash Enterprise to be able to install dependencies. A common strategy is to create a mirror of pypi.org.
Similarly, if any Dash apps depend on APT packages, you’ll need to prepare a custom APT repository.
This private Python package index and/or custom APT repository must have a TLS/SSL certificate from a globally trusted certificate authority.
C A Kubernetes cluster. This cluster has the following requirements:StorageClass defined (unless you plan to specify a different StorageClass during configuration).proxy.replicated.com at install time and runtime (required to pull Dash Enterprise images) or if this is not possible, you must install using Dash Enterprise images that are hosted in a private container registry (A).Additional network considerations:
443. For app deployments over SSH, Dash Enterprise listens on port 22.D A machine from which to perform the installation. This machine has the following requirements:
kubectl installed and configured to access the Kubernetes cluster.skopeo (sudo apt-get install skopeo). Not required if installing using the Dash Enterprise image bundle, which comes with these packages.In addition to the above, you must also have the following ready before the installation.
E Permission to manage the Kubernetes cluster in an administrator capacity. Required for installing Dash Enterprise in the cluster.
F Credentials with push permission for the private container registry, if using.
G The Dash Enterprise image bundle, if using. Provided by Plotly via a secure link.
H Your Dash Enterprise license ID. Provided by Plotly.
I A fully qualified domain name (FQDN). This will act as the base domain to access the Dash Enterprise App Manager.
J The ability and permissions to add DNS entries in your organization’s service of choice. You can preview the required DNS entries, but note that you’ll only be able to create them after the installation.
K A wildcard or multi-domain TLS/SSL full certificate chain and unencrypted, 2048-bit private key. The full certificate chain must be a .pem file in the following format:
txt
-----BEGIN CERTIFICATE-----
<Your>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Your>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<Your>
-----END CERTIFICATE-----
(Unless you are using a self-signed certificate, in which case the certificate chain is a single certificate).
The root certificate can be issued by an external/globally-trusted CA or by a CA that is internal to your organization. If using a root certificate issued by an internal CA, you’ll need the root certificate (must be a .crt file) in addition to the full chain.
If you obtained your certificate chain as multiple files, you need to combine them into a single .pem file. You can do this with cat server.pem intermediate.pem trustedroot.pem > fullchain.pem, replacing the file names if yours are different. Using multiple certificates is not supported.
The full certificate chain and unencrypted private key will be used to terminate TLS/SSL.
In this step, you’ll define variables that will be used for the installation in a later step.
On the machine from which you’re performing the installation, use this command to create an install-env.sh file containing these variables. Replace and add values where applicable for your installation.
The first four variables are predefined by Plotly for a Dash Enterprise installation.
cat > install-env.sh << 'EOF'
#!/bin/bash
export CHART_VERSION=6.0.0
export RELEASE_CHANNEL=standard
export CHART_REGISTRY=oci://registry.replicated.com/dash-enterprise
export RELEASE_NAME=dash-enterprise
export LICENSE_ID=<license-id>
export EMAIL=<email> # email address associated with your Dash Enterprise license
export NAMESPACE=<your-namespace> # must be unique for the cluster
export HOSTNAME=<your-hostname>
export CERT_PATH=<your-TLS-certificate-path>
export KEY_PATH=<your-TLS-key-path>
# If planning to integrate Dash Enterprise with an identity provider (IdP) that uses a
# self-signed or internal CA signed certificate, define a certificate that will establish
# trust with the IdP server. The Common Name (Server Name) in the certificate must be
# set to the fully qualified domain name (FQDN) that Dash Enterprise's auth service,
# Keycloak, will use to reach the IdP server.
export CA_CERT=<your-internal-ca-certificate-path>
# AIRGAP CONFIGURATION
export PYTHON_PACKAGE_INDEX_URL=<python-package-index-url>
# Leave REGISTRY_PREFIX empty if the images do not need to be
# pushed to a specific subpath in the registry. Note that
# REGISTRY_PREFIX cannot start nor end with slashes but can
# contain them.
export REGISTRY=<your-registry>
export REGISTRY_PULL_SECRET=<your-registry-pull-secret>
export REGISTRY_PREFIX=""
EOF
If the Dash Enterprise images are already present in your private container registry, add
export SKIP_PUSH=1
to the command (before EOF). Note that SKIP_PUSH will disable image pushes regardless of its
value when it is set. If accidentally set, unset it with unset SKIP_PUSH.
Then apply the file contents to your environment:
source install-env.sh
In this step, you’ll create the namespace for Dash Enterprise in the cluster and define required secrets.
To set up the Dash Enterprise namespace:
Create the namespace:
sh
kubectl create namespace $NAMESPACE
Create a namespace-scoped Kubernetes secret for your TLS certificate:
sh
kubectl create secret tls de-tls \
--namespace=$NAMESPACE \
--cert=$CERT_PATH \
--key=$KEY_PATH
If you defined a CA_CERT, create the corresponding namespace-scoped Kubernetes secret:
sh
kubectl create secret generic keycloak-ca-secret \
--namespace=$NAMESPACE \
--from-literal=customer.crt.b64="$CA_CERT" \
--dry-run=client -o yaml | kubectl apply -f -
This step is only required if installing from images in a private container registry. Skip to Configuration if installing directly from the Helm chart registry.
In this step, you’ll review some Dash Enterprise default parameters and decide whether they are appropriate for your environment.
Good to know: You can continue to make configuration changes after Dash Enterprise is installed.
To apply changes to the defaults below, you’ll add the required flags to your helm install command in the following step. For now, make a note of which ones you’ll need for your desired configuration.
For an EKS cluster:
```txt
–set proxy.service.annotations.”service.beta.kubernetes.io/aws-load-balancer-type”=nlb \
–set proxy.service.annotations.”service.beta.kubernetes.io/aws-load-balancer-scheme”=internal \
–set proxy.service.annotations.”service.beta.kubernetes.io/aws-load-balancer-internal”=”true”
For an AKS cluster:
text
--set proxy.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"="true"
For a GKE Standard cluster:
txt
--set proxy.service.annotations."networking\.gke\.io/load-balancer-type"=Internal
Ingress: Dash Enterprise does not come with an Ingress nor an Ingress controller, but you can create an Ingress inside the Dash Enterprise namespace if you need one. Be sure to point it to the de-proxy service.
Note about Ingress controllers: Some Ingress controllers do not support TCP proxying. Using these Ingress controllers in the cluster means that app developers will be unable to deploy apps from their workstations over SSH unless additional configuration is performed on port 22.
By default, the service type for de-proxy is LoadBalancer. You can change it to ClusterIP or NodePort with the following flags:
For ClusterIP:
txt
--set proxy.service.type=ClusterIP
For NodePort:
txt
--set proxy.service.type=NodePort
Using a proxy: You can configure Dash Enterprise to use an HTTP/HTTPS proxy (address like http://my.proxy.url:port). Secure HTTP proxies (addresses like https://my.proxy.url:port) are not supported. The proxy must support websocket connections. To make Dash Enterprise aware of a proxy in your environment, you’ll need:
txt
--set global.env.httpProxy="<http>" \
--set global.env.httpsProxy="<https>" \
--set global.env.noProxy="<no>"
replacing the placeholder values with the appropriate proxy information.
Using a custom StorageClass: By default, the cluster’s default StorageClass is used for persistent volumes. To define a custom StorageClass for all of Dash Enterprise’s persistent volumes, you’ll need this flag (the custom StorageClass must exist on the cluster prior to installing Dash Enterprise):
txt
--set agents.persistence.storageClass=<storage-class-name>
where <storage-class-name> is the name of the StorageClass that you want to use.
App image storage: By default, the images created as a result of apps being deployed to Dash Enterprise are stored in a Distribution container registry within Dash Enterprise. You can configure Dash Enterprise to store these images in a private container registry that you maintain instead. Contact us for assistance.
To apply changes to the defaults below, you’ll need to override values in the Helm chart’s values.yaml file. Extract the values.yaml file if you haven’t already and create a copy such as values-custom.yaml. Make any changes in the custom values file only (you’ll pass it to the helm install command in the next step).
sudo at build time nor at runtime. To allow the use of sudo, modify your custom values file as follows:For builds:
txt
global:
...
agents:
...
build:
...
builder:
...
# -- Security context for build job containers, supports allowPrivilegeEscalation and readOnlyRootFilesystem
securityContext:
allowPrivilegeEscalation: true
...
For apps at runtime:
```txt
global:
…
worker:
…
app:
…
# – Allow privilege escalation for Dash apps
allowPrivilegeEscalation: true
…
```
For workspaces:
txt
global:
...
worker:
...
workspace:
...
# -- Allow privilege escalation for workspaces
allowPrivilegeEscalation: true
...
Sidecars: By default, Dash Enterprise makes use of sidecars in app and workspace pods in order to display their logs in the App Manager. If sidecars are not allowed in your environment, you can disable them as follows (no logs will appear in the App Manager):
txt
...
features:
...
# -- Enable sidecar logging for workspaces
deSidecarLoggingEnabled: false
Start with
sh
helm install $RELEASE_NAME \ $CHART_REGISTRY/$RELEASE_CHANNEL/dash-enterprise \
--version "$CHART_VERSION" \
--namespace $NAMESPACE \
--set global.hostname="$HOSTNAME"
If using a private container registry, pass the file that was generated during the registry preparation step by adding:
sh
--values values-private-registry.yaml \
If installing Dash Enterprise in an airgapped (internet-restricted cluster), add
sh
--set global.env.airgapEnabled=true \
--set replicated.isAirgap=true
If using a private Python package index, add
sh
--set global.env.pipExtraIndexUrl="$PYTHON_PACKAGE_INDEX_URL"
If you defined a CA_CERT in your install-env.sh file, add
sh
--set auth.keycloak.internalCaCertSecretName=keycloak-ca-secret
Dash Enterprise exposes the registry on node port 30100 by default. If this node port is already taken by another tenant on the cluster, add
sh
--set registry.internal.service.nodePort=<port>
replacing <port> with a node port that is unique for the cluster. The port must be within the 30000-32767 range (reference).
Add any additional flags for your desired configuration.
Finally, if your desired configuration involves using custom values, pass your custom values file:
sh
-f values-custom.yaml
changing the file name if your custom values file is named something else.
Run the assembled command.
Note: The TLS secret that you created is provided automatically (
--set global.tls.secretName="de-tls"is used internally).
sh
watch -- kubectl get pod -n $NAMESPACEand wait until the output shows all the pods in Running or Completed state.
For an AKS or GKE Standard cluster:
sh
kubectl get service -n $NAMESPACE de-proxy -ojsonpath='{.status.loadBalancer.ingress[0].ip}' && echo
For an EKS cluster:
sh
kubectl get service -n $NAMESPACE de-proxy -ojsonpath='{.status.loadBalancer.ingress[0].hostname}' && echo
| Name | Type | Value |
|---|---|---|
<base-domain> |
A Record | <load-balancer-ip> |
api-<base-domain> |
CNAME | <base-domain> |
auth-<base-domain> |
CNAME | <base-domain> |
where <load-balancer-ip> is the IP address that you retrieved in step 1.
Dash Enterprise uses Keycloak for identity and access management. During the installation, an initial Keycloak admin user was created to allow you to access the Keycloak Administration Console. As part of Keycloak security best practices, you’ll create a second Keycloak admin user. With this new Keycloak admin user, you’ll create the Dash Enterprise account that you’ll use to log in to https://<your-dash-enterprise-server>.
In this step, you’ll retrieve the password for the initial Keycloak admin user and use it to create a new admin user.
To create the new Keycloak admin user:
Retrieve the password for the initial Keycloak admin user (this displays the password in plain text):
sh
kubectl get secret keycloak-admin-password -n $NAMESPACE -o jsonpath='{.data.password}' | base64 -d && echo
Copy the password.
https://auth-<your-dash-enterprise-server><img>
A warning message is displayed that recommends you create a new admin user and delete the existing one. Important: Do not delete nor edit the initial Keycloak admin user. This user is managed by Dash Enterprise.
admin role:Use this user from now on when logging in to Keycloak.
You can rotate the password for this user in Keycloak by going back to the Keycloak (master) realm, editing the user, and changing the Password that is set. Note that managing this user is the only reason to go to the Keycloak (master) realm. All Dash Enterprise user management is done in a different realm.
In this step, you’ll log in to Keycloak using the newly created admin user and create a Dash Enterprise user that has admin permissions at the Dash Enterprise level. Dash Enterprise administrators have access to the Admin section of the Dash Enterprise App Manager, which you’ll use to configure system limits in a later step. Learn more about Dash Enterprise permissions.
To create your Dash Enterprise user:
Go to the realm responsible for Dash Enterprise users by selecting dash from the realm list in the top left corner.

Select Users > Add User.
admin role:dash admin”. Note that if you intend on deploying apps, you’ll also need the “dash licensed_user” role, and assigning this role consumes a license seat.You can now log in to https://<your-dash-enterprise-server> using the credentials for the newly created Dash Enterprise user. Dash Enterprise opens to the Portal. Go to the App Manager by selecting Apps > App Manager.